Alternate Login IDs with Azure Active Directory

  • Article

image Microsoft recently announced support for alternative Login IDs with Azure Active Directory, those of you who have found this to be a restriction when adopting cloud services will be pleased to hear. it’s fair to say that 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” domains) and the guidance for these customers up until now is to change their on-premises UserPrincipalNames to use a different domain as recommended here: https://technet.microsoft.com/en-us/library/jj151831.aspx

However, those same customers may not be able to implement that guidance for a variety of reasons.

In this article I will walk through the steps to modify the Azure Active Directory Sync attribute flow for UserPrincipalName for provisioning/sync & Leveraging the Alternate Login ID feature of AD FS for Single Sign-On authentication.

The following information is valid providing that the attribute in which you are going to use is a publically routable, verified domain. An alternative attribute must

  1. Be of a compatible data type to the UserPrincipalName attribute in Active Directory (schema details documented here: https://msdn.microsoft.com/en-us/library/windows/desktop/ms680857(v=vs.85).aspx
  2. Conform to the UserPrincipalName restrictions as documented here: https://technet.microsoft.com/en-us/library/jj943764.aspx 

IMPORTANT 

Customers that wish to enable Single Sign-On using ADFS are required to deploy/upgrade ADFS to Windows Server 2012 R2 with KB2919355

We strongly recommend that you make this configuration change to Directory Sync before you perform your initial synchronization run. There are several scenarios where making this configuration change after you have populated your tenancy can cause issues.

I will now walk through the changes that need to be made to the Windows Azure Directory Sync Tool & Active Directory Federation Services 2012 R2.

Azure Directory Sync Tool

Note: If this is the first time you are configuring directory sync and you are not editing an existing deployment, ensure that you complete these changes within 3 hours of completing the Directory Sync Config Wizard. Otherwise, please refer to the comments below regarding ‘making these changes after initial sync has been completed’

  1. Deploy the Windows Azure Directory Sync Application BUT do not perform an initial sync. [Final Step of Wizard]

    image

  2. Update the attribute flow rule for UserPrincipalName in your Directory Sync configuration (in the Active Directory Connector) to synchronize an alternate attribute from your on-premises Active Directory instead of their AD.User.UserPrincipalName to Azure Active Directory.

 

Before: image
After: image

and then go ahead and run your initial sync, if this is a new installation it will happen +3hours after Install. If this is an update then you will need to do the following:

  • Launch regedit
  • browse to the following key HKEY_LOCAL_MACHINESOFTWAREMicrosoftMSOLCoExistence
  • edit the ‘FullSyncNeeded’ REG_DWORD value to be 1
  • Launch /.DirSyncConfigShell.psc1 [C:Program FilesWindows Azure Active Directory Sync]
  • In the console, type Start-OnlineCoexistenceSync

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:

  1. The old UserPrincipalName and the new Alternate Login ID values for a User are both using Federated Domains.

  2. If the user has a License Assigned

    You will need to do this manually with the Set-MsolUserPrincipalName cmdlet https://msdn.microsoft.com/en-us/library/azure/dn194135.aspx in addition to changing the attribute mapping in Directory Sync

  3. The new Alternate Login ID value is currently being used by another user. This will result in a Duplicate UserPrincipalName Sync Error. You will need to ensure that no other user in the directory is currently using the new Alternate Login ID value for this operation to succeed.

Active Directory Federation Services [SSO]

 

Set-AdfsClaimsProviderTrust -TargetIdentifier "AD AUTHORITY" -AlternateLoginID –LookupForests

Where,

  • AlternateLoginID is the LDAP name of the attribute to use instead of UserPrincipalName for login. This attribute will also be issued as the UserPrincipalName claim in the SAML token.
  • LookupForests is a single string containing the list of forest DNS where the user may belong to, with domains separated by commas

Both AlternateLoginID and LookupForests must be set when calling the Set-AdfsClaimsProviderTrust cmdlet.
For example, the following command configures ADFS such that users sign-in with their “Mail” attribute rather than their UserPrincipalName, and ADFS will look up users in the contoso.com and fabrikam.com forests:

Set-AdfsClaimsProviderTrust -TargetIdentifier "AD AUTHORITY" -AlternateLoginID mail -LookupForests contoso.com, fabrikam.com

Additionally,

  • administrators will need to update the ADFS Claims Issuance Rules.
  • They will need to update Rule #1 with the appropriate attribute name as follows.
  • The example attribute used below is “mail”.
  • You must specify the attribute you’ve chosen instead of UserPrincipalName (matches to the -AlternateLoginID parameter value)

Old Claim Rule

c:[Type = "http: //schemas.microsoft. com/ws/2008/06/identity/claims/windowsaccount Name"] => issue (store = "Active Directory", types = ("https://schemas.xm1soap.org/c1aims/UPN ",
"http: //schemas.microsoft. com/LiveID/Federation/2008/05/ImmutablelD"),query = " samAccountName={0};userPrincipalName, objectGuiD; (1)", param = regexreplace(c.Value, "(?<domain>[’\)+)\(?<user>.+)", "${user)"),param = c.Value);

New Claim Rule

c:[Type = "http: //schemas.microsoft. com/ws/2008/06/identity/claims/windowsaccount Name"] => issue (store = "Active Directory", types = ("https://schemas.xm1soap.org/c1aims/UPN ",
"http: //schemas.microsoft. com/LiveID/Federation/2008/05/ImmutablelD"),query = " ;mail, objectGuiD; (1)", param = regexreplace(c.Value, "(?<domain>[’\)+)\(?<user>.+)", "${user)"),param = c.Value);

Important

The text in red in the ‘old claim rule’ should be replaced with the red text in the ‘new claim rule’.
It is critical that the semicolon (“;”) precede the word “mail” in the updated claim rule.

note:

When configuring alternate login ID, admin needs to make sure that AD FS can uniquely identify the user account with this ID across the lookup forests that admin configures, otherwise the login will fail.

Admins must make sure that all AD authenticated users can access the CanonicalName attribute of the user object.
That is, the ACLs of CanonicalName AD attribute should include “Authenticated Users””

 

If you have any questions please feel free to post them here, the official Microsoft wiki can be viewed here: https://social.technet.microsoft.com/wiki/contents/articles/24096.using-alternate-login-ids-with-azure-active-directory.aspx which i encourage you to check out in case any updates have been published.

Enjoy!

James.