Always On VPN Intermittent 13801 Error

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.

  1. Right-click the VPN device authentication certificate template and choose Properties.
  2. Select the Extensions tab.
  3. Click on Application Policies.
  4. Click Edit.
  5. Click Add.
  6. Select the IP security IKE intermediate application policy.
  7. Click Ok.
  8. Click Ok.
  9. 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.

Summary

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.

Additional Information

Troubleshooting Always On VPN Error 13801

Troubleshooting Always On VPN Error 13806

Troubleshooting Always On VPN Error 13868

Strong Certificate Mapping Enforcement February 2025

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.

Reminder: There’s still space available in my Certificates and Intune Masterclass. Register now!

KB5014754

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.

Key: HKLM\Software\Microsoft\MicrosoftIntune\PFXCertificateConnector
Name: EnableSidSecurityExtension
Type: DWORD
Value: 1

You can implement this change by opening an elevated PowerShell command window and running the following command.

Set-ItemProperty -Path ‘HKLM:\SOFTWARE\Microsoft\MicrosoftIntune\PFXCertificateConnector’ -Name EnableSidSecurityExtension -Value 1 -Force

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.

Key: HKLM:\SYSTEM\CurrentControlSet\Services\Kdc
Name: StrongCertificateBindingEnforcement
Type: DWORD
Value: 1

You can implement this change by opening an elevated PowerShell command window and running the following command.

New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Services\Kdc’ -Name ‘StrongCertificateBindingEnforcement’ -PropertyType DWORD -Value 1 -Force

September 2025

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.

Additional Information

Training: Certificates and Intune Masterclass

Certificate-Based Authentication Changes and Always On VPN

Strong Certificate Mapping for Intune PKCS and SCEP Certificates

Entra Conditional Access Certificates with SID Information Now Available

Intune Strong Certificate Mapping Error

Strong Certificate Mapping Error with PKCS

KB5014754: Certificate-Based Authentication Changes on Windows Domain Controllers

Migrating from Always On VPN DPC Commercial to Open Source

Always On VPN Dynamic Profile Configurator (DPC) is a software solution that enables administrators to deploy and manage Always On VPN client configuration settings using Active Directory and Group Policy or Microsoft Intune. DPC began life as a commercial product. Recently, DPC has been released to the public via open source. DPC open source allows administrators everywhere to deploy the solution without cost. If you’re not using DPC today, I’d strongly recommend it. If you were previously a DPC commercial customer, you’ll want to migrate to DPC open source soon.

Migration

Migrating from DPC commercial to open source requires the administrator to deploy a Group Policy Object (GPO) and client software in a specific order to avoid disruption to end users. Perform the following steps to complete the migration.

GPO Files

Download the DPC v5.0 (open source) group policy settings file (ADMX) file here and the language definition (ADML) file here.

After downloading the files, copy dpc.admx to the following location.

\\<DC name>\sysvol\<domain name>\Policies\PolicyDefinitions

Next, copy dpc.adml to the following location.

\\<DC name>\sysvol\<domain name>\Policies\PolicyDefinitions\en-US

Once complete, allow domain controller replication to finish before deploying DPC group policy settings.

New GPO

Create a new GPO that will contain the VPN client configuration settings. Do NOT copy the original DPC commercial GPO. Starting with a blank GPO is best to ensure proper operation and prevent conflicts. Also, please note the location for DPC settings has changed. The new location for DPC v5.0 settings is:

Computer Configuration > Policies > Administrative Templates > DPC Client

You can now link the GPO to the applicable OU(s) or complete this task before deploying the new software.

Migration Tool

The easiest way to migrate from DPC commercial to open source is to migrate the settings from the current GPO to a new one. A PowerShell script is available to simplify this task. You can download the Migrate-DpcConfig.ps1 PowerShell script here.

Note: It is not strictly required to migrate your current settings from DPC commercial. Although this migration script makes importing settings easier, nothing prevents you from creating a new GPO for DPC open source and starting from scratch if you wish.

Prerequisites

The PowerShell migration script requires the installation of the Remote Server Administration Tools (RSAT). Specifically, the Group Policy Management tools are needed. Although it’s possible to run this script on a domain controller, it is not recommended. The best practice is to install the RSAT tools on an administrative workstation or server.

You can install the necessary RSAT feature on Windows 11 by opening an elevated PowerShell or command window and running the following command.

dism.exe /Online /add-capability /CapabilityName:Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0

On Windows Server, you can install the Group Policy Management tools by opening an elevated PowerShell command window and running the following command.

Install-WindowsFeature -Name GPMC

Once complete, restart the server to complete the installation process.

Import Settings

To migrate the DPC settings, open an elevated PowerShell command window and run the following command.

.\Migrate-DpcSetting.ps1 -PreviousGPOName <name of old DPC GPO> -NewGPOName <name of new DPC GPO>

For example,

.\Migrate-DpcSetting.ps1 -PreviousGPOName ‘Always On VPN DPC’ -NewGPOName ‘Always On VPN DPC – Open Source’

Apply GPO

If not done earlier, link the new DPC open-source GPO to the applicable OU(s). Do NOT unlink or delete the old GPO until all endpoints have been upgraded to the DPC v5.0 client.

Install Software

Once the new GPO has been configured and applied in Active Directory, the next step is to upgrade the DPC commercial client to the DPC open source client (v5.0). Software can be deployed via GPO using Active Directory software installation, SCCM, or any other method you use in your environment to deploy software. No switches or additional parameters are required to perform the upgrade. Simply run the .MSI file on the device, and the upgrade will occur automatically.

Important Note: Administrators must ensure that the new GPO settings are applied to the endpoint before installing the DPC v5.0 client.

Clean Up

After all endpoints have been upgraded to DPC v5.0, administrators can remove the DPC commercial GPO from AD. In addition, the commercial DPC ADMX and ADML files can be removed from domain controllers if desired.

Need Help?

If you’d like assistance migrating DPC commercial to open source, please don’t hesitate to reach out! I’m available to answer questions or provide remote assistance if necessary. You can reach me on the DPC-Chat channel on Discord here. Alternatively, you can fill out the form below, and I’ll provide more information.

Additional Information

PowerON Platforms Are No More

Always On VPN DPC Open Source

Always On VPN DPC Advanced Features

Always On VPN DPC with Microsoft Intune