Always On VPN Authentication Failed Reason Code 16

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.

Detect-RsaePss.ps1

Remediate-RsaePss.ps1

Additional Information

Windows TPM 2.0 Client Authentication in TLS 1.2 with RSA PSS

Always On VPN NPS Auditing and Logging

Always On VPN NPS RADIUS Configuration Missing

Always On VPN NPS Load Balancing

Always On VPN Error 13868

Troubleshooting Always On VPN Error 691 and 812 – Part 2

The Internet Key Exchange version 2 (IKEv2) VPN protocol is the protocol of choice for Microsoft Always On VPN deployments where the highest levels of security and assurance are required. However, as I’ve written about in the past, often the default IKEv2 security settings are less than desirable. Before using IKEv2 VPN in a production environment the administrator will need to update these security settings accordingly.

Connection Failure

When configuring Windows Server Routing and Remote Access Service (RRAS) or a third-party VPN appliance to support IKEv2 using custom security policies, the administrator may encounter a scenario in which a connection cannot be established due to a policy mismatch error. When the connection attempt fails, an error will be recorded in the Windows Application event log from the RasClient source with Event ID 20227. The error message states the following:

“The user [username] dialed a connection named [connection name] which has failed. The error code returned on failure is 13868.”

Always On VPN IKEv2 Policy Mismatch Error

Error Code 13868

Error code 13868 translates to ERROR_IPSEC_IKE_POLICY_MATCH. Essentially this error indicates that the IKEv2 security policy on the client did not match the configuration on the server.

Server Configuration

To view the current IKEv2 IPsec policy configuration, open an elevated PowerShell command window and run the following command.

Get-VpnServerIPsecConfiguration

Always On VPN IKEv2 Policy Mismatch Error

Client Configuration

To ensure interoperability, the VPN client must be configured to use the same IKEv2 security policy as defined on the sever. To view a VPN client’s currently configured IKEv2 security policy, open an elevated PowerShell command window and run the following command.

Get-VpnConnection -Name [connection name] | Select-Object -ExpandProperty IPsecCustomPolicy

Always On VPN IKEv2 Policy Mismatch Error

Note: If this PowerShell command returns no output, the VPN connection is not using a custom IKEv2 IPsec security policy.

Updating Settings

Guidance for configuring IKEv2 security policies on Windows Server RRAS and Windows 10 can be found here.

NPS Policy

Another common cause of IKEv2 policy mismatch errors is a misconfigured Network Policy Server (NPS) network policy. Specifically, administrators may disable Basic and Strong encryption for MPPE in an attempt to improve security.

Always On VPN IKEv2 Policy Mismatch Error

The NPS policy for Always On VPN must include Strong encryption at a minimum. Basic and No encryption can be safely disabled.

Always On VPN IKEv2 Policy Mismatch Error

Summary

IKEv2 policy mismatch errors can be resolved easily by ensuring both the VPN server and client are configured to use the same IPsec security policies. Use the PowerShell commands in the above referenced above to validate settings and make changes when necessary.

Additional Information

Microsoft Always On VPN Error 13801

Microsoft Windows Always On VPN Error 13806

Microsoft Windows Always On VPN Certificate Requirements for IKEv2

Microsoft Windows Always On VPN IPsec Root Certificate Configuration Issue

Microsoft Windows Always On VPN IKEv2 Policy Mismatch Error

Microsoft Windows Always On VPN IKEv2 Security Configuration

Microsoft Windows Always On VPN IKEv2 Fragmentation

Microsoft Windows Always On VPN IKEv2 Load Balancing and NAT

Microsoft Windows Always On VPN IKEv2 Features and Limitations

Always On VPN RADIUS Configuration Missing

Windows Server Routing and Remote Access Service (RRAS) is a popular choice for administrators deploying Always On VPN. It is easy to configure and scales out easily. Most commonly, RRAS servers are configured to use RADIUS authentication to provide user authentication for Always On VPN client connections. The RADIUS server can be Microsoft Network Policy and Access Server (NPAS, or simply NPS) or a third-party RADIUS solution. It is best to have the RADIUS service running on a server separate from the RRAS server.

RADIUS Authentication

Administrators can configure RADIUS authentication by opening the Routing and Remote Access management console (rrasmgmt.msc), right-clicking the VPN server, then choosing Properties > Security. Click the Configure button to configure authentication and accounting providers accordingly.

RADIUS Options Missing

In some cases, the administrator will notice that the option to configure RADIUS authentication and accounting servers is missing. In its place is the following error message.

“Because Network Policy Server (NPS) is installed, you must use it to configure authentication and accounting providers. To configure authentication and accounting providers, create or modify connection request policies.”

Configuration Options

It might be tempting for administrators to follow this guidance when presented with this message by opening the Network Policy management console (nps.msc) to configure it. However, that is not recommended or necessary. This message results from a common configuration error that should be corrected.

NPS Role Installed

The error message above occurs when an administrator mistakenly installs the NPAS role on the RRAS server itself. Again, this is not recommended or required. To resolve this issue, uninstall the NPS role by opening an elevated PowerShell command window and running the following command.

Uninstall-WindowsFeature NPAS

Configuration Corrupted

After removing the NPAS role from the RRAS server, administrators may encounter the following error message when configuring RADIUS authentication and accounting servers in RRAS.

“The connection request policy used for authentication and accounting configuration is corrupted. Either install Network Policy Server (NPS) and restore the connection request policy manually, or click Repair Settings to restore the connection request policy by using Windows Accounting and Windows Authentication.”

Repair Settings

To resolve this issue, click the Repair Settings button. Once complete, RADIUS authentication and accounting configuration should work as expected.

Additional Information

Always On VPN Network Policy Server (NPS) Auditing and Logging

Always On VPN Network Policy Server (NPS) Load Balancing

Always On VPN and Windows Server 2019 Network Policy Server (NPS) Bug