3.0.12 EAP-PEAP with OpenLDAP group membership and Packet-Src-IP-Address checking

[Alan DeKok]

On Jan 11, 2017, at 12:05 PM, Staiger, Moritz (RRZE) <moritz.staiger at 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.html
> 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.