Within Active Directory, each user account has two types of logon credentials available for authentication:
- Pre-Windows 2000 User Logon Name (sAMAccountName): For example, domain\User1
- User Logon Name (userPrincipalName or UPN): For example, User1@domain.com (resembles an email address). Generally speaking, there are two types of UPNs:
Implicit UPN (iUPN): Always associated with the user account, regardless of whether an explicit UPN is configured.
Explicit UPN (eUPN): Optional, administrator-defined alternative.
When no eUPN is defined for a user account, the iUPN will appear in the user's enrolled certificate (if specified in the certificate template). See the examples below:
The left figure illustrates a certificate template configured for user-based certificate enrollment, while the right figure displays an issued certificate containing the User Principal Name (UPN) in its Subject Alternative Name (SAN) field. This occurs when the "User Principal Name (UPN)" option is selected within the certificate template configuration.
The eUPN follows the format "userID@FQDN", where the both components are administratively defined:
-
userID: Typically matches the user ID (e.g.,User1) -
FQDN: The UPN suffix (e.g.,contoso.com)
Once again, while an eUPN may match the user's email address, this is not required. The eUPN serves as an administrator-defined alternative to the iUPN. When an eUPN is defined, it replaces the iUPN in issued certificates (if the certificate template includes the UPN in the SAN). From user authentication point of view, users can authenticate using:
-
sAMAccountName (
DOMAIN\User1) -
iUPN (
User1@domain.com) -
eUPN (if configured, e.g.,
User1@contoso.com)
Organizational Practices:
-
Some organizations align eUPN with iUPN values.
-
Others synchronize eUPN with the user's primary email address for consistency.
The iUPN is automatically unique because it combines: The user's sAMAccountName (unique within the domain) and the domain's FQDN (e.g., user1@domain.com). In contrast, eUPN requires manual uniqueness management:
-
Active Directory does not inherently enforce eUPN uniqueness at the directory level. However, the "Active Directory Users and Computers" console performs client-side validation and warns against duplicate eUPNs. As an example, I have created a user in Active Directory using "Active Directory Users and Computers" console, named "User 20". The user's iUPN is "user20@domain.com", but he's eUPN is user20@something.com:
Now, if I try to create a same user with the same eUPN:
- LDAP tools bypass uniqueness checks. If creating/modifying users via LDAP tools (e.g., “Attribute Editor”, “ldp.exe”), duplicates can occur since no validation is performed. If multiple users share the same eUPN, authentication attempts using that UPN will fail—AD cannot resolve which account to authenticate.
The iUPN is not stored in any attribute. It is just there and it depends on the username and the FQDN of the AD domain. In other words, iUPN – derived, not stored. However, the eUPN is physically stored in the userPrincipalName attribute of the user object (see the figure below). Administrators can modify or remove this value, allowing customization independent of the domain’s FQDN.
There are two methods to configure UPN Suffixes in Active Directory:
LDAP-based tools (e.g., Attribute Editor, ldp.exe, or PowerShell) allow administrators to:
-
Set any custom value in the
userPrincipalNameattribute. -
Use arbitrary UPN suffixes, regardless of whether they are formally defined in the domain.
The Active Directory Users and Computers and Active Directory Administrative Center consoles enforce stricter controls:
-
Only predefined UPN suffixes (listed in Active Directory Domains and Trusts) can be selected.
-
Administrators cannot manually type an unregistered suffix in these interfaces.
Now the main concern arises: How does UPN affect certificate-based network authentication methods like EAP-TLS?
In certificate-based authentication (e.g., EAP-TLS), the UPN serves as the primary linkage between:
- In EAP-TLS, the UPN is typically embedded in the certificate’s SAN field.
-
Active Directory uses this UPN to: Map the certificate to the correct user account and then validate the user’s identity during authentication.
If the UPN in the certificate doesn’t match AD’s expected value (iUPN or eUPN), authentication fails.
