The UPN and sAMAccountName are user account attributes in Active Directory. In this article, I’ll explain how these two user account attributes work and how the username and user logon name can be used in your organization.
In the world of Active Directory, there are two core user naming attributes – UserPrincipalName (UPN) and the sAMAccountName (SAM). These identify user objects such as logon names and IDs used for security purposes.
Essentially, a user object is a security principal object. The configuration of your Active Directory will dictate how your users use these various objects when authenticating to their computers.
The sAMAccountName (or sam account name) attribute was utilized with the birth of Windows NT way back in the day. It was also the default used with previous versions of Windows at the time, like Windows 95 and Windows 98 to name a few. It is a logon name to support clients and servers that had a hard limitation of 20 characters and was required to be unique among all security principal objects within your domain.
And here is similar information in the more modern Active Directory Administrative Center.
Before the advent of Active Directory in Windows 2000, this was used for authentication purposes when logging into Windows NT 4 Workstation computers and Windows NT 4 Server servers. Users could log in against the local SAM (Security Authentication Model) databases found on said Windows NT 4 computers.
The format used is this: DomainName\UserAccount. So, if your (NetBIOS) domain name was ‘Reinders’, you would log in to your workstation like this: ‘REINDERS\mreinders’.
You also see this type of login method to this day, in Windows 10 and Windows 11. However, these more modern operating systems are built with DNS in mind. This is why the preferred method to log in today is by ‘User Principal Name’ which is built upon the attributes of DNS.
What is this UPN I speak of? Well…
The UPN or userPrincipalName is the more modern attribute or user naming object introduced with Active Directory in Windows 2000. It is an Internet-style login name for users based on the Internet standard RFC 822.
The UPN attribute consists of a user principal name (UPN), which is the most common today for Windows users. Users typically use their UPN when logging onto a domain-joined workstation/computer. The attribute is single-valued and an indexed string.
The UPN is shorter than a distinguished name and much easier to remember! This should map to the user’s email name, by convention. It is not required, but it has obvious advantages for your users when it is the same. This is the whole point – to consolidate the email and login namespaces so that the user only has one item to remember (and not write down underneath their keyboards…much less their passwords!)
As I stated above, the main advantage of using a UPN is consolidating several user attributes into one single item. All a user needs to know is that they use their email address when logging into their computer. And, if you happen to be using Microsoft 365 services, your users can use this same UPN to log in to Microsoft 365! 3-in-1!
Another advantage for IT pros is the ability to identify what Active Directory domain the user belongs to. One user could log in with ‘[email protected]’ and another could log in as ‘[email protected].’ Without asking the user or HR, you can determine whether they are a corporate employee. Very slick!
The userPrincipalName format is the email address format. Again, this is Internet standard RFC 822. The UPN must be unique among all security principal objects in the forest.
A UPN consists of a UPN prefix (the user account name) and a UPN suffix (a DNS domain name). They are joined with the ‘@’ symbol. And to be clear, the prefix of a UPN can be reused in a forest, just not the same suffix. So, you can have [email protected] and [email protected].
The quick answer is Yes. Remember – the sAMAccountName was created in Windows NT days. The userPrincipalName was created in Windows 2000 days – many years apart. But, back to engineering, they do not need to be the same. In fact, there may be advantages to using differing attributes for each.
Windows Server allows IT pros to add a new UPN suffix to your domain. Go ahead and open Active Directory Domains and Trusts, right-click on your root domain, and click Properties.
Here, you can add a new UPN suffix and click Add.
Be aware that there is one restriction: the user account that adds these suffixes needs to be in the Domain Admins or Enterprise Admins security groups. Or, you must be delegated the authority. Plus, UPN suffixes should conform to DNS conventions for valid characters and syntax.
With the advent of Active Directory, a lightweight directory accesses protocol (LDAP)-based directory service, DNS became the foundation for its hierarchical organizational structure. And in turn, the birth of the userPrincipalName (UPN).
When a user logs into a domain-joined workstation with their UPN, Active Directory first searches the specified domain (UPN suffix) for the user’s credentials, then the global catalog (which will search the entire forest). If that search comes up fruitless, the login will fail.
The only aspect you need to know about validating user naming objects is that sAMAccountNames need to be unique in a domain. UPNs need to be unique in your forest. Aside from that, UPNs are optional. Meaning, your user accounts in Active Directory don’t need to have them. Nothing will break.
Also, if you make changes to other name attributes for your user accounts, their UPNs will not change, unless you explicitly specify.
Now that you have a better understanding of the purpose behind the sAMAccountName and the userPrincipalName, you have an improved method of what naming conventions you can use in your enterprise and how to educate your users on how to login to their computers. Remember, you generally want to make things easy for them. Because…users!
If you have any questions or comments, please feel free to leave a comment below. Thank you for reading!