Use Alternate Login ID implementing Enterprise Mobility Suite in a Multi-Forest scenario

Last week I came across a scenario where Alternate Login ID feature of Active Directory Federation Services (AD FS) came at its best.

Scenario

Part of an Enterprise Mobility Suite (EMS) implementation we were facing a challange to overcome. In this scenario the customer has multi-forest (fictive contoso.local & adatum.local) AD structure with a two-way forest trust relationship. The user resources are currently located in te frabrikam.local (blue) where all server resources are part of the contoso.local (grey) domain including AD FS.

As fabrikam.com is the public domain namespace used, we added a UPN suffix for the fabrikam.local domain to make sure the user objects synced from the on-premise Active Directory – by Azure Active Directory Sync – matches the public User Principal Name (UPN) domain namespace.

Challenge

As we enabled Single Sign-On (SSO) for fabrikam.com, users will authenticated against local Active Directory by AD FS for online services like Azure, Microsoft Intune, Azure Rights Management Service and Office 365. As both AD FS servers resides in the contoso.local domain, fabrikam.com users cannot be authenticated as these user objects are not in the contoso.local forest, despite the two-way trust between contoso.local and adatum.local forusts.

Solution

In this scenario we (re)used UserPrincipalName attribute as AlternateLoginID and added the adatum.local as lookup forest. By adding adatum.local as lookup forest UPN’s for frabrikam.local and UPN suffix contoso.com are resolved and ends up in a succesfull login.

• Set-AdfsClaimsProviderTrust -TargetIdentifier “AD AUTHORITY” -AlternateLoginID userPrincipalName –LookupForests <your forestname>

If applicable you’re able to adde multiple forest at once (adatum.com, fabrikam.com, etc) .To show the configured AlternateLoginID and associated forest(s) use the following Powershell commando.

• Get-AdfsClaimsProvidertrust

Various scenarios

Further AlternateLoginID can also used when your users email addresses doesn’t match the UPN according the routed/public namespace used by Azure/Intune/Office365. In this example my email address doesn’t match my UPN.

 

By adding mail as AlternateLoginID attribute I’am able to login with my email address instead of my UPN.

• Set-AdfsClaimsProviderTrust -TargetIdentifier “AD AUTHORITY” -AlternateLoginID mail –LookupForests buildingclouds.lan

Using the ClaimApp I’m able to show you the claim value used to login. As you can see I’m using the AlternateLoginID ronny.de.jong@inovativ.nl instead of my primary UPN ronnyj@inovativ-cloud.nl

Background

AlternateLoginID is a feature introduced with Windows Server 2012 R2 Update (KB2919355) that facilitates login to AD FS with an administratively defined user attribute.

Many customers would like their end users to only know about their email address for ease of use when signing in. However, within a customer’s AD DS environment, administrators may be unable to ensure that user UserPrincipalName (UPN) and email addresses match. In addition, in some AD DS environments UPNs are not publically routable and that may pose challenges for some SaaS providers.

In Windows Server 2012 R2 Update, AD  FS provides the capability for an administrator to enable user sign in via an alternate login ID that is an attribute of the user object in AD DS. Once configured, AD FS will prefer to locate the user account within AD DS by the defined alternate attribute first instead of UPN.

Sources

Introduction to Active Directory Federation Services (AD FS) AlternateLoginID Feature

DirSync: Using Alternate Login IDs with Azure Active Directory