Addendum: Getting started with Azure Active Directory Sync – UPN Suffix

In this post we’ll explore briefly using UPN (UserPrincipalName) suffix matching when configuring Azure Active Directory Sync Services. This particular configuration may seem like the silver bullet to getting our users synchronised in to the Azure AD correctly but it could also give you more problems if you don’t consider the rest of your infrastructure and how it may rely on that UPN suffix. I’d ask that you read this entry through before actually making any changes to your on-premises AD infrastructure.

In order to add a UPN suffix to your Active Directory you use Active Directory Domains and Trusts, right-click the root node and select Properties. Here you add your additional UPN suffix which, in our example is the same as the external domain we added and verified on our Azure portal.

Adding the new UPN suffix of transishun.co.uk has the effect of giving each user a new UPN suffix in the on-premises AD but, crucially, it does not change their currently set UPN.

To sync up to the cloud and create this user with the new UPN suffix, you would need to set the user’s UPN suffix to the newly added UPN from the drop-down. Having previously added and verified the external domain in Azure AD, this is basically the same user object name that the sync process will create in the Azure AD.

After setting each user’s UPN suffix that you want to sync up to the Azure Active Directory you would configure Azure Active Directory Sync Services. I’m not going to repeat Part 2 of the series here but suffice to say, in the Matching with Azure AD section of the Uniquely identifying your users page, next to userPrincipalName attribute, select userPrincipalName from the drop-down. This is actually selected by default.

Once configured and synchronising, these settings result in users having their usual Windows user name with the new external domain suffix created for their Azure AD credentials. For example, my users’ internal logon name would typically be lroberts@transishun.local but the sync services created an lroberts@transishun.co.uk in Azure AD because we have that external domain configured and verified in Azure AD and we asked it to use the users’ userPrincipalName attribute to create the user object. If we didn’t have the external domain configured and verified in Azure AD, it wouldn’t use the @transishun.co.uk UPN and we’d end up with the Default Directory’s domain suffix [something].onmicrosoft.com.

I should add that when you actually set the UPN suffix on each user object is irrelevant as far as when you configure syncing is concerned. If the on-premises user object doesn’t have a UPN suffix in the on-premises AD that matches a verified domain in the Azure Active Directory, that user object will be configured with the Default Directory domain suffix. As an example, the user oazure has been configured with the transishun.local UPN:

This setting results in the following happening in Azure AD. As you can see, our other users must have the correct userPrincipalName set in our on-premises AD and so they get the correct UPN in Azure AD.

So, why did I use the mail attribute when I configured sync in Part 2?

As you can see, using the UPN suffix change will require you to set each on-premises users’ UPN suffix to the verified external Azure AD domain before they’ll get an account that uses the correct domain suffix in Azure AD. Initially it might not sound like such a big deal to change the users’ UPN suffix in your on-premises AD but large domains may employ Public Key Infrastructure for issuing certificates to user accounts automatically using their primary/configured UPN. These can be for things such as automatic access to Enterprise Wireless services or user authentication. A service expecting to authenticate a user certificate assigned to, for example: lroberts@transishun.local will likely not accept a certificate assigned to lroberts@transishun.co.uk. It does of course depend on the service but my opinion is that using the mail attribute is the most fool-proof method of getting the correct results.

The reality is that people use their email address more often than their Windows AD username and it’s probably on their business card too so, to me, it makes more sense to use the mail attribute as described in Part 2 to match users, as opposed to the userPrincipalName shown in this post.

What about the fringe cases of people that have a different primary mail address?

Easy, set their userPrincipalName in Azure AD manually. See Part 3 – Mopping Up for how to do that.

Thanks

-Lewis