Azure dependence on UPN being mail address

  • Last Post 31 August 2015
matt_testxx posted this 27 August 2015

Our company is looking to move to Azure offering for Office 365. The project is in the initial discussion phase with MS regarding requirements. One thing that came up (and is of some concern to us) is the recommendation that userPrincipalName is set to mail address in the internal forest.
We have explicit UPN set on all users, which is not the mail address. There is heavy PKINIT dependency so cert's are issued with this UPN (non-MS PKI).  Basically it will be very challenging to move away from the current naming concept for UPN (70k users) from both a technical and process side so we are looking to avoid it if at all possible.
I would be interested to know if anyone has experience of onboarding to azure without using mail address as UPN (or somehow translating mail address from azure to upn in internal forest) and if so, what is the experience there.. Any drawbacks / pitfalls? Is it even possible ?

Order By: Standard | Newest | Votes
dbowbyes posted this 27 August 2015

Have you considered configuring Office 365 to use an alternate login ID.
Sent from my iPhone


ThomasVuylsteke posted this 27 August 2015

Watch out though. Not all scenario’s are supported or work with alternate login id. I’ve not come across those, but the MS folks should definitely point you to

those and tell you if that’s still the case.




The Alternate Login ID feature is not compatible with Exchange Online Hybrid Deployments.  Customers that wish to configure Exchange

Online Hybrid Deployments with Office 365 must not configure Alternate Login ID.


The Alternate Login ID feature may impact various other Azure AD and Office 365 scenarios including:

•Office 365 ProPlus activation may require explicit sign-in 


Please contact your Account representative for more information on these incompatibilities.


Kind regards,




hcoleman posted this 27 August 2015

Our UPNs don’t match our email addresses, and things with Office 365 work fine. The caveat to that statement is that our UPN suffix matches our email address



Assuming that you set up a federation trust between your AD environment and your O365 tenant, you’ll need to provide a public domain name that you own. It greatly

simplifies things if this domain is the same as your email address suffix, because most users know what their email address is. So when they get to the O365 login portal, they can enter their email address and on the back end it will redirect them to your

ADFS infrastructure based on the domain name. Assuming that the user is logged into their machine with domain credentials, they should get a single sign-on experience.



BrianB posted this 27 August 2015

Our Domain suffix does not match the email suffix either. We created an alternate UPN suffix in the forest that matches our email suffix and updated all user

objects UPN suffix. User can use either when logging into the domain.






bdesmond posted this 27 August 2015

You can put a custom sync rule in to AAD Connect that either flows a different attribute to AAD for UPN or constructs it on the fly. As long as it ultimately

is the value you need (sounds like email address), you’ll be fine.







hcoleman posted this 27 August 2015

Yes, same here. Our AD domain name does not match our email address domain name, so we went with the alternate UPN suffix as well. The other point is that the

left side of the UPN does not have to match the left side of the email address for the Office 365 federated authentication to work.



matt_testxx posted this 31 August 2015

Thanks all the responses.. sounds like what we need is possible based on your comments.


KenHooveroxfordcomputergroupcom posted this 31 August 2015

As Brian said, you can definitely use another attribute (like mail) to provide the source value for UPN in the cloud using AADSync/AADConnect.


If you do this and want to use ADFS or other federated authentication, you also need to tweak the claim rules in ADFS so that the value sent as the

UPN claim to AzureAD is sourced from the correct user attribute in AD (e.g. mail) or logins will fail due to the mismatch. 


This is pretty easy to do and I’ve done it with numerous customers.


If you’re using password-based authentication then this additional step isn’t necessary.


Ken Hoover