SV: FreeRadius LDAP group verification

15 Dec 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@pobox.com>
Skickat: den 15 december 2016 11:10
Till: Stefan Sundberg; freeradius-users@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.