Office 365’s single sign-on capabilities with ADFS are a great improvement over dual-identities, and it takes online users a step closer to the seamless experience they have become accustomed to with an on premise web application. If you’re looking to set it up, Microsoft provide some great information and even some step-by-step videos: https://support.microsoft.com/en-us/kb/3061192.
But, once you’ve got it all hooked up you quickly find a couple of unexpected “features” that can ruin your user experience.
If you are aware of these features and have tried everything, jump to the end of this post to see the magic! It’s not rocket science, but the workaround isn’t obvious and the technique isn’t overly well documented or communicated.
So, if you are still with me, the following process should sound familiar:
When you attempt to access https://portal.office.com you are prompted for credentials, email address and password. When you finish typing in your email address the page bounces you via your ADFS server, prompting you for credentials again if you are not on the domain.
If you are on the domain it signs you in and takes you to the Office 365 portal landing page – not a very exciting page. None of which requires you to use your password, so why show them that box on the first screen?
If you’re not on the domain you will need to enter your password, but on the second screen, not the first screen, so don’t start typing too quickly.
The next time your open your browser to go to Office 365 via https://portal.office.com, although it can remember who you are, it simply sits on the this login page until you click on your email address.
You receive a similar experience when you attempt to access your SharePoint Online site, none of which provides a very friendly user experience, particularly for those users that aren’t aware of any difference between their old Intranet and the SharePoint Online Intranet.
Now, I completely understand the technical barriers and implementations that Microsoft needs to support but we can’t realistically expect users to be happy with all of these steps. In addition, most users expect that the home page that IT pops into their browser is going to take them to the Intranet, not some strange portal landing page.
Now we’ve got all of the doom and gloom out of the way, let’s talk about how we fix this.
The first thing we need to do is to bypass the step before the ADFS redirect. The login page checks the domain of your email address to see if it can bounce you via ADFS, so if we could somehow include this in the URL we could skip the need for users to type in their email address. Fortunately there is such a URL!
In place of https://portal.office.com you can get users to use:
https://login.microsoftonline.com/login.srf?wa=wsignin1.0&whr=%5Byour domain|RS|
So if your email address was bob@example.com you would use https://login.microsoftonline.com/login.srf?wa=wsignin1.0&whr=example.com. Note, the same URL can be used for all users of the domain as it doesn’t care what the user’s username is, just their domain.
Now although this is a massive improvement, it isn’t really memorable. So it would be a good idea to set this as the user’s homepage. But, now, even though the user is logged straight it, it takes them to the Office 365 landing page. This shows you all of your “Apps” but it won’t be immediately obvious to users where they can find the Intranet. Click on Sites, click on the promoted link – not a great experience.
What would be really cool is if you could use this magic login technique alongside your SharePoint Online URL. Guess what, you can.
The %3A%2F%2F after https is :// URL encoded, as this is a querystring parameter it is a good idea to make sure it is encoded.
Following this URL will take you via example.com’s ADFS server, log you in if you are on the domain or prompt your for credentials on an example.com branded page, and then take you to example.com’s SharePoint Online team site – sorted!
