Microsoft, this is why people do not deploy NAP, NAC and other things like this, small little problems that take hours to fix – and then when something goes awry later on, people pull their hair out.
If you are running Windows 2012, with Windows 8 Desktops, everything is happy in your world.
The same is true for Windows 2008, and Windows 7 Desktops.
However as Microsoft changes things, and starts to deprecate protocols, features and functionality we keep running into cross version funnies, here is one.
A typical wireless network with 802.1X Enterprise Auth requires a few things.
- AP’s or a controller that knows where to go for authentication
- Some kind of RADIUS server that can respond to auth requests
- A certificate that is trusted by everyone involved — trusted and apparently formatted right.
The 1st and 2nd parts are pretty easy, but the 3rd, that’s where things get interesting. First it’s not totally obvious that Microsoft NPS needs a certificate, and to add insult, you need to use PEAP instead of Password Authenication — but more on that later.
While configuring a clients Wireless for 802.1X authentication, I ran into clients who would refuse to connect, they were Windows 7 clients. Windows 8 clients, mobile devices were all fine.
Ok….. So let’s go check our event log on the NPS server…. We see Error 6273 Reason 16
Ok.. so Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password is incorrect. This is easy… Wait.. is it? I clicked on the network, it used my WINDOWS CREDENTIALS.. I did log on to this laptop right? Let’s do the logoff/logon dance, make sure we are wired, and we know the cred’s are right… Did that. Logon to another PC — check. Logon to a DC directly with same test account — check. Ok we know this user and password are fine.
I wish I could find something that proves why this isn’t working but I ran across this article
When selecting a certificate for NAP
“Certificates that do not contain a Subject name are not displayed.”
Oh, well in 2012 they are… That’s because Windows 8 clients are OK with that… Except Windows 7 clients ARE NOT.
I was also tossed the wrong way by multiple articles that claimed it was something to do with the “validate certificate” checkbox — which by the way, should be checked, why would you EVER turn off certificate validations checking! If you do that, cred’s are easily stolen by nearby attackers.
So yes, this is a bit of a ranty post, but I want to get down to this… Let’s make this work.
The key is when you request your machine certificate.
Start your enrollment
MAKE SURE YOU SELECT DOMAIN CONTROLLER — Not Authentication or Kerberos — as much as those might sound like what you want. Those certs would be published, without a subject. Click Enroll, no need to modify more
No go back and open the cert you just created… Make sure the “Subject” line has something in there, yes, the yellow bit that I have blacked out, should have the computer name in there.
In the above guide it calls out the PEAP section, make sure you select the cert you just created.
Another common mistake… In the box below you should see Protected EAP (PEAP) DO NOT ADD MSCHAPv2 “secured password” — again, it might sound like what you want, but it is not.
So that’s it, yes a little bit ranty. This needs to be easier, if I was a powershell guy, I am certain I could write a script that just does this for me, you can even add radius clients with New-NPSRadiusClient and create all the policies in PowerShell, but I am simply not a programmer.
Microsoft — this does not need to be this difficult.