On 14/12/2016 22:11, Stefan Sundberg wrote:
To guard againt this I have worked to implement LDAP Group checking in FreeRadius 3 and this seems not to to be working. Even if I mess up the filter settings under the ”Group” section in /usr/local/etc/raddb/mods-enabled/ldap, FreeRadius gladly accepts the user as long as the user/password is OK. The Group section does not seem to affect the process at all.
Correct. You'll need to create some policy to do this. e.g. # in the "default" server authorize { ... eap { ok = return updated = return } # these are for when you are handling non-EAP RADIUS requests ldap group_authorization # In the "inner-tunnel" server: authorize { ... eap { ok = return } ldap group_authorization # in policy.d/group_authorization: group_authorization { if (&Huntgroup-Name == "wifi") { if (&LDAP-Group[*] == "cn=staff,cn=groups,cn=accounts,dc=example,dc=se") { ok } else { update reply { &Reply-Message := "Not authorized for wifi" } reject } } elsif (&Huntgroup-Name == "vpn") { ... etc } } That's just an example. Write it to suit your environment. Beware that LDAP-Group is a dynamically generated attribute. It won't cause an LDAP group membership query to be done until the comparison operator is invoked. Each time you do a test against LDAP-Group, a new query is done. Also, it doesn't work unless you put '&' in front of it. However, if you set either cacheable_dn=yes or cacheable_name=yes, the LDAP group membership query is done up-front and the results put into a real attribute (either the group dn or the group name respectively). You can then test this attribute multiple times without generating any more LDAP queries. Running with -X will hopefully make this clear. Regards, Brian.