(2010-10-12) User Principal Names In AD (Part 1)

Within AD, every user account had two types of password based logon credentials that can be used to authenticate. The first one is the "pre-Windows 2000 User Logon Name" (a.k.a. the sAMAccountName) and the "User Logon Name" (a.k.a. userPrincipalName). The format of the first is for example "ADCORPID12345" and the format of the second is for example "ID12345@ADCORP.LAB". The "userPrincipalName" (UPN) requires additional explanation.

The UPN is a variation of a user account name that looks like an e-mail name which can be used to log on to an AD domain. Within an AD domain, two types of UPNs exist, the "implicit UPN" (iUPN) [1] and the "explicit UPN" (eUPN) [2].

[1] The Implicit UPN (iUPN): has the form of "username@FQDNDomainName". The iUPN for the user Jorge de Almeida Pinto is for example "ID12345@ADCORP.LAB" for which the username is "ID12345" in the AD domain "ADCORP.LAB". The iUPN is just there as you cannot view or configure it. The iUPN is always associated with the user’s account whether or not an eUPN is defined. The iUPN is the UPN that will always be shown in Kerberos TGTs and Kerberos Service Tickets whether or not an eUPN is defined. If no eUPN has been defined on the user account, the iUPN will be shown in an enrolled certificate for the user if also specified in the certificate template.

[2] The Explicit UPN (eUPN): Has the form of "userIDstring@FQDNstring". Both "userIDstring" and "FQDNstring" (UPN suffix) are explicitly defined by the administrator. For example, Jorge de Almeida Pinto might have the eUPN "Jorge.De.Almeida.Pinto@THEQUESTFORKNOWLEDGE.COM" configured, which in this case is exactly the same as his e-mail address, but that’s not mandatory. The eUPN is the UPN that will never be shown in Kerberos TGTs and Kerberos Service Tickets. During the logon process when the "Kerberos Authentication Service Request (AS-REQ)" takes place, the request is made using the username (in this case, the eUPN) that has been provided by the user at logon. However, Kerberos tickets are always returned to the user specifying the iUPN of the user account that has the same eUPN used at logon. In short, the eUPN is just a cosmetic thing to allow the specification of a different UPN which can be different than the iUPN. If an eUPN has been defined on the user account, the eUPN, instead of the iUPN, will be shown in an enrolled certificate for the user if also specified in the certificate template. In some companies the eUPN ic configured the same as the iUPN value and others configure the eUPN with the same value as the primary e-mail address. In addition to the sAMAccountName and the iUPN, a user is also able to logon with the eUPN if configured. Some companies don’t like to configure the eUPN with the primary e-mail address because that could/would mean "the world" by default would already know half of your creds, leaving the password left to guess. Other companies do not really care about the eUPN being the same as the mail address. Using the mail address does solve the uniqueness problem because an e-mail address by itself must be unique. In a multiple AD forest environment that uses forest trusts it is not possible use the same eUPN in different AD forests without creating conflicts. Therefore, only one AD forest should be configured as the owner of a certain UPN suffix. Each AD forest should therefore only use unique UPN suffixes to make sure UPN routing works correctly.

The sAMAccountName of any security principal within a certain AD domain must be unique across that AD domain. AD itself will enforce uniqueness by not allowing duplicates. No matter what tool or method is used to specify/populate the sAMAccountName, AD will always check within the local AD instance if it has already been used on another security principal within the same AD domain. Although the sAMAccountName is a mandatory attribute for every security principal, it is not mandatory to specify this attribute. When no unique value is specified, AD itself with generate a unique random value.

Because the iUPN depends on the sAMAccountName and the FQDN of the AD domain, it will always be unique. The eUPN can have any value and should of course also be unique. I’m saying ‘should’ and not ‘must’ because AD itself does not enforce uniqueness for the eUPN. However, when you create or edit a user account through Active Directory Users and Computers (ADUC), uniqueness will be enforced. In this case ADUC itself is checking for uniqueness and will warn when the specified value is not unique, not the directory services itself. If you were to create the same user account using some LDAP tool, it would not check for uniqueness. If multiple user accounts in AD have the exact same eUPN configured, when logging on with that eUPN AD cannot determine which user account to logon with so an error will be generated.

–

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————