SV: FreeRadius LDAP group verification
    Stefan Sundberg 
    timewind at hotmail.com
       
    Thu Dec 15 14:08:24 CET 2016
    
    
  
Hi and thank you. The following code in the file policy.d/group_authorization (created) enabled my Group policy:
group_authorization {
                if (&LDAP-Group[*] == "cn=Radius,ou=Groups,dc=example,dc=se") {
                        ok
                }
                else {
                        reject
                }
}
Best Regards :)
Stefan Sundberg
________________________________
Från: Brian Candler <b.candler at pobox.com>
Skickat: den 15 december 2016 11:10
Till: Stefan Sundberg; freeradius-users at lists.freeradius.org
Ämne: Re: FreeRadius LDAP group verification
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.
    
    
More information about the Freeradius-Users
mailing list