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”.
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:
The userPrincipalName attribute is the user’s login ID in Azure AD. By default the userPrincipalName attribute in ADDS is used. If this attribute is not routable or not suitable as the login ID a different attribute, such as mail, can be selected in the installation guide.
No warning, however, of any potential limitations to come…
- 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.