So prior to Update 1 (note update 2 is out now and is the one you should use) for ADFS 2.0 RTW, enterprises that implemented ADFS based identity federation with Office 365 was required to deploy an ADFS federation farm per user principal name (UPN) that needed to authenticate against an Office 365 service. This meant that the enterprise had to deploy 2 x ADFS Proxy and 2 x ADFS servers per UPN that needed to be supported! So 8 servers would be required in order to support 2 UPNs! Yes I agree, you could go with 1 x ADFS Proxy and 1 x ADFS server per UPN but would you really like to introduce a single point of failure like that nowadays? That’s what I thought.
The good thing is that with Update 1 or later for ADFS 2.0 RTW, we now have support for multiple UPNs per ADFS federation farm and in this post, I’ll walk you through how you introduce support for an additional UPN in your existing ADFS deployment.
So first off, you should install update 2 on all ADFS Proxy and ADFS servers in your environment following by making sure the new logon domain you wish to use has been added to the UPN suffix list in your Active Directory.
With the UPN suffix added, verify the respective users that need to logon using the new UPN have this set for their Active Directory user account.
Now we can add the new domain to the tenant in the Office 365 Portal.
With the domain added and verified, logon on to the primary ADFS server in your environment and open the ADFS 2.0 Management Console. Expand “Trust relationships” and select “Relying Party Trusts”. Now delete the “Microsoft Office 365 Identity Platform” trust.
Important
Once you delete this trust users using the existing UPN will not be able to access any Office 365 services until we issue the next command.
With the trust deleted, open the “Microsoft Online services Module for Windows Powershell”. Type “Connect-MsolService” and then enter the credentials for your tenant admin. When connected to the Office 365 tenant run the following command to create the trust:
Update-MsolFederatedDomain –DomainName “domain.com” –SupportMultipledomain
Now we need to convert the newly added domain to a federated domain. This is done using this command (remember to include the –SupportMultipleDomain parameter):
Convert-MsolDomainToFederated –DomainName “newdomain.com” –SupportMultipledomain
With the domain converted run this command:
Update-MsolFederatedDomain –DomainName “newdomain.com” –SupportMultipleDomain
Now open a browser on an external client and access portal.microsoftonline.com. You’re redirected to login.microsoftonline.com where you can enter “[email protected]”. Since the domain is federated, the password box will be greyed out and you can click “Log on to newdomain.com”.
You will now be taken to the ADFS Proxy login page where you can authenticate using “[email protected]” and the associated password.
If using a domain-joined client on the internal network, the users will experience single sign-on (SSO) and won’t be taken to login.microsoftonline and the ADFS Proxy login page.
Pretty cool heh?
Until later,
Henrik Walther