Share via

Strong Name Mapping, Event ID 39 (Denied Login), Despite Previously Working Explicit Mapping

John S 0 Reputation points
2026-02-25T20:05:01.65+00:00

After recently updating one of our DCs with the 2026-02 Windows Server 2019 (KB5075904) Cumulative Update, that DC started to get Event ID 39 Kerberos errors in the logs, and users were denied login. We use a government smart card system, so we have a Strong Name Mapping policy in place with tuples for our environment. We have not had issues with this in the past. Additionally, for our IT department members, we also add an explicit mapping to altSecurityIdentities. This was also tested and confirmed working before.

Now, despite existing valid mapping rules, users (including those with explicit mappings) are being denied login and generating event ID 39 errors on the DC . Why is this happening? What can I do to fix it? No recent changes have been made, policy or otherwise, except for updating the DC.

Windows for business | Windows Server | Directory services | Certificates and public key infrastructure (PKI)
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. John S 0 Reputation points
    2026-02-27T23:10:42.32+00:00

    Posting the solution in case anyone else finds it helpful.

    The cause ended up being a duplicate thumbprint in the Strong Name Mapping GPO tuple. For whatever reason the duplicate did not cause an issue in processing the tuples for over a month (since the last update to that GPO), and applying the cumulative update caused the processing of the tuples to fail. Failure is technically the correct response in that situation, since documentation explicitly states that each tuple must have a unique thumbprint. However, the delayed failure response caused considerable troubleshooting delays as it suggested a recent change or event had caused the authentication issues.

    The key factor in determining the source was a Kerberos log on our domain controller.
    Event Viewer | Applications and Services Log> Microsoft> Windows> Kerberos-Key-Distribution-Center: Operational

    The operational log contained Event ID 313, which is sparse on information. It indicates that there is an invalid strong name match policy. It also includes a bit at the bottom reading: "Faulting Line: #". The 'Faulting Line' refers to the Strong Name Mapping GPO tuple list, where the # in the log indicates which line was considered the faulting line.

    Regarding the reply I got:
    The "SID extension (1.3.6.1.4.1.311.25.2)" is not relevant since we do not generate our certificate requests using Microsoft CAs.
    Thank you for attempting to answer the question though.

    0 comments
  2. Kate Pham (WICLOUD CORPORATION) 585 Reputation points Microsoft External Staff Moderator
    2026-02-26T02:23:39.8766667+00:00

    Hi John S,

    Thank you for contacting Microsoft Q&A community, allow me to address your issue on bellow answer:

    The Event ID 39 Kerberos errors after the update are likely due to stricter enforcement of strong certificate mapping rules introduced by recent Windows updates. The update may have moved your domain controller into Full Enforcement mode, where only certificates with strong mappings (such as explicit mapping, key trust mapping, or a SID extension) are accepted. If a certificate does not meet these criteria, authentication is denied—even if explicit mappings exist in altSecurityIdentities.

    1. Check the certificate mapping: Ensure that certificates used for authentication have the SID extension (1.3.6.1.4.1.311.25.2) and that the SID matches the user account. For certificates issued by third-party CAs, contact the vendor to add the SID extension. Microsoft CAs with KB5014754 installed will automatically insert the extension unless it was an offline request or disabled on the template.
    2. Audit and update mappings: If explicit mappings in altSecurityIdentities are not working, verify that the mapping format is correct and that the certificate issuer string does not contain problematic characters (such as " , + = \ < > # ;) that could cause mapping failures.
    3. Reissue certificates: If certificates predate the user account or lack strong mapping, reissue them or add secure altSecurityIdentities mappings. If you believe this information adds some value, please accept the answer so that your experience with the issue would help contribute to the whole community.

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.