Filter OpenLDAP users account upon Freeradius 3.0.10 NAS-Port-Id

[François Lacombe]

Hi Alan

2015-12-13 16:06 GMT+01:00 Alan DeKok <aland at deployingradius.com>:
>> The current question, and this is where freeradius+ldap are useful, is
>> to know if each user is allowed to access to a given network area.
>> Strongswan informs the radius of which connection configuration the
>> user is asking for in the NAS-Port-Id.
>
>   That's good to know.  It would have been helpful to say that at the start.  Otherwise it's hard to tell what you're really doing.

Ok, sorry to have hidden it to the list.

>> In my situation, all users are roadwarriors, may use any public IP
>> they can depending of their location and it can't be part of any
>> stable conf.
>
>   Those people do not send RADIUS packets.  The OpenSWAN system sends RADIUS packets.  Therefore, the NAS-IP-Address *should* always be the IP of the OpenSWAN system.
I'm not sure OpenSWAN and StrongSwan are the same software.

As explained in the first lines of this article :
https://wiki.strongswan.org/projects/strongswan/wiki/EAPRAdius
Strongswan only redirects EAP packets to the radius. The EAP packets
come directly from users.
I don't know exactly what 'redirect' means here. Strongswan may modify
on the fly some fields to let Freeradius imagine strongswan actually
has sent radius packets.

Nevertheless I agree that NAS-IP-Address should always be the IP of
strongswan server instead of the users' one.


>>>> Is this the same with NAS-Port Id?
>>>> Should I take care of that ?
>>>
>>>  Define what you mean "take care of that" ?
>>
>> To conform to the RFC2865 guidelines.
>
>   I still have no idea what that means.  Perhaps you could explain in detail.

Let's forget this :)


One extra question if you don't mind.

I've changed the filter and now the RADIUS only authorize users with
networkAccess corresponding to NAS-Port-Id. It's ok.
If not, LDAP isn't returning any result and Freeradius still go in the
authenticate section instead of rejecting directly the request in the
Authorize section. Is this correct ?

This log shows a request with a user which actually doesn't have
networkAccess attribute with a nasPortId1 value in the LDAP.

(5) ldap: EXPAND
(&(uid=%{%{Stripped-User-Name}:-%{User-Name}})(stcDiallUpNetworkAccess=%{request:NAS-Port-Id}))
(5) ldap:    --> (&(uid=*my_login*)(networkAccess=nasPortId1))
(5) ldap: Performing search in "ou=users,..." with filter
"(&(uid=*my_login*)(networkAccess=nasPortId1))", scope "sub"
(5) ldap: Waiting for search result...
(5) ldap: Search returned no results
rlm_ldap (ldap): Released connection (7)
(5)     [ldap] = notfound
(5) eap: Peer sent EAP Response (code 2) ID 1 length 67
(5) eap: No EAP Start, assuming it's an on-going EAP conversation
(5)     [eap] = updated
(5) pap: WARNING: No "known good" password found for the user.  Not
setting Auth-Type
(5) pap: WARNING: Authentication will fail unless a "known good"
password is available
(5)     [pap] = noop
(5)     [expiration] = noop
(5)     [logintime] = noop
(5)   } # authorize = updated
(5) Found Auth-Type = EAP
(5) # Executing group from file /etc/freeradius/sites-enabled/mercure_def.ldap
(5)   authenticate {
(5) eap: Expiring EAP session with state 0xde5bb728de5aad6c
(5) eap: Finished EAP session with state 0xde5bb728de5aad6c
(5) eap: Previous EAP request found for state 0xde5bb728de5aad6c,
released from the list
(5) eap: Peer sent packet with method EAP MSCHAPv2 (26)
(5) eap: Calling submodule eap_mschapv2 to process data
(5) eap_mschapv2: # Executing group from file
/etc/freeradius/sites-enabled/mercure_def.ldap
(5) eap_mschapv2:   Auth-Type MS-CHAP {
(5) mschap: WARNING: No Cleartext-Password configured.  Cannot create
NT-Password
(5) mschap: WARNING: No Cleartext-Password configured.  Cannot create
LM-Password
(5) mschap: Creating challenge hash with username: l4c0mb5f
(5) mschap: Client is using MS-CHAPv2
(5) mschap: ERROR: FAILED: No NT/LM-Password.  Cannot perform authentication
(5) mschap: ERROR: MS-CHAP2-Response is incorrect

In this particular case, Freeradius would better to reject the request
in the Authorize section, wouldn't it ?


All the best

François L