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 Nameemail@example.com
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 = firstname.lastname@example.org
Please note that this will not meet the UPN matching rule since the SAN is email@example.com
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 firstname.lastname@example.org
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.
Anyway – hope it was useful to someone. Have fun out there