HowTo: Disable UPN mapping for SmartCard logon

<rant>

good lord this is an ugly blog... I need to find the time to customize this hideous new theme

</rant>

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:

Serial: 10e8bd03000000000032

Issuer: CN=SpatDoD Root CA, DC=dod, DC=local

Subject: CN=gman

SubjectAltName: Other Name:Principal Name=gman@fedid.gov

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 = gman@dod.local  

Please note that this will not meet the UPN matching rule since the SAN is gman@fedid.gov

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 https://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?

Almost.

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    gman@dod.local

 

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 https://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

Spat

Comments

• Anonymous
  June 28, 2010
  Hi. 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?

• Anonymous
  June 29, 2010
  2003 and XP do not have this capability .. sorry

• Anonymous
  August 10, 2010
  If I do this, will Windows XP systems still be able to use the UPN value?

• Anonymous
  May 23, 2011
  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. HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaKerberosParameters 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.

• Anonymous
  June 05, 2011
  Script Kitty - thanks so much for the details - good info.

• Anonymous
  May 17, 2012
  Script Kitty - awesome info. it was my solution, thanks for sharing. Can anyone explain what SendPreauthForNewerETypes = 1 really does and why it is necessary?

• Anonymous
  May 22, 2012
  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: First.  Splat,  I love you.   Second.   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: blogs.technet.com/.../hspd-12-logical-access-authentication-and-2008-active-directory-domains-on-download-center.aspx Third.    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.

• Anonymous
  June 02, 2013
  What are the other impacts of turning off mapping the UPN from the SAN, if any?

• Anonymous
  December 30, 2015
  Hi there, My company relies heavily on UPN mapping, so disabling this at the DC level would cause a lot of confusion to users who don't even know what their username is anymore. It would be better if this could be disabled only for users who do not require the UPN mapping (like sys admins with multiple admin accounts, one for each of their admin duties). So we are in a hybrid state where some accounts are using UPN mapping and others use name mapping with user name hint. I should mention our smart cards have multiple certs: one with the UPN/SAN attribute for the one-to-one mapping and another without (used for name mapping to the cert subject + issuer). I ran into one problem with name mapping: I can log onto servers fine with the name mapped cert plus user name hint, but if I try to map a network drive to that same server with the same cert/hint, it fails. Looking at the Security log on the server does not show that the hint ever got passed on. Could this be a bug? Is anyone else having trouble mapping network drives with a name mapped cert + hint?