Strong mapped certificates Intune NDES SCEP

For quite some I’ve been considering writing about Microsoft’s Strong Mapping changes to certificates

With the first enforced changes via Patch Tuesday just around the corner (Feb 11 2025), I felt compelled to share my insights that might help the community navigate the transition.

I will not cover too much on the basics as so much info is available on Microsoft’s and other posts about Strong Mapping.

Requirements for Strong Mapping (Note 2019 Server on DC’s)

Note the requirement for 2019 Server, although not well documented the fact is Intune or Jamf for Mac (Offline Certs) through things like NDES only will be seen as strong mapped if your DC’s are 2019 and above, I have tested this on 2016 and although the certificates have strong mapping they fail to be seen as such and the DC still gives Warning that it cant see the mapping. Switch the user to authenticate the cert on 2019 or above it works and passes Authentication. The same is not true of On premise (Online certs anything above 2008r2 is ok for these) So if you are using say Intune NDES you are going to need to upgrade your DC’s

Timeline

May 2022 – Initial strong mapping changes, Certificate templates automatically got a new attribute and Domain controllers could give us Event 39 so we could know what certs are not seen strong mapped.

September 2024 – Microsoft gave the ability to add strong map in Intune  (However 2016 DC’s cannot read the URL tag it uses, more on this in troubleshooting section below below)

Jan 2025 – Apple management system Jamf gave advice KB’s on adding strong mapping for Apple Certs

Feb 2025 – (was going to be November 2023 but delayed) Microsoft will push domain controllers to Full enforcement via Patch Tuesday Feb 2025 unless a reg key is added (KDC reg Key  StrongCertificateBindingEnforcement on DC’s)

Sept 2025 – Full enforcement, doesn’t matter if you have regkeys in place, they will be ignored, so you must aim to be fully ready with strong mapped certs and no warnings on your DC events by this date.

What is Certificate Strong Mapping ?

A strong mapped certificate refers to a certificate that has been securely linked to a user or device in a way that ensures robust validation during certificate-based authentication. This involves using identifiers that are unique and cannot be reused, such as a Security Identifier (SID) or a specific serial number.

In Windows environments, strong mapping is crucial for preventing spoofing and ensuring that the certificate presented during authentication genuinely belongs to the user or device it claims to represent.

(You will notice once strong mapping is setup, where devices and or users are synced from Active Directory to Azure Entra AD the certificate will contain an on-premise identity. i.e a user cert that is strong mapped will have a User SID that matches the users SID onpremise thus making it hard to spoof)

Is my environment affected?

The easiest way to tell if your environment is to check your Domain Controllers for Event ID 39 , The event will show for each and every cert it finds where the user or device is not seen as strong mapped.

Go to the check my site part of the post for more diagnostics

Different scenarios for likelihood of having to take action

Scenario 1

Completely On premise devices / users – (Certificates probably already mapped)

In May 2022 Microsoft Monthly Update (KB5014754) automatically added an extra extension to certificates authority templates OID 1.3.6.1.4.1.311.25.2

Once that update was applied any certs that were due to renewal or any new templates or certs should contain the extension thus making them strong mapped. Unless you had certs with an extremely long expiry set and your devices or users have not updated their certs, if you are in this scenario and completely on premise you should be ok, unless you have not applied patches since, 2022 or your certs need renewing for devices or users as they had a 5 year validity or similar.

OID 1.3.6.1.4.1.311.25.2 (was added to certs 2022)

Check your DC events anyway and see if you have issues (steps for this outlined below)

Scenario 2

Intune environment where Users sync from On-premise i.e via AAD Connect and you are deploying certs via NDES through Intune, devices are AAD Joined Intune. (Certificates likely need mapping)

In September 2024 Microsoft added the ability to add strong mapping to Offline Certificates , i.e through Intune and NDES. You can now add the below attribute to your certificate templates within Intune

Attribute – URI Value – {{OnPremisesSecurityIdentifier}}

