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

Always On VPN and Blast-RADIUS

Microsoft released an update for the Windows Server Network Policy Server (NPS) to address recently disclosed vulnerabilities in the Remote Access Dial-In User Service (RADIUS) protocol in the July 2024 security updates. RADIUS is an industry-standard authentication protocol widely used for remote access, including Always On VPN. The RADIUS protocol was first introduced in the early 1990s and, unfortunately, still relies on the deprecated MD5 cryptographic hash function. The good news is that this vulnerability does not affect Always On VPN. Read on to learn more.

Blast-RADIUS

Blast-RADIUS is an attack on the RADIUS protocol that allows an attacker to alter network authentication packets to gain access to a service relying on RADIUS for authentication by exploiting the weakness of MD5 integrity checks in RADIUS. In the absence other controls, an attacker could alter an authentication response and change the reply from Access-Reject to Access-Accept.

Considerations

It’s important to note that leveraging this attack is not trivial. It requires local network access, so the attacker must have a presence on the target network to carry out this attack. However, cloud-hosted RADIUS services are inherently more vulnerable. In addition, the attack is mostly academic today because the default timeout for authentication requests is typically short, usually between 5 and 30 seconds. This is not enough time (today) for an attacker to mount the attack. However, this attack could become more feasible if authentication timeouts are increased (sometimes required to support MFA) or if an attacker has access to vast computing resources.

Affected Protocols

Although Blast-RADIUS is a vulnerability in the RADIUS protocol itself, not all authentication protocols are affected. Specifically, this vulnerability affects services leveraging PAP, CHAP, MS-CHAP, and MS-CHAPv2. Extensible Authentication Protocol (EAP) and Protected Extensible Authentication Protocol (PEAP) are not vulnerable to this attack. Since Always On VPN requires EAP authentication, it is not susceptible to this attack.

Mitigation

Microsoft has published guidance in KB5040268 for mitigating Blast-RADIUS attacks on Windows NPS servers. Specifically, administrators are encouraged to enable the Message-Authenticator attribute in Access-Request packets sent by the network access server and to ensure the NPS server requires the Message-Authenticator attribute in any Access-Request messages it receives.

Note: The following changes are not required for Always On VPN or any other workload using EAP-TLS or Protected EAP, as these protocols use TLS natively to protect the authentication exchange.

NPS

To configure this setting in the UI, open the NPS management console (nps.msc) and perform the following steps.

  1. Expand RADIUS Clients and Servers.
  2. Highlight RADIUS Clients.
  3. Right-click the RADIUS client to configure and choose Properties.
  4. Select the Advanced tab.
  5. Check the box next to Access-Request messages must contain the Message-Authenticator attribute.

PowerShell

To configure this setting using PowerShell, open an elevated PowerShell command window and run the following command.

Set-NpsRadiusClient -Name <RADIUS client name> -AuthAttributeRequired $True

Additional NPS Settings

Administrators should also run the following commands on their NPS servers to further protect their infrastructure from Blast-RADIUS attacks.

netsh.exe nps set limitproxystate all = enable

netsh.exe nps set requiremsgauth all = enable

RRAS

When using Windows Server Routing and Remote Access (RRAS) without EAP, ensure the RADIUS server configuration always includes the Message-Authenticator. To configure this setting, open the Routing and Remote Access console (rrasmgmt.msc) on the RRAS server and perform the following steps.

  1. Right-click the VPN server and choose Properties.
  2. Select the Security tab.
  3. Click the Configure button next to the Authentication provider drop-down list.
  4. Highlight the RADIUS server and choose Edit.
  5. Check the box next to Always use message authenticator.

Repeat these steps for any additional configured RADIUS servers.

CLI

Administrators can implement this change at the command line by opening an elevated command window and entering the following command.

netsh.exe ras aaaa set authserver name = <name of RADIUS server> signature = enabled

For example:

netsh.exe ras aaaa set authserver name = nps.lab.richardhicks.net signature = enabled

New NPS Events

After installing the KB5040268 update on NPS servers, the NPS server will record event ID 4421 from the NPS source after a service start if the RequireMsgAuth or LimitProxyState settings are not configured.

“RequireMsgAuth and/or limitProxyState configuration is in Disable mode. These settings should be configured in Enable mode for security purposes.”

Optional Mitigation

If administrators cannot configure the above settings, consider using IPsec to secure network traffic at the transport layer. IPsec will protect all RADIUS traffic at the network layer to mitigate Blast-RADIUS attacks. Unfortunately, Windows Server NPS does not support TLS or DTLS, so IPsec is your only option.

Summary

Always On VPN is not vulnerable to the Blast-RADIUS attack. However, NPS is commonly a shared service in many organizations, and other workloads may use older, vulnerable protocols. Consider implementing the changes detailed in KB5040268 as outlined in above to ensure the integrity of your environment and mitigate these potential attacks.

