Strong authentication is essential for remote access to on-premises resources over the public Internet. Using the Protected Extensible Authentication Protocol (PEAP) in combination with user certificates issued by the organization’s internal certification authority (CA) provides high assurance for remote user authentication. It includes the added benefit of making the Always On VPN connection completely seamless for the user, as their certificate is presented to the authentication server transparently during VPN connection establishment. Using PEAP with user certificates is the recommended authentication method for Always On VPN deployments.
Reason Code 16
When configuring Always On VPN to use PEAP with client authentication certificates, administrators may encounter a scenario in which a user has a valid certificate. Yet, their authentication request is rejected by the Network Policy Server (NPS) server when attempting to connect remotely. Looking at the Security event log on the NPS server, administrators will find a corresponding event ID 6273 in the Network Policy Server task category from the Microsoft Windows security auditing event source. In the Authentication Details section, you’ll find that the reason code for the failed request is Reason Code 16, with the following reason specified.
“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”.
Password Incorrect?
The reason code indicates the user may have entered an incorrect password. However, the user does not enter their password when using PEAP with client authentication certificates, so there’s no chance the password was entered incorrectly.
TPM
I have increasingly encountered this scenario with many customers deploying Always On VPN over the last year or so. This error is often caused by a known issue with older TPM models. Specifically, those with a TPM specification sub-version of 1.16 and earlier. You can view these TPM details by opening the Windows Settings app and entering ‘security processor’ in the search field.
Workaround
These older TPM models seem to have an issue with RSA-PSS signature algorithms, as described here. If possible, administrators should upgrade devices with older TPM versions to ensure the highest level of security and assurance for their remote users. However, in cases where that is not feasible, administrators can remove RSA-PSS signature algorithms from the registry, which forces the use of a different signature algorithm and seems to restore functionality.
To do this, open the registry editor (regedit.exe) and navigate to the following registry key.
HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\
Configuration\Local\SSL\00010003\
Double-click the Functions entry and remove the following algorithms from the Value data section.
- RSAE-PSS/SHA256
- RSAE-PSS/SHA384
- RSAE-PSS/SHA512
Once complete, reboot the device and test authentication once again.
Intune Proactive Remediation
Administrators using Intune Proactive Remediation will find detection and remediation scripts to make these changes published on GitHub.
Additional Information
Windows TPM 2.0 Client Authentication in TLS 1.2 with RSA PSS
Always On VPN NPS Auditing and Logging
Ryan Winn
/ February 24, 2023Thanks for publishing this, Richard. As you know we struggled with this for some time before we found the PSS issue. Our traces looked a bit different than the example article. The Client Hello for the initial TLS connection would show the signature hash algorithms for the PSS ones as “Unkown”. We ended up using a remediation script in Intune that would watch for user tunnels not connecting and getting the 16 error, then it would remove the PSS entries from the registry value. Worked like a charm!
Richard M. Hicks
/ February 27, 2023Thanks for the insight. Excellent idea to use Intune and Proactive Remediation to remove those ciphers on affected endpoints selectively. Thanks for the tip!
Jaroslav H.
/ March 24, 2023Hi. We have also encountered this problem and ended up with quite a lot of stations. If you have a working remediation script would it be possible to share? Thank you.
Richard M. Hicks
/ March 24, 2023Funny you should ask. 😉 I’m working on this as we speak. I hope to have this wrapped up in the next few days, time permitting. I’ll respond here again with the link once it is published.
Jaroslav H.
/ March 24, 2023Hi. We have also encountered this problem and ended up with quite a lot of stations. If you have a working remediation script would it be possible to share? Thank you.
Richard M. Hicks
/ March 24, 2023I’m assuming you are interested in detection/remediation scripts to use with Microsoft Intune proactive remediation, correct? That’s what I’m working on at the moment.
Jaroslav H.
/ March 24, 2023Yes that’s correct. That’s great. I’ve tried it too, but it doesn’t have the right quality 🙂
Sorry for the duplicate post.
Richard M. Hicks
/ March 24, 2023No worries. I’ll let you know as soon as it’s available.
Richard M. Hicks
/ March 24, 2023Detection and remediation scripts for this have been posted to GitHub. Enjoy!
https://github.com/richardhicks/endpointmanager/blob/main/Detect-RsaePssCiphers.ps1
https://github.com/richardhicks/endpointmanager/blob/main/Detect-RsaePssCiphers.ps1
Aleksandar Ristovski
/ March 25, 2023Hi,
I’m having same Reason Code: 16 on NPS server.
On end user side error 860 (user tunnel) when trying to establish connection.
AOVPN servers are in Azure, on them i have following:
The following error occurred in the Point to Point Protocol module on port: VPN1-999, UserName: [email protected].
The connection was prevented because of a policy configured on your RAS/VPN server. Specifically, the authentication method used by the server to verify your username
and password may not match the authentication method configured in your connection profile. Please contact the Administrator of the RAS server and notify them of this error.
Laptop that i have is fairly new, and TPM chip is 01/28/2021
Tried also registry edit, no progress:
RSAE-PSS/SHA256
RSAE-PSS/SHA384
RSAE-PSS/SHA512
Checked and recreated network and connection policies, nothing works so far.
NPS is Server 2019 standard, VPN servers also Server 2019 standard. Client is Windows 10 Enterprise 22H2
All worked fine till 2 days ago.
Any suggestion is appreciated, i’m out of ideas what went wrong and why this is happening….
KR,
Richard M. Hicks
/ March 25, 2023There are numerous things that could result in Reason Code 16 on your NPS server. Make sure all of your domain controllers have a Kerberos Authentication certificate issued by your internal CA. Also, make sure all of your issuing CA server certificates are in the NTAuth store in the domain. I’d check on the NPS server itself just to make sure. More details here: https://directaccess.richardhicks.com/2021/08/02/troubleshooting-always-on-vpn-error-853/.