…or how to use a single login for SharePoint Online + your own on-premises SharePoint installation, in short.
As people move ever cloud-wards something unique we can offer in Microsoft is the ability to stage migrations from entirely in-house or on-premises systems to entirely in cloud (if desired) by enabling hybrid systems to offload just bits of the system at a time. SharePoint is no different in that respect; there are parts of SharePoint you can run in cloud or on-premise and it’s just up to your organisation to decide what works best for you. It’s something of a unique selling point as it happens.
So let’s say for example we have certain SharePoint sites we want to move into the cloud; how would we deal with the fact our users don’t want multiple logins for (our now) multiple SharePoint systems? Enter: single-sign-on & Active Directory Federation Services (ADFS). This article is a run-through how to set this up; a more hands on & abridged version of this official guide basically.
My Example System
In my example I have my on-premises farm and SharePoint Online tenant setup and working on their own nicely. The problem is, neither one knows about the other; there’s no seamless transition at all going from one to the other. Bummer!
This example revolves around my rather random SharePoint domain, awesomespaceships.com. I have an on-premise setup already using this via ADFS (I had to migrate it off the real awesomespaceships.com domain onto an ADFS identity provider) – this is a key first step; all your users need to be on ADFS.
Here it is:
Anyhoo, the challenge is to allow my ADFS users to browse SharePoint Online without seeing a separate login prompt, or in other words have single-sign-on working between on-premises and SharePoint Online.
- Have users on ADFS already with same UPN domain as your Office 365 domain.
- Synchronise users to Office 365 (enable it in Office 365 first).
- Establish trust between on-premise ADFS and Office 365 domain.
- Enjoy no more annoying login screens.
Verify ADFS Users – UPNs
First, check your users are using the right domain:
This guy is ready to by synced up to the cloud – the UPN matches perfectly what we’re going to login as in the cloud.
Prepare AD Sync
Next up, enable AD syncing in Office 365 if it isn’t already done. In the admin control panel you should see a link to enable SSO, of which this is a step. Click “activate” and you’re done.
If you’re running the script from another machine you’ll need remote PowerShell enabled and port 5985 open (Windows Remote Management HTTP); do this with “Enable-PSRemoting –force”
Synchronise ADFS Active Directory Users with Office 365
You need to download this tool to do this. It’s pretty straight-forward.
This user used for the syncing has to be in the “enterprise administrator” group.
Setup ADFS to Office 365 Trust
This is the magic bit where we basically tell Office 365 it can trust tokens from our ADFS server. To do this you’ll need to install the Windows PowerShell for single sign-on with AD FS – http://msdn.microsoft.com/en-US/library/azure/jj151814.aspx on either the ADFS server or the sync machine.
This is based on this article – Set up a trust between AD FS and Azure AD. Run this script on your sync machine:
$cred=Get-Credential -UserName "firstname.lastname@example.org" -Message "Enter Creds for SPO Domain"
Connect-MsolService -Credential $cred
Set-MsolAdfscontext -Computer adfs.awesomespaceships.com
Convert-MsolDomainToFederated -Domain awesomespaceships.com # We assume the domain’s already setup in Office 365. If not, run New-MsolFederatedDomain
When running “Set-MsolAdfscontext” if you see an authentication prompt (which fails) you’re either running the script remotely from the ADFS machine and haven’t enabled remote PS on the ADFS machine, or the Kerberos ticket being used against WinRM (PowerShell) is the wrong one so the command is failing (in which case you need to get your Kerberos troubleshooting hat on).
Make sure the user being used for the Office 365 credentials isn’t in the domain you’re trying to convert or else you’ll get a big ugly error when you try to setup the trust. That means using “email@example.com” in my example, not “firstname.lastname@example.org”.
Testing the SSO Configuration
Now we’ve configured that, going to SharePoint Online and typing “email@example.com” as the username, the login page redirects us…
…to our internal ADFS server.
Logging in here takes us right back to the cloud again and we’re logged in, even though we didn’t supply the credentials to SharePoint Online. Clever!
Even better, if we enter the URL of our on-premises SharePoint server we go straight in without any need to authenticate at all.
SSO is configured & working!