Office 365 ADFS SSO

Office 365 with ADFS and SSO

A step by step guide

By David Howell



For this guide, I will assume an internal domain name of contoso.local, an external domain name of and all servers will be running Server 2012 Standard.



An Internet Domain Name for use with Office 365 Sign In. This will form the suffix of the usernames used to sign in.

An SSL Certificate matching the Federation Service name e.g.
This should be installed into the local store of the server running ADFS.

I would recommend reading the TechNet articles covering this scenario which all stem from a parent page found here.

Domain Preparation

If your internal domain name doesn't match what will be used externally, an additional User Principal Name (UPN) will need to be added to each users account to allow sign in to Office 365.

Select Properties from the top item in the tree from Active Directory Domains and Trusts and add in the new UPN e.g.

If you have a large domain, now maybe a good time to reorganise your OU's and remove objects such as Service Accounts and Groups so they later don't get synchronised to the Cloud service.

The new UPN must be set manually for each Office 365 user but a Powershell script can be used to make things easier. Assuming there is an OU containing all the users and that they all will be signing into Office 365, the following script can be run from a Domain Controller.

$users = Get-ADUser -Filter * -SearchBase "OU=Users,DC=Contoso,DC=local"

$users | ForEach-Object ($_.SamAccountName) {$CompleteUPN = $_.SamAccountName + ""; Set-ADUser -Identity $_.DistinguishedName -UserPrincipalName $CompleteUPN}

Make sure the Distinguished Name in the Get-ADUser cmdlet and the UPN value in the $CompleteUPN variable are changed to match your setup.

if you have multiple OU's, you can add another line to add in more users to $users
Although the use of += doesn't work on one 2012 DC and does on another. Not sure why yet.

$users += Get-ADUser .........

Changing the UPN for non Office 365 users won't affect normal AD login.

Internal users will need to resolve the Federation Service name i.e. to the server running ADFS. You may need to create an additional zone ( on your internal DNS server for this then add the adfs record. Be careful to also create any other records present in the external zone as internal lookups for those names will fail if the internal zone doesn't have them.

Installing ADFS

ADFS can be installed on a Domain Controller. My initial experience with this was less than stellar. The Default Domain Controllers Group Policy prevented the Windows Internal Database Service account from starting which caused the ADFS installation to fail.

After that, once the DC was rebooted, ADFS was automatically uninstalled which trashed the install requiring a total reinstall of ADFS. I also had issues with the WID caused by permissions on the ADFS Service Account. As such, I won't be doing that anymore and will use a separate server to run ADFS. Besides, installing IIS on a DC just didn't feel right and without a proxy, you'll need to expose your DC to the Internet!

Install the ADFS Role, selecting the Federation Service option and accept all of the defaults for IIS etc. Now open the ADFS Management Console and follow through the wizard to setup a new federation service.

In the case of single name certificate being present in the local store, the wizard will automatically select it and correctly show what will be the external address. For a multiple SAN or wildcard cert, the address will need manual entry.

You will need to open up the perimeter firewall for HTTPS traffic to the ADFS server and setup DNS on the external domain for the adfs record. If you have a DMZ and will be using the ADFS Proxy, the setup is pretty much the same. Just install the Federation Proxy role instead and use the same Service Credentials and Certificate. Then open up HTTPS for the Proxy and ensure it resolves the federation service name to the internal ADFS server so the traffic is passed on.

ADFS Proxy

Out of the box, the ADFS Proxy Service will present a rather basic page using Forms Based Authentication requiring the input of both the username and password. This slightly breaks the SSO experience as the user has already had to enter their username on the Portal page. The following link details a process to automatically populate the username on the Proxy page which allows a smoother experience for users not on the internal network.

Setup a trust between ADFS and Windows Azure AD

You will need a server to install the Windows Azure Active Directory Powershell Module and also the Directory Sync Tool. If you're installing ADFS on a Domain Controller, you'll need another box as the Sync Tool can't run on a DC. I'll be using the ADFS server in this example.

At this stage, it is worth running the Microsoft Deployment Readiness Tool and resolve any issues found then install the .NET 3.5 Feature, the Microsoft Online Services Sign-In Assistant and the Windows Azure AD Module.

There are several Powershell commands required to configure the Online Service to work with ADFS. I would recommend reading the TechNet articles but the commands I use are listed here for reference...

Save the 365 Admin Credentials to a Variable
$msolcred = Get-Credential

Connect to Office 365
Connect-MsolService -Credential $msolcred

If your Sync Computer is also your ADFS Server, the following is optional
Set-MsolADFSContext -Computer ADFSServer.contoso.local

Assuming the domain name isn't already setup in Office 365, create a federated domain
New-MsolFederatedDomain -DomainName

Or, convert an existing domain
Convert-MsolDomainToFederated -DomainName

Output from the New-MsolFederatedDomain cmdlet can be used to setup DNS Validation of your Domain. This output is not given for the Convert cmdlet.

DNS Configuration

Sign into the Portal as the Admin and click Domains. Your federated domain should be visible. Click 'Setup in Progress' then 'Set the domain purpose and configure DNS'.

Complete the setup by adding the necessary DNS records to validate the external domain.
If you have an internal DNS zone for your external domain, configure the records here as well.

In my setup, I just ticked Lync as Exchange is still on premise.

Directory Synchronisation

Run the following Powershell command to enable Directory Sync
Set-MsolDirSyncEnabled -EnableDirSync $true

This can also be done from the Users section of the Portal

Install the Windows Azure Active Directory Sync Tool -64 bit

If you don't want to sync your entire Directory, it is possible to customise the parts of AD that are synchronised. If you have just one OU with your 365 user accounts, use the steps below to customise the sync.

Untick 'Synchronize your directories now' on the last page of the Configuration Wizard
Reset the password for the MSOL_AD_Sync account and keep it safe
Open miisclient.exe from C:\Program Files\Microsoft Online Directory Sync\SYNCBUS\Synchronization Service\UIShell
Click Management Agents then double click SourceAD
Enter the MSOL_AD_Sync password in Connect to Active Directory Forest
Click Containers on Configure Directory Partitions
Select the OU's you want to Sync

Run DirSyncConfigShell.psc1 from C:\Program Files\Microsoft Online Directory Sync
A manual sync can be kicked off with the command Start-OnlineCoexistenceSync

You can view the progress in progress syncs from the Operations section of the Synchronization Service Manager.

When the Sync is complete, you will see your AD users in the Cloud.

Single Sign On

When signing into Office 365, detection of federated domain suffixes causes an automatic redirection to ADFS. Due to the split DNS configuration setup earlier, users on the internal network either directly or via VPN/Direct Access will hit the ADFS server and external users will hit the ADFS Proxy if configured.

Internal users are authenticated using Windows Authentication. The ADFS site,, will most likely be in the Internet Zone in Internet Explorer which doesn't allow Windows Authentication. This causes an authentication prompt requiring the entry of Domain Credentials (Usernames can be in any valid UPN format). This can be avoided by adding to the Local Intranet Zone.

External users are authenticated using Forms Based Authentication. Assuming the username fix described earlier is in place, username entry occurs on the Office 365 Sign in page, then password entry occurs on the ADFS Proxy page.