A big challenge for many companies in their on-prem AD is that the UPN suffix doesn’t have a publicly routable domain name which is a requirement for e.g. O365, AAD and is preferred/recommended when using any cloud services.
The UPN got shipped with Active Directory in Windows 2000 Server and is based on the RFC 822. The general recommendation has been to form the UPN to match the users e-mail address for ease of usage and support. There has been some challenges because many AD domains is named e.g. corp.local which results in a users UPN: firstname.lastname@example.org.
And who uses an e-mail like email@example.com?
A new UPN suffix is easy to add in the Active Directory Domains and Trusts snap-in. To change the UPN suffix and logon name (and also preferably sAMAccountName) could be more trickier and needs some good planning informing the users of the change, making sure service accounts and other dependencies/applications is not affected, create and test scripts is recommended because you don’t wan to do this by hand.
Well I’m not going any deeper to this because for those who didn’t plan this at the Active Directory deployment planning stage, can now take use of the Alternate Login ID.
Alternate Login ID enables you to utilize other attributes as a login name when using ADFS. The preferred one is of course the mail attribute. When enabled, ADFS will first try to match the alternate login name and then fallback to the UPN.
Although the best would be to use the UPN as the preferred login name for the best user experience, the Alternate Login ID feature is a good option.
More info about requirements, considerations and configuration can be found here: Configuring Alternate Login ID