Wednesday, 16 April 2014

samAccountName vs userPrincipalName


   In Active Directory based environment, everyone should come across the AD attribute names samAccountName and userPrincipalName or UPN. In this article, I am going to explain the difference between samAccountName and userPrincipalName(UPN).

The samAccountName is the User Logon Name in Pre-Windows 2000 (this does not mean samAccountName is not being used as Logon Name in modern windows systems). The userPrincipalName is a new way of User Logon Name from Windows 2000 and later versions. user Name part can be different for the same user like DomainName\testUser and userTest@DomainName.Com.

Before see the detailed explanation, we can check the summarized details of userPrincipalName and samAccountName.


   - The samAccountName attribute is the user logon name used to support clients and servers from a previous version of Windows ( Pre-Windows 2000).
   - The user logon name format is : DomainName\testUser.
   - The samAccountName must be unique among all security principal objects within the domain.
   - The samAccountName should be less than 20 characters.
   - Query for the new name against the domain to verify that the samAccountName is unique in the domain.
   - The USERNAME environment variable is the samAccountName even when logging with UPN

UserPrincipalName - (UPN)

   - The UPN is an Internet-style login name for the user based on the Internet standard RFC 822.
   - The user logon name format is :
   - The UPN must be unique among all security principal objects within the directory forest.
   - The advantage of using an UPN is that it can be the same as the users email address so that the user need to remember only a single name.
   - The UPN is optional, it can be assigned or not when the user account is created.
   - The userPrincipalName is unaffected by changes to other attributes of the user object, for example, if the user is renamed or moved, or changes to the domains in the tree, for example, if a parent domain was renamed or a domain was moved. Thus, a user can keep the same login name, although the directory may be radically restructured.

Working with samAccountName and userPrincipalName

Lets take the following test user whose samAccountName is Test2 and userPrincipalName is Test1@Work2008.local

samAccountName vs userPrincipalName in Active Directory
samAccountName vs userPrincipalName in Active Directory

Now, we can use the RunAs command to validate these two user logon names. To use RunAs command, you need to run the command prompt with an elevated privilege (Run As Administrator) and the Test user should be the member of Domain Admins group.

Use the below command to validate samAccountName login name
C:\> RunAs /user:work2008\Test2 cmd
difference between samAccountName and userPrincipalName(UPN)

Use the below command to validate userPrincipalName login name
C:\> RunAs /user:Test1@work2008.local cmd
difference between userPrincipalName and  samAccountName

USERNAME environment variable is the sAMAccountName even when logging with UPN:

    We have stated that the USERNAME environment variable is the sAMAccountName even when logging with UPN. To check this run the below command in new cmd window opened by RunAs command with userPrincipalName
C:\Windows\system32> Set UserName
userPrincipalName vs samAccountName

Software Developer



  1. Is there an environment variable for the UPN?

    1. No julien, as for as I know, there is no build-in environment variable for upn.

  2. What a horrible mess.
    I only started looking at this after weird authentication issues using an AD service account in UNIX
    The "clever" person who created used a . (dot) in the middle of the name for UPN but a , (comma) for the sAMAccountName
    Maybe there was a good reason in the distant past for backwards compatibility and NT4 --> 2000 migrations to let them differ. But surely Microsoft could enforce them to be the same nowadays?

  3. it's quite the opposite..

    windows is bending / breaking kerberos rules, while it's linux and Kerberos which is still stuck in the past.

    As you stated @anonymous you ran into trouble with a Linux / unix acct. Kerberos requires the older sAMAccountName while newer windows products are able to use a UPN or name@domain type account