Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Thursday, April 8, 2010 12:42 AM
We're in the midst of relocating our RADIUS role from a 2003 DC to a 2008 R2 member server.
The following features have been installed and configured:
- Network Policy Server
- Routing and Remote Access Services
- Remote Access Service
- Routing
All policies have been recreated identically to the previous ones and the server has been registered in AD DS.
When attempting to connect to the RADIUS server I receive the following event:
Network Policy Server denied access to a user.
Contact the Network Policy Server administrator for more information.
User:
Security ID: NULL SID
Account Name: test
Account Domain: DOMAIN
Fully Qualified Account Name: DOMAIN\test
Client Machine:
Security ID: NULL SID
Account Name: -
Fully Qualified Account Name: -
OS-Version: -
Called Station Identifier: -
Calling Station Identifier: -
NAS:
NAS IPv4 Address: x.x.x.x
NAS IPv6 Address: -
NAS Identifier:
NAS Port-Type: -
NAS Port: 1
RADIUS Client:
Client Friendly Name: server.fqdn
Client IP Address: x.x.x.x
Authentication Details:
Connection Request Policy Name: Use Windows authentication for all users
Network Policy Name: -
Authentication Provider: Windows
Authentication Server: server.fqdn
Authentication Type: PAP
EAP Type: -
Account Session Identifier: -
Logging Results: Accounting information was written to the local log file.
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.
All credentials, shared secrets and authentication methods are correct. I have also checked Dial-Up properties in AD DS. Has anyone else experienced this issue?
Regards,
Ryan.
All replies (63)
Monday, April 12, 2010 12:17 AM | 1 vote
If we enable "Accept users without validating credentials" in the connection policy this works but does not match the Network Policy.
Wednesday, April 14, 2010 1:51 AM
Does anyone know if the authentication methods or the way RADIUS interacts with clients has changed dramatically from 2003 onwards? Is there any further troubleshooting or debugging that I could try to help try and diagnose the issue?
I tried setting up another RADIUS box on 2003 R2 and experienced the exact same issue again.
Thursday, May 13, 2010 2:19 PM
If its any help, we have the exact same problem. Trying to setup L2TP over IPSec from our Astaro firewall with backend authenication to Windows 2008 R2 radius server. Did you ever get this resolved?
Friday, May 21, 2010 3:50 PM
I am having the same problem with a Sonicwall firewall and Win2k8 r2 server. Event ID 6273, Reason code 16. Any solutions yet?
Tuesday, May 25, 2010 5:17 PM | 1 vote
I am also having the Event ID 6273, Reason Code 16, "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."
My configuration: I have a 3rd party VPN server that authenticates to IAS/NPS. In IAS/NPS, I am using PEAP Authentication and a network policy condition that the "Windows Groups" has to be MY_DOMAIN\VPN_User. Users that authenticate as MY_DOMAIN\User authenticate just fine. In IAS (Windows 2003), I have a connection request policy that removes the domain part of the user name by Finding (.*)\(.*) and Replacing With $2. (NPS: "Specify a Realm Name": http://technet.microsoft.com/en-us/library/dd197583(WS.10).aspx). This works fine with Windows 2003 IAS, but gives the above error when configured identically in Windows 2008 NPS, when users log in with NOT_MY_DOMAIN\User when User exists in my domain and is in the VPN_User domain group. The Windows logs show that in both IAS and NPS the domain is truncated off of the user name. Windows 2008 NPS seems to not work like Windows 2003 IAS for my situation.
Is your situation similiar, where the domain (Realm) is different from where it is authenticating? Another thing to point out - I noticed that your User:SecurityID entry isn't DOMAIN\test like I would expect, and your User:FullyQualifiedAccountName status isn't DOMAIN.COM\OU\OU\test (OU being the location in Active Directory where the account is kept). I don't know why this would be.
Monday, May 31, 2010 11:22 AM
Did anyone find a solution to this problem? I'm experiencing the same behavior on my W2k8 r2 server.
Monday, May 31, 2010 1:24 PM
Hi Ryan,
Please verify Tools for Troubleshooting NAP, http://technet.microsoft.com/en-us/library/dd348461(WS.10).aspx
The article points out:
Event ID 6273: Network Policy Server denied access to a user.
This event occurs when there is a problem with authentication or authorization and is associated with a reason code. For more information, see NPS Reason Codes (http://go.microsoft.com/fwlink/?LinkId=136640).
Alfredo Arizaleta
Just begining
Monday, July 12, 2010 11:48 AM
Do you got an security even 4625 with content about "Security ID :NULL SID" before the even 6273 ?
If you got this event. That's possible the SID problem if both NPS and DC server are clone from the same image without change SID.
Wednesday, October 13, 2010 10:59 PM
Looking for a solution to the error listed above. The user name are password are correct. Not sure what is causing the error? Details of the error are below: Event ID 6273
Network Policy Server denied access to a user.
Contact the Network Policy Server administrator for more information.
User:
Security ID: S-1-0-0
Account Name: domain\user
Account Domain: domain
Fully Qualified Account Name: domain\user
Client Machine:
Security ID: S-1-0-0
Account Name: -
Fully Qualified Account Name: -
OS-Version: -
Called Station Identifier: -
Calling Station Identifier: 66.112.55.224
NAS:
NAS IPv4 Address: 10.55.24.2
NAS IPv6 Address: -
NAS Identifier: -
NAS Port-Type: Virtual
NAS Port: 0
RADIUS Client:
Client Friendly Name: Cisco VPN
Client IP Address: 10.55.24.2
Authentication Details:
Connection Request Policy Name: Use Windows authentication for all users
Network Policy Name: -
Authentication Provider: Windows
Authentication Server: domain.domain.local
Authentication Type: PAP
EAP Type: -
Account Session Identifier: -
Logging Results: Accounting information was written to the local log file.
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.
Jake B CO 1/1
Monday, December 6, 2010 3:57 AM
Any movement on this? Is it a bug? I am getting the same exact situation and result. I am using RADIUS Auth from a 2003 IAS server to a 2008 R2 NPS server. Thanks!
Tuesday, December 7, 2010 3:31 PM
My issue was resolved. The router had to be configured to pass MSCHAPv2 (instead of PAP). After that change (and others on the router) is still didn't work. The Cisco eng. then copied the 'Share Secret' from the running config and pasted in the RADIUS clients config. After restarting the services, it worked. I don't think there is a bug, it's just not as simple as it was in earlier versions of server.Jake B CO 1/1
Friday, March 25, 2011 3:21 PM
Hi all
i had this exact same problem, I knew i was using the correct password for the Radius client as i took it from an old config, i also know that the policies where the same as IAS as it was imported from a 2003 DC
After reading this post I made a new password on the VPN device and then it suddenly worked
Monday, July 18, 2011 8:08 PM
I was having this same issue and it turned out to be a bad radius password on the switch. Once I consoled in to the switch and re-entered the radius-server info using the correct password, it worked. I would hazard a guess that you need to re-enter your radius information on the device making the connection.
radius-server host IP_ADDRESS auth-port 1645 acct-port 1646 key RADIUS_PASSWORD
Hope that helps. thanks!
Monday, July 18, 2011 9:31 PM
I also wanted to point out the list of Windows Server Migration Guides and Tools that we've published at http://technet.microsoft.com/en-us/library/dd365353(WS.10).aspx. The list includes support for NPS, RRAS, and many others. Most of the Guides include troubleshooting sections. Dave Bishop
Content Publishing Manager - Networking
Windows Server Information Experience Team
Microsoft Corporation
Friday, August 24, 2012 7:54 AM
Hi,
I am actually doing the same config as the original poster, using PEAP over MSCHAPv2, but the weird thing is: laptops, android phones, windows mobile phones can login but the Nokia Symbian phones can not. Unlilke others we are using CA certificate and not shared secret.
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 24.8.2012 10:46:23
Event ID: 6273
Task Category: Network Policy Server
Level: Information
Keywords: Audit Failure
User: N/A
Computer: nps.fqdn
Description:
Network Policy Server denied access to a user.
Contact the Network Policy Server administrator for more information.
User:
Security ID: fqdn\username
Account Name: username@xxx
Account Domain: xxx
Fully Qualified Account Name: xxx/yyy/zzz/User Name
Client Machine:
Security ID: NULL SID
Account Name: -
Fully Qualified Account Name: -
OS-Version: -
Called Station Identifier: AB-10-CD-E3-1E-3B
Calling Station Identifier: 12-7A-92-B6-11-D2
NAS:
NAS IPv4 Address: 10.0.0.3
NAS IPv6 Address: -
NAS Identifier: CN23F2D212
NAS Port-Type: Wireless - IEEE 802.11
NAS Port: 1478
RADIUS Client:
Client Friendly Name: MSM720
Client IP Address: 10.0.0.25
Authentication Details:
Connection Request Policy Name: Secure Wireless Connections
Network Policy Name: Secure Wireless Connections
Authentication Provider: Windows
Authentication Server: nps.fqdn
Authentication Type: PEAP
EAP Type: -
Account Session Identifier: 35646133666564302D3030303030373836
Logging Results: Accounting information was written to the local log file.
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.
Wednesday, August 29, 2012 8:32 PM
Thank goodness for this thread! I moved from IAS to NPS and the connection profiles were migrated and NPS has never worked since. I was able to open the ias.mdb from the old server in Access and looked at the properties for the shared key (which are in plain text..hmm), and re-entered them into my RADIUS Client properties and it started working instantly
So if you know your authentication and encryption values are correct in both the Connection Request Policies and Network Policies, check the RADIUS Client, specifically the shared secret and reset if needed (on both sides).
Tim Magnuson | MCTS, MCITP | MCCA 2011 |
Ok, so I changed my name...you can still call me Tom if you like. It's a...jump...to conclusions...mat.
My Blog Site: http://tmagnuson.wordpress.com
Friday, January 4, 2013 5:31 PM
Hello,
I am getting the same error. But I am trying to set visitor connection.
Basically, NPS with Compliant and Non Compliant is working just fine.
It is the last Network Policy, that I am trying to implement, will switch you to the guest vlan if you do not fulfill with all previous one.
But it is being denied at the Connection Request level.
Any idea how to set visitors, to allow them access to restricted Vlan if they have no authentication at all enabled?
Thank you
Thursday, January 10, 2013 1:10 PM
Hi,
I have this same problem with reason code 16 and NULL SID for username in the log, but only when Windows 7 is trying to authenticate over wireless using PEAP authentication.
Windows 8, Windows Phone 8, iOS devices can connect without any problems. So there is some bug with WINDOWS 7 ONLY. It is clean install of Windows 7, so SID is not an issue.
I had the same problem on Lexmar printers before firmware updates.
Tuesday, January 22, 2013 8:22 AM | 2 votes
FWIW I had this problem (with Sonicwall RADIUS authentication -- when moving from Server 2003 IAS to 2008R2 NPS.)
Using NTRadPing, I discovered that ANY lower-case characters in the shared secret caused the authentication to fail on Server 2008R2 NPS, with a username/password credentials error, not a shared secret mismatch. This same configuration works fine with IAS on Server 2003.
Using only upper-case characters and digits in the shared secret fixed this on the testing 2008R2 server. The behavior was explicit and repeatable: ANY lower-case character in the shared secret would fail the RADIUS authentication. Because this was using NTRadPing and not the Sonicwall, I have to presume this is an issue within NPS.
I still had an issue with the Sonicwall going to the live NPS server. Changing the port in the Sonicwall from 1812 to 1645 got authentication to work again, and then it continued to work after putting it back on 1812. I've seen this same behavior occasionally with Server 2003 RADIUS and Sonicwall.
Anyway, some things to try if you've reached the hair-pulling stage.
Friday, April 12, 2013 2:44 AM
Do you got an security even 4625 with content about "Security ID :NULL SID" before the even 6273 ?
If you got this event. That's possible the SID problem if both NPS and DC server are clone from the same image without change SID.
hi Joshua,
I have get the same issue, but the NPS and DC at the same server windows 2008 R2 enterprise. in addition, Installed the OS on VMware virtual machine. Is there any doubt?
Wednesday, June 26, 2013 4:28 PM
Did you ever find a resolve for your issue? I am having the same type of issue with some Windows 7 machines, iOS devices connect with no problem. Even strangers is that I have 2 locations which use the same Certificate and Radius server. When someone is at one location they can connect, if they move to the 2nd location it denys connection.
Tuesday, July 23, 2013 4:08 PM
Has anyone solved the issue?
I have the same problem. iOS devices would connect using username and password while Windows 7 clients don't connect. Haven't tried other OS yet.
I've tried changing shared secret to upper case+numbers only but it didn't work either?
Does anyone have a solution?
Friday, December 13, 2013 7:42 AM | 15 votes
I had the same experience - Windows 8 clients could connect but not Windows 7 clients.
Turned out for in my case that the 'validate server certificate' checkbox is honored by Windows 8 but not necessarily by Windows 7. If the subject name of the certificate that the NPS server is using is blank then Windows 7 will throw these errors while Windows 8 connects happily. The fix was to use the RAS and IAS Server template in Certificate authority per this article.
http://technet.microsoft.com/en-us/library/cc754198.aspx
Wednesday, April 2, 2014 2:19 AM
I had two NPS servers, the primary one functioned correctly, but if I pointed our network switches at the secondary NPS server attempts to authenticate would fail with "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." - Event ID: 6273 & Reason Code: 16
The only difference between the two servers that I could find was that the primary had two certificates installed and the secondary only had one. The difference between the two certificates was that one had an empty subject attribute and the other had the fully qualified domain name of the server.
This guide "Step Guide: Demonstrate NAP 802.1X Enforcement in a Test Lab" helped : http://www.microsoft.com/en-us/download/details.aspx?id=733
Friday, May 23, 2014 1:14 PM
Event ID 6273 code id 16, technet article below, Was this key to resolving your issue?
http://technet.microsoft.com/en-us/library/cc735399(v=ws.10).aspx
Thursday, June 12, 2014 6:25 PM | 1 vote
Joe's solution fixed mine as well, here is another article explaining why your Domain Computer Certificate may me missing the subject name.
http://setspn.blogspot.com/2010/12/error-selecting-certificate-when.html
Wednesday, June 25, 2014 5:21 PM
I had the same experience - Windows 8 clients could connect but not Windows 7 clients.
Turned out for in my case that the 'validate server certificate' checkbox is honored by Windows 8 but not necessarily by Windows 7. If the subject name of the certificate that the NPS server is using is blank then Windows 7 will throw these errors while Windows 8 connects happily. The fix was to use the RAS and IAS Server template in Certificate authority per this article.
http://technet.microsoft.com/en-us/library/cc754198.aspx
This is the solution! Thank you so much!
Thursday, July 10, 2014 12:49 PM | 1 vote
ringing a little crazy but it's true. I have the same problem with the macaffee/stonesoft firewall. the change of shared key has helped, but not from lower-case character to upper-case characters, but from upper-case characters to lower-case character. I can hardly believe it
Friday, March 13, 2015 9:37 PM | 1 vote
Hi, In the Subject Name's TAB on RAS and IAS Server Certificate template, activate Built from this active directory Information, and the subject format, select DNS name. Bye.
Tuesday, June 9, 2015 1:51 PM
GREAT!!!
Thanks, that was the solution (ANY lower-case character in the shared secret would fail the RADIUS authentication=
Wednesday, October 14, 2015 6:22 AM
Spot on! this fixed the issue for me. In my case I was using a generic Server Auth cert from my CA which didn't contain a Subject. I also found the cert would work for Apple and Windows 8 but not Windows 7. I then requested a new RAS and IAS cert from the CA on my NPS server and issue fixed!
Thanks Sparqz!
Wednesday, February 17, 2016 7:16 PM
I resolved my issue and it was Joe and Hatem's information that helped me.
I'm starting to think it's not consistent and the *very* weird constraint about what the RADIUS preshared key can be may be determined by the RADIUS client and not the NPS server.
My situation was configuring a Meraki MX80 device to allow client VPN users to authenticate against my NPS server (Win 2012r2) using PAP.
- I tried limiting letters to be all caps; it didn't work.
- I tried limiting letters to be all lowers; it didn't work.
- Then I tried limiting the key (I was using a generator tool) to only using lower characters and numerals; HOORAY THAT WORKED.
So the moral of the story from my point of view is... If you know it should be working, try changing the RADIUS client preshared key. But you may have to try several different variations to get one that will work. Some users on this thread needed all caps, some needed all lowers, and mine needed lowers and some (or all) special characters removed.
Saturday, March 19, 2016 11:49 PM
For me, it was a rather simple fix. After hours and hours of non working solutions, I cleaned installed the server, one again, and let all updates run through. Since then, it has been working like a charm on Win2012 R2.
Edit: I do not know which update did the trick, just one of the hundreds must have done it.
Monday, April 18, 2016 8:29 AM
You meant updating on the NPS ?
Tuesday, April 26, 2016 9:46 AM
Thank you, jnouguera7777. This is help me.
But I don't understand yet, why is it very important?
Tuesday, June 28, 2016 10:44 AM
We experienced the same 'Reason Code 16' '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.' on our NPS and it was caused by using a third-party wildcard certificate which did not match the subject name of our NPS server.
It worked fine on iOS clients but Windows clients refused to connect.
It seems as if the server certificate *must* meet the following requirements in order to be accepted, according to https://support.microsoft.com/en-us/kb/814394
- The name in the Subject line of the server certificate matches the name that is configured on the client for the connection.
- For wireless clients, the Subject Alternative Name (SubjectAltName) extension contains the server's fully qualified domain name (FQDN).
Replacing the certificate with a self-signed certificate manually imported into Group Policy via Public Key Policies\Trusted Root Certificate Authority was sufficient to resolve the problem.
Wednesday, July 13, 2016 6:25 AM
Please, help. I have a problem with the certificate for IP-based cameras and printers. What should I use templates? I tried to issue certificates Request> Submit a certificate request using a base-64-encoded CMC or PKCS # 10 files, Web server templates and the router (offline request), but get an error 16, 265, or 8.
Thursday, August 25, 2016 8:54 AM
Full Credits to Joe. Had exactly the same issue and fixed it by creating new RAS and IAS Server template, then issued new cert to the Radius server. Connected straight through from a Windows 7 client.
Wednesday, July 5, 2017 11:28 AM
Bull's eye! Thanks Joe, you saved us a lot of time. We had a similar issue, Windows 10 working but Windows 7 wasn't. Issuing a new certificate based on the RAS and IAS Server template did the trick! Again, big thumbs up!
Tuesday, July 25, 2017 6:36 PM
I tried all the solutions referenced in this forum to no avail after building a new NPS server with full Microsoft Updates that failed to authenticate certificates for 802.1x. My co-worker discovered KB4025335 broke his NPS server in the same manner. After removing this July 2017 update the server started processing 8021.x certificate requests again.
Wednesday, July 26, 2017 9:29 PM
I too was receiving Reason Code 16 errors when attempting to authenticate WiFi users with self-generated (no AD/GP Auto-Enrolled) certificates.
One solution we found to the issue was to find the user in AD Users & Computers (with Advanced Mode selected), right cllcked on the user and selected "Name Mappings". Within the resultant dialog box we associated the user's certificate with the AD user. With the explicit mappings; the users could log in.
Monday, July 31, 2017 7:51 AM
Same Problem here, after Installation of KB4025335 NPS not working.
Event ID 6273 and error code 16
After deinstallation and reboot of Server its working again.
Monday, July 31, 2017 11:55 AM
Hi @all,
we got the same Problem. System patched and NO authentication on 802.1x is working. After 3 hour of searching testing and everything else we found this posts. Uninstall KB4025335 and everything works fine.
I'm asking me if Microsoft is testing his own Patches, it going on my nerve that every third patch is faulty!
Thanks of guys who tease the solution.
Monday, July 31, 2017 7:06 PM
We got hit with the same problem after production patching. Uninstalled KB4025335 and everything worked again.
Thursday, August 10, 2017 5:55 PM
Ended up being a security update for us too, uninstalled and rebooted and we're good. Thanks to all the contributors
Monday, August 14, 2017 11:00 AM | 1 vote
Hi
Update KB4034681 also breakes NPS EAP Authentication .
https://support.microsoft.com/da-dk/help/4034681/windows-8-1-windows-server-2012-r2-update-kb4034681
There is a workaround provided with the link from MS.
Tuesday, August 15, 2017 5:30 AM | 1 vote
Hi Michael,
great! Thank you for the link. After applying the updates this weekend NPS stopped working.
But doing this:
On the server, set the following DWORD registry key's value to = 0: SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13\DisableEndEntityClientCertCheck
Fixed it!
No Reboot needed. Just works. Is there a site that lists all workarounds if they are needed?
Regards Stephan
Tuesday, August 15, 2017 3:04 PM
Still experiencing this issue even after removing KB4025335, rebooting and adding the DWORD entry.
KB4025335 has been superseded by KB4034681 which is now installed on the NPS server, the DWORD entry is still in place.
I've checked the certificate on the server used for the authentication of WLAN clients and the subject name is populated with the server FQDN.
Alas, Windows 7 laptop user still cannot connect to the WLAN.
Any ideas on what else to try?
Thanks
Matt
Sunday, August 27, 2017 10:19 AM | 1 vote
Hi all,
After many many checks and spending many more times,
wusa /uninstall /kb:4034681
and reg entry
On the server, set the following DWORD registry key's value to = 0: SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13\DisableEndEntityClientCertCheck
Fixed.
Thanks !!
Monday, August 28, 2017 6:35 AM | 1 vote
No need to remove it, just set this key:
On the server, set the following DWORD registry key's value to = 0: SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13\DisableEndEntityClientCertCheck
Monday, September 11, 2017 5:44 AM
Juli update broke it, fixed it with the reg key and GPO preferences.
Thursday, September 14, 2017 6:30 PM
I'm having the same issue. I've already tried all the solutions posted here. My environment DC's 2012 R2, NPS on Server 2016, unique CA on Server 2012, we are using PEAP, authenticating computers. The switch is cisco 2960x.
Checked the DNS registers. The subjetc name in the certificates is correct. I'm using IAS & RAS certificate template for server authentication, and workstation certificate template for computers. The certificate is issued by GPO correctly to both (server and client). I've already tried changing the shared secret key (all capitals or all lowers, not simbols). I've already set the registry key entry.
Is not working yet.
Any aditional ideas?
Monday, September 18, 2017 11:07 PM
No previous solutions listed here worked for me.
Be aware of this:
NPS must be Certification Authority, in my case SubCA (I followed this steps to configure the SubCA https://mizitechinfo.wordpress.com/2013/08/31/step-by-step-deploying-an-enterprise-subordinate-ca-in-server-2012-r2-part-2/ ). Thats all.
Enjoy.
Thursday, September 28, 2017 11:26 AM
Hi
Update KB4034681 also breakes NPS EAP Authentication .
https://support.microsoft.com/da-dk/help/4034681/windows-8-1-windows-server-2012-r2-update-kb4034681
There is a workaround provided with the link from MS.
Hi! Thanks
We have two NPS . One 2008r2 and one 2012r2. 2012r2 NPSs users had problem with connect to wifi corp network. This workaround resolve that problem.
Wednesday, November 29, 2017 3:08 AM
Joe,
Thank you so much. I was pulling my hair out here. You are a lifesaver!
Monday, December 4, 2017 10:13 AM
I had the same experience - Windows 8 clients could connect but not Windows 7 clients.
Turned out for in my case that the 'validate server certificate' checkbox is honored by Windows 8 but not necessarily by Windows 7. If the subject name of the certificate that the NPS server is using is blank then Windows 7 will throw these errors while Windows 8 connects happily. The fix was to use the RAS and IAS Server template in Certificate authority per this article.
http://technet.microsoft.com/en-us/library/cc754198.aspx
Indeed this was the solution but we had already a certificate in place with a filled "subject name" but still we followed the article and created a template with "compatility" Setting for 2012 R2 (reflects our env), deleted our old certificate, reissued a new one, restarted nps and everything worked (again)
we experienced this problem just after we did inplace upgrad our NPS from 2008 R2 to 2012 R2
Friday, April 6, 2018 12:42 PM
I had the same experience - Windows 8 clients could connect but not Windows 7 clients.
Turned out for in my case that the 'validate server certificate' checkbox is honored by Windows 8 but not necessarily by Windows 7. If the subject name of the certificate that the NPS server is using is blank then Windows 7 will throw these errors while Windows 8 connects happily. The fix was to use the RAS and IAS Server template in Certificate authority per this article.
http://technet.microsoft.com/en-us/library/cc754198.aspx
One more vote for this solution - was indeed a blank subject name in the certificate on the NPS server - using the CA cert template RAS and IAS server solved it
Tuesday, June 26, 2018 6:04 PM
Our previously working NPS authentication solution has suddenly stopped working this week.
All windows 7 clients are no longer able to authenticate with the reason code 16
I have verified the Cert with the subject name included, tried the registry change, and attempted other options for the RADIUS shared password.
Any other ideas would be appreciated.
Thursday, June 28, 2018 2:22 PM
We're seeing the same thing on two new domain members, one running Win 10 1709 and the other 1803. Wireless 802.1x works fine, wired throws reason code 16. I have an active case with Microsoft support going right now.
Wednesday, January 16, 2019 5:41 PM
Any chance you got a solution, get notifications if anyone replies to a 6 month old post AND you'd be willing to share what it was?
Thursday, March 14, 2019 11:55 AM
Basically our issue was using a wildcard certificate in combination with .local domain type. If your network policy for NPS uses PEAP, be sure to check validity of the certificate.
Step by step guide is here: https://www.entrustdatacard.com/knowledgebase/how-is-the-server-certificate-installed-on-microsoft-network-policy-server-nps-on-windows-2008-server
Thursday, February 27, 2020 5:34 PM
My case with NPS on 2019 DC: GP - Network Security:LAN Manager authentication level. Suddenly was set to: "Send NTLMv2 only. Refuse NTLM&LM". That`s do not work. What works: "Send NTLMv2 only. Refuse LM".
Seems like NPS used NTLM v1 for authentication for clients, comes from RADIUS. Don`t block NTLM completely for DCs.
Monday, April 6, 2020 6:33 PM
Anyone else have any ideas? I just upgraded all our NPS servers to 2019 and now none of my Windows 7 computers and a few printers cannot authenticate. They get the same error code 16. I have played with many different certificate settings. The current PEAP certs have the DNS name as the subject as well as the SAN. I have tried the DisableEndEntityClientCertCheck on and off. Alaso tried the LAN Manager auth level. None of it has worked. I never had any issues with WIN10 and the majority of my printers.