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 ?
Azure dependence on UPN being mail address
- 289 Views
- Last Post 31 August 2015
Have you considered configuring Office 365 to use an alternate login ID.
Sent from my iPhone
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.
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.
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.
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.
Thanks all the responses.. sounds like what we need is possible based on your comments.
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.