Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

Thanks.

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." :/ )

share|improve this question
    
Have you distributed the new certificate from the new CA to the clients? Have you verified that those clients are actually using the new certificate for auth? –  MDMarra Jul 16 '12 at 17:50
    
Yup. Manual tests so far [MMC -> certificates snap-in -> request new certificate], and I have been manually deleting the old certs while I'm at it. The old DCs still show up as the default option for the CA, but I can select the new one and get a cert just fine. Just doesn't seem to be helping. –  HopelessN00b Jul 16 '12 at 17:53
    
Are you actually importing the root certificate and the client certificate? –  MDMarra Jul 16 '12 at 18:05
    
@MDMarra: Actually, that was a helpful suggestion. If you want to suggest that the server-side certificate is corrupt and needs to be re-issued (as one might discover when trying to import it), I'd be happy to accept that answer. –  HopelessN00b Jul 16 '12 at 18:50
1  
It's not that the server-side certificate is corrupt, it's that you replaced the CA that signed that cert and you (presumably) replaced the server-side cert with one from the new CA. Your clients won't trust that cert until they trust the root that signed it. –  MDMarra Jul 16 '12 at 19:01

2 Answers 2

up vote 2 down vote accepted

If you're replacing the signing root CA, you'll need to make sure that you're importing both the new trusted root and the new client certificate.

share|improve this answer

Please make sure that the new server certificate has been imported into the personal certificate due to the server sending hello package to client. if there is none, server cannot initialize the EAP-TLS handshake with error occuring on EAP protocol.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.