WPA-EAP configuration with LDAP backend calls ldap module twice

[Mark van Reijn]

Thank you for your response. 

> On 20 Mar 2019, at 16:05, Alan DeKok <aland at deployingradius.com> wrote:
> 
>> FreeRADIUS Version 3.0.15
> 
>  You probably want to upgrade...
>> 

We do want to upgrade but are currently limited to the version supplied by the OS-vendor.

>> (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.

I will have to take a closer look at the reply, it is only necessary in the final packet as you mention. Thanks for spotting this. 

>> 
>> (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.

My apologies, I have that set to 'yes' in the eap configuration on our production server. This was somehow turned off on the test server where this log was generated, I now have enabled it again.

> 
>  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.

I have added this in the inner server configuration (I might have done a similar thing before) 
It's probably me, but it does not work unfortunately. 
In the debug log it clearly states:

(8) server eduroam-inner {
(8)   session-state: No cached attributes
(8)   # Executing section authorize from file /etc/raddb/sites-enabled/nivo-eduroam-inner
(8)     authorize {

so somehow the session-state is not persisted in the inner server (it is persisted in the outer server, where I cache attributes in the TLS session cache).

What am I doing wrong?

Cheers,

Mark

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3949 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20190320/dec46e68/attachment.bin>