Some customers cannot use their on-premises UserPrincipalNames to authenticate their users with Windows Azure Active Directory, or one of its associated services (i.e. Office 365, InTune, etc.).
This is commonly because their on-premises UserPrincipalNames are using a non-routable domain (i.e. single level domains or “.local” / ”.intranet” domains). Standard guidance for
these customers is to change their on-premises UserPrincipalNames to use a different domain as recommended in Password policy in Azure AD.
However, those same customers may not be able to implement that guidance for a variety of reasons.
If this sounds like the situation you're in, then this wiki is for you!
In this wiki, we'll prescribe the process that will allow you to on-board to Azure Active Directory, and its associated services, using an Alternate Login ID.
Follow the guidance provided below which will walk you through the process of:
The Alternate Login ID feature may impact various Azure AD and Office 365 scenarios including:
- Office 365 ProPlus activation may require explicit sign-in
- Exchange Online Hybrid Deployment Autodiscover
- InTune customers using SCCM connectors may require additional configuration.
Please contact your Account representative for more information.
↑ Back to top
This solution assumes that you can specify a different attribute (we refer to this as the “Alternate Login ID”) in your on-premises AD that can be used as sign-in value for your users.
The attribute must be using a publically routable, verified domain.
An alternate attribute must:
Customers will be able to deploy the prescribed solution below on the currently available version of either:
No upgrade/new versions of software are required to achieve this configuration.
You can still use Password Sync if you deploy this solution.
No changes are required to the Password Sync feature/configuration for this solution to work.
If you want Single Sign-On via ADFS, you’ll need to perform the steps outlined in the sections below - called out as appropriate.
Customers using other 3rd party STS’ as supported by the Works with Office 365 Identity program should refer to their respective STS documentation for the analogous configuration steps.
Step-by-step instructions to change the synchronization attribute flow can be found in the Updating Sync Engine Configuration section at the end of this wiki.
If you need to make this change after you have run your initial sync, you must handle the following potential scenarios:
If the customer requires Single Sign-On, they should also:
If you have just installed the Directory Sync tool, and have not yet run the first sync cycle, then you will need to log off the machine and log back on before you can perform the steps below. This is required to refresh your group memberships to give access
To update the attribute that is synchronized to the cloud, you must do the following: