Back in April of 2014, Microsoft announced a feature called “Alternate Login ID” (sometimes referred to as “Alternative Login ID”). The idea was that instead of changing the UPNs in your on-premises Active Directory, you could use a different value to authenticate to Office 365 and sync that value to the cloud as your login.
At the time of release, I wrote an article (“Office 365 – Configuring AD FS & DirSync with an Alternate Login“) that covered the necessary configuration to use Alternate Login ID. It seemed like a very viable option for organizations that had dependencies on their current UPNs and would not be able to easily change their UPNs. In the past 10 months, that article has been one of the more popular articles that I’ve written so I wanted to follow it up with an update based on information that we now know today.
The Previous 10 Months…
While Alternate Login has been touted by some, even at Microsoft, as the magical answer to your UPN woes, I’ve been hesitant to recommend it. In my opinion, this feature is for when you absolutely cannot change your UPNs, not when an organization “doesn’t want to” or hasn’t taken the time to investigate dependencies on the current UPNs. We’re all familiar with the phrase “bleeding edge” and even though the feature is almost a year old, there are still some limitations being discovered. However, for some organizations, it is the only solution which is fine as long as you understand the footnotes that come with it.
What We Know Today
When the feature was first released, there was a bit of a vague reference to incompatibilities with Intune and to “contact your Account representative for more information”. Eventually there were some concerns that came up regarding Exchange hybrid environments, I first saw some chatter about this on Yammer and then in an article by Steve Goodman.
Fast forward to February 2015 and Microsoft has now added the following text to the wiki page for Alternate Login ID:
This update was made on February 17th, the previous version of the article just gave a warning about Autodiscover in Exchange hybrid under the “may impact various other Azure AD and Office 365 scenarios” section. The same information was added at some point to the TechNet page for this feature: Configuring Alternate Login ID.
The language seems a bit stronger now saying that the feature is not compatible.
Issues We’re Aware Of
Below are a list of items that we know have issues with implementing Alternate Login ID. That’s not to say that you shouldn’t use it if there are not alternatives, but it really should be the last resort and you should be ready to communicate these issues to your end users.
I don’t have much background on this one other than it’s been there since the original feature release. The notes have always said: “If you are an Intune customer using the SCCM Connector, there may be additional configuration required”. That tells me there’s some kind of issue but perhaps someone more involved with Intune can help fill in the details.
Exchange Hybrid Autodiscover: Domain Joined
The primary issue here is the mismatch between credentials that are valid on-premises and credentials that are valid in the cloud. In an Exchange Hybrid environment, the Autodiscover records still point to the on-premises Exchange where a user authenticates and then performs an Autodiscover lookup. If the user has a cloud mailbox, the user is then redirected to Office 365 where another Autodiscover lookup is done, with authentication, and then the Autodiscover response is returned. The problem that occurs is that different credentials are necessary for on-premises (which doesn’t know anything about Alternate Login ID) and the cloud (which expects the Alternate Login ID).
For domain joined machines, the logged in credentials are sufficient to authenticate to the on-premises Exchange and then the user receives the usual single prompt to authenticate to Exchange Online. The only difference you’ll notice here is that the prompt for Office 365 has the wrong credentials populated in the login box and you need to enter your Alternate Login ID.
Exchange Hybrid Autodiscover: Non-Domain Joined
For non-domain joined machines, the user is presented with prompts for both on-premises and the cloud without knowing which platform the prompt is for. The result is that while it’s technically possible to navigate the login prompts, it’s unlikely that your users will know what credentials to provide during what prompt.
Where this really becomes difficult to know what account to use is when you have on-premises Public Folders that you’ve made accessible by cloud mailbox users. The proxy mailbox for the on-premises Public Folders is returned as part of the cloud Autodiscover response and at some point when opening Outlook, you’re expected to enter the on-premises credentials. I would say that this configuration is nearly unusable.
Exchange Hybrid Autodiscover: Mac
When using the new “Outlook for Mac”, the credential mismatch of Alternate Login ID will cause Outlook to fail during the automatic account setup. The user will need to manually configure Outlook to use the target of “https://outlook.office365.com/EWS/Exchange.asmx”.
Office ProPlus
The behavior here is somewhat odd. When a user is using Alternate Login ID, Office ProPlus will install and show activated under that user’s account in the cloud however in the local applications, it will show you logged in under your on-premises UPN.
The result is that you won’t see the links to your OneDrive for Business within the Office applications and the OneDrive for Business Sync Client will not be setup. While you are able to sign out of the on-premises UPN and sign in with your Alternate Login ID, I question if Office ProPlus would go into “reduced functionality mode” after a period of time if left logged in with the on-premises account.
Remote Connectivity Analyzer
Not that this is a critical issue but the Remote Connectivity Analyzer Autodiscover test does not know how to handle Alternate Login ID with Exchange Hybrid due to the double authentication prompt.
Azure Application Proxy
As noted by the commenter below, the new Azure Application Proxy has a footnote stating: “The UPNs in Azure Active Directory must be identical to the UPNs in your on-premises Active Directory in order for preauthentication to work. Make sure your Azure Active Directory is synchronized with your on-premises Active Directory.” This means Alternate Login ID is not compatible in this situation.
Third-Party Identity Providers (IDPs)
Microsoft has a program for tested third-party IDPs called “Works with Office 365 – Identity”. Part of this program is a list of tested providers along with any exceptions that might be known with those products. Listed in the notes for this program is that “Use of Sign-in by Alternate ID to UPN is also not tested in this program”. So basically your mileage may vary when using Alternate Login ID with any of these third-party IDPs.
In addition to the above known issues, it would be reasonable to have concerns about future compatibility with features like the upcoming authentication change to Active Directory Authentication Library (ADAL).
Concerns with AADSync
When Alternate Login ID was released, the new AADSync did not exist yet. The configuration for DirSync, as outlined in my article, was relatively straight-forward but took some effort and investigation.
Today, we have the new AADSync tool which is replacing DirSync. This tool provides a, perhaps too easy way, to enable Alternate Login ID during installation. It’s very likely that someone installing AADSync wouldn’t necessarily know that they were enabling this feature based on how the configuration options are presented.
During installation, you are asked what you would like the “userPrincipalName” in the cloud to be matched to in your on-premises Active Directory. Should you change this value from the default to something like “mail”, you are now using Alternate Login ID from a Directory Synchronization perspective (although you still need to configure AD FS).
The “Learn more about user matching” link in the installer doesn’t provide much additional guidance, it takes you to a page that says:
No warning, however, of any potential limitations to come…
Summary
- Alternative Login ID allows you to use a value other than the on-premises UPN to authenticate to Office 365.
- The feature should be used when you “can’t change UPNs”, not when you “don’t want to”.
- There are a list of known “limitations” with using Alternative Login ID that you should be aware of should you decide to implement it.
- AADSync provides an easy way to implement Alternate Login ID, possibly without the installer knowing they are doing so.
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.
Super useful article, thanks!. There’s another place I bumped into the recently, although it isn’t specifically Office 365 related. The Application Proxy service that’s been GAed recently for Azure AD Premium is pretty slick, especially the fact that it can work with Kerberos-enabled on-premise apps. I was thinking “hey, easy way to do seamless access to internal SharePoint content from the internet”. But sadly this isn’t quite true if people are using alternate login id, as noted in the footnote at the bottom here: https://msdn.microsoft.com/en-us/library/azure/dn879065.aspx
Thanks for the clarification. It does seem like MS is making strides to make implementing Alternate Login ID easier. I hope it is soon because we do come across many customer that ask for it when they are too lazy to make a simple change to the UPN.
Have you actually experienced any of the stated issues is an Exchange Hybrid deployment with AD FS?
Sam- Thanks for the feedback and the additional issue you’ve uncovered, I’ll get it added into the article.
Todd- Absolutely. I’ve seen these issues in production and did some pretty extensive testing in a lab environment as part of this article. I think trying to use Alternate Login ID is going to put organizations in the “exception” case with any future features. It should really only be used when you absolutely cannot change the UPN.
Todd Nelson, I can attest to experiencing these issues directly with an Exchange Hybrid deployment w/ ADFS.
Hi Joe,
What happens when the UPN doesn’t work, when I sync, the MOERA .onmicrosoft is used in O365. I have to use a PS script to change these in bulk. The new internet domain suffix has been added to ADDS and the users have had their UPN’s changed accordingly but not the SAMaccountname. If I sync using the mail attribute the sync works fine and the users in O365 have the correct domain suffix. Any ideas why the UPN would not work. It looks correct in ADSIedit.
Kind Regards,
Paul
Paul-
Since the sync appears to be working with you when using the mail attribute, the sync out of the metaverse to Office 365 sounds like it’s working. I would look at the metaverse in AADSync and see what the UPN looks like there.
Thanks
Joe
Great article. AADsync is already configured in my environment to use UPN but I want to change it to the mail attribute. Rerunning the wizard, it gives me a message stating “These settings were previously configured and are displayed for information purposes only.” Because the tool is relatively new, there’s isn’t much information out there on it. Have you run into this before or know how to change the alternate ID after its been initially configured? Thanks in advance!
It is true that you cannot change those values after installation.
Aside from uninstalling and reinstalling, it’s very likely you could change the sync rule via the “Sync Rules Editor” utility although I’m not positive that would be a supported change.
Thanks for the feedback!
Joe
Thank you for that clarification.
Hi,
we did cutover migration from one forest and synced users to office 365 from different forest.
AAD sync configured with sourceAnchor field= mail and user principal name attribute = mail.
After syncing users to office 365 with immuteable ID mail, cutover batch created users can login through ADFS to office 365 portal,
When we create a new user in on-prem AD with mail attribute, that user is syncing to office 365 successfully , but unable to login on O365 portal through ADFS.
Error: After entering credentials in ADFS, reverted back to sign on portal.
Sajeel- The error you describe is usually one I see when there is an issue with the immutableID. I’m not sure that I would recommend “mail” as it’s a value that is possible to change in the future. I would look at the immutableID in Azure AD and make sure it’s the value you think it is, also check that AD FS is properly configured to use that value.
You might want to also check out this article for some info on immutableID: https://blogs.perficient.com/microsoft/2015/04/office-365-why-you-need-to-understand-immutableid/
Hello Joe
Great article, now we have an updated version that no longer says not compatible.
Instead we have listed some “considerations”: https://technet.microsoft.com/windows-server-docs/identity/ad-fs/operations/configuring-alternate-login-id
I was recently tasked to look at UPN / Alt ID for the medium sized business I work for. Everything I read basically says, “Change the UPN if at all possible”. Of course the business does not want to change this value (we currently use firstinitial_lastname rather than smtp address) because of legacy apps with dependencies. I was thinking that this issue must affect thousands of business, and I was curious if anyone had a sense of what most are doing, and what the common issues are. Basically, what’s the consensus now in 2017? I’d really appreciate anyone’s first hand experiences. Thanks.
Reading this article in July 2018 – do all of these caveats still apply? We have multiple disparate AD forests but single email domain. Setting all suffixes the same is simply not possible any time soon.
Have the associated tools moved on in the last 3 years? Microsoft reps we spoke to are still advising to make everything match and this is hindering our cloud adoption, but unsure if they’re peddling the same advise from years ago or whether it will really hinder the user experience that much?