I recently wrote about changes to certificate-based authentication affecting Always On VPN implementations. These changes were introduced by Microsoft’s security update KB5014754. When the update is installed on domain controllers and enterprise Certification Authorities (CAs), administrators can perform strong user mapping for certificates used for Active Directory authentication. However, when first introduced, the update came with some serious limitations that prevented administrators from enabling full enforcement mode for certificate mapping.
Limitations
When KB5014754 is installed on an enterprise issuing CA, a new certificate extension (1.3.6.1.4.1.311.25.2) is added to the issued certificate that includes the principal’s (user or device) Security Identifier (SID). However, this only occurs when an online template is used. An online template is one with the subject name built from Active Directory information. The SID is not embedded in certificates issued using an offline template. Offline templates are templates where the subject name is supplied in the request. There are two scenarios where this causes problems for Always On VPN.
Microsoft Intune
Certificates delivered with Microsoft Intune via the Intune Certificate Connector use an offline template. This applies to certificates using PKCS or SCEP. Today, the SID is not embedded by issuing CAs using offline templates.
Azure Conditional Access
The short-lived certificate issued by Azure when Conditional Access is configured for Always On VPN did not include the SID. However, that recently changed.
Recent Updates
Today we can scratch Azure Conditional Access off the list of limitations for Always On VPN. Microsoft recently introduced support for the new SID extension in Azure Conditional Access certificates, as shown here.
Now when an Azure Conditional Access certificate is issued to an on-premises user or device account that is synced with Azure Active Directory, Azure Conditional Access will include the SID information in the issued short-lived certificate.
Intune
Unfortunately, we’re still waiting for Microsoft to address the limitation with certificates delivered using Microsoft Intune. Hopefully we’ll see an update for that later this year.
Always On VPN client configuration settings are typically deployed in the user’s context. However, this presents a unique challenge when sharing a single device with multiple users who have an Always On VPN profile assigned to them. By design, Windows designates only a single user profile on a shared device to be “always on”. When multiple users with assigned Always On VPN profiles share the same machine, it could yield unexpected results.
Auto Trigger Profile
When an Always On VPN profile is provisioned to a user, Windows records information about this profile in the registry. Specifically, the Always On VPN profile’s name and GUID are recorded, as well as the user’s Security Identifier (SID) and the path to the rasphone.pbk file that contains the Always On VPN profile.
Multiple Users
When a new user logs on to a shared device and receives their Always On VPN profile, Windows overwrites this existing data in the registry with the current user’s information. Each time this user logs on, their Always On VPN connection will establish automatically. Any other users with Always On VPN profiles configured on the same shared device will no longer connect automatically after this. The most recently deployed Always On VPN profile will be designated the “always on” profile.
Connect Automatically
In the above scenario, any user with an assigned Always On VPN profile on the shared device can take over the “always on” designation by opening the VPN connection properties and checking the “Connect automatically” check box.
When this happens, this user will now own the “always on” profile, and other users on the shared device will no longer connect automatically.
Workarounds
If multiple users share a single device requiring Always On VPN connectivity, you have a few options.
Intune
If you are deploying Always On VPN client configuration settings using Intune, you must use the Custom device configuration profile template. Specifically, as shown here, you must deploy your XML configuration file using the ./Device/Vendor/MSFT/VPNv2/ OMA-DM URI.
Unfortunately, the native Intune VPN template does not support deploying Always On VPN profiles in the “all users” context.
PowerShell
When using PowerShell, either natively or with SCCM or another software deployment tool, administrators can use my Always On VPN deployment PowerShell script with the -AllUserConnection parameter.
PowerON DPC
When using PowerON Platforms’ Dynamic Profile Configurator (DPC) to deploy Always On VPN client configuration settings using on-premises Active Directory or via Intune, no changes are required. DPC deploys Always On VPN user profiles in the “all users” context by default.
Microsoft introduced important changes affecting certificate-based authentication on Windows domain controllers as part of the May 10, 2022 update KB5014754 that may affect Always On VPN deployments. The update addresses privilege escalation vulnerabilities when a domain controller is processing a certificate-based authentication request. The recommendation from Microsoft is that the update be applied to all Windows domain controllers and Active Directory Certificate Services (AD CS) servers as soon as possible.
After applying the update to certification authority (CA) servers, a non-critical extension with Object Identifier (OID) 1.3.6.1.4.1.311.25.2 is added to all issued certificates with the user or device security identifier (SID) included. Domain controllers with the update installed will use this information to validate the certificate used for authentication and ensure that it matches the information in Active Directory.
Domain Controllers
The update operates in Compatibility Mode, by default, when applied to domain controllers. Windows monitors authentication requests and records audit events for certificates presented for authentication under the following conditions.
No strong mapping (event ID 39) – The certificate has not been mapped explicitly to a domain account, and the certificate did not include the new SID extension.
Certificate predates account (event ID 40) – A certificate was issued before the user existed in Active Directory, and no explicit mapping could be found.
User’s SID does not match certificate (event ID 41) – A certificate contains the new SID extension, but it does not match the SID of the corresponding user account.
Certificate Mapping
Administrators can map certificates explicitly to accounts in Active Directory, but this results in a significant administrative burden in most environments. A better option is to reissue user and device authentication certificates after applying the KB5014754 update to all issuing CA servers.
Reenroll Certificates
Administrators should reissue user and device authentication certificates after applying the KB5014754 update. Open the Certificate Templates management console (certtmpl.msc), identify the user or device authentication certificate template, then right-click on the template and choose Reenroll All Certificate Holders.
Enforcement Mode
After applying update KB5014754, administrators should monitor domain controller event logs for event IDs 39, 40, and 41. Once all certificates have been updated, and none of these events have been recorded for 30 days, administrators can switch to Full Enforcement Mode by enabling it in the registry on all domain controllers.
Updated 12/8/2022: Microsoft has pushed back the original enforcement date of May 9, 2023, to November 14, 2023 “or later”. Stay tuned!
Updated 11/29/2022: Microsoft now states that the full enforcmenet mode date is now February 11, 2025 “or later”. Once again, stay tuned!
Known Issues
There have been some reports of authentication issues after installing the KB5014754 update. Early indications are that device authentication certificates missing a Subject Alternative Name (SAN) entry are to blame. Administrators are encouraged to update their device certificates to include the SAN entry. Optionally, but not recommended, administrators can place the update in disabled mode by editing the registry.
Note: An out-of-band update for these authentication issues is now available. See the reference links at the top of this article for more information.
Caveat
It’s important to understand that this new OID is added only to online templates. Online templates are those that build the subject information from Active Directory. Unfortunately, this new OID is NOT applied to offline templates (templates where the subject name is supplied in the request), such as those used for delivering certificates with Microsoft Endpoint Manager/Intune using PKCS or SCEP. It is impossible to move to enforcement mode when issuing user or device authentication certificates with Microsoft Endpoint Manager or Intune today. Microsoft is aware of this limitation and is working to address this issue as we speak. I expect a fix to be available sometime before the May 2023 deadline when Microsoft permanently switches on enforcement mode.
