multiattribute testing in git 1411859

[Zenon Mousmoulas]

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.