multiattribute testing in git 1411859

[Franks Andy (RLZ) IT Systems Engineer]

Thanks Zenon.
  Glad you've been able to confirm the cache behaviour.

>As per mods-available/ldap: [cache_attribute] overrides the normal
cache 
>attribute (<inst>-LDAP-Group) and creates a custom attribute. It
doesn't 
>affect the behavior you noted previously.

True, just looking for an acceptable way, either via ldap caching or
manual collection via ldap of attributes or anything really to populate
multivalued attributes and check them all without multiple single
instance (i.e. ldap1-ldap-group) lookups. It's slow and if that ldap
server is down, obviously doesn't work. Arran says he'll have a look.
Thanks
Andy

-----Original Message-----
From:
freeradius-users-bounces+andy.franks=sath.nhs.uk at lists.freeradius.org
[mailto:freeradius-users-bounces+andy.franks=sath.nhs.uk at lists.freeradiu
s.org] On Behalf Of Zenon Mousmoulas
Sent: 06 August 2014 13:49
To: freeradius-users at lists.freeradius.org
Subject: Re: multiattribute testing in git 1411859

On 2014-08-06 14:21, Franks Andy (RLZ) IT Systems Engineer wrote:
>  I saw the thread "multi-valued ldap-group attributes in rlm_cache"
> and figured that FR has been sorted to have multivalued attribute
> lookups in it now.
> 
> I may be completely wrong but thought I'd test it anyway.

I just had a chance to test it and I was going to follow up in the other

thread.

> I've got a simple case where I look up groups in ldap (AD 2008)
> 
> mods-enabled/ldap
> 
> [..]
> 
> update {
> 
>  control:Ldap-MemberOf += 'memberOf'
> 
> }
> 
> .. and then a policy which takes the first value before the comma from
> the ldap group set that comes back:
> 
> ldap-memberof-filter-regexp="^CN=([^,]*)"
> 
>  ldap-memberof-filter {
> 
>  update control {
> 
>  Tmp-String-0 !* ANY
> 
>  }
> 
>  foreach control:Ldap-MemberOf {
> 
>  if ("%{Foreach-Variable-0}" =~
> /${policy.ldap-memberof-filter-regexp}/) {
> 
>  update control {
> 
>  Tmp-String-0 += "%{1}"
> 
>  }
> 
>  }
> 
>  }
> 
>  update control {
> 
>  Ldap-MemberOf !* ANY
> 
>  }
> 
>  foreach control:Tmp-String-0 {
> 
>  update control {
> 
>  Ldap-MemberOf += "%{Foreach-Variable-0}"
> 
>  }
> 
>  }
> 
>  update control {
> 
>  Tmp-String-0 !* ANY
> 
>  }
> 
>  }
> 
> .. this works ok, and the "stripped" group name is processed and
> listed back to the original attribute name.

I believe freeradius can do this without unlang; see the group section 
in mods-available/ldap and the partial config posted in the other 
thread.

> I'd then expect to be able to add it to the cache as per Arran's
> suggestion from the thread where he says:
> 
>>> update {
> 
>>> control:ldap_xyz-Ldap-Group += &ldap_xyz-Ldap-Group[*] }
> 
>>> So now, essentially:
> 
>>> &ldap_xyz-Ldap-Group[0] and &ldap_xyz-Ldap-Group
> 
>>> are synonymous in terms of update blocks, not matter what the
> operator is.
> 
> So I do:
> 
> update {
> 
>  control:Ldap-MemberOf += &control:Ldap-MemberOf[*]
> 
> }
> 
> .. but it either stops the server output when it's populating the
> cache - no segfault, just stops on that line and needs ctrl-c.
> 
> Or it goes into a loop:
> 
> (1) cache : Ldap-MemberOf += 'SSID_SaTH_Guest-Virgin-PRH'
> 
> (1) cache : Ldap-MemberOf += 'SSID_SaTH_Guest-Virgin-PRH'
> 
> (1) cache : Ldap-MemberOf += 'SSID_SaTH_Guest-Virgin-PRH'
> 
> (1) cache : Ldap-MemberOf += 'SSID_SaTH_Guest-Virgin-PRH'
> 
> (1) cache : Ldap-MemberOf += 'SSID_SaTH_Guest-Virgin-PRH'
> 
> .. and also needs ctrl-c.

I can confirm that freeradius hangs at this point, either with 
Ldap-Group or with any other multi-valued attribute. However I don't see

any loop behavior.


> Also,
> 
> If I didn't fill the cache and had a section that said something like
> 
> If (&control:Ldap-MemberOf [*] == "something") {
> 
> ..
> 
> Should it pick up all instances now in the check? It only seems to act
> on the first one still. I also tried "%{control:Ldap-MemberOf[*]", but
> that does the same.

There was a discussion about such syntax in another thread, but I'm not 
sure how it should work after all.

> Again maybe my misinterpretation.
> 
> I also briefly tried the ldap cache enabling and shared load balance
> redundant way of checking each ldap server (cache_attribute) but it
> only seems to pick up the first attribute still:
> 
> Mods-enabled/ldap
> 
> [..]
> 
> Ldap ldap1 {
> 
>  Group {
> 
>  cacheable_name = yes
> 
>  cache_attribute = "Cached-Ldap-Group"
> 
> [..]
> 
> (1) ldap1 : Added control:Cached-Ldap-Group with value
> "SSID_SaTH_Guest-Virgin-PRH"
> 
> (1) ldap1 : Added control:Cached-Ldap-Group with value "SSID_RSH_WiFi"
> 
> 
> (1) if (&control:Cached-Ldap-Group[*] == "SSID_RSH_WiFi") -> FALSE
> 
> ..
> 
> (1) if (&control:Cached-Ldap-Group[*] == "SSID_SaTH_Guest-Virgin-PRH")
> -> TRUE

As per mods-available/ldap: [cache_attribute] overrides the normal cache

attribute (<inst>-LDAP-Group) and creates a custom attribute. It doesn't

affect the behavior you noted previously.

Regards,
Z.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html