More Information

Microsoft KB5040268: how to manage Access-Request packets attack vulnerability associated with CVE-2024-3596

RADIUS Protocol Vulnerability Exposes Networks to MitM Attacks

New Blast-RADIUS attack breaks 30-year-old protocol used in networks everywhere

Overview of Microsoft Protected Extensible Authentication Protocol (PEAP)

Always On VPN NPS Auditing and Logging

Microsoft Intune Cloud PKI

Recently, Microsoft introduced the general availability of its new PKI-as-a-service solution called Microsoft Intune Cloud PKI. Cloud PKI allows administrators to issue and manage user and device authentication certificates for Intune-managed endpoints without deploying Active Directory Certificate Services (AD CS) on-premises. Cloud PKI frees administrators from the burdens of deploying and managing AD CS, including the complicated Network Device Enrollment Service (NDES) server configuration required for Simple Certificate Enrollment Protocol (SCEP) certificate deployment with Intune.

Advantages

Microsoft Intune Cloud PKI offers many significant advantages over traditional on-premises AD CS deployments.

No Infrastructure

The most obvious advantage of using Cloud PKI is that you do not have to deploy and manage your own Certification Authority (CA). Although implementing AD CS isn’t that difficult, managing and operating a CA infrastructure securely can be quite challenging. In addition, a high-security AD CS deployment utilizes hardware secure modules (HSMs) to protect CA private keys, which are quite expensive and sometimes difficult to support.

Cloud-Hosted SCEP

Removing the requirement to configure and deploy your own NDES server to support SCEP certificates is certainly a welcome advantage. NDES is notoriously difficult to configure, secure, and troubleshoot when it doesn’t work correctly. Cloud PKI includes cloud hosted SCEP services that are highly available and redundant within the Microsoft Azure infrastructure.

Automatic Revocation

Cloud PKI automates the deployment of certificates to Intune-managed users and devices and automatically revokes certificates when they fall out of scope. Administrators can also manually revoke certificates using the Intune management console.

Reporting

Administrators can easily view the status of Cloud PKI-issued certificates in Intune. The UI shows the active, expired, and revoked certificates for the issuing CA.

Clicking View all certificates shows a detailed list of all certificates.

BYOCA

Another compelling feature of Cloud PKI is Bring Your Own CA (BYOCA). This feature enables administrators to deploy a cloud-hosted CA that is chained to their existing on-premises AD CS root CA. This is helpful for scenarios where AD CS is already in place and used to issue and manage certificates to existing domain-joined clients and servers. BYOCA effectively allows you to extend your existing CA infrastructure to the cloud and use Cloud PKI to issue and manage certificates for your Intune-managed endpoints while maintaining the full functionality and feature set of on-premises AD CS for non-Intune-managed devices.

Limitations

Although there are many advantages to Cloud PKI, there are some limiting factors to consider.

RSA Only

Today, Cloud PKI is limited to RSA keys only. Administrators can create CAs using RSA 2048, 3072, or 4096-bit keys. Elliptic Curve (EC) keys are not currently supported in Cloud PKI.

Intune Devices Only

Cloud PKI is limited to issuing certificates to Intune-managed devices only. Endpoints must be Entra-joined, or hybrid Entra-joined to enroll for certificates using Cloud PKI.

Inflexible Configuration

The Cloud PKI root and issuing CAs cannot be reconfigured after deployment. Since Cloud PKI root and issuing CAs don’t support the Any Purpose EKU (2.5.29.37.0), all EKUs must be defined when the CA is created. If, in the future, an administrator requires an EKU that was not present when the CA was deployed, an entirely new hierarchy (root and issuing CA) must be deployed.

Cost

There’s been much discussion about the cost associated with Cloud PKI. Cloud PKI can be licensed as part of the Intune Suite, which is $10.00 per user per month. Cloud PKI licenses will also be available as a standalone add-on for $2.00 per user per month. For large organizations, this might be cost-prohibitive.

Summary

Overall, Microsoft Intune Cloud PKI is a welcome addition to the Microsoft suite of cloud services. Certificates are excellent phishing-resistant credentials that can be used to improve security for organizations of all sizes. However, managing a CA can be tedious and time-consuming. Leveraging the cloud for PKI and certificate management will be helpful in many scenarios. However, Cloud PKI has some potential drawbacks, and many may not fit everyone.

More Information

Want to learn more about Microsoft Intune Cloud PKI and how it can benefit your organization? Take the first step towards streamlined certificate management and enhanced security for your organization. Fill out the form below, and I’ll provide more information about using Intune Cloud PKI to safeguard your digital assets confidently.