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.
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
What do you do on a 2003 server and XP clients?
Can you just add the Reg Entry and it should work? Or am i out of luck with those Operating Systems?
2003 and XP do not have this capability .. sorry
If I do this, will Windows XP systems still be able to use the UPN value?
Love the Postings.
We found in our enviroment (multi-domain Empty-root forest) We needed to add two registry settings to the Windows 7 workstations, if we didn't want to turn on User Hints.
SendPreauthForNewerETypes = 1
UseSubjectAltName = 0
Without the SendPreauthForNewerEtypes, the DCs didn't seem to be able to find the user. this was only a factor in cross domain authentication.
Another data point for anyone testing. Turn off your cashing of credentials, it really confuses the testing data of what works and dosn't.
Script Kitty - thanks so much for the details - good info.
Script Kitty - awesome info. it was my solution, thanks for sharing.
Can anyone explain what SendPreauthForNewerETypes = 1 really does and why it is necessary?
Sorry, Devotee, I still don't have a clear understanding on what that key does, it has something to do with telling the windows clients what information they are suppose to be sending up in the initial request. Vista+ can handel it. I have been wanting to put a sniffer trace on it and see, but I am such a lazy cat, and the sun is shining on my favorit napping spot. so maybe tommarow...
there are three more data points I would like to share:
Splat, I love you.
Microsoft has been updating the white paper on how to do Smartcard Auth for the HSPD-12 goverment badges. it's a pretty good read:
We have recently run into an interesting problem at out location. We have been mapping our certs using the Cert mappting trick (See: blogs.msdn.com/.../howto-map-a-user-to-a-certificate-via-all-the-methods-available-in-the-altsecurityidentities-attribute.aspx , Now do you understand why I love Splat?) and we had been using the SHA1 mapping trick. we ran into trouble when the site started upgrading to exchange 2010. turns out exchange uses powershell, and Powershell didn't like the name mapping format, only the Subject and Issuer format, so we had to change to that.
Microsoft is "working on it" and is going to fix it, but we couldn't wait.
now back to my sunny spot.
What are the other impacts of turning off mapping the UPN from the SAN, if any?