Once the user receives the new certificate or it gets renewed it will be strong mapped. The certificate will show the the new attribute tag in the cert under subject Alternative name, the URL Tag will match the users SID in AD

***A big note on this is your Domain Controllers need to be 2019 or above to accept strong mapping in (Offline) Intune certificates) ***

Scenario 3

Intune Entra hybrid joined devices where device certificates are Offline (i.e NDES Intune supplied certificates) (Certificates likely need mapping)

Same as above, for your device certificates add the Attribute – URI Value – {{OnPremisesSecurityIdentifier}} to your Device certificates in Intune and it should then match the SID of the Device in on premises AD, again you will need to redeploy or renew certificates.

Workaround for February 2025

So you may be here like many where there has been no preparation for this, or the February 2025 patch Tuesday has just been deployed to your DC’s and your users can no longer login to wifi or VPN as certs are getting rejected .

Deploy the KDC regkey to your DC’s to keep logging events to dc’s but ignoring the fact that certs are not strong mapped

You could either deploy the regkey via GPO or Script , maybe even via SCCM (MECM)

Group policy – maybe preferable if you are deploying this before Feb 2025 patch Tuesday or its your preferred deployment mechanism

deploy key HKLM:\System\CurrentControlSet\Services\KDC StrongCertificateBindingEnforcement Dword Value = 1

Or you could deploy the regkey with script via SCCM (MECM) or even a a compliance remediation

#KDC RegKey for Feb2025
$CheckKeyExists = (Get-ItemProperty "HKLM:\System\CurrentControlSet\Services\KDC" -Name "StrongCertificateBindingEnforcement" -ErrorAction SilentlyContinue)
If ($CheckKeyExists -eq $Null) {
New-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\KDC" -Name "StrongCertificateBindingEnforcement" -PropertyType DWORD -Value "1" -Force | Out-Null
$Output = "Added Key"
} Else {
If ($CheckKeyExists.StrongCertificateBindingEnforcement -ne 1) {
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\KDC" -Name "StrongCertificateBindingEnforcement" -Value "1" -Force
$Output = "Updated Key to 1"
} Else {
$Output = "Key Already Existed With correct setting - Skipping"
}
}
Return $Output


You now have till September 2025 to get Strong mapping working

Getting Strong Mapping Working

Step 1) Getting the current state of your environment

If you are right at the beginning of this journey here’s some useful steps for you to gather information

The Most Important step – Getting the events from your DC’s

Since 2022 Microsoft added events to your DC’s to display whether your DC’s are currently finding certificates that are not strong mapped – if this is the case its likely that they are warning events instead of error events, With the February 2025 Patch update these events will turn from Warning to an error, and the authentication will be denied.

Event 39

The most likely event if you are using NDES and Intune and haven’t done anything about Strong Mapping is Event 39 (Event 41 if you are using 2008 R2 for DC’s)

If you have one or 2 DC’s you can login and go to System Events and filter by EventID

Powershell find Event 39 on your DC’s

You can also run a powershell Script to search for Event ID 39

Get-EventLog -LogName System | 
Where-Object {
    $_.EventID -eq 39
} | 
Sort-Object -Property TimeGenerated | 
Select-Object -Last 30 | 
Format-Table -AutoSize -Wrap

My favored way is to use CMPIVOT in SCCM (MECM)

I’m running a CMPivot to look for last 12hours of error 39 against all DC’s

WinEvent(‘System’, 12h) | where ID == 39

Looking at the event first thing you may notice is the event is a “Warning” this would change to “Error” if Feb 2025 Patch Tuesday has applied to your DC’s – Setting the Regkey for KDC in the workaround again will set this back to warning

If you look further into the event details from CMPivot you can take the Serial Number from the cert and see why its failing

If I now go to my Certificate Authority server and search by filtering for a serial number

On View Filter by Serial Number and enter one of the serial numbers

And here’s the cert this will fail as it has no URL tag in the Subject Alternative name

