We have our coporate SSID that seems to simply not work on Windows10 clients. Help desk has to manually configure the profiles on Win10 boxes in order to allow them to connect. We have tested this ad nausea and from what I gather when a win10 user attempts to connect and authentication is pushed to an NPS server using a wildcard certificate an error 16 is thrown on the NPS server. But if I use the same u/p from the meraki portal to test authentication it works fine.
Reason Code: 16 Reason: Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.
If we push AUTH to an NPS server using a cert that matches its name it works without issue. OSX doesn't have this issue, just windows.
Has anyone seen this before?
Nope because it doesn't even get far enough to create the profile automatically in Win10. It just fails to connect without creating a profile. Trying to make this work so no manual intervention is needed.
Are you using PEAP with MSCHAPv2 - or are you using certificates?
The certificate you your NPS server - what issued this? Whatever CA issued it has to be trusted by the Windows 10 machines.
When your helpdesk manually configures the settings - what settings do they configure to make it work? And when you say manually - what is normally configuring them? GPO?
PEAP man and its from digicert or thawte IIRC. Dont know the settings as I am not on the helpdesk but the fact remains something with Win10 and the NPS/CERT is causing an issue. Manually creating the profile or pushing out via GPO doesn't solve the issue at hand, its just a workaround.
What do you want to know exactly? What settings are changed where? I don't follow your question. Like I said Win10 cannot create the profile by itself when a user attempts to connect for the first time. It has to be created manually and that is the problem I am trying to solve.
FWIW I asked the help desk team for the settings they are using and will share them.