FreeRadius LDAP group verification

[Brian Candler]

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.