In trying to troubleshoot the "strong certificate mapping" issue with user certificates, the event logs on the Domain Controller were reporting that if in compliance mode was enable users would be getting authentication failures, this error was the server saying "I am to old upgrade me....."
"oldbeardc01.bear.local","04/09/2025 11:15:57","39","Microsoft-Windows-Kerberos-Key-Distribution-Center","The Key Distribution Center (KDC) encountered a user certificate that was valid but could not be mapped to a user in a secure way (such as via explicit mapping, key trust mapping, or a SID). Such certificates should either be replaced or mapped directly to the user via explicit mapping."
After diving deep into Microsoft's strong certificate mapping requirements, I discovered what was happening and how to fix it. Here's what I learned.
The Root Cause: Microsoft's Strong Certificate Mapping Enforcement
In May 2022, Microsoft introduced strong certificate mapping with update KB5014754 to address serious vulnerabilities in certificate-based authentication. Starting February 2025, they began enforcing this by default, and by September 2025, there will be no way to disable it.
The key requirement is that all user certificates must include a Security Identifier (SID) extension with OID 1.3.6.1.4.1.311.25.2 to prove the certificate belongs to the specific user attempting authentication.
Mixed Domain Controller Environments
If you environment consisted of various levels of Domain Controllers lets review the problem with each:
- ❌ Server 2012 R2 domain controller - Strong Mapping not supported
- ❌ Server 2016 domain controllers - Strong Mapping not supported
- ✅ Server 2019+ domain controllers - - Strong Mapping supported
The Investigation: Comparing Working vs. Failing Certificates
When I compared a working certificate with the failing one, the difference was clear:
Working Certificate (issued via GP auto-enrollment):
- ✅ Had OID 1.3.6.1.4.1.311.25.2 extension with embedded SID
- ✅ Subject Alternative Name with UPN
- ✅ Issued from "online" certificate template
Failing Certificate (issued via Intune SCEP):
- ❌ Missing the SID extension (even though template was configured correctly)
- ✅ Had UPN in Subject Alternative Name
- ✅ Template was configured as "online" but SCEP delivery method meant SID extension wasn't added
Check/Configure Certificate Templates
For certificates issued via Group Policy auto-enrollment, the fix was straightforward. I needed to ensure our user certificate templates were configured as "online" templates:
Solution 1 : Certificate Template Configuration:
- Open Certificate Templates MMC snap-in
- Edit your user certificate template
- On the Subject Name tab:
- Select "Build from this Active Directory information"
- Choose "Fully distinguished name" format
- Under "Include this information in alternate subject name":
- ✅ Check "User principal name (UPN)"
- ✅ Check "E-mail name" (optional)
This configuration ensures that when the May 2022 update (KB5014754) is installed on your Certificate Authority, the SID extension is automatically added to newly issued certificates.
Solution 2: Intune SCEP Strong Mapping
For Intune SCEP certificates, the solution was more complex. Microsoft added support for strong mapping in October 2024, but it requires specific configuration:
In your SCEP certificate profile, add the SID variable to the Subject Alternative Name:
- Attribute: URI
- Value:
{{OnPremisesSecurityIdentifier}}
This embeds the user's SID in the certificate's Subject Alternative Name in the format: tag:microsoft.com,2022-09-14:sid:<SID>
The Hidden Problem: Domain Controller Version Requirements
Here's where I discovered the real issue in our environment. Even with the correct Intune configuration, authentication was still inconsistent. The problem? Domain Controller version compatibility.
For Intune SCEP certificates with the OnPremisesSecurityIdentifier, domain controllers must be Windows Server 2019 or above. Server 2016 and earlier don't support this new mapping format.
Recall : Our Mixed Environment Problem
If you have a mixed of supported and unsupported Domain Controller OS version then this is true:
- Server 2012 R2 & 2016 DCs : ❌ Don't support Intune SCEP/OID strong mapping
- Server 2019 DCs : ✅ Support Intune SCEP/OID strong mapping
This meant users had:
- 33% chance of successful authentication (hitting 2019 DCs)
- 67% chance of Event ID 39 failures (hitting older DCs)
Checking for Authentication Failures
To identify which DCs were having issues, I used this PowerShell script:
# Check for Event ID 39 on domain controllers
Get-EventLog -LogName System | Where-Object { $_.EventID -eq 39 } | Sort-Object -Property TimeGenerated | Select-Object -Last 30 | Format-Table -AutoSize -Wrap
The pattern was clear - only the older DCs were logging these failures.
The Long-term Solution
The proper solution involves upgrading your legacy unsupported Domain Controllers to Server 2019+ - all the other options were configured as they should be, and the "workaround" will not work after patch Tuesday of September 2025.
Conclusion
The authentication failures I was seeing weren't due to certificate configuration issues, but rather infrastructure compatibility problems. Understanding Microsoft's strong certificate mapping requirements and the version dependencies helped me identify and resolve the real root cause.
If you're experiencing similar issues, check your domain controller versions first - you might be dealing with the same compatibility lottery that was causing my authentication headaches!