Windows Clients not authenticating to NPS / RADIUS Server

I have been in the process of setting up a BYOD solution at my school for the past few months (more on this to follow!) and have set-up a NPS / RADIUS Server as the core authentication server for this solution. All was going well and the launch was publicised to everyone for the start of the January term.

I returned after the Christmas break to perform some final tests and document the system ready to let our students start connecting their own devices; when I found that Apple and Android devices would connect fine but I could not get any Windows laptops to connect at all!

After a lot of hunting around on the web and searching through SQL access logs for the NPS server and Error Logs I finally found the solution to our problem. I thought I would post it up here in case anyone else runs into it and also in case I need it again!

Inspecting the NPS SQL Logs revealed that when a Windows device tried to connect it was sent a reject packet. We then cross referenced this with the Windows Security Log for the NPS server and found an Event with ID “6273 – Reason: The message received was unexpected or badly formatted.”

The server’s System event log I also found lots of Schannel errors with ID 36887 and warnings with ID 36885.

This lead me to these two pages from Microsoft: and

It appears as if Microsoft’s December Root Certificates Update has increased the list of trusted certificate authorities to a length which is greater than a Windows client can accept… This is what causes the unexpected format return message to the NPS server, which then issues the reject packet.

Microsoft present three solutions on their page: we followed the regedit solution and are happy to say that Windows clients are now authenticating with our NPS / RADIUS server again.

Now on with the BYOD roll-out!

4 thoughts on “Windows Clients not authenticating to NPS / RADIUS Server

  1. Hi John.

    We are in the same situation with regards to supporting wireless clients at a school and also soon to implement BYOD..

    I’m really interested to know how you went about authenticating private devices that dont belong to the domain via NPS ?

    Most of the documents require the use of an Internal Certificate authority which only domin pcs will trust. How did you go about connecting the private devices if this is the case.



    1. Hi Shaun,

      Have a read of my post here: on how we set it all up for BYOD at my place.

      Interestingly it seems that it is only Microsoft devices which are worried about the 802.1x cert coming from a known authority (and possibly only Win 7 and below); and with Win 7 even if you did purchase a cert from a known authority the user would still have to implicitly tell their machine to trust the cert! Android, iOS and OSX are more than happy to present you the cert when you first try to connect and allow you to accept the cert being presented.

      So we use a self-signed cert for 802.1x and instruct Windows users how to either install the cert so that it is trusted or turn off certificate validation for 802.1x…

      I would be interested to hear how others handle this too.


  2. Thanks for posting – I’ve witnessed exactly the same problem but wonder if we could purchase a certificate that was publically trusted but dealt with the internal domain (for the non-domain windows clients connecting to NPS). I’ve asked a certificate provider if we can do such as thing and will post here if they can.

    I’ve read somewhere that this will work and have asked the cert company to provide me with a temp cert.

    I want to try and get the windows devices to work without user intervention (i.e. installing the internal cert) so quite determined to get this working…

    1. Hi Dylan,
      I would be interested in hearing what you find out. It was my understanding that Windows 7 would still require the certificate to be explicitly installed regardless if it was purchased from a known provider or not; but I am open to being corrected on that one!


Leave a Reply

Your email address will not be published. Required fields are marked *