WPA2 Client Authentication using Radius and remote LDAP server
Hello Guys, I have been trying to set up Freeradius to remotely query an LDAP server when it gets authentication requests from a Wireless LAN Controller. I have been able to test that the Freeradius Server can communicate with the LDAP Server by using a Radtest tool (I get the access-accept reply) but when I try to query the remote LDAP server with requests from the Wireless LAN controller I get the following response: [ldap] No default NMAS login sequence[ldap] looking for check items in directory...[ldap] looking for reply items in directory ...WARNING: No ''known good'' password was found in LDAP. Are you sure that the user has been configured properly? Not sure if its the EAP section of the request that has issues. Your assistance would be highly appreciated. Muyiwa
On Sep 18, 2018, at 10:58 AM, daada muyiwa via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I have been trying to set up Freeradius to remotely query an LDAP server when it gets authentication requests from a Wireless LAN Controller.
Is it an actual LDAP server? Or is it Active Directory?
I have been able to test that the Freeradius Server can communicate with the LDAP Server by using a Radtest tool (I get the access-accept reply) but when I try to query the remote LDAP server with requests from the Wireless LAN controller I get the following response: [ldap] No default NMAS login sequence[ldap] looking for check items in directory...[ldap] looking for reply items in directory ...WARNING: No ''known good'' password was found in LDAP. Are you sure that the user has been configured properly?
Yes... you should read the debug output to see what else is going on.
Not sure if its the EAP section of the request that has issues.
The LDAP server is configured to not return the "known good" password to FreeRADIUS. And, you've configured FreeRADIUS to use "ldap" for authentication. Don't do that. LDAP is a database. It doesn't implement EAP. FreeRADIUS is an authentication server. It implements EAP. Allow FreeRADIUS to read the "known good" password from LDAP, and it will Just Work. Alan DeKok.
Is it an actual LDAP server? Or is it Active Directory? ''Active directory''
Allow FreeRADIUS to read the "known good" password from LDAP, and it will Just Work.
How do I make Freeradius decrypt the EAP request and query the AD with the clear text password in order to authenticate a user. Muyiwa On Tuesday, September 18, 2018, 4:13:12 PM GMT+1, Alan DeKok <aland@deployingradius.com> wrote: On Sep 18, 2018, at 10:58 AM, daada muyiwa via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I have been trying to set up Freeradius to remotely query an LDAP server when it gets authentication requests from a Wireless LAN Controller.
Is it an actual LDAP server? Or is it Active Directory?
I have been able to test that the Freeradius Server can communicate with the LDAP Server by using a Radtest tool (I get the access-accept reply) but when I try to query the remote LDAP server with requests from the Wireless LAN controller I get the following response: [ldap] No default NMAS login sequence[ldap] looking for check items in directory...[ldap] looking for reply items in directory ...WARNING: No ''known good'' password was found in LDAP. Are you sure that the user has been configured properly?
Yes... you should read the debug output to see what else is going on.
Not sure if its the EAP section of the request that has issues.
The LDAP server is configured to not return the "known good" password to FreeRADIUS. And, you've configured FreeRADIUS to use "ldap" for authentication. Don't do that. LDAP is a database. It doesn't implement EAP. FreeRADIUS is an authentication server. It implements EAP. Allow FreeRADIUS to read the "known good" password from LDAP, and it will Just Work. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Sep 19, 2018, at 5:04 AM, daada muyiwa via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Is it an actual LDAP server? Or is it Active Directory? ''Active directory''
Then it's not a real LDAP server. It's close. but not quite a real LDAP server.
Allow FreeRADIUS to read the "known good" password from LDAP, and it will Just Work.
How do I make Freeradius decrypt the EAP request and query the AD with the clear text password in order to authenticate a user.
You don't. It's impossible. You need to follow the Active Directory configuration guide: http://deployingradius.com/documents/configuration/active_directory.html Alan DeKok.
EAP comes in many forms but I imagine you are using MSCHAP which is a hash of the real password. Both sides (server and client) compare their hashes for authentication so the plain-text password is never transferred across the network. The password stored in active directory is also hashed. MSCHAP is similar in hashing principle to NTLM so the hashes can be compared between server and AD. MSCHAP is massively flawed though and passwords can be worked out in 24hrs no matter the size or complexity, and LDAP does not encrypt the data when set to use EAP-MSCHAP. You could try PEAP or TTLS but only Windows natively supports PEAP, leaving OSX with only MSCHAP and neither with TTLS. The better option is to use client certificate authentication.
On 19 Sep 2018, at 18:41, Alan DeKok <aland@deployingradius.com> wrote:
On Sep 19, 2018, at 5:04 AM, daada muyiwa via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Is it an actual LDAP server? Or is it Active Directory? ''Active directory''
Then it's not a real LDAP server. It's close. but not quite a real LDAP server.
Allow FreeRADIUS to read the "known good" password from LDAP, and it will Just Work.
How do I make Freeradius decrypt the EAP request and query the AD with the clear text password in order to authenticate a user.
You don't. It's impossible. You need to follow the Active Directory configuration guide:
http://deployingradius.com/documents/configuration/active_directory.html
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Sep 19, 2018, at 5:00 PM, Christian Salway via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
You could try PEAP or TTLS but only Windows natively supports PEAP, leaving OSX with only MSCHAP and neither with TTLS. The better option is to use client certificate authentication.
Windows 10 supports TTLS. OSX has supported TTLS for years. Alan DeKok.
Yes, sorry, it’s not supported with VPN connections. With WiFi, both PEAP and TTLS are supported on OSX. Apologies for the confusion.
On 20 Sep 2018, at 09:28, Alan DeKok <aland@deployingradius.com> wrote:
On Sep 19, 2018, at 5:00 PM, Christian Salway via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote: You could try PEAP or TTLS but only Windows natively supports PEAP, leaving OSX with only MSCHAP and neither with TTLS. The better option is to use client certificate authentication.
Windows 10 supports TTLS. OSX has supported TTLS for years.
Alan DeKok.
Hi, On Wed, Sep 19, 2018 at 09:28:20PM -0400, Alan DeKok wrote:
On Sep 19, 2018, at 5:00 PM, Christian Salway via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote: Windows 10 supports TTLS. OSX has supported TTLS for years.
Is there any advantage of TTLS over PEAP security wise? Thanks, HC
Hello, after ios 12 update, our clients started to get the following errors. Sep 20 17:12:39 freeradius[15228]: TLS Alert read:warning:close notify Sep 20 17:12:39 freeradius[15228]: TLS_accept: failed in unknown state Sep 20 17:12:39 freeradius[15228]: rlm_eap: SSL error error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure Sep 20 17:12:39 freeradius[15228]: SSL: SSL_read failed in a system call (-1), TLS session fails. Sep 20 17:12:39 freeradius[15228]: Login incorrect (TLS Alert read:warning:close notify): [e1xxxx] (from client port cli ) Can you please advise? Kind regards,
On 20 Sep 2018, at 15:16, Seniha S. ÖZTEMİZ TULGAR <seniha.oztemiz@gmail.com> wrote:
ssl handshake failure
Are you: * Running a very old version of FreeRADIUS? * Running a very old version of OpenSSL? * Using EAP certificates with sha1 hashes/512 bit RSA/DSA, or other obsolete crypto? My guess is the answer to one of those questions is probably "yes" - in which case the solution is to upgrade. Adam Bishop gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460 jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.
Hello, Changing the certificate worked. Thank you very much. Kind regards, On Thu, 20 Sep 2018, 17:25 Adam Bishop, <Adam.Bishop@jisc.ac.uk> wrote:
On 20 Sep 2018, at 15:16, Seniha S. ÖZTEMİZ TULGAR < seniha.oztemiz@gmail.com> wrote:
ssl handshake failure
Are you: * Running a very old version of FreeRADIUS? * Running a very old version of OpenSSL? * Using EAP certificates with sha1 hashes/512 bit RSA/DSA, or other obsolete crypto?
My guess is the answer to one of those questions is probably "yes" - in which case the solution is to upgrade.
Adam Bishop
gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460
jisc.ac.uk
Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi, On Thu, Sep 20, 2018 at 06:43:29AM -0400, Alan DeKok wrote:
On Sep 20, 2018, at 2:15 AM, Hans-Christian Esperer <hc@hcesperer.org> wrote:
Is there any advantage of TTLS over PEAP security wise?
Not a lot. They're both based on EAP-TLS, so they share that security.
Okay, thank you. I know this is not related to this thread anymore, but could you elaborate a bit on the "Not a lot"? Another question, while we're at it: I just read about WPA3 and realized that WPA2-PSK does not offer forward secrecy. AFAICT EAP-TLS, TTLS and PEAP *do* provide forward secrecy, as long as the TLS handshake establishes a session key via diffie hellman. Correct? Now I wonder whether EAP-PWD, which uses a PSK per user, also provides forward secrecy? My assumption is that it doesn't. Thanks HC
On Sep 20, 2018, at 10:26 AM, Hans-Christian Esperer <hc@hcesperer.org> wrote:
Not a lot. They're both based on EAP-TLS, so they share that security.
Okay, thank you. I know this is not related to this thread anymore, but could you elaborate a bit on the "Not a lot"?
They can both carry MS-CHAP inside of the TLS tunnel. Only TTLS can do PAP or CHAP, or other EAP methods. PEAP can do EAP-GTC, which is sort of PAP if you look hard enough. Both can do client certificates, tho Windows doesn't support it.
Another question, while we're at it: I just read about WPA3 and realized that WPA2-PSK does not offer forward secrecy. AFAICT EAP-TLS, TTLS and PEAP *do* provide forward secrecy, as long as the TLS handshake establishes a session key via diffie hellman. Correct?
Now I wonder whether EAP-PWD, which uses a PSK per user, also provides forward secrecy? My assumption is that it doesn't.
Forward secrecy depends on the cipher suite you select. So "it all depends" is the best answer. Alan DeKok.
On Thu, Sep 20, 2018 at 10:46:45AM -0400, Alan DeKok wrote:
Now I wonder whether EAP-PWD, which uses a PSK per user, also provides forward secrecy? My assumption is that it doesn't.
Forward secrecy depends on the cipher suite you select. So "it all depends" is the best answer.
I just discussed on the #freeradius irc channel: Apparently EAP-PWD always guarantees forward secrecy. https://tools.ietf.org/html/rfc5931#page-35 7.b.2. (Security claims) Cheers HC
Both can also , depending on client and server, trust anchoring (crypto binding). TTLS has the advantage of being able to carry/tunnel a whole load of sub types (though commonly only around 4 are supported by clients and servers) alan On Thu, 20 Sep 2018, 15:27 Hans-Christian Esperer, <hc@hcesperer.org> wrote:
Hi,
On Thu, Sep 20, 2018 at 06:43:29AM -0400, Alan DeKok wrote:
On Sep 20, 2018, at 2:15 AM, Hans-Christian Esperer <hc@hcesperer.org> wrote:
Is there any advantage of TTLS over PEAP security wise?
Not a lot. They're both based on EAP-TLS, so they share that security.
Okay, thank you. I know this is not related to this thread anymore, but could you elaborate a bit on the "Not a lot"?
Another question, while we're at it: I just read about WPA3 and realized that WPA2-PSK does not offer forward secrecy. AFAICT EAP-TLS, TTLS and PEAP *do* provide forward secrecy, as long as the TLS handshake establishes a session key via diffie hellman. Correct?
Now I wonder whether EAP-PWD, which uses a PSK per user, also provides forward secrecy? My assumption is that it doesn't.
Thanks HC - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (7)
-
Adam Bishop -
Alan Buxey -
Alan DeKok -
Christian Salway -
daada muyiwa -
Hans-Christian Esperer -
Seniha S. ÖZTEMİZ TULGAR