- Freeradius-Users - lists.freeradius.org

RE: multiattribute testing in git 1411859
by Franks Andy (RLZ) IT Systems Engineer 11 Aug '14

11 Aug '14

Hi Arran, Is the test cases directory thing documented somewhere? I just echo this lot to a file under policy.conf and reference it from default, but I guess from your reply that's not what you're after..? my-regexp=(.*) my-policy { update control { Tmp-String-0 := "ssid=ABCDEF" Tmp-String-0 += "ssid=GHIJKL" } if (User-Name) { foreach control:Tmp-String-0 { if ("%{Foreach-Variable-0}" =~ /${policy.my-regexp}/) { update control { SSID := "%{1}" } } } } foreach control:Tmp-String-0 { if ("%{Foreach-Variable-0}" =~ /${policy.my-regexp}/) { update control { SSID := "%{1}" } } } -----Original Message----- From: freeradius-users-bounces+andy.franks=sath.nhs.uk(a)lists.freeradius.org [mailto:freeradius-users-bounces+andy.franks=sath.nhs.uk@lists.freeradiu s.org] On Behalf Of Arran Cudbard-Bell Sent: 08 August 2014 22:10 To: FreeRadius users mailing list Subject: Re: multiattribute testing in git 1411859 On 6 Aug 2014, at 17:02, Franks Andy (RLZ) IT Systems Engineer <Andy.Franks(a)sath.nhs.uk> wrote: > Thanks Arran for taking the time to reply in-depth. > I did send a test case over on skype? Needs to be in a format I can just drop in the test cases dir and see fail. -Arran Arran Cudbard-Bell <a.cudbardb(a)freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

2 1

multi-valued ldap-group attributes in rlm_cache
by Zenon Mousmoulas 08 Aug '14

08 Aug '14

Hi, I am trying to cache ldap group membership like this: modules { ldap ldap_xyz { [...] group { base_dn = "ou=Groups,dc=koko,dc=lala" filter = "(objectClass=groupOfNames)" membership_attribute = "memberOf" cacheable_name = "yes" } } cache cache_xyz { [...] update { &control:ldap_xyz-Ldap-Group += &control:ldap_xyz-Ldap-Group } } } [...] authorize { [...] update control { Cache-Read-Only := yes } cache_xyz if (notfound) { ldap_xyz cache_xyz } [...] } I can see rlm_ldap populate control:Ldap-Group: Sat Aug 2 12:12:55 2014 : Debug: Added control:ldap_xyz-Ldap-Group with value "abc" Sat Aug 2 12:12:55 2014 : Debug: Added control:ldap_xyz-Ldap-Group with value "def" [...] But it looks like rlm_cache only caches the first value: Sat Aug 2 12:12:56 2014 : Debug: (4) cache_xyz : Adding to cache entry: Sat Aug 2 12:12:56 2014 : Debug: (4) cache_xyz : control:ldap_xyz-Ldap-Group += &ldap_xyz-Ldap-Group -> 'abc' And the next cache lookup only shows the first value: Sat Aug 2 12:13:02 2014 : Debug: (9) cache_xyz : Merging cached control list: Sat Aug 2 12:13:02 2014 : Debug: (9) cache_xyz : ldap_xyz-Ldap-Group += 'abc' Is this supposed to work? I am using 3.0.4 rc1. Thanks, Z.

2 5

RE: multiattribute testing in git 1411859
by Franks Andy (RLZ) IT Systems Engineer 08 Aug '14

08 Aug '14

Thanks Arran for taking the time to reply in-depth. I did send a test case over on skype? -----Original Message----- From: freeradius-users-bounces+andy.franks=sath.nhs.uk(a)lists.freeradius.org [mailto:freeradius-users-bounces+andy.franks=sath.nhs.uk@lists.freeradiu s.org] On Behalf Of Arran Cudbard-Bell Sent: 06 August 2014 18:01 To: FreeRadius users mailing list Subject: Re: multiattribute testing in git 1411859 On 6 Aug 2014, at 12:37, Franks Andy (RLZ) IT Systems Engineer <Andy.Franks(a)sath.nhs.uk> wrote: > Ah, ok so it's just functionality built into the cache module then..? It's code in radius_map2vp which is shared by rlm_cache, rlm_ldap and the unlang update blocks. It's not supported by conditions *yet*. update request { foo += &control:bar[*] } Would copy all instances of control:bar as foo attributes, into the request. If foo and bar are different types, there's an attempt made to cast one to the other, which may fail. If they're the same time, new instances of foo would be created with all the values of bar. 10 internet points if you can guess what this does :) update request { foo += "%{control:bar[*]}" } > I'll consider foreach then, and do my tests another way perhaps. Means > a decent portion of unlang being rewritten. > Did you manage to reproduce the foreach and if statement issue I > sketched out on skype at all? If so, I can be sure that foreach will > be ok. No. I don't have the bandwidth currently to work on reproducing issues. If you can get it down to a test case (look in src/test/keywords for examples) then i'll have a go at fixing it. For unlang issues, it's really helpful in general if people can create test cases for issues, as it means we can add them to the suite to prevent regressions. I sit on the LuaJIT list as well, and that's pretty much how their entire bug reporting/fixing system works :). -Arran Arran Cudbard-Bell <a.cudbardb(a)freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

