Forum Discussion
Best practice when UPN and email address are different but both routable?
Our on-premise AD is a multi-domain forest with different business units in separate child domains. Each child domain uses a UPN of the form username[at]unitX.onpremad.com and we've validated all these in the cloud. However, all users have email addresses like fullname[at]emaildomain.com, that domain is also validated with Entra AD. Users frequently join teams in a different business unit so their AD account is migrated across domains and their UPN changes at that time, but their email address stays the same.
I've read through a lot of documentation on how the best practice is for the UPN and email to be the same for O365, but that you could have them be different using alternate ID support. But when they are different, apparently there are a number of little "gotchas" in terms of application support. So, before we sync our on-prem AD, I'm trying to understand which scenario will be the best supported over the long term with the least headaches to both users and IT.
Changing the on-prem UPN to match the email address isn't possible due to a critical LOB app that expects the UPN suffix to break down into username and business unit domain name. So, would it best to:
- Sync users with their on-prem UPN as their cloud UPN. This seems easiest to configure, but the documentation seems to imply there's a lot of manual fixing up when the UPN changes and possibly application compatibility issues since the UPN and email are different.
- Sync the primary email address as the cloud UPN. Looks to require custom configuration. Has the advantage that UPN and email match and the email address rarely changes. However, I'm unclear if this is supported since we'd still have some accounts (primarily administrators) without a mailbox and so no mail or proxyAddresses fields filed in. Unclear if there are any other "gotchas" to watch out for since this is a non-standard configuration.
Thanks for any advice you can provide.
Hi, Brian.
While I'm happy to stand corrected, last I checked, having userPrincipalName and mail contain the same value is recommended practice, not best practice. That's a subtle but important point of difference as technically, there's absolutely nothing wrong with those two values differing.
It's more akin to say "this will make your life easier", which in this scenario, it can.
Additionally, alternative login is a separate topic of discussion to whether or not userPrincipalName and mail should contain the same value.
That's the technical perspective. Now for the practical perspective.
userPrincipalName and mail having different values is not an issue at all for Active Directory, Azure Active Directory (or Entra ID for the marketing addicts) or most of the Microsoft (aka first party) Azure ecosphere, but when you branch out into third parties, it's potentially quite a different story.
I can't tell you how many applications I've come across that assume the two will always be the same and/or that anchor themselves to mail rather than userPrincipalName (where both are bad through not being immutable; developers should only be using these for joining and then anchoring off the objectId - or simply "id" as it's presented via Graph).
So, what that means is having different values is fine for logging into Office/Azure/a domain-, hybrid- or Azure-joined device, but your wider application landscape may present challenges. Only you can verify your third-party applications, so I won't harp on about it.
Alternate ID has nothing to do with the values being different across userPrincipalName and mail. You can readily set up Alternate ID even if both contain the same value.
By default, you log in with your userPrincipalName, where if you try and log in with your mail address - assuming it's a different value to userPrincipalName, you will fail to authenticate.
Alternate ID is the method by which you allow another attribute - in this scenario we're talking about mail - to be recognised by Azure AD as a valid username. So, if you enable Alternate ID for the mail attribute, then you can log into Office 365/Azure with either the mail or userPrincipalName value as the username.
Alternate ID has no bearing on the third-party application considerations I mentioned above, but it may (or may not, but I can't seeing it make things worse) make life easier for your users to have both options. It might also ease the decision-making pain your trying to navigate.
Given you already have applications leveraging the per domain userPrincipalNames, then the path of least resistance - both technically and politically (as you're going to need business acceptance to change everyone's userPrincipalNames - unless you're a very small organisation), is to stick with your existing structure of per domain userPrincipalName and universal mail.
The fact that both the userPrincpalName and mail are routable has no real bearing on the discussion. Certainly, if one were non-routable, that might warrant further discussion, but that isn't the case, so it's not warranted.
In summary, while you have numerous options you can pursue at your and the business' discretion, best practice is not a blocker to what you're considering and sticking with your current design is perfectly valid (and may generate less resistance as there's no significant user-facing change).
Cheers,
Lain
- Lain - thank you so much for taking the time to provide a detailed response. I appreciate it. At least on this page: https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configuring-alternate-login-id there is a call out that email == UPN is best practice, so I think that's where I got the idea from.
The fact that MS 1st party applications are okay with UPN != mail is encouraging. I had read some (probably outdated) blogs that seemed to suggest that there were known issues with the desktop applications like Outlook needing extra configuration when UPN and email don't match.
Again, thanks for the helpful reply.Hi, Brian.
With respect to Outlook, there's been a fix for a few years now in relation to how AutoDiscover behaves, which given you're a hybrid customer, you could easily deploy to domain-joined machines using Group Policy/SCCM and/or MDM-managed machines using something like Intune.
Cheers,
Lain
