ADFS 3.0: Use Alternate Login ID & get rid of the UPN requirement in WAAD

Hello Everyone,

What a nice thing, isn’t it?
Not speaking? Let’s see why it’s nice then 😉

When you talk about Office 365 or Azure in general, it’s always a challenge for companies to match the requirement regarding the UPN.

Indeed, one of the requirement for the synchronization between your on-prem AD and WAAD  is to use an external routable domain as for the UPN suffix. Adding a UPN suffix to your on-prem AD is quite easy. On the other hand, changing it for all your users can have a lot of consequences.

Hopefully, Microsoft released Update 1 for Windows 2012 R2 last month, see: http://technet.microsoft.com/en-us/library/dn645472.aspx

One of the updates is the following:

Active Directory Federation Services (AD FS) has added the capability for an administrator to enable signing in with an alternate login ID that is an attribute of the user object in Active Directory Domain Services (AD DS). This enables customers to adopt Azure Active Directory without modifying on-premises User Principal Names (UPNs). It also allows users to log in to Office 365 services by using an email address instead of a UPN. This change does not affect the Active Directory schema.

Let’s have a look at the necessary steps to perform to get it working.

In this example, we have a federated environment with O365 and want to use the mail attribute as an alternate login ID

1) Prerequisite, having Update 1 installed on your on prem ADFS servers. If not the case already, you can get it via Windows update or using the following link: http://support.microsoft.com/kb/2919355

2) Execute the following command on one of your ADFS server, this will allow the usage of an alternative attribute to use to authenticate:

3) Modifying the AD MA attribute flow on the sync engine.

On the server running dirsync, launch the FIM console by executing: C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe

Go on the AD MA properties

Click on Configure Attribute Flow then expand the User object type to find the UPN Metaverse Attribute, then modify the flow to a Direct Mapping with the Mail attribute

4) Back on the ADFS server, we’ll have now to update the Relying Party claim rule for O365 so edit the first one

Change the UPN attribute by the mail attribute

What to do right-now? Nothing. You’re ready for the testing!

So let’s take a good case to do the testing, a user who’s having a non routable domain suffix internally:

And having an email address using the company external domain name

If your directory sync is working as expected, you should see in your O365 (or Azure, Intune) management console a corresponding user provisioned with the username equal to the mail address.

There are specific situations which could make the change not working (if for example you were already syncing) then you can have a look at the Wiki link at the end of the post if you’re in such a case.

So now, let’s give a try and go on the O365 portal, we enter our user mail address

As expected, we’re redirected to our corporate ADFS server

And being asked to authenticate with the user’s mail address

Hitting Sign-In and… Here we go 🙂

If you want additional information, you can have a look at the following Wiki describing the steps we’ve just performed: http://social.technet.microsoft.com/wiki/contents/articles/24096.using-alternate-login-ids-with-azure-active-directory.aspx

Cheers!

Mitch