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@lists.freeradius.org [mailto:freeradius-users-bounces+andy.franks=sath.nhs.uk@lists.freeradiu s.org] On Behalf Of Zenon Mousmoulas Sent: 06 August 2014 13:49 To: freeradius-users@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