The user principal name (UPN) and SAM account name user naming attributes in Active Directory are often confused by administrators. After all, aren't we past Windows NT domains and single-label names? Let's sort out the mystery right away.

When I entered the information technology (IT) industry in 1998, I worked with Windows NT 4.0 domains and domain-joined Windows NT 4.0 Workstation client systems. Microsoft created the Security Account Manager (SAM) database to store user account information.

Each Windows NT 4.0 Workstation system had its own local SAM account database, and each Windows NT 4 Server domain controller had a domain-scoped SAM account database.

When I needed to sign into my workstation by using a local account, I'd provide the username (tim). When I needed to sign into the NT domain, I'd use the format domain\user (corp\tim) as the user name field.

This pattern worked fine in those days because we generally used proprietary local area network (LAN) protocols like NetBIOS and NetBEUI. Moreover, most businesses used a single-domain organizational structure. Windows NT supported domain trusts, but each domain was essentially an island unto itself.

The SAM account name had (and still has to this day) a fixed, 20-character length limit. Moreover, the following characters are prohibited: "/ \ [ ] : ; | = , + * ? < >.

Enter the user principal name ^

In late 1999/early 2000, Microsoft changed the game rules by releasing Windows 2000. We now have a lightweight directory access protocol (LDAP)-based directory service that uses domain name system (DNS) names as a hierarchical organizational structure.

In an Active Directory domain, each user in the forest is uniquely identified by their account's principal user name, or UPN. The UPN uses Request for Comments (RFC) 822, the Internet standard document that defines the email address format as its naming convention:


What's cool about the UPN user account attribute is that you can see where a user fits into your Active Directory forest. For instance, which of the following users is a member of the root domain, and which is a member of a child domain?

UPNs help you avoid user name collisions in a forest. For example, you might have two Pat Smiths in two different forest domains. I think you'd agree that and are likely different people from different parts of their org.

Another crucial idea behind the UPN is that, as a user sign-in name, it can and should reflect the user's Simple Mail Transfer Protocol (SMTP) email address. Sadly, I've found that many businesses miss the proverbial boat on this final point and wind up with an AD domain name that is different from the organization's mail-enabled business domain.

Look, I get it—at one time it was customary to use non-Internet-routable domains for your internal Active Directory domains. However, in today's Azure Active Directory-synchronized world, you need to have an internal domain name that matches the business domain you verified in your Azure AD tenant.

The good news is Windows Server allows you to add a new UPN suffix to your domain. After you ensure your user account's membership in either the Domain Admins or Enterprise Admins groups, open the Active Directory Domains and Trusts Microsoft Management Console (MMC), right-click the root node, and select Properties from the shortcut menu. In the Active Directory Domains and Trusts window, add a new UPN suffix and click Add. I show you the interface in the figure below.

Adding a new UPN suffix to your domain

Adding a new UPN suffix to your domain

You now can update the User logon name property for your affected domain users, either in the user's Properties sheet in Active Directory Users and Computers (shown in the next figure), or by using some PowerShell, as in the following example.

In the next code block, we start by retrieving a list of our Active Directory users and their current UPNs. We then change their original 4sysops.local UPN suffix to and then verify the change:

# Get a list of domain users and their current UPNs:
Get-ADUser -Filter * | Sort-Object -Property Name | Format-Table -Property Name, UserPrincipalName
# Replace existing UPN with new UPN
$LocalUsers = Get-ADUser -Filter {UserPrincipalName -like '*4sysops.local'} -Properties userPrincipalName -ResultSetSize $null
$LocalUsers | foreach {$newUpn = $_.UserPrincipalName.Replace("4sysops.local",""); $_ | Set-ADUser -UserPrincipalName $newUpn}
# Verify the new UPN
Get-ADUser -Filter * | Sort-Object -Property Name | Format-Table -Property Name, UserPrincipalName
Updating a user's UPN suffix

Updating a user's UPN suffix

What does this mean for us in 2021? ^

Okay. If you've been following me thus far, we are now aware that since Active Directory Domain Services has been released, our domain users have two sign-in names:

  • UPN, which looks like an email address and uniquely identifies the user throughout the forest (Active Directory attribute name: userPrincipalName)
  • SAM account name, also called the "pre-Windows 2000 logon name," which takes the form domain\user (Active Directory attribute name: sAMAccountName)

It's important to note that when a local AD user signs into their workstation by using their sAMAccountName, the domain portion is a single label, akin to a NetBIOS name. Thus, a user signing into their Windows 10 domain-joined workstation would use corp\username and not\username because sAMAccountName has no "knowledge" of DNS or Internet standards, for that matter!

When you synchronize local AD user accounts into Azure AD by using Azure AD Connect, the tool uses the userPrincipalName attribute as the Azure AD sign-in name property by default, as shown in the following figure:

Azure AD Connect default sync behavior

Azure AD Connect default sync behavior

That said, Azure AD Connect also allows you to use another local AD user account attribute as the Azure AD username; this feature is called Alternate ID.

Interestingly, when you configure a Windows Server virtual machine (VM) for Azure AD authentication, you need to sign into the VM by using a sAMAccountName-type syntax, substituting the static string AzureAD for the domain field, like so:


Takeaway conclusions ^

In summary, I'd like you to walk away from this tutorial with three primary conclusions:

Subscribe to 4sysops newsletter!

  • Do whatever you can to ensure your local AD UPNs match your email-enabled business domains.
  • Train your users to sign into the local domain by using what they think is their email address (but what is actually their UPN, as you now understand).
  • Accept the inconsistencies introduced with the sAMAccountName attribute. Unless Microsoft redoes Windows internal plumbing, those dependencies are likely to persist indefinitely.
1 Comment
  1. Apurva Mishra 2 years ago

    Great Article..

    I need some advice from you. In my current organization we have SharePoint ON-Premise as well as SharePoint Online. There is one application that is hosted on SHarePoint OnPremise version and it is using sAMAccountName  attribute from user profile. WE are given the task to move this application to SharePoint Online , which uses Azure AD. Can you please let me know if the sAMAccountName attribute can be accessed in SharePoint Online/O365.

Leave a reply

Your email address will not be published.


© 4sysops 2006 - 2022


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account