Remember – For Strong mapping to work it needs the new Microsoft Tag which is mapping your on prem details

Step 2) Readying and deploying new Intune Certs with strong mapping

You are likely in the scenario where you currently have non strong mapped certificates deployed to users and or devices and you now need to swap them out for strong mapped certs

Important — information, I’ve read from some forums is that just adding the change to the current certificates Attribute – URI Value – {{OnPremisesSecurityIdentifier}} will just redeploy it automatically and overwrite the old, I’ve tested this in 2 environments and even tried other changes to certs and it has not automatically deployed again, but people in forums are saying this works, will test again and update this.

Here is what I’ve done in different environments either way seems to work as a more gradual rollout, though you may find the above works ok

Deployment Solution Option 1 (Preferable)

If you are happy with your current certs, as in they have always worked apart from not being strong mapped —

1. Create a new cert in Intune with all the same attributes as your old certs but add the new attribute for OnPremisesSecurityIdentifier

2. Create a new Group to deploy this new cert to, I’m going to call this group Strong Mapped Cert Deployment

3. Deploy this new cert with the strong mapping to a new group, we don’t need to put users in the group yet

4. Original cert (non strong mapped ) deployment, exclude this new group

i.e lets suppose Original non strong mapped cert is deployed to All Users

ORIGINAL NOT STRONG MAPPED CERTIFICATE

Deployed to all Users currently – and now I’ve added the excluded new group below, this excluded new group is where I’m deploying the new cert to.

5. Now slowly and at first very slowly add users to the new Group Strong Mapped Cert Deployment

Its best to add some test users in to your new deployment group first and upon next device sync it should pull down the new cert and remove the old.

Deployment Solution Option 2

Another option that seems to work

1. Add the new attribute to your current non strong mapped cert

2. Change the current renewal threshold to a higher number — example lets go from 20% to 30%

3. Keep changing the renewal threshold say every 1 to 2 days gradually till you get to say 98% –100%

This should gradually then replace everyone’s certificate for the same template but with the strong mapping in it

***EITHER WAY YOU DO THIS ESPECIALLY IN LARGE ENVIRONMENTS ROLL OUT VERY GRADUALLY, YOU CAN FLOOD YOUR CERT SERVERS WITH REQUESTS AND YOU CAN END UP WITH USERS NOT BEING ABLE TO CONNECT TO WIFI / VPN AS THEY HAVENT GOT THE NEW CERT DUE TO BOTTLENECKS OF LARGE NUMBERS OF REQUESTS***

Troubleshooting

My Intune configuration is set to strong map, I can see strong mapping sid’s in the certificates but I’m still getting error 39, what‘s wrong?

Are your Domain Controllers 2019 and above? 2016 DC’s or below do not support the new OnPremisesSecurityIdentifier, so they work fine for On premises certs as they read the OID mapping OK, but not the offline way in Intune, with OnPremisesSecurityIdentifier, you will need to upgrade your DC’s, this is true also in a mixed environment. You will see where your Users hit a 2019 or above DC they will be accepted with no error 39, where as the same user hits a 2016 or below DC it will still error There is only the smallest hint of this being documented by Microsoft in the document below, under testing I have found this to be true that you really do need 2019 and above.

Support tip: Implementing strong mapping in Microsoft Intune certificates | Microsoft Community Hub

Useful Articles

Richard Hicks all round cert and auth guru

Strong Certificate Mapping for Intune PKCS and SCEP Certificates | Richard M. Hicks Consulting, Inc.

Strong Certificate Mapping Enforcement February 2025 | Richard M. Hicks Consulting, Inc.

Microsoft

Support tip: Implementing strong mapping in Microsoft Intune certificates | Microsoft Community Hub

KB5014754: Certificate-based authentication changes on Windows domain controllers – Microsoft Support

Apple Jamf

Supporting Microsoft Active Directory Strong Certificate Mapping Requirements – Technical Articles | Jam