All posts in category TPM

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

11 Comments

by Richard M. Hicks on February 13, 2023 • Permalink

Posted by Richard M. Hicks on February 13, 2023

https://directaccess.richardhicks.com/2023/02/13/always-on-vpn-authentication-failed-reason-code-16/

Intune Certificate Connector Service Account and PKCS

Microsoft Always On VPN administrators have two choices when deploying enterprise PKI certificates using Intune; PKCS and SCEP. I prefer using PKCS because it is easier to configure and manage. Also, PKCS requires no inbound connectivity, simplifying the deployment and reducing the organization’s public attack surface. Provisioning certificates using Intune is inherently risky. However, there are some steps administrators can take to mitigate much of this risk.

Note: The techniques described in this article also apply to the NDES server when using SCEP certificate deployment in Intune, with one exception noted below.

PKCS Security

The service account is the most critical aspect of configuring the Intune Certificate Connector for PKCS securely. The service account has permission to enroll for an exceedingly dangerous published certificate template. Specifically, the PKCS certificate template has the deadly combination of supplying the subject information in the request, and the Client Authentication enhanced key usage (EKU). Further, the scenario does not allow administrative approval to be enabled on the certificate template. If an attacker were to gain access to this certificate template, they could enroll as any principal they chose, including a domain administrator, and their request would be processed automatically. Subsequently, they could authenticate to Active Directory using only the certificate without knowing the account’s password.

Service Account

Using a Group Managed Service Account (GMSA) would be ideal in this scenario. However, the Intune Certificate Connector does not support using GMSA when using PKCS. With that, administrators must use a regular domain service account instead, which introduces additional risk. To enhance the overall security of the solution, consider performing the following PKCS service account hardening tasks when using the Intune Certificate Connector to issue PKCS certificates with Intune.

Standard User

The service account should be a standard domain user with no special privileges. The service should be dedicated to PKCS and not shared with other services in the enterprise. Create the account from scratch (do not duplicate another account!), and use a long, complex password. Document this password securely. In addition, ensure the PKCS service account is not a member of any other security groups. It does not require local administrator access, either.

Account Hardening

After creating the service account, click the Log On To button on the Account tab and ensure the account can only log on to the server(s) where you have installed the Intune Certificate Connector.

Next, check the box next to Account is sensitive and cannot be delegated in the Account options section.

In addition, select the option Deny access in the Network Access Permission section of the Dial-In properties page.

Finally, uncheck Enable remote control on the Remote control properties page.

Local Access Rights

Open the Local Group Policy Editor (gpedit.msc) on each server where you installed the Intune Certificate Connector. Navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment. Enable the following policy settings for the PKCS service account.

Deny access to this computer from the network
Deny log on as a batch job
Deny log on locally
Deny log on through Remote Desktop Services

Optionally these settings can be enforced on the Intune Certificate Connector server using Active Directory group policy.

Important Note: When implementing these settings for hardening an NDES server do not specify the Deny log on as a batch job user rights assignment.

Disclaimer

I am not an Active Directory security expert! The guidance provided here is based on my many years of Windows administrative experience, conversations with Identity and Access security professionals, and published guidance found on the Internet. If you have suggestions to further improve service account security, don’t hesitate to let me know! Please share in the comments, below.