Always On VPN and Cloud PKI for Intune Error 853

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.

New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13\’ -Name IgnoreNoRevocationCheck -PropertyType DWORD -Value 1 -Force

Once complete, restart the NPS server for the changes to take effect.

Additional Information

Cloud PKI for Microsoft Intune

Cloud PKI for Microsoft Intune and Active Directory

Cloud PKI for Microsoft Intune and Certificate Templates

Strong Certificate Mapping for Microsoft Intune PKCS and SCEP Certificates

Troubleshooting Intune Failed PKCS Request

Cloud PKI for Microsoft Intune SCEP URL

Delete A Cloud PKI for Microsoft Intune Certificate Authority

Cloud PKI for Microsoft Intune on RunAs Radio Podcast

Mastering Certificates with Microsoft Intune Online Training

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

Always On VPN DPC Open Source

Recently, I wrote about the demise of PowerON Platforms, the company behind the popular Always On VPN Dynamic Profile Configurator (DPC) software that allows administrators to deploy and manage Always On VPN client configuration settings using Active Directory Group Policy or Microsoft Intune with custom ADMX/ADML. Initially, the future of DPC was uncertain. However, I’m happy to announce that DPC will continue to be developed.

DPC Open Source

The lead developer of DPC and my good friend Leo D’Arcy retained the source code for the product and has been working diligently to decommercialize the software. That work has been completed, and Always On VPN DPC is now available via open source. You can find the source code for DPC on GitHub here.

DPC Features

This initial open-source release (version 5.0.0) contains no significant new features or functionality. Most of the development efforts focused on removing references to PowerON Platforms (registry paths, binary names, etc.).

Support

Today, DPC support is community-based. You can report issues on the GitHub issues page for DPC. In addition, you can ask questions about DPC on Discord in the Microsoft Remote Access UG. Leo and I will monitor the group closely and answer any questions you might have there.

Deployment

If you’re not a DPC user today, I encourage you to have a look at its impressive feature set. Not only does DPC make Always On VPN deployment and management easier, but it also includes many advanced capabilities that will make connections more stable and reliable. Here are some links to articles outlining some of those advanced features.

Migration

If you already have a previous commercial release of Always On VPN DPC deployed, migrating to the new open-source DPC is straightforward. You will find guidance for migrating your existing DPC configuration here.

Contribute

Now that DPC is open source, we encourage everyone to contribute. If you have development skills, feel free to help. If you have feedback or feature requests, don’t hesitate to submit them!

Learn More

Are you interested in learning more about Always On VPN DPC? Would you like a personal demonstration of DPC’s features and capabilities? Do you need help migrating from a previous release to the new open-source software? Fill out the form below and I’ll contact you with more information.

Additional Information

Always On VPN DPC Open Source on GitHub

PowerON Platforms Are No More