Best practice when UPN and email address are different but both routable?

BTW97 

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