HowTo: Map a user to a certificate via all the methods available in the altSecurityIdentities attribute

Today I am going to talk a little bit about certificate mapping. This topic is somewhat related to my last post about disabling mapping, but you once you disable the UPN mapping what type of mapping is available to you?

The image below ( stolen from MSDN ) outlines the mapping of user accounts to smartcard logon. The easiest ( and most common) one to understand is the SAN to UPN mapping, where the SAN in the smartcard certificate matches a username’s UserPrincipalName in the AD.

I have noted in green – the ones which are correct and boxed the incorrect ones in red. Oddly enough in one place it says “Issue,Subject, and serial” and in the other it says “X509:<I><SR>” ( which is correct ) and not “X509:<I><S><SR>” ( which is incorrect ) .


The more complex, and less documented ( or documented incorrectly ) are as follows:


  • UPN ( self-explanatory unless the cert has this in it and you want to disable it – see my last post for more info on this )
  • Subject and Issuer fields
    • altSecurityIdentities: X509:<I>DC=local,DC=dod,CN=SpatDoD Root CA<S>CN=gman
  • Subject DN
    • altSecurityIdentities: X509:<S>CN=gman
  • Subject Key Identifier
    • altSecurityIdentities: X509:<SKI>ddde2ca4b86db8a908b95c6cbcc8bb1ac7a09a41
  • Issuer, and Serial Number
    • altSecurityIdentities: X509:<I>DC=local,DC=dod,CN=SpatDoD Root CA<SR>32000000000003bde810
  • SHA1 Hash
    • altSecurityIdentities: X509:<SHA1-PUKEY>ed913fa41377dbfb8eac2bc6fcae71ecd4a974fd
  • RFC822 name
    • altSecurityIdentities: X509:<RFC822>

The only one which is kind of tricky ( other than actually knowing the correct identifiers ) is the Serial number. Here is an example of a cert and serial:


When dealing with certificates there is a CERT_CONTEXT data structure which has the CERT_INFO structure which contains the information of a certificate. The specific field which is looked at is ‘SerialNumber’. MSDN describes serial number as follows:


A BLOB that contains the serial number of a certificate. The least significant byte is the zero byte of the pbData member of SerialNumber. The index for the last byte of pbData, is one less than the value of the cbData member of SerialNumber. The most significant byte is the last byte of pbData. Leading 0x00 or 0xFF bytes are removed. For more information, see CertCompareIntegerBlob.

Note the text in red – this basically means that the last byte is the first byte returned – in other words, reversed. So the serial number as seen in the screen shot above 10e8bd03000000000032, will be read as 32000000000003bde810.

And this (32000000000003bde810 ) is what the code will be looking for, so this is what needs to be entered in the altSecID field.

Alrighty then – now that that’s all cleared up, on to other things.


