I’m excited to announce that I’ll be speaking at the Arizona Systems Management User Group (AZSMUG) at their next user group meeting on Friday, March 7, at 9:00 AM MST. I am presenting on the topic of Certificate Deployment Strategies with Microsoft Intune.
Intune and Certificates
My session at AZSMUG will provide an overview of issuing and managing certificates with Microsoft Intune. We’ll begin by examining common scenarios for certificate authentication and explore various delivery methods, including PKCS and SCEP. Additionally, we’ll discuss supporting technologies such as the Network Device Enrollment Service (NDES) and review deployment strategies and high availability options for the Intune Certificate Connector. The session will also cover Cloud PKI for Intune, integration with on-premises Active Directory, and best practices for securing certificate lifecycles and key management in enterprise environments.
Register Now
If you are in the Phoenix area and would like to attend the user group meeting on Friday, March 7, you will find the registration link here. Hope to see you there!
Always On VPN error 13801 is common when establishing an IKEv2 VPN connection. Typically, the issue is related to a configuration error or a problem with certificate deployment. However, administrators may encounter the 13801, an IKE authentication error, intermittently. Configuration errors are binary. If there is a misconfiguration, IKEv2 never works at all. However, a configuration error seems unlikely since the connection works occasionally yet fails at other times.
Client Authentication
The minimum application policy (Enhanced Key Usage, or EKU) requirement for the device authentication certificate for IKEv2 is Client Authentication (1.3.6.1.5.5.7.3.2). When intermittent 13801 errors occur, administrators may find multiple certificates in the local computer certificate store with the Client Authentication EKU issued by different certificate authorities. Commonly, Intune-managed Windows devices may include several certificates with Client Authentication.
Certificate Selection
When Windows attempts to establish an Always On VPN IKEv2 connection, and there are multiple certificates in the local computer certificate with Client Authentication defined, Windows must choose one certificate to use for the connection. If Windows chooses incorrectly, you will receive the 13801 IKE authentication failure error. If Windows selects the right one, the connection succeeds.
Resolution
There are several ways to resolve this issue. The best way is to update the Always On VPN device authentication certificate to include the IP security IKE intermediate application policy (EKU). When Windows encounters multiple client authentication certificates in the local computer certificate store, it will prefer any certificate with the IP security IKE intermediate application policy for IKEv2 VPN connections. Including the IP security IKE intermediate application policy on the Always On VPN device authentication certificate ensures proper certificate selection when multiple client authentication certificates are present.
Note: This change must be made to the Intune certificate enrollment template when using Intune with PKCS or SCEP.
Certificate Template
To update an existing Always On VPN device authentication certificate to include the IP security IKE intermediate application policy, open the certificate templates management console (certtmpl.msc) and perform the following steps.
Right-click the VPN device authentication certificate template and choose Properties.
Select the Extensions tab.
Click on Application Policies.
Click Edit.
Click Add.
Select the IP security IKE intermediate application policy.
Click Ok.
Click Ok.
Click Ok.
Once complete, any certificates issued after this change is applied will now include the IP security Ike intermediate application policy.
Force Renewal
Administrators may wish to update all certificates immediately rather than wait until they renew to receive the new setting. The course of action depends on how certificates are issued.
On-Premises
When issuing certificates using Active Directory Certificate Services (AD CS) on-premises, right-click the Always On VPN device authentication certificate template and choose Reenroll All Certificate Holders. This will force all domain-joined clients with Autoenroll permissions on the template to renew their certificate on their next enrollment cycle, regardless of the certificate’s lifetime.
Intune
Follow the steps below to force re-enrollment for all certificate holders when deploying certificates using Intune.
SCEP – Add the IP Security IKE Intermediate application policy to the Intune VPN policy. After this change is applied, Intune will reenroll all endpoints.
PKCS– A new Intune device configuration policy must be created that includes the IP security IKE intermediate application policy. Assign the new policy and remove the old one to replace all certificates.
PowerShell
It’s also possible to resolve this issue using PowerShell. Administrators can use the Set-VpnConnection PowerShell cmdlet to select a certificate based on the root certification authority (CA) or a specific custom application policy defined on the Always On VPN device authentication certificate. Be sure to add the -AllUserConnection switch when working with the device tunnel.
Root CA
Open a PowerShell command window and run the following command.
$RootCA = Get-Child-Item -Path Cert:\LocalMachine\My\<thumbprint of root CA certificate> Set-VpnConnection -Name <name of VPN profile> -MachineCertificateIssuerFilter $RootCA
Application Policy
Open a PowerShell command window and run the following command.
Set-VpnConnection -Name <name of VPN profile> -MachineCertificateEKUFilter <OID>
Note: When using a custom application policy Windows will return a warning message stating the EKU could not be validated. You can safely disregard this warning.
Intune Remediation
While running PowerShell commands locally might be helpful for troubleshooting and targeted evaluation testing, deploying settings via PowerShell at scale is challenging. For those organizations managing their devices using Microsoft Intune, I’ve published a few detection and remediation scripts on GitHub to perform these tasks.
The intermittent Always On VPN 13801 IKE authentication credentials are unacceptable error message is best resolved by updating the Always On VPN device authentication certificate to include the IP security IKE intermediate application policy (EKU). Although using PowerShell also works, it doesn’t scale effectively. SCCM or Intune remediations can help, but I’d encourage you to update the certificate template as best practice instead.
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.
