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>email@example.com
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.