Alternate Login IDs cannot be used with ConfigMgr 2012 and Windows Intune

Back to ConfigMgr main menu

(Edit 17th May 2015: This issue has been resolved by Microsoft and Alternate Login IDs are now fully supported with the ConfigMgr/Intune hybrid solution. This involved updates to the Intune service. The WiKi article (referenced below) has been edited to reflect this. Thanks for the information Stefan Schörling and Jörgen Nilsson.)
 
I hope that this blog post helps other Consultants to avoid the trap that I fell into. "Alternate Login IDs" are a really cool new feature of Windows Server 2012 R2 Update. They are described in detail here

DirSync: Using Alternate Login IDs with Azure Active Directory

The process involves:

• Modifying the DirSync attribute flow for UserPrincipalName for provisioning/sync 
• Leveraging the Alternate Login ID feature of AD FS for Single Sign-On authentication

The concept is particularly useful for customers that cannot or will not change their on-premise UserPrincipalNames to use a different routable domain (changing the UPN is one of the first steps we have to do when deploying ConfigMgr/Intune). It works really well to authenticate your users in Azure for Office 365. An AD account with the UPN gerry.hampson@contoso.local can now synchronise with a cloud identity gerry.hampson@contoso.com. Lovely. The end result looks exactly the same as if we implemented using UPNs.

However, it doesn't work with the Unified Device Management solution of ConfigMgr 2012 and Intune. This is because ConfigMgr handles AD user accounts differently. When a user is first discovered all the AD attributes are committed to the ConfigMgr database. This includes the UPN (eg. gerry.hampson@contoso.local). When I add this user to my "Intune Users" collection this change cannot be synchronised to Intune. The CloudUserSync log tells us that the internal AD UPN is being used to sync to Azure. As the DirSync Direct Mapping is not involved in this process it fails - UserNotFound. Of course it does - gerry.hampson@contoso.local does not exist in Azure.

The article above has warned me that I might have a problem:

"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 contacted Microsoft CSS for this "additional configuration". They were aware of this shortcoming. There is no supported solution at this time - and no estimated time for a possible solution. The suggested workaround is to run a script on the ConfigMgr database to change the UPN for the user accounts to use the public routable domain. Clearly this is not supported so I don't think it's a great idea.

A recent customer engagement had several phases. Phase 1 was an Office 365 migration. They were very pleased to implement the new features so that UPNs did not have to be changed. Phase 2 was the ConfigMgr/Intune solution - guess what - UPNs now had to be changed. It's a real shame because Alternate Login IDs are a cracking new feature.