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.