HowTo: Disable UPN mapping for SmartCard logon



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:


Serial: 10e8bd03000000000032

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

Subject: CN=gman

SubjectAltName: Other Name:Principal


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


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 ) 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 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    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

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






Comments (9)

  1. Lukas says:


    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?

  2. SpatDSG says:

    2003 and XP do not have this capability .. sorry

  3. Justin says:

    If I do this, will Windows XP systems still be able to use the UPN value?

  4. Script Kitty says:

    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.

  5. SpatDSG says:

    Script Kitty – thanks so much for the details – good info.

  6. Devotee says:

    Script Kitty – awesome info. it was my solution, thanks for sharing.

    Can anyone explain what SendPreauthForNewerETypes = 1 really does and why it is necessary?

  7. Script Kitty says:

    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:…/hspd-12-logical-access-authentication-and-2008-active-directory-domains-on-download-center.aspx


     We have recently run into an interesting problem at out location.  We have been mapping our certs using the Cert mappting trick (See:…/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.

  8. SigurdReg says:

    What are the other impacts of turning off mapping the UPN from the SAN, if any?

  9. jokezone says:

    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?

Skip to main content