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

As specified earlier it is possible to logon to an AD domain using either the legacy logon name (sAMAccountName), the implicit UPN (iUPN) or and the explicit UPN (eUPN). When trusts are in place between AD forests or between AD domains in different AD forest, the following conditions apply:

• External Trust between AD domains in different AD forests –> You can only use the iUPN to logon across AD domain boundaries;
  
• Forest Trust between AD forests –> As long as no conflict exists, you can logon with the default UPN Suffix of any AD domain in the AD forest or logon with any custom UPN Suffix configured at AD forest level to logon across AD domain boundaries.
  

In the second case, as you may know already, you can only create a Forest Trust when the Forest Functional Level of both AD forests is at least configured with "Windows Server 2003". With a Forest trust you can leverage UPN Suffix Routing, which routes any authentication request using the UPN to an AD domain within an AD forest that is connected to another AD forest by a Forest Trust. By default all UPN Suffixes (default and custom) are enabled for routing assuming no conflicts exist. The system will detect any conflict automatically and disable the UPN Suffix accordingly from routing that’s causing the conflict. It is also possible to exclude UPN Suffixes from being routed or disable custom UPN Suffixes from routing as needed.

For more information about UPN Suffix routing, see the following information about it:

• Interactive logon styles and Key Distribution Center account lookup in Windows Server 2003
• Users Can Log On Using User Name or User Principal Name
• Routing name suffixes across forests
• Modifying Name Suffix Routing Settings

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/ ########
———————————————————————————————

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

The implicit UPN (iUPN) is not stored in any attribute. It is just there and it depends on the username (e.g. ID12345) and the FQDN of the AD domain (e.g. ADCORP.LAB). However, the explicit UPN (eUPN) is stored in the attribute called "userPrincipalName" on the user object in AD. You can see an example of that in the following pictures.

With any LDAP tool (e.g. Attribute Editor, LDP, ADSIEDIT, DSMOD, ADMOD, etc.) you can configure any value you like in the "userPrincipalName" attribute, using any UPN Suffix you like also. However when using either Active Directory Users and Computers (ADUC) or Active Directory Administrative Center (ADAC) you can only configure UPNs with either one of the following UPN Suffixes:

• The default UPN Suffix which is the same as the FQDN of the AD domain. So for the AD domain "ADCORP.LAB", the default UPN Suffix is also "ADCORP.LAB".
  
• One or more custom UPN Suffixes which can be configured at AD forest level through Active Directory Domains and Trusts (ADDT) or by configuring the "uPNSuffixes" attribute on the "Partitions" container in the configuration naming context (the "uPNSuffixes" attribute on the "Partitions" container is a multivalued attribute that stores a list of custom eUPN suffixes for the AD forest);
  

• One or more custom UPN Suffixes which can be configured at OU level by configuring the "uPNSuffixes" attribute on the OU where user accounts reside (the "uPNSuffixes" attribute is a multivalued attribute that stores a list of custom eUPN suffixes for that OU only).
  

Looking at the possible configurable and usable options the following behavior exists when creating or editing user objects:

1. When no custom UPN Suffixes have been configured at any level, both ADUC and ADAC will only show the default UPN Suffix for the corresponding AD domain;
   

 

1. When custom UPN Suffixes have been configured at AD forest level, both ADUC and ADAC will show the default UPN Suffix for the corresponding AD domain and any custom UPN Suffix;
   

 

1. When custom UPN Suffixes have (also) been configured at OU level, a difference exists in the behavior between ADUC and ADAC. The difference is:
   
   1. ADUC will only show custom UPN Suffixes that have been configured at OU level where the user object is located. It will not inherit UPN Suffixes from parent container objects;
      
   2. ADAC will show the default UPN Suffix for the corresponding AD domain including any custom UPN Suffixes configured at AD forest and/or OU level. It will also not inherit UPN Suffixes from parent container objects;
      

 

If you want to remove any of the custom specified UPN Suffixes, it will not impact the existing configured UPN values on existing user objects. The configured values will remain configured. It will, of course, only impact newly created user objects after the removal of the custom UPN Suffix. Removing a custom UPN Suffix at AD forest level will impact UPN Suffix Routing over a Forest Trust, but that’s another story for a new blogpost!

Remember though, while ADUC and ADAC allow you to use a preconfigured UPN Suffix, nothing prevents you from using any LDAP tool (e.g. Attribute Editor, LDP, ADSIEDIT, DSMOD, ADMOD, etc.) and write whatever you like into the "userPrincipalName" attribute on the user object.

–

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/ ########
———————————————————————————————

(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/ ########
———————————————————————————————