All posts tagged ADCS

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
Tagged , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on January 27, 2025

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

November Microsoft Security Updates and AD CS

As I do each month on Patch Tuesday, I look through the list of published vulnerabilities in search of things that might interest Always On VPN Administrators. Frequently there are updates for things like Routing and Remote Access Service (RRAS) or various VPN protocols. The good news is that the November 2024 security updates include NO such vulnerabilities! However, a vulnerability has been disclosed that affects Active Directory Certificate Services (AD CS) on which Always On VPN often relies on for user and device authentication.

Certificate Templates

AD CS Enterprise certificate authorities are closely integrated with Active Directory and use certificate templates that administrators can publish for users and devices to enroll. These templates control properties of the issued certificates, such as the subject name, usage, key length, enrollment policies, and much more. There are several different template versions available, versions 1 through 4. Version 1 templates are legacy templates that don’t provide many capabilities. Later versions include more features and capabilities.

CVE-2024-49019

The November 2024 Microsoft security updates include CVE-2024-49019, a privilege escalation vulnerability recently discovered in AD CS. Specifically, this vulnerability affects only legacy schema version 1 certificate templates published on a certificate authority (CA) server that include the option to supply the subject name in the certificate request. A typical example of this would be the default Web Server template.

Exploitation

The Web Server template does not include the Client Authentication Enhanced Key Usage (EKU) by default, which is required to authenticate to Active Directory. However, this vulnerability allows an attacker with enrollment privileges on this template to supply additional EKUs in the request and the certificate issued will include those capabilities. This allows a non-privileged attacker to quickly elevate to a domain or enterprise administrator by supplying a known administrator’s User Principal Name (UPN) along with the Client Authentication EKU in the certificate request. As version 1 templates cannot enforce CA manager approval for enrollment, an attacker can easily leverage this vulnerability if permissions allow, leading to complete domain compromise.

Note: This applies to any schema version 1 certificate template published with the subject name supplied in the request, not just the Web Server template.

Complications

Making matters worse, the Web Server template is one of the default certificate templates published automatically when a Windows Server CA is deployed. The best practice is to disable the publishing of any certificate templates by default when a new CA is provisioned. However, it requires additional configuration that is often overlooked. In addition, many administrators use overly broad enrollment permissions for this template, such as Domain Users, Domain Computers, or Authenticated Users, further broadening the attack surface.

Mitigation

Administrators should update their CA servers as soon as possible. If you cannot deploy this update immediately, consider replacing any schema version 1 templates with version 2 templates, which are not vulnerable. Also, as best practice, ensure that any certificate templates that allow the subject name to be supplied in the request also requires CA manager approval or additional authorized signatures for enrollment.

Investigation

Administrators should review enrollment privileges for all published certificate templates to ensure the least privileged access. In addition, administrators should audit all valid certificates issued with schema version 1 certificate templates that allow the subject name to be supplied in the request immediately to look for indicators of compromise. Review issued certificates for unauthorized EKUs or unusual subject names, especially those with a UPN.

Additional Information

Microsoft November 2024 Security Updates

CVE-2024-49019 – AD CS Elevation of Privilege Vulnerability

EKUwu: Not Just Another AD CS ESC – TrustedSec

Leave a comment
by Richard M. Hicks on November 13, 2024  •  Permalink
Posted in Active Directory, Active Directory Certificate Services, ADCS, administration, Always On VPN, AOVPN, authentication, Certificate Authority, Certificate Services, certificates, Enterprise, Microsoft, Operational Support, PKI, public key infrastructure, Security, Security Update, Windows 10, Windows 11, Windows Server 2016, Windows Server 2019, Windows Server 2022, Windows Server 2025
Tagged , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on November 13, 2024

https://directaccess.richardhicks.com/2024/11/13/november-microsoft-security-updates-and-ad-cs/

Microsoft Cloud PKI for Intune SCEP URL

Earlier this year, Microsoft announced Cloud PKI for Intune, a cloud service for issuing and managing digital certificates for Intune-managed endpoints. With Cloud PKI for Intune, administrators no longer need to deploy on-premises infrastructure to use certificates for user and device-based authentication for workloads such as Wi-Fi and VPN. Cloud PKI for Intune can be used standalone (cloud native) or integrated with an existing on-premises Active Directory Certificate Services (AD CS) enterprise PKI to extend an existing on-premises certificate services infrastructure.

Provisioning

Cloud PKI for Intune utilizes Simple Certificate Enrollment Protocol (SCEP) to enroll certificates for users and devices. To deploy Intune Cloud PKI certificates, administrators must create and deploy a SCEP Certificate device configuration policy in Intune.

SCEP URL

When creating the SCEP certificate device configuration policy in Intune, administrators are asked to supply the SCEP server URL. Administrators will find this information by opening the Intune management console, navigating to Tenant Administration > Cloud PKI, clicking on the issuing certification authority, and then clicking Properties.

Administrators may notice the URL is unreachable if they try to connect to it using their web browser or PowerShell. Specifically, the FQDN is not shown in the URI; instead, it is represented as the variable {{CloudPKIFQDN}}, as highlighted above.

Policy Configuration

You can safely ignore this as it is not an error or misconfiguration. Simply copy and paste the entire URL into your SCEP certificate device configuration profile as is. Intune in the background will convert this to a fully formed URL with a proper FQDN accessible from the public Internet. This variable is used because it allows Microsoft to use different resources dynamically according to geography and availability.

Additional Information

RFC 8894 – Simple Certificate Enrollment Protocol

Microsoft Cloud PKI for Intune

Microsoft Cloud PKI for Intune and Active Directory

Microsoft Cloud PKI for Intune and Certificate Templates

2 Comments
by Richard M. Hicks on June 25, 2024  •  Permalink
Posted in Active Directory, Active Directory Certificate Services, AD CS, ADCS, administration, authentication, Azure Active Directory, Azure AD, Azure AD Join, Certificate Authentication, Certificate Authority, Certificate Connector for Intune, Certificate Services, certificates, cloud, Cloud PKI, Cloud Service, Cryptography, Enterprise, enterprise mobility, Entra, Entra ID, Infrastructure, InTune, MDM, MEM, MEMCM, Microsoft, Microsoft Endpoint Manager, Microsoft Entra, Microsoft Entra ID, Microsoft Intune, Mobile Device Management, Mobility, PKI, public cloud, public key infrastructure, SCEP, Security, Simple Certificate Enrollment Protocol, systems management, VPN, Windows 10, Windows 11
Tagged , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on June 25, 2024

https://directaccess.richardhicks.com/2024/06/25/microsoft-cloud-pki-for-intune-scep-url/

« Older Posts
Newer Posts »