So, I guess the short version of the question is:
I'm unable to get clients to connect to an enterprise-WPA wireless network after setting up a "new" NPS server and a new CA. After I manually request a new cert on my client from the NPS/CA server and trying to connect to the wireless network, they sit at "Attempting to authenticate"/"Waiting for network to be ready" for about a minute before giving up and saying they can't connect.
The logs on my NPS/CA server give an IAS4142 "Reason Code" of 23... which is absent from the technet documentation on what the various error codes mean. >:/ What's going on, and does anyone know how to fix it? Or where to begin troubleshooting this? (Google's been pretty unhelpful... found a few people with the same problem, but no solutions.)
The longer version, which hopefully contains information that can help someone help me is:
A couple weeks back, we had an event that involved forcefully seizing FSMO roles from our two "main" DCs at the home office (2k3 R2). As a result, they're offline, and aren't coming back. Of course, after doing this, and resolving the immediate crisis, we were getting reports that wireless access wasn't working anymore. Which made sense, when we went back and looked at the disconnected former DCs, and found that one was our only IAS server, and the other was the only CA in our environment. (%#&*!!!) Of course, we use WPA-enterprise wireless encryption with certificates issued to client machine accounts, and domain credentials required to authenticate (the lazy way, allowing clients to use their logon credentials to auth automagically with no user interaction). So the problem was that there was no RADIUS server available to service the requests, and the issuing CA was gone anyway.
The solution, which seemed like a good one at the time, was to stand up a new server, and because of equipment limitations, put the CA and NPS roles on it. I would have liked to also make it a DC, but was unable to as a result of other limitations. Everything I know, and read, indicated this would be fine. I also had the comical assumption that I'd be able to set it up right this way and not have all the irritations of the previous setup. And, not wanting to manually re-enter a couple hundred clients and a couple dozen policies, I followed this technet article on how to migrate NPS servers (and the fix for the incorrect IAS to NPS EAP parameter. Mostly. Instead of 0,16,515 in that section, I had 0,15,521... so I corrected the '0' as directed and moved on.)
I changed a few CA crypto settings (SHA-1 to SHA-512, on account of SHA-1 being insecure these days, named the root cert in a less retarded manner, etc.), registered NPS in AD, and thought I was good to go. Then I ran into the issue that XP can't use SHA-2 certs for AAA (&%#^!!!), which is problematic when our clients are still on XP. Applied that hotfix (which mentions that the update will be included in XP SP4... :/ ), and still no joy. Found the error code with a little more work than I'd like to admit (especially when I later noticed the error in the Security Event Logs, so I wasted my time deciphering the **ing IAS logs), and went to Google for help, and came up almost completely empty. Other people have reported the same issue, but no one seems to know what's wrong, or how to fix it. EventLog text:
Log Name: Security Source: Microsoft-Windows-Security-Auditing Date: 7/16/2012 11:25:37 AM Event ID: 6273 Task Category: Network Policy Server Level: Information Keywords: Audit Failure User: N/A Computer: [The NPS/CA server] Description: Network Policy Server denied access to a user. Contact the Network Policy Server administrator for more information. User: Security ID: [domain\username] Account Name: [domain\username] Account Domain: [domain] Fully Qualified Account Name: [domain\username] Client Machine: Security ID: NULL SID Account Name: - Fully Qualified Account Name: - OS-Version: - Called Station Identifier: 003a.9a18.7671 Calling Station Identifier: 0013.e888.ecef NAS: NAS IPv4 Address: [AP's IP] NAS IPv6 Address: - NAS Identifier: [AP's name] NAS Port-Type: Wireless - IEEE 802.11 NAS Port: 1939 RADIUS Client: Client Friendly Name: [AP's name] Client IP Address: [AP's IP] Authentication Details: Connection Request Policy Name: [Wifi access policy name] Network Policy Name: [Wifi access policy name] Authentication Provider: Windows Authentication Server: [The NPS/CA server.domain.tld] Authentication Type: PEAP EAP Type: - Account Session Identifier: - Logging Results: Accounting information was written to the local log file. Reason Code: 23 Reason: An error occurred during the Network Policy Server use of the Extensible Authentication Protocol (EAP). Check EAP log files for EAP errors.
And, actually, as I was going through the logs to grab that error, I noticed this one just before it (same timestamp, but just before the other in the EventLog)... not sure what it means... my root cert is bad?!?!?
Log Name: Security Source: Microsoft-Windows-Security-Auditing Date: 7/16/2012 11:25:37 AM Event ID: 5061 Task Category: System Integrity Level: Information Keywords: Audit Failure User: N/A Computer: [The NPS/CA server] Description: Cryptographic operation. Subject: Security ID: SYSTEM Account Name: [The NPS/CA server] Account Domain: [domain] Logon ID: 0x3e7 Cryptographic Parameters: Provider Name: Microsoft Software Key Storage Provider Algorithm Name: RSA Key Name: [Root cert created when the CA was installed] Key Type: Machine key. Cryptographic Operation: Operation: Decrypt. Return Code: 0x80090010
Before I do something drastic, [cry] like reinstalling our CA and NPS server, then configuring it all by hand... or buying a bunch of ammo and driving toward Remdond [/cry] does anyone have any ideas on less painful measures that might help resolve my problem?
EDIT: (I don't want to muddle up the concise, generally applicable answer given by MDmarra, but it turns out that the CA/NPS server also required an unprompted reboot after generating its own machine certificate. Not sure if that's true in the general case, or just because the server's doing both roles, or because our environment is so **ed up, but it seems worth mentioning. Restarting the services was insufficient, but rebooting the box seems to have resolved everything. Windows admin 101, or something. "If at first you don't succeed, reboot and try again." :/ )