Hi,
In future we want to enable VLAN assignment via LDAP so we want to use LDAP group membership comparison and combine it with Packet-Src-IP-Address checking.
Users from LDAP group „Admins“ should be assigned to VLAN 10 (management) Users from LDAP group „Operators“ should be assigned to VLAN 20 (operator) Users from other LDAP groups „Group-X“ should be assigned to userspecific VLAN which is represented in the LDAP attribute „radiusTunnelPrivateGroupId“.
okay. simple policy
1. according to Alan DeKoks suggestions here: http://lists.freeradius.org/pipermail/freeradius-users/2015-April/077171.htm... configured freeradius/mods-enabled/ldap „group“ section for group checking. In our case every LDAP user has an LDAP attribute 'gidNumber' which represents its group membership.
okay
2. configured /freeradius/users file
# in LDAP: Admins gidNumber = 111, Operators gidNumber = 222, Users in POP1 gidNumber = 901 DEFAULT LDAP-Group == "111", Auth-Type = LDAP DEFAULT LDAP-Group == "222", Auth-Type = LDAP DEFAULT Packet-Src-IP-Address == 10.0.0.1, LDAP-Group == „901“, Auth-Type = LDAP ... DEFAULT Packet-Src-IP-Address == 10.0.0.15, LDAP-Group == „915“, Auth-Type = LDAP DEFAULT Auth-Type := Reject
eugh. none of that old rubbish. just use a policy written in unlang in the post-auth section of your inner-tunnel. ensure that the return attributes are in the outer tunnel (so the NAS can read that info)
3. configured /freeradius/sites-enabled/default
no "ldap" in the "authorize" section so ldap gets commented here -> #ldap
be sure there's "Auth-Type LDAP" in the "authenticate" section so #Auth-Type LDAP { # ldap # } gets uncommented here -> Auth-Type LDAP { ldap }
no. you cannot trust the outer ID...anything can be in there dont enable anything apart from the EAP in the outer
4. configured /freeradius/sites-enabled/inner-tunnel
authorize { ldap
authenticate { #Auth-Type LDAP { # ldap # }
LDAP should be enabled for authentication in inner tunnel
Is there a more elegant way to implement it?
unlang
Is it possible to reduce the LDAP queries exept from sorting the POP listing in users file? (there seems to be a change in 3.0.13 ?)
there was another addition so handle the occasional 'updated' return...the default pre 3.0.13 has served most people ...i guess the reason you are seeing 2 requests is the authenticate and the authorise.....or its a side effect of the authenticate in outer tunnel (default) which might lead to another try - if you only auth in inner tunnel then things will be cleaner. alan