good lord this is an ugly blog... I need to find the time to customize this hideous new theme
It’s been a while since I’ve blogged about something around smartcards ( ha! ) , so here goes.
Here is the basic setup. The smartcard certificate has the following key information:
Issuer: CN=SpatDoD Root CA, DC=dod, DC=local
SubjectAltName: Other Name:Principal Namefirstname.lastname@example.org
The domain to logon to is DOD.LOCAL with a number of forest trusts to other domains, but NOT a trust to any forest with the name suffix of FEDID.GOV, which of course is the suffix for the SAN on the smartcard cert.
Typically, if the certificate contains an SAN/UPN extension and no user object is found based on the UPN, the authentication fails.
In this case we look at the UPN of the user we will see UPN = email@example.com
Please note that this will not meet the UPN matching rule since the SAN is firstname.lastname@example.org
So, how can we map this user?
Keep in mind , if the SAN doesn’t match a user in the target domain, it will look for the domain suffix ( in this case fedidi.gov ) in a forest trust routable namespace ( see this post for more info ) . But for this scenario there is no other forest in play – the user resides in the immediate DOD.LOCAL domain. If no routable namespace is found, it will fail the authentication.
So, we need a way to map the user and NOT use the UPN – instead we want to use the altSecurityIdentities attribute to map the certificate to the user. I am not going to go into all the different ways to map altSecurityIdentities to
various fields in a smartcard certificate – see here for more information on that.
First, we need a way to disable the default UPN mapping behavior . Aha! See http://technet.microsoft.com/en-us/library/ff520074(WS.10).aspx for an interesting reg value called useSubjectAltName .
The Technet blurb describes it as follows:
KEY = HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc.
Type = DWORD
Value Name = UseSubjectAltName
Value Data = 0
And it is important to note that the value of UseSubjectAltName needs to be set on all KDCs for the domain.
OK – so now that we have disabled UPN mapping, we can use standard altSecurityIdentities mapping right?
There is a small matter of which user to logon – you need to give an additional hint to the system in the form of one of the following
SamAccountName --- i.e gman
Domain\samAccountName --- i.e dod\gman
UPN of user i.e email@example.com
This additional UI is controlled via GPO under Computer Configuration\Administrative Templates\Windows Components\Smart Card
And the resulting logon looks like this:
This does seem to fly in the face of the following statement from http://msdn.microsoft.com/en-us/library/bb905527.aspx#BKMK_ClientCertificate.
It agrees with the first statement in blue, but obviously contradicts the red sentence. I have not had the time to determine why – but if someone really wants to know I can look at the KDC paths to determine.
The certificate object is parsed to look for certain contents to perform user account mapping. When a user name is also provided with the certificate, then the user name is used to locate the account object. This operation is the fastest, because string matching occurs. When only the certificate object is provided, then a series of operations are performed to locate the user to map the user to an account object. When no domain information is available for authentication, the local domain is used by default. If any other domain is to be used for lookup, then a domain name hint should be provided to perform the mapping and binding. Mapping based on generic attributes is not possible, because there is no generic API to retrieve attributes from a certificate.
Currently, the first method that locates an account successfully wins, and the search stops. But if two mapping methods map the same certificate to different user accounts when the client does not supply the client name via the mapping hints, then it is a configuration error.
Anyway – hope it was useful to someone. Have fun out there