Filter OpenLDAP users account upon Freeradius 3.0.10 NAS-Port-Id
Hi all, My Freeradius 3.0.10 setup currently accepts eap-mschapv2 requests by cheking credentials against LM/NT password checksums obtained from a LDAP. The only freeradius client is an IPSec server which forwards EAP protocol to the radius (strongswan 5.2.1 with eap-radius method) The LDAP module is configured to let the user connect when the diallupAccess is set to true. But it let any users connect to any network my VPN server is offering access to. What is the best method to filter users depending on which NAS-Port-Id they are using ? It will allow me to authorize several users to access any networks they need to access without puting any network configuration in the LDAP. Many thanks in advance for any help to improve this point of config. François Lacombe @InfosReseaux
On Dec 10, 2015, at 1:50 PM, François Lacombe <fl.infosreseaux@gmail.com> wrote:
My Freeradius 3.0.10 setup currently accepts eap-mschapv2 requests by cheking credentials against LM/NT password checksums obtained from a LDAP.
Ok... just to be clear, they're hashes, and not checksums. And the LM hashes have been deprecated (and broken) for a decade. The LDAP server probably stores just NT hashes.
The only freeradius client is an IPSec server which forwards EAP protocol to the radius (strongswan 5.2.1 with eap-radius method)
OK.
The LDAP module is configured to let the user connect when the diallupAccess is set to true. But it let any users connect to any network my VPN server is offering access to.
And... what does the debug output say? It will tell you *why* the user was allowed in.
What is the best method to filter users depending on which NAS-Port-Id they are using ?
You can check for the value of the NAS-Port-Id attribute. What do you want to do? Do you have an example?
It will allow me to authorize several users to access any networks they need to access without puting any network configuration in the LDAP.
Typically you control access by NAS IP address, not NAS Port-Id. As always, run the server in debug mode to see what the server is receiving. Then, write rules to match those attributes, and go from there. Alan DeKok.
Thank you Alan for your help Le 11 déc. 2015 1:37 AM, "Alan DeKok" <aland@deployingradius.com> a écrit :
The LDAP module is configured to let the user connect when the diallupAccess is set to true. But it let any users connect to any network my VPN server is offering access to.
And... what does the debug output say?
It works normally, no problem IMHO. Debug output from freeradius 3.0.10 : Fri Dec 11 20:05:09 2015 : Debug: (1) ldap: EXPAND (uid=%{%{Stripped-User-Name}:-%{User-Name}}) Fri Dec 11 20:05:09 2015 : Debug: (1) ldap: --> (uid=*my_login*) Fri Dec 11 20:05:09 2015 : Debug: (1) ldap: EXPAND TMPL LITERAL Fri Dec 11 20:05:09 2015 : Debug: (1) ldap: Performing search in "ou=users,... ldap root..." with filter "(uid=*my_login*)", scope "sub" Fri Dec 11 20:05:09 2015 : Debug: (1) ldap: Waiting for search result... Fri Dec 11 20:05:09 2015 : Debug: (1) ldap: User object found at DN "uid=*my_login,ou=users,... ldap root..." Fri Dec 11 20:05:09 2015 : Debug: (1) ldap: Processing user attributes Fri Dec 11 20:05:09 2015 : Debug: (1) ldap: control:Password-With-Header += '....' Fri Dec 11 20:05:09 2015 : Debug: (1) ldap: control:NT-Password := 0x.... Fri Dec 11 20:05:09 2015 : Debug: (1) ldap: control:LM-Password := 0x.... Fri Dec 11 20:05:09 2015 : Debug: (1) ldap: Attribute "radiusControlAttribute" not found in LDAP object Fri Dec 11 20:05:09 2015 : Debug: (1) ldap: Attribute "radiusRequestAttribute" not found in LDAP object Fri Dec 11 20:05:09 2015 : Debug: (1) ldap: Attribute "radiusReplyAttribute" not found in LDAP object Fri Dec 11 20:05:09 2015 : Debug: rlm_ldap (ldap): Released connection (1) Fri Dec 11 20:05:09 2015 : Debug: (1) modsingle[authorize]: returned from ldap (rlm_ldap) for request 1 Fri Dec 11 20:05:09 2015 : Debug: (1) [ldap] = updated Fri Dec 11 20:05:09 2015 : Debug: (1) modsingle[authorize]: calling eap (rlm_eap) for request 1 Fri Dec 11 20:05:09 2015 : Debug: (1) eap: Peer sent EAP Response (code 2) ID 1 length 67 Fri Dec 11 20:05:09 2015 : Debug: (1) eap: No EAP Start, assuming it's an on-going EAP conversation Fri Dec 11 20:05:09 2015 : Debug: (1) modsingle[authorize]: returned from eap (rlm_eap) for request 1 Fri Dec 11 20:05:09 2015 : Debug: (1) [eap] = updated Fri Dec 11 20:05:09 2015 : Debug: (1) modsingle[authorize]: calling pap (rlm_pap) for request 1 Fri Dec 11 20:05:09 2015 : Debug: (1) pap: Converted: Password-With-Header = '.....' -> Crypt-Password = '....' Fri Dec 11 20:05:09 2015 : Debug: (1) pap: Removing &control:Password-With-Header Fri Dec 11 20:05:09 2015 : Debug: (1) pap: Normalizing NT-Password from hex encoding, 32 bytes -> 16 bytes Fri Dec 11 20:05:09 2015 : Debug: (1) pap: Normalizing LM-Password from hex encoding, 32 bytes -> 16 bytes Fri Dec 11 20:05:09 2015 : WARNING: (1) pap: Auth-Type already set. Not setting to PAP Fri Dec 11 20:05:09 2015 : Debug: (1) modsingle[authorize]: returned from pap (rlm_pap) for request 1 Fri Dec 11 20:05:09 2015 : Debug: (1) [pap] = noop Fri Dec 11 20:05:09 2015 : Debug: (1) modsingle[authorize]: calling expiration (rlm_expiration) for request 1 Fri Dec 11 20:05:09 2015 : Debug: (1) modsingle[authorize]: returned from expiration (rlm_expiration) for request 1 Fri Dec 11 20:05:09 2015 : Debug: (1) [expiration] = noop Fri Dec 11 20:05:09 2015 : Debug: (1) modsingle[authorize]: calling logintime (rlm_logintime) for request 1 Fri Dec 11 20:05:09 2015 : Debug: (1) modsingle[authorize]: returned from logintime (rlm_logintime) for request 1 Fri Dec 11 20:05:09 2015 : Debug: (1) [logintime] = noop Fri Dec 11 20:05:09 2015 : Debug: (1) } # authorize = updated Fri Dec 11 20:05:09 2015 : Debug: (1) Found Auth-Type = EAP Fri Dec 11 20:05:09 2015 : Debug: (1) # Executing group from file /etc/freeradius/sites-enabled/mercure_def.ldap Fri Dec 11 20:05:09 2015 : Debug: (1) authenticate { Fri Dec 11 20:05:09 2015 : Debug: (1) modsingle[authenticate]: calling eap (rlm_eap) for request 1 Fri Dec 11 20:05:09 2015 : Debug: (1) eap: Expiring EAP session with state 0xab2a5c78ab2b464c Fri Dec 11 20:05:09 2015 : Debug: (1) eap: Finished EAP session with state 0xab2a5c78ab2b464c Fri Dec 11 20:05:09 2015 : Debug: (1) eap: Previous EAP request found for state 0xab2a5c78ab2b464c, released from the list Fri Dec 11 20:05:09 2015 : Debug: (1) eap: Peer sent packet with method EAP MSCHAPv2 (26) Fri Dec 11 20:05:09 2015 : Debug: (1) eap: Calling submodule eap_mschapv2 to process data Fri Dec 11 20:05:09 2015 : Debug: (1) eap_mschapv2: # Executing group from file /etc/freeradius/sites-enabled/mercure_def.ldap Fri Dec 11 20:05:09 2015 : Debug: (1) eap_mschapv2: Auth-Type MS-CHAP { Fri Dec 11 20:05:09 2015 : Debug: (1) eap_mschapv2: modsingle[authenticate]: calling mschap (rlm_mschap) for request 1 Fri Dec 11 20:05:09 2015 : Debug: (1) mschap: Found NT-Password Fri Dec 11 20:05:09 2015 : Debug: (1) mschap: Found LM-Password Fri Dec 11 20:05:09 2015 : Debug: (1) mschap: Creating challenge hash with username: *my_login* Fri Dec 11 20:05:09 2015 : Debug: (1) mschap: Client is using MS-CHAPv2 Fri Dec 11 20:05:09 2015 : Debug: (1) mschap: Adding MS-CHAPv2 MPPE keys Fri Dec 11 20:05:09 2015 : Debug: (1) modsingle[authenticate]: returned from mschap (rlm_mschap) for request 1 Fri Dec 11 20:05:09 2015 : Debug: (1) [mschap] = ok Fri Dec 11 20:05:09 2015 : Debug: (1) } # Auth-Type MS-CHAP = ok Fri Dec 11 20:05:09 2015 : Debug: (1) MSCHAP Success Fri Dec 11 20:05:09 2015 : Debug: (1) eap: Sending EAP Request (code 1) ID 2 length 51 Fri Dec 11 20:05:09 2015 : Debug: (1) eap: EAP session adding &reply:State = 0xab2a5c78aa28464c Fri Dec 11 20:05:09 2015 : Debug: (1) modsingle[authenticate]: returned from eap (rlm_eap) for request 1 Fri Dec 11 20:05:09 2015 : Debug: (1) [eap] = handled Fri Dec 11 20:05:09 2015 : Debug: (1) } # authenticate = handled Fri Dec 11 20:05:09 2015 : Debug: (1) Using Post-Auth-Type Challenge Fri Dec 11 20:05:09 2015 : Debug: (1) Post-Auth-Type sub-section not found. Ignoring. Fri Dec 11 20:05:09 2015 : Debug: (1) # Executing group from file /etc/freeradius/sites-enabled/mercure_def.ldap Fri Dec 11 20:05:09 2015 : Debug: (1) session-state: Nothing to cache Fri Dec 11 20:05:09 2015 : Debug: (1) Sent Access-Challenge Id 74 length 0 Fri Dec 11 20:05:09 2015 : Debug: (1) EAP-Message = 0x010200331a0301002e533d46343036424236353131394133333632313543433342323030384533444645414545454435393844 Fri Dec 11 20:05:09 2015 : Debug: (1) Message-Authenticator = 0x00000000000000000000000000000000 Fri Dec 11 20:05:09 2015 : Debug: (1) State = 0xab2a5c78aa28464c6d6710904a42a679 Fri Dec 11 20:05:09 2015 : Debug: (1) Finished request
What is the best method to filter users depending on which NAS-Port-Id they are using ?
You can check for the value of the NAS-Port-Id attribute.
What do you want to do? Do you have an example?
It will allow me to authorize several users to access any networks they need to access without puting any network configuration in the LDAP.
Typically you control access by NAS IP address, not NAS Port-Id.
My NAS has always the same IP when only the NAS Port-Id takes different values. I can only differentiate the networks my users try to reach by NAS Port-Id Furthermore, RFC2865 say that we shouldn't use NAS-Identifier to find the shared secret but we'd better deal with NAS-IP Address. Is this the same with NAS-Port Id? Should I take care of that ?
As always, run the server in debug mode to see what the server is receiving. Then, write rules to match those attributes, and go from there.
Ok, so I can write things like : user { filter = "(&(uid=%{%{Stripped-User-Name}:-%{User-Name}})(accessNetwork=%{request:NAS-Port-Id}))" } instead of user { filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})" } in my freeradius/mods-available/ldap file ? accessNetwork is a multi-valued attribute of a custom LDAP schema I wrote a few months ago. All the best François L.
On Dec 11, 2015, at 2:18 PM, François Lacombe <fl.infosreseaux@gmail.com> wrote:
\\ It works normally, no problem IMHO. Debug output from freeradius 3.0.10 :
Fri Dec 11 20:05:09 2015 : Debug: (1) ldap: EXPAND (uid=%{%{Stripped-User-Name}:-%{User-Name}})
Please use "radiusd -X" as recommend in the FAQ, "man" pages, web pages and on this list. Adding another "-x" to get the dates doesn't help. It makes the debug output harder to read in most cases. And the debug output doesn't show anything unusual. The user is in LDAP, and is allowed to log in.
My NAS has always the same IP when only the NAS Port-Id takes different values. I can only differentiate the networks my users try to reach by NAS Port-Id
I have no idea what that means. I don't know what equipment you're using, and I don't know your network topology. Please describe what you're talking about. Are your NASes behind a NAT? If so, say so.
Furthermore, RFC2865 say that we shouldn't use NAS-Identifier to find the shared secret but we'd better deal with NAS-IP Address.
No. The *source IP* of the packet is used to determine the shared secret. The NAS-IP-Address is informational, but has minimal meaning.
Is this the same with NAS-Port Id? Should I take care of that ?
Define what you mean "take care of that" ?
Ok, so I can write things like :
user {
filter = "(&(uid=%{%{Stripped-User-Name}:-%{User-Name}})(accessNetwork=%{request:NAS-Port-Id}))"
Yes that should work. Alan DeKok.
2015-12-11 20:52 GMT+01:00 Alan DeKok <aland@deployingradius.com>:
On Dec 11, 2015, at 2:18 PM, François Lacombe <fl.infosreseaux@gmail.com> wrote:
\\ It works normally, no problem IMHO. Debug output from freeradius 3.0.10 :
Fri Dec 11 20:05:09 2015 : Debug: (1) ldap: EXPAND (uid=%{%{Stripped-User-Name}:-%{User-Name}})
Please use "radiusd -X" as recommend in the FAQ, "man" pages, web pages and on this list. Adding another "-x" to get the dates doesn't help. It makes the debug output harder to read in most cases. Sorry for this misunderstanding of the mailing-list guidelines. I'll use -X only in any further posts.
And the debug output doesn't show anything unusual. The user is in LDAP, and is allowed to log in.
Indeed.
My NAS has always the same IP when only the NAS Port-Id takes different values. I can only differentiate the networks my users try to reach by NAS Port-Id
I have no idea what that means. I don't know what equipment you're using, and I don't know your network topology.
Please describe what you're talking about. Are your NASes behind a NAT? If so, say so.
In my first mail, it was mentionned that the NAS was Strongswan 5.2.1, but I didn't thought that exposing this part of the problem might be useful. Its configuration exposes many different connections capabilities distinguished by the public key used to authenticate the strongwan side. My roadwarrior users always use the same public IP address to reach it but can ask for different ids during the IKEv2 process (strongswan's ipsec.conf left|rightid parameters) To each id correspond a tunnel IP configuration and thus give access to different LAN depending of the L3 routing/firewall. 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. I can use it to filter my users account when requesting the LDAP as the piece of config I provide below show.
Furthermore, RFC2865 say that we shouldn't use NAS-Identifier to find the shared secret but we'd better deal with NAS-IP Address.
No. The *source IP* of the packet is used to determine the shared secret. The NAS-IP-Address is informational, but has minimal meaning.
Understood. This is a really useful detail. 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.
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.
Ok, so I can write things like :
user {
filter = "(&(uid=%{%{Stripped-User-Name}:-%{User-Name}})(accessNetwork=%{request:NAS-Port-Id}))"
Yes that should work.
Nice, thank you François L
On Dec 12, 2015, at 5:21 PM, François Lacombe <fl.infosreseaux@gmail.com> wrote:
My roadwarrior users always use the same public IP address to reach it but can ask for different ids during the IKEv2 process (strongswan's ipsec.conf left|rightid parameters) To each id correspond a tunnel IP configuration and thus give access to different LAN depending of the L3 routing/firewall.
OK.
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.
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.
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. Alan DeKok.
Hi Alan 2015-12-13 16:06 GMT+01:00 Alan DeKok <aland@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
On Dec 15, 2015, at 1:30 PM, François Lacombe <fl.infosreseaux@gmail.com> wrote:
I'm not sure OpenSWAN and StrongSwan are the same software.
They're based on the same FreeSWAN code base.
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.
Please read the page again. That's EAP. It's NOT sending RADIUS packets from the end users to FreeRADIUS. StrongSWAN is sending RADIUS packets to FreeRADIUS. StrongSWAN is the RADIUS client.
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.
No.
Nevertheless I agree that NAS-IP-Address should always be the IP of strongswan server instead of the users' one.
Yes. That's what the RFCs say the NAS-IP-Address should be.
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 ?
Yes. LDAP is just a database.
In this particular case, Freeradius would better to reject the request in the Authorize section, wouldn't it ?
Not for EAP. And the server is NOT set up to automatically reject users who aren't found in the database. *You* can configure that, but it's not the default. This is because some people have users in multiple databases. And they want the server to try them all, instead of just rejecting a user who isn't found in the first database. Your use-case is not everyone's use-case. Alan DeKok.
On Tue, Dec 15, 2015 at 01:36:48PM -0500, Alan DeKok wrote:
On Dec 15, 2015, at 1:30 PM, François Lacombe <fl.infosreseaux@gmail.com> wrote:
Strongswan only redirects EAP packets to the radius. The EAP packets come directly from users.
StrongSWAN is sending RADIUS packets to FreeRADIUS. StrongSWAN is the RADIUS client.
Nevertheless I agree that NAS-IP-Address should always be the IP of strongswan server instead of the users' one.
Yes. That's what the RFCs say the NAS-IP-Address should be.
In my experience setting up strongSwan and FreeRADIUS recently, strongSwan behaved correctly with regard to RADIUS. (Though in the end I used IKEv2 which doesn't do EAP, so I just get RADIUS accounting.) Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
2015-12-15 19:36 GMT+01:00 Alan DeKok <aland@deployingradius.com>:
On Dec 15, 2015, at 1:30 PM, François Lacombe <fl.infosreseaux@gmail.com> wrote:
I'm not sure OpenSWAN and StrongSwan are the same software.
They're based on the same FreeSWAN code base.
Ok
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.
Please read the page again. That's EAP. It's NOT sending RADIUS packets from the end users to FreeRADIUS.
StrongSWAN is sending RADIUS packets to FreeRADIUS. StrongSWAN is the RADIUS client.
Ok I wasn't making the right distinction. Thank you for this information.
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 ?
Yes. LDAP is just a database.
In this particular case, Freeradius would better to reject the request in the Authorize section, wouldn't it ?
Not for EAP.
And the server is NOT set up to automatically reject users who aren't found in the database. *You* can configure that, but it's not the default. This is because some people have users in multiple databases. And they want the server to try them all, instead of just rejecting a user who isn't found in the first database.
Ok. Obviously I won't ask to change things, I was only interested to know if all was normal. As you suggest it, how can I prevent freeradius to go in authenticate section when LDAP return no user record ? All the best François L.
On Dec 16, 2015, at 6:34 PM, François Lacombe <fl.infosreseaux@gmail.com> wrote:
As you suggest it, how can I prevent freeradius to go in authenticate section when LDAP return no user record ?
For EAP, you can't. EAP requires that the server return an EAP failure at the appropriate stage. The EAP protocol is designed to work a certain way. Forcing it to behave in a different way means that nothing good will happen. Alan DeKok.
Hi Alan, 2015-12-17 1:46 GMT+01:00 Alan DeKok <aland@deployingradius.com>:
On Dec 16, 2015, at 6:34 PM, François Lacombe <fl.infosreseaux@gmail.com> wrote:
As you suggest it, how can I prevent freeradius to go in authenticate section when LDAP return no user record ?
For EAP, you can't. EAP requires that the server return an EAP failure at the appropriate stage.
The EAP protocol is designed to work a certain way. Forcing it to behave in a different way means that nothing good will happen.
Is this really an EAP matter ? Freeradius won't go in authenticate section when the access_attribute is set to false in the LDAP user account with access_positive = yes in ldap module conf. Because the account is locked out. (0) ldap: User object found at DN "uid=*my_login*,ou=users,..." (0) ldap: "dialupAccess" attribute exists but is set to 'false' - user locked out rlm_ldap (ldap): Released connection (0) rlm_ldap (ldap): Need 5 more connections to reach 10 spares rlm_ldap (ldap): Opening additional connection (5), 1 of 27 pending slots used rlm_ldap (ldap): Connecting to ldap rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Bind successful (0) [ldap] = userlock (0) } # authorize = userlock (0) Invalid user: [*my_login*/<no User-Password attribute>] (from client STRONGSWAN) (0) Using Post-Auth-Type Reject (0) # Executing group from file /etc/freeradius/sites-enabled/mercure_def.ldap (0) Post-Auth-Type REJECT { (0) attr_filter.access_reject: EXPAND %{User-Name} (0) attr_filter.access_reject: --> *my_login* (0) attr_filter.access_reject: Matched entry DEFAULT at line 11 (0) [attr_filter.access_reject] = updated (0) eap: Request was previously rejected, inserting EAP-Failure (0) eap: Sending EAP Failure (code 4) ID 0 length 4 (0) [eap] = updated (0) policy remove_reply_message_if_eap { (0) if (&reply:EAP-Message && &reply:Reply-Message) { (0) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (0) else { (0) [noop] = noop (0) } # else = noop (0) } # policy remove_reply_message_if_eap = noop (0) } # Post-Auth-Type REJECT = updated (0) Delaying response for 1.000000 seconds It would be great to reject the request the same way when no user is found in the ldap. François L.
On Dec 19, 2015, at 7:53 AM, François Lacombe <fl.infosreseaux@gmail.com> wrote:
2015-12-17 1:46 GMT+01:00 Alan DeKok <aland@deployingradius.com>:
On Dec 16, 2015, at 6:34 PM, François Lacombe <fl.infosreseaux@gmail.com> wrote:
As you suggest it, how can I prevent freeradius to go in authenticate section when LDAP return no user record ?
For EAP, you can't. EAP requires that the server return an EAP failure at the appropriate stage.
The EAP protocol is designed to work a certain way. Forcing it to behave in a different way means that nothing good will happen.
Is this really an EAP matter ?
Yes. See where I said "the EAP protocol is designed to work a certain way".
Freeradius won't go in authenticate section when the access_attribute is set to false in the LDAP user account with access_positive = yes in ldap module conf. Because the account is locked out.
Sure. But bailing early on an EAP authentication *might* work. i.e. it won't work by design.
It would be great to reject the request the same way when no user is found in the ldap.
See where I said "people other than you use FreeRADIUS". Your needs are *not* everyone else's needs. If you want it to bail early when no user is found in LDAP, this is trivial. And documented. See "man unlang". ldap if (notfound) { reject } This can cause problems for some EAP clients. But it's your network. If you want to violate the protocols and break things, it's up to you. Alan DeKok.
participants (3)
-
Alan DeKok -
François Lacombe -
Matthew Newton