All posts tagged conditional access

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

3 Comments

by Richard M. Hicks on January 27, 2025 • Permalink

Posted in Active Directory, Active Directory Certificate Services, AD CS, administration, Always On VPN, AOVPN, authentication, Azure Active Directory, Azure AD, Azure VPN, CBA, Certificate Authentication, Certificate Authority, Certificate Connector for Intune, Certificate Services, Certificate-Based Authentication, certificates, cloud, Cloud PKI, Conditional Access, Endpoint Manager, Enterprise, enterprise mobility, Entra, Entra Conditional Access, Entra ID, InTune, Intune Certificate Connector, Intune PFX Connector, MDM, Microsoft, Microsoft Endpoint Manager, Microsoft Entra, Microsoft Entra ID, Microsoft Intune, Mobile Device Management, Mobility, Network Device Enrollment Service, Network Device Enrollment Services, network policy server, NPS, Operational Support, PFX Connector, PKCS, PKI, PowerShell, public cloud, public key infrastructure, Remote Access, SCEP, Security, Security Update, Simple Certificate Enrollment Protocol, systems management, troubleshooting, Update, user tunnel, VPN, Windows 10, Windows 11

Posted by Richard M. Hicks on January 27, 2025

https://directaccess.richardhicks.com/2025/01/27/strong-certificate-mapping-enforcement-february-2025/

Microsoft Entra Global Secure Access

Last week Microsoft introduced new Security Service Edge (SSE) capabilities as part of the Microsoft Entra suite of technologies. Included in these announcements, Microsoft introduced the public preview of two new secure remote access technologies – Microsoft Entra Internet Access and Microsoft Entra Private Access. The latter of these will particularly interest Microsoft Always On VPN administrators in some deployment scenarios.

Microsoft Entra Internet Access

Microsoft Entra Internet Access is a new Secure Web Gateway (SWG) cloud service solution designed to protect users from threats on the public Internet. Features include web content filtering, malware inspection, TLS inspection, and more. In addition, Entra Internet Access can protect Microsoft 365 applications. Azure Conditional Access policies can be enforced for Internet traffic. Network conditions are now included with Azure Conditional Access, which can further protect against attacks by requiring access from specific trusted or compliant networks. Today, the public preview is available for Microsoft 365 scenarios only. Internet traffic and other SaaS applications will be available later this year.

Microsoft Entra Private Access

Microsoft Entra Private Access is a Zero Trust Network Access (ZTNA) cloud service solution that leverages the Azure Application Proxy access model. With Azure App Proxy, administrators can easily publish private, on-premises web applications by installing the connector on an on-premises server. Administrators can leverage Azure AD authentication and conditional access policies to ensure device compliance or enforce multifactor authentication (MFA), if required. Microsoft Entra Private Access extends the capabilities of the Azure Application Proxy to support TCP and UDP-based applications.

Private Access vs. Always On VPN

Microsoft Entra Private Access will be a compelling alternative to Always On VPN in the future. Specifically, organizations using native Azure AD join devices could benefit tremendously from this technology. Microsoft Entra Private Access is much simpler to implement than Always On VPN and requires no on-premises infrastructure other than the Azure Application Proxy connector. Using Microsoft Entra Private Access also means that no inbound access from the Internet is required, making the solution inherently more secure and reducing the public attack surface. For organizations using hybrid Azure AD join, Always On VPN continues to be the best Microsoft solution for these scenarios.

References

Microsoft Entra Expands into Security Service Edge (SSE)

Microsoft Entra – Secure Access for a Connected World

Microsoft Entra Internet Access Preview

Microsoft Entra Private Access Preview

What is Zero Trust?

What is Zero Trust Network Access?

What is Security Service Edge (SSE)?

What is Secure Access Service Edge (SASE)?

What’s the Difference Between SSE and SASE?

Contact Us

I’ve had the privilege of participating in the private preview for Microsoft Entra Internet Access and Private Access. If you’d like to learn more about these technologies and how they can help your organization, fill out the form below, and I’ll provide more information.

8 Comments

by Richard M. Hicks on July 17, 2023 • Permalink

Posted by Richard M. Hicks on July 17, 2023

https://directaccess.richardhicks.com/2023/07/17/microsoft-entra-global-secure-access/

Azure Conditional Access Certificates with SID Information Now Available

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.