I'll try to answer the LDAP question here.
Here's the short answer: make sure the ldap
module is removed from the authenticate
section, and make sure the mschap
module is present in both the authorize
and the authenticate
section. And just ignore the 'No "known good" password'.
And now here's the (very) long answer.
How does the ldap module work?
When you activate the ldap
module in the authorize
section, this is what it does when a RADIUS packet is received by FreeRADIUS:
- it tries to bind to the LDAP server (as a guest user, or using the given identity if one is configured in
ldap.conf
)
- it searches for the user's DN entry using the filter under the base DN (configured in
ldap.conf
).
- it fetches all the LDAP attributes it can get among those configured in
ldap.attrmap
, and converts them into RADIUS Attributes.
- it adds those attributes to the RADIUS packet's check items list.
When you activate the ldap
module in the authenticate
section, this is what FreeRADIUS does:
- it tries to bind to the LDAP server as the user.
- if it can bind, then it's a successful authentication, and a
Radius-Accept
packet will be sent back to the client, or else, it's a failure, leading to a Radius-Reject
packet.
So how can I configure FreeRADIUS to make PEAP/MS-CHAP-v2 work with LDAP?
The important point here is that binding as the user will only work if the FreeRADIUS server can retrieve the cleartext password of the user from the RADIUS packet it received. This is only the case when PAP or TTLS/PAP authentication methods are used (and possibly also EAP/GTC). Only the TTLS/PAP method is really secure, and it is not available by default in Windows. If you want your users to connect with TTLS/PAP, you need to have them install a TTLS supplicant software, which is seldom an option. Most of the time, when deploying WiFi with WPA Enterprise securiy, PEAP/MS-CHAP-v2 is the only reasonable option.
So the bottom line is: unless you are using PAP or TTLS/PAP, you can safely remove the ldap
module from the authenticate
section, and actually, you should: binding as the user will not work.
If your test works when you use radtest
, it probably means that the ldap
module is activated in the authenticate
section: it will try to bind as the user, and since radtest uses PAP authentication, it will succeed. But it will fail if you try to connect through the access point, since you are using PEAP/MS-CHAP-v2.
What you should do is remove the ldap
module from the authenticate
section, and make sure you activate the mschap
module in both the authorize
and the authenticate
section. What will happen is that the mschap
module will take care of authentication using the NT-Password
attribute which is retrieved from the LDAP server during the authorize
phase.
Here is what your sites-enabled/default
file should look like (without all the comments):
...
authorize {
preprocess
suffix
eap {
ok = return
}
expiration
logintime
}
authenticate {
eap
}
...
And here is what your sites-enabled/inner-tunnel
file should look like:
...
authorize {
mschap
suffix
update control {
Proxy-To-Realm := LOCAL
}
eap {
ok = return
}
ldap
expiration
logintime
}
authenticate {
Auth-Type MS-CHAP {
mschap
}
eap
}
...
What about the 'No "known good" password' warning?
Well, you can safely ignore it. It's just there because the ldap
module could not find a UserPassword
attribute when it fetched the user details from the LDAP server during the authorize
phase. In your case, you have the NT-Password
attribute, and that's perfectly fine for PEAP/MS-CHAP-v2
authentication.
I guess the warning exists because when the ldap
module was designed, PEAP/MS-CHAP-v2
did not exist yet, so the only thing that seemed to make sense at the time was to retrieve the UserPassword attribute from the LDAP server, in order to use PAP, CHAP, EAP/MD5 or such authentication methods.
Best Answer
In this instance, provided the certificate presented by the server is validated correctly by the supplicant, confidentiality (protection against snooping) and integrity (protection against modification), are provided by EAP-TLS/TLS.
The key thing here is that the server's certificate is validated correctly. If it's not, then an attacker can set up a honeypot network, present a fake certificate to the supplicant, and harvest the plaintext credentials.
Any organisation serious about security will either implement EAP-TLS (negating the need for a password) or run a dissolvable installer (SecureW2, Cloudpath, eduroamCAT - If this is for eduroam) on their wireless clients to configure the 802.1X authentication settings correctly.
Last time I checked Windows 10, in particular, didn't implement any sort of certificate/SSID pinning, so indicating you trusted the server's cert during the initial authentication attempt didn't actually add any security. For subsequent auth attempts with a different cert, the supplicant would happily present you with the fingerprint of the new certificate without any indication of the mismatch. The only way to fix this is to explicitly set the certificate validation settings (trusted CAs, expected subject name pattern) for the wireless network, either manually or with a dissolvable installer (as mentioned above).
To answer your other question about which TTLS/PEAP inner methods will work with LDAP, if you're using LDAPv3 authenticated binds to authenticate the user, then yes, only PAP or GTC (See PEAPv0/GTC) will work. They both operate in pretty much the same way.
If you're pulling back hashes and doing the comparison locally on the RADIUS server, and store the NT-Password hash of the user's password as well as whatever other hash you're using, then this allows you to do MSCHAPv2.
Honestly, though, the NT-Passwords use extremely weak hashing (MD4), so it's almost as bad as storing cleartext in OpenLDAP. You need to weigh the likelihood of your OpenLDAP installation being compromised, and the risk of all the hashes being stolen/cracked, and the likelihood of someone mounting a MITM attack, and the risk of a subset of passwords being stolen.
As a final note, If you're using EAP-PWD there is some limited support for using hashed copies of the password on both the Supplicant and RADIUS server but this EAP method is not widely supported outside of Linux environments.
I'm pretty dissatisfied with the situation TBH, but getting everyone to adopt a new EAP-Method would require a significant effort from multiple vendors.
The only thing that's implementable on the FreeRADIUS side, is to setup 'spot checks' on cert validation settings, and remediate any users that fail them. How you can do this is by dynamically swapping out the certificate presented to the supplicant with an invalid one, and verifying that the supplicant returns the correct alert (invalid_ca) to the RADIUS server. This will cause an authentication failure (if everything works correctly), but supplicants will also retry fairly quickly, so as long as the spot checks are fairly infrequent it's not too big of a deal.