8662_2350_WoodyWalton_SMB_PTA_1ACBB3E7_thumb_21C5197C

Woody Walton

 

Usually My peers or I would have noticed this one sooner.  Any enhancement to Azure Active Directory, ADFS, or DirSync is right up our alley as we often help partners deploying and integrating Office 365 for customers.   This one slipped under the radar!

On May 6th, Paul Andrew, the technical product manager for Identity Management on the Office 365 team, posted Alternate login ID for Office 365 reduces dependence on UPN to the Office Blog.  There were many announcement on the Office blog during this time, but this one stands to help customers and partners alike who have encountered issues using the UPN (user principal name) for authenticating against Azure Active Directory/ Office 365.  This update provides a level of flexibility in how customers choose to authenticate against the service and accommodates some common scenarios that required significant workaround before.

 

 

To Quote Paul:

Previously, if you used the synchronized or federated identity model, you were required to use the User Principal Name (UPN) attribute in your on-premises Active Directory as the user sign-in name for Office 365. This caused issues if the UPN was already populated with something incompatible, such as an internal non-routable DNS suffix, or if it had duplicate entries.

AlternateSignInID

Required reliance on UPN has been removed for the synchronized identity and federated identity models, and you can now select an alternate login ID for use with Office 365 and Azure Active Directory if you use either of these models to create your user accounts. The use of UPN is still the default for these two models. If you want your users to be able to use an alternate login ID, you have to configure your system. When you configure, you can select the Mail attribute or any other attribute in your on-premises Active Directory.

Both the synchronized identity and federated identity models require configuration in Azure Active Directory, and the federated identity model requires additional configuration in Active Directory Federation Services.

The associated TechNet Blog wiki, Using Alternate Login IDs with Azure Active Directory, details the step by step process to utilize the Alternate lopin ID.

The table of contents is below:

Table of Contents

 

So when is this applicable?  Well, by reading the “problem statement” mentioned in the TechNet Wiki it becomes quite clear.

Problem Statement

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.

I remember the days well of .local AD domains and though I do not architect Active Directory Infrastructures any longer, I build many as a Microsoft consultant when Windows Server 2000 was new and word of the day was “.local”.   …There are a lot of them out there for sure.  And now we have a way to accommodate scenarios when the customer cannot or will not change their UPNs.  This is just one more step toward  make your migrations, integrations, and single sign configuration “easy”.  A tool top have in your tool bag for sure.

 

Props to the Office 365 Team for adding this much need feature!

Enjoy!

Woody