Microsoft introduced changes to Windows domain controllers in the February 2025 security update that may result in authentication failures for Always On VPN user tunnel connections. If you suddenly find that all your Always On VPN user tunnel connections fail, additional changes may be required to resolve the issue.
Authentication Failure
Administrators may find that Always On VPN connections fail after applying the February 2025 Microsoft security updates. Specifically, users may receive the following warning message.
“The remote access connection completed, but authentication failed because the certificate that authenticates the client to the server is not valid. Ensure that the certificate used for authentication is valid.”
Error 853
Administrators will also find a corresponding event log entry with event ID 20227 from the RasClient source with the following error message.
“The user <username> dialed a connection named <connection name> which has failed. The error code returned on failure is 853.”
NPS Events
The event log on the NPS server will also record event ID 6273 from the Microsoft Windows security auditing source with the following error message.
“Network Policy Server denied access to a user.”
The authentication details of the event include Reason Code 16 with the following 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.”
DC Events
If the issue is related to changes implemented to domain controllers in the February 2025 security update, administrators will also find a corresponding event log entry on a domain controller with event ID 39 from the Kerberos-Key-Distribution-Center source with the following error message.
“The Key Distribution Center (KDC) encountered a user certificate that was valid but could not be mapped to a user in a secure way (such as via explicit mapping, key trust mapping, or a SID). Such certificates should either be replaced or mapped directly to the user via explicit mapping.”
Root Cause
The above conditions indicate that a user attempted to authenticate to the VPN with a certificate that was not strongly mapped. Most likely, the certificate was issued using Microsoft Intune with SCEP or PKCS. This results from changes made to domain controllers in the February 2025 security update that requires certificates used for Active Directory authentication to be strongly mapped. Until now, domain controllers allowed access and only logged an event in the event log when a certificate did not include strong certificate mapping. The February 2025 security update now enforces strong certificate mapping, and authentication requests will fail without it.
Resolution
Administrators must issue new certificates that are strongly mapped to resolve this issue. For certificates issued with PKCS, changes are required on the Intune Certificate Connector server before re-issuing. For certificates issued with SCEP, changes to the device configuration policy are required. See the post Strong Certificate Mapping for Intune PKCS and SCEP Certificates for more details.
Workaround
Re-issuing certificates takes time. To restore connectivity immediately, administrators can implement the following registry settings on all domain controllers to switch back to audit mode and allow authentication without strong certificate mapping.
Key: HKLM:\SYSTEM\CurrentControlSet\Services\Kdc
Name: StrongCertificateBindingEnforcement
Type: DWORD
Value: 1
I recommend deploying this setting via GPO assigned to the Domain Controllers OU. However, you can also implement this change using PowerShell if necessary.
New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Services\Kdc’ -Name ‘StrongCertificateBindingEnforcement’ -PropertyType DWORD -Value 1 -Force
Additional Information
Strong Certificate Mapping for Intune PKCS and SCEP Certificates
Strong Certificate Mapping Enforcement February 2025
Certificate-Based Authentication Changes and Always On VPN
DirectAccess is a thing of beauty when everything is working as it should. When it isn’t, troubleshooting can be quite challenging. DirectAccess relies on many Windows platform technologies such as Active Directory for authentication, PKI for certificate management, group policy for settings deployment, IPsec for encryption, and IPv6 for transport. With so many dependencies, locating the source of the problem can be a difficult and daunting task.
