Microsoft recently introduced Entra Private Access, an identity-centric Zero Trust Network Access (ZTNA) solution to provide secure remote access to on-premises resources. With Entra Private Access, administrators can leverage Entra Conditional Access to enforce policy-based access control for network access. However, Entra Private Access isn’t for everyone. It does not provide full feature parity with Always On VPN, and there are also licensing considerations. However, for those organizations using Always On VPN, the good news is that you can integrate Entra Conditional Access with Always On VPN today to gain some of the security benefits it provides.
Conditional Access
Microsoft Entra Conditional Access is a security feature that enables administrators to create and enforce policies that specify how users can access resources. In the specific case of Always On VPN, conditional access is critical to ensuring legitimate access to authenticated users on authorized devices.
Signals
Conditional access policies use a wide variety of signals for policy enforcement, such as:
User Identity: Who is making this access request?
User Properties: Is this user a member of a specific group?
Location: Where is this access request originating?
Device Management: Is this device joined to Entra ID?
Device State: Is this device compliant with security policies?
Device Platform: Is this a Windows device?
Risk Level: Is this login considered risky?
Access Control
Based on these signals, administrators can design a conditional access policy to enforce granular access control, such as:
Enforce specific authentication types (e.g., phishing-resistant credentials)
Allow access only from specific device platforms (e.g., Windows only)
Require Entra hybrid-joined device
Block access when a device is not compliant with security policies
Always On VPN
Entra Conditional Access works with Always On VPN by issuing a special, short-lived user authentication certificate once the user has been authorized. The Always On VPN infrastructure can be configured to use this certificate to grant access to the VPN. Integrating conditional access with Always On VPN can significantly improve the security posture of organizations using this feature.
Are you ready? In just a few short weeks(!) Microsoft will release the February 2025 security updates. This is a critical update because Microsoft plans to enable full enforcement of strong certificate mapping on Active Directory Domain Controllers (DCs) with this release. Administrators unprepared for this may incur outages for workloads using certificate-based authentication such as Always On VPN, Wi-Fi, and others.
Microsoft introduced strong certificate mapping with the May 2022 update KB5014754 to address vulnerabilities identified with certificate-based authentication. The update makes changes to Active Directory Certificate Services (AD CS) certification authorities (CAs) to embed the principal’s Security Identifier (SID) on issued certificates with a new certificate extension. The update also changes domain controller behavior to monitor and optionally enforce strong certificate mapping for authentication.
Enforcement Mode
When first introduced, the update is configured in compatibility mode. If a certificate that isn’t strongly mapped is presented for authentication, an event is recorded in the event log indicating that. Microsoft has been planning for years to enable full enforcement. After many delays, that time is now upon us. Specifically, full enforcement for strong certificate mapping will be enabled by default on DCs after applying the February 2025 security updates.
Note: Administrators can switch back to compatibility mode for now. See below for more details.
Limitations
Initially, the strong certificate mapping update was applied only to online certificate templates. Specifically, those templates are configured to build the subject name from Active Directory information. However, offline templates, where the subject name is supplied in the request, do not include this information by default. Crucially, any certificate issued with Microsoft Intune with PKCS or SCEP uses offline templates and is not strongly mapped. The lack of strong certificate mapping options for Intune-issued certificates forced Microsoft to delay its full enforcement deadline until these limitations were resolved.
Updates
In October 2024, Microsoft Intune announced support for strong certificate mapping for PKCS and SCEP certificates. Administrators can now configure these certificates to include strong certificate mapping. However, administrators must take action to affect this change.
PKCS
To enable strong certificate mapping for PKCS certificates, administrators must ensure that the certificate connector is running at least version 6.2406.0.1001. In addition, the following registry key must be configured on the connector server.
The Intune Certificate Connector server must be restarted for this change to take effect. No changes are required on the PKCS certificate policy in Intune.
SCEP
To enable strong certificate mapping for SCEP certificates, administrators must add the following attribute/value pair to the Subject alternative name settings on their existing Intune SCEP certificate policy.
Attribute: URI Value: {{OnPremisesSecurityIdentifier}}
Preparation
Administrators using certificate-based authentication against on-premises Active Directory should ensure all user and device authentication certificates include embedded SID information. For certificates issued on-premises, with Intune using PKCS or certificates issued by Entra Conditional Access, the certificate should now have the extension 1.3.6.1.4.1.311.25.2, including the principal’s SID.
SCEP certificates issued using Intune will include the following information in the Subject Alternative Name field.
URL=tag:microsoft.com,2022-09-24:sid:<sid>
Note: This applies to certificates issued using Cloud PKI for Microsoft Intune as those certificates are deployed using a SCEP device configuration policy.
Opt-Out
With the February 2025 security update, all domain controllers will be switched to full enforcement mode. Authentication requests using certificates without strong mapping will be denied in this configuration.
If your organization is not prepared to move to full enforcement mode, the February 2025 update allows administrators to opt out and switch back to compatibility mode by enabling the following registry key on all domain controllers.
Administrators are strongly encouraged to update all user and device authentication certificates before September 2025. With the September 2025 security update, Microsoft will no longer honor the opt-out registry settings and strictly enforce strong certificate mapping for all certificate-based authentication requests.
Troubleshooting
Certificate authentication is commonly used for Always On VPN and Wi-Fi authentication. If full enforcement mode is enabled on domain controllers and a certificate is presented for authentication that is not strongly mapped, administrators may see the following event log information recorded on the Network Policy Server (NPS).
Network Policy Server denied access to a user.
The details of the event include the following.
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.
Obviously, the user does not enter their password when using certificates for authentication. However, the indication of a credential mismatch can be caused by missing strong certificate mapping information when the DC is in full enforcement mode.
Note: There are other causes for reason code 16 failures on NPS. Further investigation may be required to determine the root cause.
Microsoft Cloud PKI for Intune is a PKI-as-a-Service offering that allows organizations to issue and manage digital certificates without on-premises infrastructure. Certificates are excellent phishing-resistant credentials that are well-suited for applications requiring strong authentication, such as secure remote access with Always On VPN. However, administrators may encounter errors when attempting to authenticate users or devices using certificates issued by Cloud PKI for Intune.
Error 853
After publishing certificates with Cloud PKI for Intune and configuring the on-premises Always On VPN infrastructure to support this, administrators will find that the Always On VPN connection fails to connect. Attempts to manually start the connection result in the following error message.
“The remote access connection completed, but authentication failed because the certificate that authenticates the client to the server is not valid. Ensure the certificate used for authentication is valid.”
In the event log on the Windows client, you’ll find an event ID 20227 from the RasClient source that includes the following error message.
“The user <domain>\<user> dialed a connection named <VPN connection name> which has failed. The error code returned on failure is 853.”
Error 853 (ERROR_EAP_USER_CERT_INVALID) indicates the user certificate is invalid.
Certificate
Upon further investigation, the certificate shows no issues, is valid, is trusted, and has a private key.
NPS
Looking at the event log on the Network Policy Server (NPS), you’ll find a corresponding event ID 6273 from the Microsoft Windows security auditing source that includes the following error message.
“Network Policy Server denied access to a user.”
Looking at the authentication details section of this event log entry yields the following important clue.
Reason Code: 258 Reason: The revocation function was unable to check revocation for the certificate.
Failed Revocation Check
Since the NPS server indicates that it rejected the authentication request because it could not perform a revocation check, let’s bring the user authentication certificate to the NPS server and perform some tests.
Export Certificate
Open the user certificate store (certmgr.msc) on the client and expand Personal > Certificates. Right-click on the certificate in question and choose All Tasks > Export. Export the certificate only (not the private key) and copy the file to the NPS server.
Verify Certificate
Open a PowerShell or command window on the NPS server and run the following command to validate the certificate.
certutil.exe -verify -urlfetch <path to exported certificate>
For example.
certutil.exe -verify -urlfecth .\rdeckard.cer
The command generates a lot of output, but if you look at the very end of the data stream, you’ll see two interesting items.
Revocation check skipped – no revocation information available
Leaf certificate revocation check passed
Based on this information the user certificate (the leaf certificate) passed a revocation check. However, it would appear that another certificate in the chain does not include revocation information. Since there is only a root and issuing CA in the chain, and root certificates don’t include revocation information because they are the self-signed root of trust, it would appear that revocation information is missing from the issuing CA certificate.
We can confirm this by scrolling up in the previous command’s output to where the verification of the issuing CA certificate takes place. Here, you’ll see that the issuing CA certificate is missing CDP (CRL Distribution Point) information.
When NPS attempts to validate the certificate and the certificate chain, it expects to find CDP information, which it will use to check if the issuing CA certificate has been revoked. The revocation check fails without this information, and the authentication request is rejected.
Design Error?
Missing CDP information is not unusual for end-entity (leaf) certificates when they are short-lived. An example is Entra ID conditional access certificates, which do not include CDP information by design. However, I expect this information to be listed on an issuing CA certificate. Why it’s not there, I’m not sure. I’ll investigate this in more depth and report on anything I learn that’s new.
Workaround
To move forward using Cloud PKI for Intune certificates with Always On VPN, administrators must implement the following registry setting on all NPS servers handling authentication requests for Always On VPN servers.
Key = HKLM\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13 Name = IgnoreNoRevocationCheck Type = DWORD Value = 1
To implement this change using PowerShell, open an elevated PowerShell command window and run the following command.