Comments (11)

  1. SpatDSG says:

    NOTE: I removed the semicolons from the examples ( they are left in from the cut and paste from LDP.EXE — they now reflect what needs to be manually inserted as the literal value for altSecID — like "X509:<I>DC=local,DC=dod,CN=SpatDoD Root CA<S>CN=gman"

  2. ajprout says:

    What does the "Client certificate does not need to meet NT_AUTH policy" notation in the flowchart mean? If the cert doesn't need to meet the NTAuth policy, what policy does it need to meet?

  3. SpatDSG says:

    It means that the issuing CA of the cert does not need to be in the NTAuth store. See…/295663 for more info on that store

  4. Script Kitty says:

    I love this method.  We have combined this with the UseSubjectAltName=0 registry key on the DCs to allow us to use Smart cards issued from external CA’s without having to trust the CA’s (and having to trust that they aren’t creating a Certificate with the SAN of my enterprise admin.  Why would we do this?  Think government.

    I am using the X509:<SHA1-PUKEY>  method.  But wanted to leave one warning.  We set these values programmatically as part of our identity system.  But in testing I would copy a certificates thumbprint into notepad.  Then use search and replace to get rid of the spaces, put a X509:<SHA1-PUKEY> in front.  And then put the whole thing into the altSecurityIdentities attribute of the test user.

    And then get really confused because it didn’t work.

    Everything looks right.  And it works when I do it programmatically.

    It turns out that if you look at it with a dsquery command (I was searching to see if anyone else had a matching hash.

    You get:  X509:<SHA1-PUKEY>?2BE1954D50282082B54065F356868127AC44B60A

    Notice the ? before the hash?

    That’s actually a control character.   You don’t see it in the graphical interface.  But if you try to delete it it’s there.

    Once I removed the hidden ?  everything worked fine  (and I could stop pulling out my hair).

    This isn’t an issue with certificate mapping, just something odd about how I put the value in by hand.  Just wanted to put this here in case other people have similar problems.

  5. gaubert says:

    To get the right SerialNumber of a certificate, you can use the command : certutil -dump -v myCert.cer

    X509 Certificate:

    Version: 3

    Serial Number: 61157eee000000000011

       11 00 00 00 00 00 ee 7e 15 61

    Then you have your AltSecId :


  6. SpatDSG says:

    Ahh thanks Gaubert – never noticed that certutil dumped that format

  7. Brett Prucha says:

    In an X509 certificate the issuer and subject can contain CRLF (Carriage Return Line Feed) characters. When mapping a user to a certificate using subject and issuer fields that contain this sequence of characters, you need to replace them with the "," character (…/hh536384.aspx).

    Interestingly, Microsoft's Active Directory Users and Computers tool does not replace CRLF with a comma in the altSecurityIdentities value which results in an invalid mapping. I guess that would be a bug in that tool.

  8. J. Danno Crown says:

    For those unable to see X509 hints even after following the above, make sure your smart card vendor doesn't install a credential provider that overrides the default one. Have a look under [HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionAuthenticationCredential Providers, and make sure any related filters are removed. The cred provider can be disabled with  Disabled=1.

    Took me a bit to figger that out.

    J. Danno

  9. Josh B. says:


    On Windows 7 we would set the LastLoggedOnProvider value under the HKLMSOFTWAREMicrosoftWindowsCurrentVersionAuthenticationLogonUISessionData path to the smart card credential provider which is {8BF9A910-A8FF-457F-999F-A5CA10B4A885} on Windows 7. This would result in the smart card login being the default authentication method but still allow username/password login by clicking "Other Credentials".

    When we try to set LastLoggedOnProvider to {8FD7E19C-3BF7-489B-A72C-846AB3678C96} which is the new smart card credential provider value on Windows 10, it does not work.  We would like to default the credential provider to smart card instead of username/password.  We still want the username/password to be available so we don't want to completely exclude or disable the credential provider.  In Windows 7 this is relatively straightforward by using the LastLoggedOnProvider values but this does not appear to work for Windows 10.  We do not want to enable the function to remember the last logged on user account as this is prohibited by our security policy.

    Is there any way in Windows 10 to set the default credential provider for "Other User" to smart card instead of username/password?  Right now when the OS boots up, Other User is defaulted to a username/password login.  The user has to click on the Sign-in Options and then click the Smart Card icon in order to access the smart card login screen.



  10. Josh B. says:

    Answered my own question here as it appears that there is a group policy in Windows 10 under Computer Configuration>Administrative Templates>System>Logon, and set the value in Assign a default credential provider to {8FD7E19C-3BF7-489B-A72C-846AB3678C96} which is the smart card provider.

    This does appear to make smart card the default logon provider at the Windows 10 "Other User" screen.  The user can still click sign-in options to switch to username/password if desired.  Hope this helps somebody else for Windows 10 at least.

  11. SS says:

    What happens when a SmartCard has multiple certs on it? Is the above process run for each certificate that has the Key Usage of "Digital Signature" (assuming Extended Key Usage is being ignored by having "Computer Configuration/Administrative Templates/Windows Components/Smart Card/Allow certificates with no extended key usage certificate attribute" enabled in GPO) until a mapping is found?

    We are trying to get our SmartCards to work with two accounts for our sys admins. A regular account and an elevated privileges account. There are three certs on the card (card issued by third party). The first cert has a UPN on it which is mapped to the regular account and it works fine for logging in. Hoping to use the second cert which does not have a Principal Name in the SAN. Instead it has the RFC822 Name in SAN. The cert does have a key usage of "Digital Signature".

    Unfortunately, I cant get it to map properly using any of the 6 mapping methods. From a Windows 10 machine when RDP-ing into a 2008R2 server and trying to use username hint, it spits out the following: "The client certificate does not contain a valid UPN, or does not match the client name in the logon request…".

    Trying to figure out why this is failing. Is it because there is at least one cert with UPN in SAN and if that UPN does not match with the Username hint, the mapping process gives up without looking at the remaining certs on the smartcard. Or is there something missing from the other cert that we are hoping to be able to use.

    Debug logging of the logon process would greatly help in troubleshooting. Is there such a thing? I see some SmartCard channels in Event Viewer but they only have successes in them.

    I have also tried the "Force the reading of all certificates from the smart card" GPO without any change in the behavior.