Strong Mapping Error for One User

Question

Strong Mapping Error for One User

Kat7 0

Our users use DoD CACs to log into their computers. We have deployed the fixes for strong mapping and haven't had issues since.
However, we now have one user who is getting the Event Viewer error 39. I have confirmed that the DoD certificate thumbprint he's using is already included in the GP Allow name-based strong mappings for certificates.

I also added his personal one in there, just to test, and added his certificate into the altSecurityIdentities attribute on his user, but he still receives the same error.

What else do I need to look at?

Windows Server 2019

User's image

1 answer

Your answer

Answer 1

VPHAN 25,000 Independent Advisor

Hi Kat7,

It is highly probable that the certificates issued by the DoD PKI do not contain the specific Microsoft proprietary SID extension (OID 1.3.6.1.4.1.311.25.2). Without this extension, the standard Subject/Issuer mapping (format X509:Issuer<S>Subject) is technically classified as a "Weak" mapping. If your Domain Controllers are configured with the registry key StrongCertificateBindingEnforcement set to 2 (Full Enforcement), the KDC will reject these weak mappings immediately, resulting in Event 39.

To resolve this without waiting for a certificate reissue, you must manually create a "Strong" explicit mapping in the altSecurityIdentities attribute of the user object. The crucial detail is the format: you cannot use the Subject/Issuer string. You must use the SHA1-PUK (Thumbprint) or Issuer/Serial Number format to satisfy the strong binding requirement.

Please perform the following steps on the user's Active Directory object: Clear any existing entries in altSecurityIdentities that rely on  and <S> tags. Replace them with the specific SHA1-PUK format using the user's certificate thumbprint. The string must look exactly like this: X509:<SHA1-PUK>ThumbprintHexValue (Ensure there are no spaces in the hex string).

Alternatively, you can use the Issuer and Serial Number format, which is also considered strong: X509:IssuerName<SR>SerialNumber

Once you apply this change, force a replication or wait for it to propagate to the authenticating DC. The KDC will recognize the <SHA1-PUK> or <SR> tag as a strong mapping method and allow the authentication to proceed even if the certificate itself lacks the SID extension. Regarding your mention of adding the thumbprint to a GPO, note that Group Policy is typically used to configure the enforcement level (Compatibility vs. Full Enforcement), not to list individual allowed thumbprints for mapping; the mapping logic resides strictly on the user object attributes or the Certificate Authority configuration.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

VP

Kat7 0 Reputation points

2026-01-26T18:56:53.1266667+00:00

I already had the SR in the altSecurityIdentities using “X509:IssuerName<SR>1234567890”

Should the issuer portion contain all the entries in the issuer field on the certificate?

The user did get a new CAC since it was working last, but the ID stayed the same as what's on his AD user account.
VPHAN 25,000 Reputation points Independent Advisor

2026-01-26T19:04:28.71+00:00

Yes, the issuer portion in the  tag must contain the entire Issuer Distinguished Name (DN) string exactly as it appears in the certificate's properties, including all CN=, OU=, O=, and C= components. Active Directory performs a strict character-for-character comparison; if you omit a component, change the order (e.g., O= before OU=), or even miss a single space, the KDC will fail to locate the mapping.

However, the most likely cause of your continued failure is the "new CAC" factor. You mentioned the user received a new card but "the ID stayed the same." While the user's EDIPI (DoD ID number) remains constant across cards, the X.509 Serial Number changes every time a new certificate is issued. You cannot reuse the <SR> (Serial Number) value from the old card. A new CAC means a new private key and a new certificate serial number, even if the user's identity is identical.

You must inspect the new certificate on the new CAC. Open the certificate, navigate to the Details tab, and locate the Serial Number field. You must copy this new hexadecimal string and update your altSecurityIdentities value. Critically, when you copy the serial number from the Windows certificate dialog, it often includes spaces (e.g., 3A 14 B5 ...); you must remove all spaces so the string is a continuous block of hex digits (e.g., 3A14B5...) inside the <SR> tag.

If you continue to face syntax errors with the complex Issuer/Serial string, I strongly recommend switching to the Thumbprint mapping method mentioned previously (X509:<SHA1-PUK>NewThumbprintHash). The Thumbprint is unique to the specific certificate and avoids the complexities of Distinguished Name formatting entirely, making it significantly less prone to human error during manual entry.

VP
Kat7 0 Reputation points

2026-01-26T19:16:10.3666667+00:00

I pulled the serial number from the EV error, so it should be the new one. I'll try the Thumbprint mapping instead. Do I use the thumbprint for the DoD cert number, like we use in the GP, or the thumbprint number from the EV error that is specific to the user?
VPHAN 25,000 Reputation points Independent Advisor

2026-01-26T19:39:20.2266667+00:00

You must use the thumbprint specific to the user's personal certificate, not the DoD Root or Intermediate CA thumbprint found in your Group Policy. The entries in your Group Policy (likely under Public Key Policies or Enterprise Trust) establish the chain of trust for the entire organization, whereas the altSecurityIdentities attribute is a 1-to-1 mapping designed to bind a single, unique credential to a specific Active Directory user object. Using a generic CA thumbprint here would fail because it does not uniquely identify the individual user.

