I’m very excited to announce that I will be attending the annual Techmentor Conference at the Microsoft HQ campus in Redmond, Washington, this year. The event takes place August 11-15, 2025. The Techmentor Conference is one of my favorite IT pro conferences because it offers unparalleled access to experts worldwide. I will deliver two presentations at this year’s event. I hope you’ll join me!
Entra Private Access
On Tuesday, August 12, 2025, I will be presenting a session on Zero Trust Network Access with Microsoft Entra Private Access. ZTNA is the future of remote access and provides many security and operational benefits over traditional client-based VPN technologies.
On Wednesday, August 13, 2025, I’ll discuss Simplified Certificate Management with Microsoft Cloud PKI for Intune. As organizations integrate cloud-native devices in their environments, administrators must solve the problem of issuing and managing certificates for users and devices that are not domain-joined. Cloud PKI for Intune is an excellent solution that provides deployment flexibility to address these unique and specific requirements.
Registration for the event is open now. Use the promo code HICKS and receive $500.00 off the price of admission. Don’t miss this excellent opportunity to learn from the best. Register today!
Recently, I wrote about Microsoft Always On VPN and Entra Conditional Access and how conditional access improves your organization’s security posture by making policy-based access decisions based on various signals such as user identity, location, device compliance, platform, sign-in risk, and more. In this post, I’ll provide step-by-step instructions for integrating Entra Conditional Access with existing Always On VPN deployments.
Requirements
To use Microsoft Entra Conditional Access with Always On VPN you must have Entra ID P1 at a minimum. To use advanced features such as risk-based policy assessment, you must have Entra ID P2. In addition, all endpoints must be under Intune management; either native Entra ID joined, or hybrid Entra ID joined.
Enable VPN Support
To begin, open the Microsoft Entra admin center (https://entra.microsoft.com/), navigate to Identity > Protection > Conditional Access, and perform the following steps.
Click VPN Connectivity.
Click New certificate.
From the Select duration drop-down list, choose an appropriate certificate validity period.
Click Create.
Once complete, click Download certificate and copy the certificate file to a domain-joined system on-premises.
Publish Certificate
Next, administrators must publish the Entra VPN root certificate in Active Directory to support domain authentication. Open an elevated PowerShell or command window and run the following commands.
certutil.exe -dspublish -f <path to certificate file> RootCA
certutil.exe -dspublish -f <path to certificate file> NtAuthCA
Note: You must be a domain administrator to perform this task.
Conditional Access Policy
Navigate to Identity > Protection > Conditional Access and click Policies, then perform the following steps to create a conditional access policy for VPN access.
Click New Policy.
Enter a descriptive name for the new policy.
Click the link in the Target resources section.
From the Select what this policy applies to drop-down list, select Resources (formerly cloud apps).
In the Include section, choose Select resources.
Click the link in the Select section.
Enter VPN in the search field.
Check the box next to VPN Server.
Click Select.
Click the link in the Grant section.
Select Grant access.
Check the box next to Require device to be marked as compliant.
Click Select.
On the Enable policy slider, select On.
Click Create.
NPS
Changes to Network Policy Server (NPS) policy and configuration are required to support Always On VPN with Entra Conditional Access.
NPS Policy
To update the Always On VPN network policy to support Entra Conditional Access, open the NPS management console (nps.msc), expand Policies, then select Network Policies and perform the following steps.
Right-click on the Always On VPN policy and choose Properties.
Select the Settings tab.
Select Vendor Specific in the RADIUS Attributes section.
Click Add.
Select the Allowed-Certificate-OID attribute.
Click Add.
Click Add.
Enter 1.3.6.1.4.1.311.87 in the Attribute value field.
Click Ok.
Click Ok.
Click Close.
Click Ok.
Important Note: This change will block new Always On VPN user tunnel connections until you update the client configuration. When integrating an existing Always On VPN implementation with Entra Conditional Access, consider creating a new NPS policy and corresponding security group to migrate users to conditional access seamlessly.
NPS Configuration
By default, NPS will perform revocation checks for certificates used for domain authentication. However, Entra Conditional Access uses short-lived certificates (one-hour lifetime) that do not include CRL Distribution Point (CDP) information. Therefore, administrators must change the NPS server configuration to disable revocation checking for certificates lacking this information.
To do this, open the registry editor (regedit.exe) and create a new registry key with the following settings.
Once complete, the server must be rebooted for the change to take effect.
Client Configuration
After making all required changes to the supporting infrastructure, you must also update the Always On VPN client configuration to leverage Entra Conditional Access. Changes to client configuration vary depending on the method used to deploy and manage Always On VPN client configuration settings.
Intune
When using Microsoft Intune and the native VPN policy type to deploy and manage Always On VPN client configuration settings, perform the following steps to update the VPN configuration to include Entra Conditional Access support.
Click Enable next to Conditional access for this VPN connection.
Click Enable next to Single sign-on (SSO) with alternate certificate.
Enter Client Authentication in the Name field.
Enter 1.3.6.1.5.5.7.3.2 in the Object Identifier field.
Enter the organization’s root certification authority (CA) certificate thumbprint in the Issuer hash field.
XML
When using a custom XML configuration file for Always On VPN client configuration settings deployed using Intune or PowerShell, edit the XML file, remove the existing <TLSExtensions></TLSExtensions> section, and replace it with the following.
In addition, add the following code between the <VPNProfile></VPNProfile> tags after <TrustedNetworkDetection>.
Note: You will find a sample XML configuration file you can copy and paste from on GitHub here.
DPC
When using Always On VPN Dynamic Profile Configurator (DPC) for managing Always On VPN client configuration settings, open the DPC group policy and navigate to Computer Configuration > Policies > Administrative Templates > DPC Client > User Tunnel Settings > Advanced and perform the following steps.
Following the guidance in this post to integrate Entra Conditional Access with Always On VPN can significantly improve your organization’s security posture. In the example above, the conditional access policy is a basic one. Yet, it dramatically reduces the attack surface for your remote access infrastructure by ensuring only compliant devices can establish a VPN connection.
Administrators can use advanced conditional access policy settings to strengthen the VPN’s security further by performing additional checks, such as requiring strong, phishing-resistant credentials and requesting multifactor authentication (MFA) for risky sign-ins.
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.
