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.
OK. Admittedly I am not a Microsoft or GPO expert by any means but this just seems weird.
This question seemed to have half the answer - the certificate needs to be available in the Trusted Root Certification Authorities on whatever domain controller gpmc is connecting to. That seems to make sense. However, even after installing the certificate on our domain controller it still was not an option that was available for selection if I ran gpmc on my workstation. On a lark, I logged into the domain controller in question and ran gpmc directly AND the certificate was available.
I tried then installing the certificate into my workstation's Trusted Root Certificate Authorities, thinking along same the lines as @Greg Askew. No dice. Still not available as an option in the PEAP settings.
You apparently need a) to have installed the certificate in the Trusted Root Certification Authorities on whatever domain controller gpmc is connecting to and b) be running GPMC on that domain controller directly.
This makes no sense to me as RSAT is RSAT is RSAT, regardless of whether you are running gpmc on a domain controller or a workstation. Go figure... a beer goes to whomever can explain this!
From my workstation - no certificate:
From the domain controller - certificate is available!
Best Answer
It's not that clear from your query but your problem can be because not both of your certificates are correctly tagged:
According the URL you pointed: * The client certificate needs to have the 1.3.6.1.5.5.7.3.2 extension * The server certificate needs to have the 1.3.6.1.5.5.7.3.1 extension
I also believe that it's the intermediate CA you refer to that should have the 1.3.6.1.5.5.7.3.1 extension.
In short, I think your problem lies in the "Server certificate requirements" part of the page.
This shows the openssl config you can use when generating the certificates: http://lists.freeradius.org/pipermail/freeradius-users/2011-April/052962.html Of course you'll have to add the xpclient_ext/xpserver_ext to the certificates upon generation.