Stephen.franano@outlook.com
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:
Please contact your Account representative for more information on these incompatibilities.
↑ 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 miisclient.exe. To update the attribute that is synchronized to the cloud, you must do the following:
Jono Luk (MSFT) edited Revision 1. Comment: updated formatting only
This is a much welcome feature. Not having to update the existing non-routable UPN means not breaking any internal apps.
Can Dirsync alone, allow the Alternate UPN ID? or do we need ADFS too?.
All my customer wants is Dirsync with password sync. They will use a custom attribute to house the internet routable UPN and update the connector appropriately.
"If you are an InTune Hybrid customers using the SCCM Connector there may be additional configuration required.
Please contact your Account representative for more information."
I've implemented this solution and I'm having trouble with the Intune/ConfigMgr piece. When I add a user to my "Intune Users" collection this change cannot be synchronised to Intune. From the logs it looks like the AD UPN is being used. As the DirSync Direct Mapping is not available in this case the process fails - UserNotFound. The statement above suggests that this is a known issue. However there does not seem to be a solution. Is there anything that can be done? Additional UPNs are not permitted.
Hi Jono,
Thanks for sharing this awsome information. Can you tell me if there is any other claim rules to add to make the UPN have the correct value and to extract the “mail” AD attribute as email claim?
Best regards,
Should this article be updated to reflect that the Hybrid support statement has been changed per this article?
technet.microsoft.com/.../dn659436.aspx ... Also the date of this referenced article is almost a month in the future...