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.
With the October 2024 Intune update, Microsoft introduced support for strong certificate mapping for certificates issued by Intune via the Intune Certificate Connector. Enabling strong certificate mapping support in Intune is an important change for those organizations using Microsoft Intune to issue and manage certificates for their users and devices, as it resolves a critical implementation blocker.
Note: This post was updated to clarify that adding the {{OnPremisesSecurityIdentifier}} for PKCS certificates is not required. This variable is only used for SCEP certificates.
Background
In May 2022, Microsoft released security update KB5014754, which added functionality to domain controllers and enterprise issuing certification authority (CA) servers, allowing the Kerberos Key Distribution Center (KDC) to enforce strong certificate mapping. Specifically, with KB5014754 installed, issuing CAs now add the requesting principal’s Security Identifier (SID) to the certificate in a new certificate extension. Domain controllers can be configured to reject authentication requests using certificates that do not include this information.
Today, DCs with KB5014754 installed will still allow authentication without strong certificate mapping. However, Microsoft has stated they will begin enforcing strong certificate mapping in February 2025, with an option to disable it via the registry. Starting in September 2025, full enforcement will be mandatory.
The initial changes in KB5014754 applied only to online certificate templates, meaning those that build the subject name from Active Directory. However, deploying certificates with Intune using either PKCS or SCEP requires using an offline certificate template that allows the requestor to supply the subject name in the request. When using offline templates, a certificate is issued but does not embed the SID in the certificate. Using offline templates presents unique challenges to organizations moving to modern management with Intune and Entra ID.
Intune Changes
The October 2024 Intune update addresses this limitation by providing a method to include SID information in certificates using either SCEP or PKCS.
SCEP
To include the SID information in SCEP certificates, create or edit an existing SCEP device configuration policy and define a URI Subject Alternative Name (SAN) attribute with the value {{OnPremisesSecurityIdentifier}} as shown here.
PKCS
To include SID information in PKCS certificates, administrators must ensure the Intune Certificate Connector is updated to at least version 6.2406.0.1001. In addition, a registry setting must be enabled on the Intune Certificate Connector server.
On the server where the Intune Certificate Connector is installed, open the registry editor, navigate to HKLM\Software\Microsoft\MicrosoftIntune\PFXCertificateConnector, and change the value of EnableSidSecurityExtension to 1.
Optionally, administrators can update this setting at the command line by running the following PowerShell command.
Once complete, restart the Intune Certificate Connector server for the changes to take effect.
Certificates
SID information is added to certificates differently depending on which Intune device configuration policy type is used.
PCKS
PKCS certificates have the SID embedded in the certificate extension 1.3.6.1.4.1.311.25.2, as shown here.
SCEP
SCEP certificates have the SID embedded in the Subject Alternative Name (SAN) field in the format “tag:microsoft.com,2022-09-14:sid:<SID>” as shown here.
Migration
When making these changes to embed the SID in Intune-issued certificates in an existing Intune PKCS or SCEP configuration policy, the change will only affect certificates issued after the change is made. To update all certificate holders, you must create and deploy a new device configuration policy to targeted users or devices. Deleting the old profile (or ensuring it no longer applies) will remove the old certificate from the endpoint. If you’ve configured your Intune Certificate Connector to support revocation, the old certificate will also be revoked.
Entra Conditional Access
Entra Conditional Access certificates have included SID information since July 2023. More details here.
Intune Cloud PKI
The changes above will also work with certificates issued by Cloud PKI for Intune.
Other Cloud PKI Providers
Many other Cloud PKI providers, such as SCEPman and KEYTOS, already include the embedded SID in their certificates. Other cloud PKI providers may also include embedded SID. Consult your provider to confirm.