NPS EAP authentication failing after Windows Update

Question

I have a Windows 2008 Std server running NPS. After applying the latest round of updates (including Root Certificates for April 2012 KB931125 (See:http://support.microsoft.com/kb/933430/)), EAP authentication is failing due to being malformed.

Sample error (Security/Event ID 6273), truncated for brevity:

Authentication Details:
        Proxy Policy Name:              Use Windows authentication for all users
        Network Policy Name:            Wireless Access
        Authentication Provider:                Windows 
        Authentication Server:          nps-host.corp.contoso.com
        Authentication Type:            PEAP
        EAP Type:                       -
        Account Session Identifier:             -
        Reason Code:                    266
        Reason:                         The message received was unexpected or badly formatted.

The NPS policy (Wireless Access) is configured accordingly (for Constraints/Authentication methods)

EAP Types:
            Microsoft: Protected EAP (PEAP) - with a valid certificate from ADCS
            Microsoft: Secured password (EAP-MSCHAP v2)
Less secure authentication methods:
            Microsoft Encrypted Authentication version 2 (MS-CHAP-v2)
            User can change password after it has expired
            Microsoft Encrypted Authentication (MS-CHAP)
            User can change password after it has expired

We've tested a different RADIUS server without the aforementioned patch, and removed EAP as an authentication type and experienced success.

Has anyone else experienced this issue?

Solution 1

I'm going to put this here, since I experienced this yesterday and one of my first searches led me to this question.

The problem ended up being, as ALF4 mentioned, too many root certificates. It occurred after a Windows update to the root certificates.

We solved it by changing the Registry to prevent the NPS server from sending the trusted root certificates list to the clients.

Prevent NPS from sending trusted root certificates to clients

• Open regedit to the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

• Create a new DWORD value SendTrustedIssuerList and set it to 0 (false).

That immediately solved the issue and clients could connect again.

Special thanks to Brian who pointed out KB933430 which, despite being for Windows Server 2003, fixed our Server 2008 and Server 2008 R2 boxes.

Solution 2

In December 2012, this issue occurred for many people when Microsoft messed up update KB931125 on December 11th 2012 by accidentally applying the root cert update to clients and servers, when it should've only been applied on clients. This added hundreds of 3rd-party root certificates to the trusted root certs list on servers, causing problems like you showed.

Took me long enough to find it, but MS has an article and fix available at KB2801679 "SSL/TLS communication problems after you install KB 931125".The faulty update has since been expired on Windows Update and WSUS, but if you've already applied it, you can clean up the root cert list by running the Fix-it provided in the article on all affected servers.

I think it fixes the cause in a cleaner way than the registry hacks or manual cert cleanup mentioned above.

If you'd prefer to perform it manually, the fix is essentially to delete all 3rd-party root certs, after which any required ones are automatically recreated from Windows Update. Just make sure you've synced WSUS and accepted the expiration for KB931125.

Delete the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates

The Fix-it seems to work for me, without a reboot or other updates. I removed the registry modification mentioned in Jason's answer and was still able to authenticate Wi-Fi via NPS.

Comments

[Jason Taylor]

@sqlreader Do you have any links where this recommendation is mentioned? I tried to find something mentioning this, but couldn't find anything.

[Atulmaharaj]

Thanks, I successfully used this solution. I prefer it over deleting a bunch of root certificates, since I don't know which ones are safe to delete. Also a future update to the root cert list might bring the problem back, while this registry change should not.

[Atulmaharaj]

As a follow-up to your answer, it appears MS made an error causing this problem to appear in December 2012. A Fix-it is available in KB2801679. See my answer for details: serverfault.com/a/478312/9082