Are you prepared for the strong certificate mapping enforcement that Microsoft brings with its Feb 2025 patch Tuesday update for the Windows Server OS?
Microsoft introduced strong certificate mapping with the May 2022 patch Tuesday security update (KB5014754) for the Windows Server OS line to address vulnerabilities identified with certificate-based authentication.
However, back then it was introduced in COMPATIBILITY mode, meaning for a certificate-based authentication without a strongly mapped certificate, the authentication was allowed to go through, but an event for the same was to be logged under Event 39 on your DCs under Kdcsvc (in System).
Now with the Feb 2025 patch Tuesday security update for the Windows Server OS line, we will see strong certificate mapping transitioning to FULL ENFORCEMENT mode. And with this server-side change as explained in detail in this MS article, certificate-based authentication will fail for client certificates without strong mapping.
Table of Contents
What is Strong Certificate Mapping?
Using any identifiers generated or supplied by something outside the Kerberos KDC or the CA, which is the case for Intune SCEP certificates since the certificate details like CN and SAN are supplied in request by the Intune policy module, must be considered potentially attacker-controlled. Thus, they are a weak form of authentication and should no longer be used for identification purposes when Kerberos is involved.
Technically, before this change, certificate-based authentication would not account for a dollar sign ($) at the end of a machine name. This allowed related certificates to be emulated (spoofed) in various ways. Further, conflicts between User Principal Names (UPN) and sAMAccountName introduced other emulation (spoofing) vulnerabilities.
Strong certificate mapping requires certificates for a user or computer object to be strongly mapped to Active Directory (AD).
For this, a new certificate extension Object Identifier, OID 1.3.6.1.4.1.311.25.2 was added to the certificate used by ADCS that contained the principal’s (user or device) Security Identifier (SID) in Active Directory.
Initially, this could only be applied to the online certificate templates from ADCS, i.e., templates that were configured to build the Subject Name (CN) and Subject Alternate Name (SAN) from Active Directory information.
Offline templates, where the CN and SAN are supplied in the request, like what we do with SCEP certificates in Intune, couldn’t be strongly mapped as they do not build the information from AD, but with what is provided during the request by the requestor (Intune Policy Module). And it is this limitation that kept Microsoft from enforcing Strong Certificate Mapping even after introducing it with the May 2022 update. Instead, they kept going on with the COMPATIBILITY mode.
But in April 2023, Microsoft sorted out this limitation with a new mapping introduced as a preview to work with KDCs running Windows Server Preview Build 25246 and later. This new mapping, which can be used for offline certificate requests, is a Subject Alternative Name (SAN) tag-based URI with the following format.
URL=tag:microsoft.com,2022-09-14:sid:<value>
In this SAN URI, “microsoft.com” and “2022-09-14” are hard-coded values. The requestor only needs to resolve the SID value for the user or device while making the certificate request and this suffices to meet the strong mapping criteria.
Thus at the end-user space, when a user or device presents a certificate for authentication in Active Directory, the KDC will check if the required mappings are present to verify if the certificate is strongly mapped and issued to the specific user or device that is requesting for auth, thereby protecting against certificate spoofing.
The ability to configure strong mapping in SCEP and PKCS certificates in Intune came with the October 2024 service release. Since then, Microsoft has provided this period of Nov 2024 – Feb 2025 for all the organizations to have transitioned to strongly mapped certificates to start enforcing it at the KDCs with the Feb 2025 patch Tuesday update.
MS Change Timeline
| May 10, 2022 | Microsoft introduces strong certificate mapping in COMPATIBILITY mode. Was possible to revert this to DISABLED mode using Registry. |
| April 11, 2023 | Microsoft began Enablement Phase of strong certificate mapping by removing the DISABLED mode. Even if you have had the registry configured, the DC ignored the same and moved to COMPATIBILITY mode. |
| Feb 13, 2024 | Certificate mapping in Active Directory Users & Computers defaulted to selecting strong mapping using the X509IssuerSerialNumber instead of weak mapping using the X509IssuerSubject. The setting can still be changed as desired. |
| Oct, 2024 | Microsoft rolled out strong mapping for SCEP certificates in Intune for Windows, iOS and MacOS with Android support rolled out in the next month service release. |
| Feb 11, 2025 | Microsoft moves strong certificate mapping from COMPATIBILITY mode to FULL ENFORCEMENT mode by default, with an option to Opt-Out via registry, but it will be allowed only till Sept 2025 security update. |
| Sept 9, 2025 | Microsoft will make FULL ENFORCEMENT of strong certificate mapping MANDATORY without any exemption. |
How does it affect Workplace IT?
Administrators unprepared for this change may incur outages for workloads using certificate-based authentication such as Always On VPN, Wi-Fi, and others, post having the DCs patched with the Feb 2025 update, because with this, all domain controllers will be switched to Full Enforcement mode and authentication requests using certificates without strong mapping will be denied in this configuration.
Mitigation
To conform with the said changes as introduced by Microsoft and mitigate its impact, it requires involvement from multiple teams within IT.
Active Directory Scope
The certificate-based authentication is to be performed by KDC so it’s important to check if the DC infrastructure is ready for strong mapping enforcement.
For certificate-strong mapping verification to work, you need to have all your DCs running Windows Server 2019 or above.
It is this aspect where most of the organizations will be caught off-guard. Though it is not a massive issue to overcome, but still something to plan for the upgrade and enact it. For more clarification on this requirement for upgrade, please refer to Support tip: Implementing strong mapping in Microsoft Intune certificates | Microsoft Community Hub
Thus, if you have DCs running on Windows Server OS below Windows Server 2019 and need time to plan and act on the upgrade, at this point, you only have two possibilities –
- Either delay the security patching for all of the DCs indefinitely, or
- Bypass the enforcement temporarily by using a registry patch on the DCs, making them still stay in the COMPATIBILITY mode which is Possible only till September 2025!
Now it’s not a good security practice to leave your DCs unpatched with the latest security update for an indefinite time. As such, the best way forward is to go with the Feb 2025 security updates, but as a post-patching activity, have the DCs immediately 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
As mentioned earlier, this is a temporary OPT-OUT and is going to work only till Sept 2025 as MS has announced so far. But this opt-out provides all the teams involved with enough timeline to plan and enact the transition.
Intune Scope
We deploy SCEP or PKCS certificates from Intune to the managed endpoints for the purpose of authentication so that the users can connect to protected WiFi/VPN/Ethernet from their managed devices. As such, it is important to check if the existing SCEP profile is configured for strong mapping.
The strong mapping capability in Intune was released back in Oct 2024, and to implement the same, you must add the OnpremisesSecurityIdentifier URI variable to the SAN in the SCEP profile.
After you add the URI and value to the certificate profile, Microsoft Intune will append the SAN attribute with the tag and the resolved SID in the format as was mentioned earlier.
tag:microsoft.com,2022-09-14:sid:<value>
You can either make the change in your existing SCEP profiles (if they are already of type User) and increase the renewal threshold to have all the existing certificates renewed with new strong mapped certificates by Sept 2025, or you can plan to phase out the existing SCEP certificates with complete new SCEP profiles from Intune having the strong mapping configured.
It is important to note that for a cloud-only environment where devices are not bound to the Active Directory and it is only users being synced from AD to Entra ID, the strong mapping solution of Intune applies to only User certificates across all platforms. For device certificate type, it only applies to Microsoft Entra hybrid-joined Windows devices.
For cloud-only devices, as in Entra ID joined Windows devices and all other platforms including iOS, Android, and MacOS, the resulting device objects are created in Entra ID and they don’t exist in AD. As such, certificate type of Device for all other platforms including Entra ID joined Windows devices from Intune cannot be strongly mapped.
Network Scope
The Intune SCEP certs are to be used by network services at the end of the day and as such, the network team also needs to be engaged throughout to check and validate if any configuration changes are required at their backend to accommodate the change in certificates.
Ending
In the end, it is important to understand that as per the change timeline shared above, Microsoft will no longer honor the opt-out registry settings and strictly enforce strong certificate mapping for all certificate-based authentication requests with the September 2025 security update for their Windows Server OS line.
Thus, it is of utmost importance to have your infrastructure ready to comply with the new requirements before it’s too late and you have users and devices stranded with cert-based authentication failures.
Resources
Support tip: Implementing strong mapping in Microsoft Intune certificates | Microsoft Community Hub
Are those other two attributes needed in the SCEP configuration? For Entra only devices?
Hey Chris, it depends on the Radius configuration, what it is looking for in the certificate when client presents it to the service during authentication. The strong mapping attribute of having the OnPremiseSecurityIdentifier is a requirement for the KDC to perform the authentication. The ther attributes I have included, one is DNS which resolves UserName@domain as in my environment, Radius is configured to look for the DNS value in certificate. The other attribute provided as URI is for the requirement of CiscoISE getting the Intune device ID for the purpose of complince check for NAC. At the end, it all depends on your requirement and how your environment is. But whatever you have been using, be sure to add the strong mapping attribute as an addition.
Can you comment Microsoft article about OID support for “Device” type certificates over Intune PKCS? Use case is Radius auth with Mac workstations. I found from the article following paragraph:
https://learn.microsoft.com/en-us/mem/intune/protect/certificates-pfx-configure
This update applies to users and devices synced from an on-premises Active Directory to Microsoft Entra ID, and is available across all platforms, with some differences:
Strong mapping changes apply to user certificates for all OS platforms.
Strong mapping changes apply to device certificates for Microsoft Entra hybrid-joined Windows devices.
So if we want to use Device certs with OID on macs, it will not work? As I understand Device type works only for Microsoft Entra hybrid-joined Windows devices.
We updated Microsoft Intune Certificate Connector to latest version 6.2406.0.1001 and enabled SID in the registry (EnableSidSecurityExtension). Generated new cert for Mac workstation (Intune profile). Mac received the cert and new OID was present. The problem was that mac could not access the network (802.1x auth). From the logs there was a mismatch of SID:
Old certs: Security ID: Domain\workstation
New certs: Security ID: NULL SID
Certificate template in Intune (PKCS) was not changed.
Intune PCKS profile/settings:
Certificate type: Device
Subject alternative name:
DNS: CN={{DeviceName}}.domain.internal
User principal name (UPN): {{DeviceName}}$@domain.internal
Subject name format: CN={{DeviceName}}.domain.internal
Seems like it doesn’t know how to align computer(device) with this cert. If we map this cert directly to this mac computer object in AD (domain joined mac), trough Computer Name Mappings, it will start to authenticate to the internal network. Double-checked, cert will be mapped by X509IssuerSerialNumber (recommended strong auth). We have 2019 DC’s, atm running in Compatibility mode.
If we disabled SID/OID generation from registry, macs will get cert with old values (no new OID) and they would get network access automatically (SID will be aligned). So it is strange that adding OID field, will mess up the whole AD authentication thing. Correct me if I’m wrong.
Hello,
The thing about strong mapping is that it needs a object in the AD against which a certificate can be mapped so that during authentication when requestor presents the certificate, the KDC be able to use the OID to check if the requestor is the same as to the one the certificate was issued to, thereby stopping spoofing. Now for cloud environments, in general, it is only the user objects that are present in the AD, synced to entra and thus for strong mapping, it uses the SID of the user object on the AD. By default, mobile devices (android and iOS) do not join to AD so no device object is present in AD to be able to support strong mapping for device certificate. For Windows, device object is present in AD only in case of Hyrbid join and as such it is supported. If your Windows devices are Entra-joined only, as cloud devices, which it is mostly, it again aligns with the mobile devices and as such no support for device certificate, reason there is no device object in AD to be able to do the binding. Same goes true for Mac. In general, natively we dont see AD binded Mac so often, neither is supported or recomended by MS or Apple.
Thanks for reply!
I agree that cert is compared with real AD object. In our case domain joined Mac computer objects are present in AD.
Before enabling new SID/OID on Intune PKCS Connector, certs were compared by UPN (if there is a real object). It worked well and works now till Sept 2025. This was aligned with UPN under SAN (without it macs couldn’t access the 802.1X network, device cert based auth, EAP-TLS). Without this UPN, there was similar error that AD object could not be found, and network access was denied by NPS policy.
User principal name (UPN): {{DeviceName}}$@domain.internal
Mow, that new SID was added to mac certs (Intune MDM conf profile stayed the same), those new certs are not aligned with AD object anymore. AD object and cert cannot be validated (aligned), and so denied access to the network. Maybe some new UPN entry needs to be added to SAN? We use Intune PKCS.
Question, what can be done, to get it to work? Manual mapping of certs to mac computer objects is not an (good) option. There is some time to Sept 2025, maybe some solution will be proposed by Microsoft. Doubt that a little but never know. This KDC strong auth was postponed many times already.
PS! With Windows AD joined (hybrid) workstations there is no problem. They get valid/aligned certs by online request from internal CA.