Cause #1: The certificate's subject matches multiple user objects
The most common trigger for 0x80090347 is that the certificate's subject (the CN field) matches more than one Active Directory user. Windows tries to map the cert to an account, finds two candidates, and throws the error instead of guessing.
This usually happens after a user account is recreated—say, someone resigns and gets rehired with the same name. The old account still has the certificate in its userCertificate attribute, and the new one has the same cert or a similar subject. When the user presents the cert, the DC sees two accounts with the same subject and refuses to authenticate.
Here's how I fix it. First, identify all accounts that have the certificate. Use PowerShell on a machine with the AD module:
$cert = Get-ChildItem Cert:\CurrentUser\My | Where-Object {$_.Thumbprint -eq "YOUR_THUMBPRINT"}
$subject = $cert.Subject
Get-ADUser -Filter "userCertificate -like '*" + $subject + "*'" -Properties userCertificate | Select-Object DistinguishedName, userCertificate | Format-ListIf you don't have the cert locally, you can search by subject name across all users:
Get-ADUser -Filter "userCertificate -like '*CN=John Doe*'" -Properties userCertificate | Select-Object DistinguishedNameOnce you see the duplicates, remove the certificate from the stale account. The cleanest way is to clear the userCertificate attribute entirely on the old account, but if that account still needs other certs, you'll have to remove just the one. This PowerShell snippet removes a specific cert from an account:
$user = Get-ADUser -Identity "staleAccount" -Properties userCertificate
$certs = $user.userCertificate
$filtered = $certs | Where-Object { $_ -ne $targetCertBytes }
Set-ADUser -Identity "staleAccount" -Replace @{userCertificate = $filtered}That's the fix. After cleaning, test login again. It should succeed because now there's only one mapping.
Cause #2: The cert is mapped via both explicit and implicit mapping
Windows supports two ways to map certificates to accounts: implicit mapping (based on subject or issuer name) and explicit mapping (a stored mapping object in AD). If both exist for the same certificate, you get 0x80090347 because the system sees two separate mappings—even though they point to the same user.
In practice, this happens when an admin configures smart card authentication using group policy, and also creates an explicit mapping for a service account. The GPO enables implicit mapping for all users, so the cert gets mapped twice.
To check for explicit mappings, open ADSI Edit and look under CN=Users for objects of class altSecurityIdentities containing the certificate hash. Or use PowerShell:
Get-ADUser -Filter {altSecurityIdentities -like "*X509:*"} -Properties altSecurityIdentities | Select-Object Name, altSecurityIdentitiesIf you find an explicit mapping, remove it if you already rely on implicit mapping. Keeping both is redundant and causes exactly this error. Delete the altSecurityIdentities entry—don't just disable the GPO, because the mapping lives in AD.
Now, you might be tempted to disable implicit mapping globally to avoid this. Don't. That breaks the normal smart card experience for everyone. The better approach is to keep one method per certificate.
Cause #3: The certificate has subject alternative name (SAN) conflicts
A less obvious cause is a certificate with a SAN (like an email or UPN) that matches multiple accounts. Schannel uses the SAN when the subject isn't unique. If the UPN in the SAN matches two users (again, due to stale accounts), you hit the same error.
This is sneaky because the subject CN might be unique, but the SAN isn't. I've seen this with test environments where a wildcard UPN like admin@contoso.com was assigned to several test accounts.
To diagnose, check the certificate's SAN and search AD for that UPN:
Get-ADUser -Filter "UserPrincipalName -eq 'admin@contoso.com'" -Properties UserPrincipalNameIf you get more than one result, you've found the problem. The fix is to either remove the duplicate accounts or update their UPNs so only one matches the SAN.
Another variant: the certificate lacks a SAN and relies on the subject, but the subject includes a CN that's not unique. Same result. In that case, you might need to reissue the certificate with a unique SAN to avoid the conflict entirely.
Quick reference summary
| Cause | Symptom | Fix |
|---|---|---|
| Duplicate user objects with same subject | Multiple accounts show the cert in userCertificate |
Remove the cert from the stale account |
| Explicit + implicit mapping both present | altSecurityIdentities contains the cert hash |
Delete the explicit mapping entry |
| SAN (UPN) matches multiple accounts | Multiple accounts have same UPN as cert's SAN | Reassign UPNs or reissue cert with unique SAN |
Start with cause #1, because it's the most frequent. If that doesn't solve it, move down the list. The key is understanding that the error is a safety mechanism—Windows refuses to pick an account when the mapping is ambiguous, and that's actually good design. You just need to make the mapping unambiguous.