2 1

FreeRadius Client (MSCHAPv2)
by Levavi, Yariv 07 Aug '14

07 Aug '14

Hello, We are looking for a FreeRadius Client that is using MSCHAPv2 for our tests. Can't find a decent one over the net. May you please recommend on one? We prefer a windows (non-Java) client, but Linux will also do. Regards, Yariv Levavi SafeNet's Integration Team The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.

4 4

RE: multiattribute testing in git 1411859
by Franks Andy (RLZ) IT Systems Engineer 06 Aug '14

06 Aug '14

Ah, ok so it's just functionality built into the cache module then..? I'll consider foreach then, and do my tests another way perhaps. Means a decent portion of unlang being rewritten. Did you manage to reproduce the foreach and if statement issue I sketched out on skype at all? If so, I can be sure that foreach will be ok. Thanks Andy -----Original Message----- From: freeradius-users-bounces+andy.franks=sath.nhs.uk(a)lists.freeradius.org [mailto:freeradius-users-bounces+andy.franks=sath.nhs.uk@lists.freeradiu s.org] On Behalf Of Arran Cudbard-Bell Sent: 06 August 2014 17:00 To: FreeRadius users mailing list Subject: Re: multiattribute testing in git 1411859 On 6 Aug 2014, at 11:22, Franks Andy (RLZ) IT Systems Engineer <Andy.Franks(a)sath.nhs.uk> wrote: > Thanks Arran, > Can you confirm whether we should be able to do something like : > > If (&control:attribute[*] == "test") { With the control:attribute > being either just a multivalue attribute, or one from the cache? Not yet, i've been thinking about how to do that in a clean way... and I need it to for a project, so it's definitely high on my stack of stuff to write. For now, the above statement would hopefully produce an error on startup. For now just use foreach. -Arran Arran Cudbard-Bell <a.cudbardb(a)freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

2 1

RE: multiattribute testing in git 1411859
by Franks Andy (RLZ) IT Systems Engineer 06 Aug '14

06 Aug '14

Thanks Arran, Can you confirm whether we should be able to do something like : If (&control:attribute[*] == "test") { With the control:attribute being either just a multivalue attribute, or one from the cache? Thanks Andy -----Original Message----- From: freeradius-users-bounces+andy.franks=sath.nhs.uk(a)lists.freeradius.org [mailto:freeradius-users-bounces+andy.franks=sath.nhs.uk@lists.freeradiu s.org] On Behalf Of Arran Cudbard-Bell Sent: 06 August 2014 15:54 To: FreeRadius users mailing list Subject: Re: multiattribute testing in git 1411859 On 6 Aug 2014, at 10:00, Franks Andy (RLZ) IT Systems Engineer <Andy.Franks(a)sath.nhs.uk> wrote: > 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. Should be fixed. -Arran Arran Cudbard-Bell <a.cudbardb(a)freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

2 1

RE: multiattribute testing in git 1411859
by Franks Andy (RLZ) IT Systems Engineer 06 Aug '14

06 Aug '14

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(a)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(a)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

2 1

freeradius on freebsd Segmentation Fault error
by Paul Manyika 06 Aug '14

06 Aug '14

2 1

multiattribute testing in git 1411859
by Franks Andy (RLZ) IT Systems Engineer 06 Aug '14

06 Aug '14

Hi, 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'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'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. 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. 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 .. Maybe my testing is premature. Quite happy to keep testing if required! Thanks Andy

2 1

RE: radutmp
by Franks Andy (RLZ) IT Systems Engineer 06 Aug '14

06 Aug '14

Forgot to add to this - doing if (&control:Ldap-SpecificUTVid) { .. Fixes this, but loads of the stock files in policy.d also have this issue. Freeradius executable doesn't complain about using either if (attribute) or if (&attribute), so it's not obvious until you use radwho. I have changed a few, but there are quite a lot so I thought I'd confirm this first before changing them. Obviously if I'm pulling a new git then files may change and overwrite. Thanks Andy > Tue Aug 5 17:34:54 2014 : Error: if (control:Ldap-SpecificUTVid) { > > Tue Aug 5 17:34:54 2014 : Error: ^ Expected a module return code > > Have I missed something obvious? This always used to work ok. Probably needs an &control:Ldap-SpecificUTVid or the attribute hasn't been defined. -Arran Arran Cudbard-Bell <a.cudbardb(a)freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

1 0