Azure Basics: Azure AD User Pricipal Name – UPN

Looking at Azure AD User Principal Name it is the same as almost always in IT: For a successful implementation it is recommendable to have a thorough plan in place. The same can be said when implementing and connecting to cloud services. The cloud hype promised a straightforward and easy implementation. In reality it becomes evident that it is advisable to think about what you want to do with the cloud services.  This is why I chose “User Principal Name“, short UPN, as the topic for this article.

Azure AD User Principal Name (UPN) and sAMAccountName

Within the on premise Active Directory domain the sAMAccountName is unique and cannot occur twice. However, in the Azure AD domain there is no sAMAccountName. Here, the UPN is the unique property of a user account.

So, the standard configuration of the Azure AD UPN looks like this:
username@<E-mail of LifeID>.onmicrosoft.com.

The E-mail of LifeID means the e-mail address of the lifeID (without the “@” sign) with which the Azure subscription was initially created. In this way Microsoft makes sure that the UPN suffixes of the Azure AD accounts are unique.

User Principal Name for signing in to Azure AD

Users sign in to Azure Cloud Services, like O365, with the UPN. At this point you realise that it is important to plan the namespace so it will be easier for users to login. Unless you want them to login with “first name.last name@LifeId-domainsuffix.onmicrosoft.com”. In addition, it is even more important if you think about setting up a federation with ADFS. The logon from so called federated accounts is redirected to the local Active Directory domain via ADFS (or a federation service of another provider). This redirection is based on the UPN suffix of the Azure AD user account. It leads us to the next important point:

Registering the UPN suffix

Many companies follow the recommendation to register the DNS name of the local Active Directory domain online. In general, this is helpful when connecting to cloud services because the domains are registered and can be resolved. Thus they can be used for routing. In this case, the automatically created UPN (sAMAccountName@AD-Domain) can be used for ADFS delegation in Azure AD.

UPN suffix in SSL federation certificate

In order to implement a federation with Azure AD you will have to create a SSL certificate for the UPN suffix. This certificate needs to be signed by a certification authority (CA). However, it will not work if your DNS domain is not registered.

A suitable domain name

So, if your local AD domain has a DNS name such as “company.local” you might run into problems as I described above. You can neither register the domain nor acquire “official” SSL certificates. Thinking about it, you could rename the local AD domain and register the new name… jokes aside, there is another option. As a better solution, add another UPN suffix to the local AD domain which can be registered online. The simplest option is to choose the e-mail address. Since the DNS suffix of the e-mail address has already been registered there are two advantages. Firstly, these addresses are unique and secondly, your users already know them. The second point is important because users will type in this e-mail address to login to the cloud services. The easier the address, the easier the implementation.

New UPN in local AD domain

Adding the UPN suffix is very easy via the “Active Directory Domains and Trusts” console, even though it is slightly hidden. The setting cannot be found in the domain properties, but in the top node „Active Directory Domains and Trusts“. Open the settings of the top node and you will get a dialog to add alternative UPN suffixes.

So, as you can see in the following screenshot I added “univice.net” as a UPN suffix:

New UPN in user accounts

Now you have to add the UPN suffix to the user accounts in the local AD domain in order to use the UPN for login. You can either do this manually via the “Active Directory Users and Computers” console, or with PowerShell. 

To add a new UPN, use the PowerShell cmdLet Set-ADUser and add a new UPN via the parameter “-UserPrincipalName“. Read the following TechNet post which explains how to apply these changes to all user accounts of an OU.

An additional domain in Azure AD

Furthermore, you have to introduce the DNS suffix which is used for the local UPN to Azure AD as well. In order to guarantee correct and authorized domain allocation Microsoft installed a security check. You can add another DNS domain in the Azure administration console (classic) via “Default directory/domains/add custom domain“. Next, you will see a dialogue window with a TXT entry which has to be registered online in the public DNS zone. The Azure administration console will query this entry. As soon as the system can resolve this entry via DNS, the DNS zone will be registered successfully in Azure AD. From a Microsoft point of view, the user who is permitted to create new entries in the DNS zone is also authorised to register the DNS zone in Azure AD.

Here is an example of a Nslookup query with TXT:

Azure AD UPN at a glance

The picture below shows the resolving of a DNS name for the UPN “@univice.net” and the routing of the registration via the local ADFS server to the Domain Controller. (I skipped the Web Application Proxy WAP in order to keep it simple).

Conclusion Azure AD User Principal Name

In summary, it is important to plan the DNS namespace for the connection with Azure AD. It has an impact on your users.

If you are starting a cloud transition project, please contact us for advice, planning and implementation. FirstAttribute AG is a German software and consulting company with specialised knowledge of AD, O365 and Azure.