While the Event Viewer error logs (specifically Kerberos failure events) do refer to the certificate attempting to authenticate, extracting the thumbprint from text logs can sometimes lead to character encoding errors or confusion with other ID fields. The most reliable method is to view the certificate directly from the user's new CAC. You can do this by having the user insert the card, opening certmgr.msc (or the browser certificate settings), finding their authentication certificate, and copying the Thumbprint field from the Details tab.

When you enter this into the altSecurityIdentities attribute, ensure you strip all spaces from the hexadecimal string. The final value must follow the format X509:<SHA1-PUK>YourUserCertificateThumbprint exactly. This bypasses the need for the KDC to parse the complex Issuer/Subject strings and provides the "strong mapping" required by the new security enforcement.

VP
Kat7 0 Reputation points

2026-01-26T19:47:04.9233333+00:00

I tried that, had him send me the thumbprint but we're still getting the same error.
What else should I be looking at?
We have not had to add the altSecurityIdentities attribute for any of our other users and we didn't have one for him with his old CAC. Once we set up the correct Registry keys and GPs it worked for everyone.
VPHAN 25,000 Reputation points Independent Advisor

2026-01-26T19:54:20.2133333+00:00
If this configuration works for all other users without manual altSecurityIdentities mappings, your environment is likely relying on implicit UPN mapping (where the User Principal Name in the certificate's Subject Alternative Name matches the AD userPrincipalName exactly).

When you copy the Thumbprint string directly from the Details tab of the Windows certificate dialog, Windows frequently inserts an invisible Unicode Left-to-Right mark (U+200E) or a "Question Mark" artifact at the very beginning of the string. You cannot see this character in the Attribute Editor, but it corrupts the hash, causing the KDC to see a mismatch.

To fix this:

Open the user's altSecurityIdentities attribute again.

Clear the current value completely.

Type X509:<SHA1-PUK> manually.

Paste the thumbprint into a plain text editor (like Notepad) first. Use your arrow keys to go to the very start of the line and hit Delete once or twice to ensure no hidden characters exist before the first hex digit.

Copy that sanitized string and paste it into the attribute.

Ensure you are extracting the thumbprint from the correct certificate on the CAC. A standard DoD CAC contains three or four certificates (ID, Email, PIV/Authentication).

If you map the thumbprint of the Email/Encryption certificate (which lacks the Smart Card Logon or Client Authentication EKU), the KDC will reject the logon request with a generic error or mapping failure because that cert is not valid for Kerberos authentication.

You must strictly use the certificate that lists Smart Card Logon (1.3.6.1.4.1.311.20.2.2) in its Enhanced Key Usage field.

To understand why this user is the "odd one out," compare the Subject Alternative Name field on his new CAC (specifically the Principal Name value) against his userPrincipalName in Active Directory. If they do not match character-for-character, that explains why the automatic (implicit) mapping failed in the first place. Fixing the AD UPN to match the card would technically resolve the issue without needing the altSecurityIdentities attribute, but the manual map you are creating is a stronger, more permanent fix.
Kat7 0 Reputation points

2026-01-27T20:10:25.92+00:00

I did all the steps above for the altSecurityIdentities attribute with the SHA1, but it's still popping the same error.

I made sure the cert has the smart card logon, and has the same userpricipal name that we have in the system.
VPHAN 25,000 Reputation points Independent Advisor

2026-01-28T03:43:29.08+00:00
the issue is almost certainly a Certificate Mismatch.

DoD CACs typically contain three or four different certificates (Identity, PIV Authentication, Email Signature, Encryption). While they all bear the user's name, they have different Thumbprints.

The "Same Error" indicates that the KDC is receiving a certificate, failing to find a matching user for it, and rejecting it. It is highly likely that the user's machine is presenting the PIV Authentication certificate, but you have mapped the Identity certificate (or vice versa).

Please perform these two diagnostic checks to pinpoint the failure:

Go back to the Event 39 error on the Domain Controller.

Click the Details tab (not General) and select XML View.

Look for the <Certificate> node. It will contain the Issuer Name, Serial Number, and often the Thumbprint of the exact certificate that attempted the logon.

Compare this data against the altSecurityIdentities value you created.

If they do not match: Update your mapping to match the certificate details found in the Event Log.

Since your environment relies heavily on implicit mapping (UPN), it is possible the Domain Controllers are configured to ignore explicit (altSecurityIdentities) mappings.

On your Domain Controllers, check this registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

Look for the CertificateMappingMethods value.

If this value exists, ensure it includes the bit 0x4 (Explicit Mapping). A common "secure" default is sometimes restricted to 0x18 (UPN + S4U2Self).

If the value is present, modify it to include explicit mapping (e.g., set it to 0x1F to allow all methods) and reboot the DC or restart the KDC service.

You mentioned adding the "thumbprint" to a "Allow name-based strong mappings" GPO. Be aware that the Strong Certificate Binding Enforcement GPO does not accept a list of user certificate thumbprints. It only configures the enforcement level (Audit, Disabled, Enforced). If you added a user's thumbprint to a CA trust list (like Enterprise Trust), it will not fix the mapping issue. The altSecurityIdentities method is the correct override for a user whose implicit mapping is failing.

Share via

Strong Mapping Error for One User

1 answer

Your answer