Setup SharePoint Online & On-Premises Single-Sign-on (SSO)


…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:

image

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.

Setup Steps

Short version:

  • 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:

clip_image003

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.

clip_image004

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.

clip_image005

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 "admin@awesomespaceships.onmicrosoft.com" -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 “superawesomeadmin@alernativedomain.something.com” in my example, not “adminguy@awesomespaceships.com”.

Testing the SSO Configuration

Now we’ve configured that, going to SharePoint Online and typing “bob@awesomespaceships.com” as the username, the login page redirects us…

clip_image007

…to our internal ADFS server.

clip_image009

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!

clip_image011

Even better, if we enter the URL of our on-premises SharePoint server we go straight in without any need to authenticate at all.

clip_image013

SSO is configured & working!

Cheers,

Sam Betts

Comments (7)

  1. Ransher Singh says:

    Excellent post, really helpful and totally inline with what we are also trying to do with a hybrid environment.

  2. Jerry says:

    Excellent article, thanks for that! Will definitely be using in the future.

  3. Neil says:

    You have to go through two login screens though! It's offputting

  4. Hi Neil,

    That's pretty standard; given the Office 365 login page is common to Office 365 logins (Azure AD) and on-premises SSO-implemented logins, there's no way no knowing which one to use until a login name is entered. You only have to enter the username for the 1st login to figure out you need to go to your on-prem ADFS & redirect you there instead.

    // Sam

    1. Joshua Bines says:

      google *cough* bing office 365 smart links

  5. Mike says:

    Following up on Neil’s issue The problem I see is, if everyone who logs into AwsomeSpaceships.sharepoint.com must login through the on-prem Sharepoint, then it should be possible to configure the AwsomeSpaceships tenant to always use the on-prem sharepoint for authentication. I’ll take it a step further, it should be possible to configure any tenant to always use a particular federated authentication service without first entering credentials at login.microsoftonline.com.

  6. Namratha Kellod says:

    Article is really good. But is this article assuming that there is only ADFS server in picture for on-premise authentication? I have a scenario where the customer is using 2 ADFS Farms. One for On-Premise SharePoint Farm(adfs1.xxx.com and one for SPO – sts.xxx.com).

    When we are setting the ADFS context, which ADFS server should I use? If we use the adfs server of the on-premise, will the SPO requests be redirected to on-premise ADFS Server?

Skip to main content