WPA-EAP configuration with LDAP backend calls ldap module twice

[Alan DeKok]

On Mar 20, 2019, at 8:11 AM, Mark van Reijn via Freeradius-Users <freeradius-users at lists.freeradius.org> wrote:
> 
> We have an 'eduroam' freeradius setup with an LDAP backend, including profiles etc from LDAP. 
> In part thanks to key information found on this list, the setup works and WiFi authentication works. Yeah!

  That's good.

> However one thing has been bugging me and I cannot seem to fix it: 
> 
> * during the whole EAP/PEAP negotiation, radiusd performs the exact same LDAP calls twice. 
> 
> This occurs in step 7 and step 8 of the negotiation process, as can be seen in the debug output below: rlm_ldap performs the exact same lookups and searches in both steps.

  Because for the most part, each packet is processed in isolation.  The policies need to be carefully built so that they don't do unnecessary work.

> How can I prevent this from happening? The LDAP servers are fast, but this means an unnecessary doubling of the load radiusd places on them, and we have many hundreds of thousands of authentications per day. 

  Change the policy. :)

> FreeRADIUS Version 3.0.15

  You probably want to upgrade...
> 
> (7) eap_peap: Sending tunneled request to eduroam-inner
> (7) eap_peap:   EAP-Message = 0x0207004e1a0207004931dbc2433d9ded0530d4e0d99bb7319cc10000000000000000023df6c38ea64f8069dc29233129b9bba71271cc1821e701007261646975732d74657374406e69766f2e696d

  There are usually multiple packets being exchanged in the inner tunnel...

> (7) ldap: Performing search in "cn=default,ou=profiles,ou=radius,o=config" with filter "(objectclass=nivoRadiusProfile)", scope "base"
> (7) ldap: Waiting for search result...
> (7) ldap: Processing profile attributes
> (7) ldap: Tunnel-Medium-Type := IEEE-802
> (7) ldap: Tunnel-Private-Group-Id := 100
> (7) ldap: Tunnel-Type := VLAN
> (7) ldap: Processing user attributes

  These are attributes which should go into the *final* Access-Accept, and not in any intermediate challenge packet.
> 
> (7) Virtual server sending reply
> (7)   Tunnel-Medium-Type := IEEE-802
> (7)   Tunnel-Private-Group-Id := "100"
> (7)   Tunnel-Type := VLAN
> (7)   EAP-Message = 0x010800331a0307002e533d46364144364644453838443438353230413045393130313737313034313731423536373841383345
> (7)   Message-Authenticator = 0x00000000000000000000000000000000
> (7)   State = 0xfb1af5c9fa12ef35157513a9c717c55d
> (7) eap_peap: Got tunneled reply code 11

  Which is a challenge packet.
> 
> (9) Sent Access-Accept Id 9 from 127.0.0.1:1812 to 127.0.0.1:45195 length 0
> (9)   MS-MPPE-Recv-Key = 0x23263892d14c397f30d373067ad29f8c673a19bd0fa42a3e3b74f89cf3fa1f58
> (9)   MS-MPPE-Send-Key = 0x199553d51fbc32a32a4fcd3edec9f0f0a59836cca6798cd552a9baae611e7899
> (9)   EAP-Message = 0x03090004
> (9)   Message-Authenticator = 0x00000000000000000000000000000000

  And the final Access-Accept doesn't contain any VLAN information.  Is this what you want?

  For simplicity, you might set "use_tunneled_reply", which gets you the VLAN information in the final Access-Accept.

  The short fix is something like this, in the inner tunnel:


	if (!session-state:Tunnel-Type ) {
		ldap
		update session-state {
			Tunnel-Type := &reply:Tunnel-Type
		}
	}

  That will make it run "ldap" only once.

  Alan DeKok.