On Jan 11, 2017, at 12:05 PM, Staiger, Moritz (RRZE) <moritz.staiger@fau.de> wrote:
we are running freeradius 3.0.12 which is authenticating against an openldap server with EAP PEAP MSCHAPv2
OK...
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“.
With group membership and Packet-Src-IP-Address we want to authenticate users only if they try to connect from their *home POP*.
That's all easy enough to do.
What we have done:
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.
group { base_dn = "${..base_dn}" groupmembership_attribute = 'gidNumber' }
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
No, don't do that. Setting Auth-Type is wrong and unnecessary. FreeRADIUS will reject people who aren't authenticated.
#
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 }
That's the *outer* tunnel. Not the inner MS-CHAP. You don't need this here.
4. configured /freeradius/sites-enabled/inner-tunnel
authorize { ldap
authenticate { #Auth-Type LDAP { # ldap # }
You don't need to do this, either.
Within testing the config seems to do what we desire.
I'm not sure why
So my questions are:
Is this implementation correct for our needs?
If it works, perhaps.
Is there a more elegant way to implement it?
Yes.
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 ?)
FreeRADIUS v3 caches LDAP group membership. So it should already do the minimal LDAP queries.
(8) update { (8) &outer.session-state::Tunnel-Type += &reply:Tunnel-Type[*] -> VLAN (8) &outer.session-state::Tunnel-Medium-Type += &reply:Tunnel-Medium-Type[*] -> IEEE-802 (8) &outer.session-state::Tunnel-Private-Group-Id += &reply:Tunnel-Private-Group-Id[*] -> '1006' (8) &outer.session-state::MS-MPPE-Encryption-Policy += &reply:MS-MPPE-Encryption-Policy[*] -> Encryption-Allowed (8) &outer.session-state::MS-MPPE-Encryption-Types += &reply:MS-MPPE-Encryption-Types[*] -> RC4-40or128-bit-Allowed (8) &outer.session-state::MS-MPPE-Send-Key += &reply:MS-MPPE-Send-Key[*] -> 0xa850facd73abb0940518b842f0da51a0 (8) &outer.session-state::MS-MPPE-Recv-Key += &reply:MS-MPPE-Recv-Key[*] -> 0x171b0a416b36492d6c7389dd24ca27a2 (8) &outer.session-state::EAP-Message += &reply:EAP-Message[*] -> 0x03b30004 (8) &outer.session-state::Message-Authenticator += &reply:Message-Authenticator[*] -> 0x00000000000000000000000000000000 (8) &outer.session-state::User-Name += &reply:User-Name[*] -> 'Test-A'
Don't cache MS-MPPE-Send-Key, MS-MPPE-Recv-Key, EAP-Message, or Message-Authenticator. If you read the debug output, you'll see that they are deleted immediately afterwards.
From my readings of the log I think authentication is done twice against the LDAP? Do you have other hints or suggestions?
Put all of the policies into the "inner-tunnel" virtual server. Delete the "users" file entries. Don't set "Auth-Type = LDAP". Separate the authentication rules from the VLAN policies. in "inner-tunnel" virtual server, "authorize" section: if ((&LDAP-Group == "901") && (Packet-Src-IP-Address != 10.0.0.1)) { reject } ... do the same for other LDAP groups and Packet-Src-IP-Address ... in "inner-tunnel" virtual server, "post-auth" section: if (&LDAP-Group == "admin") { ... assign VLAN 10 ... } else if (&LDAP-Group == "Operators") { ... assign VLAN 20 ... } # else VLAN is assigned from radiusTunnelPrivateGroupId update { &outer.session-state::Tunnel-Type += &reply:Tunnel-Type[*] &outer.session-state::Tunnel-Medium-Type += &reply:Tunnel-Medium-Type[*] &outer.session-state::Tunnel-Private-Group-Id += &reply:Tunnel-Private-Group-Id[*] outer.session-state::User-Name += &reply:User-Name[*] } in "default" virtual server, "post-auth" section: ] update { &reply::Tunnel-Type += &session-state:Tunnel-Type[*] &reply::Tunnel-Medium-Type += &session-state:Tunnel-Medium-Type[*] &reply::Tunnel-Private-Group-Id += &session-state:Tunnel-Private-Group-Id[*] &reply::User-Name += &session-state:User-Name[*] } That should be pretty simple, and should work. Alan DeKok.