Helping your users achieve Seamless sign-on with Office 365 and ADFS

Understanding the terms

A large number of my customers use ADFS to enable single sign-on for their users but I quite often get calls to help them understand why their users are seeing the California Highway screen to select a username rather than connecting straight in as a seamless sign-on.

Some of this confusion comes from a multitude of sources, from the terms we use, the endpoints that we’re connecting to, the identity mechanisms that we have in place and the configuration of our users machines. So in this post, I’m going to try and clarify some of the terms and show you how you can achieve near seamless sign-on for your users.

Note: All of the descriptions here assume that the client environment is a typical Active Directory domain model connecting to a single Office 365 tenancy.

First off, What are these different sign-on terms, what do they mean and what identity technology do we need to deploy to achieve.

 

Term Meaning On-premises Technology required
Cloud Sign-on The user has an identity that they use to log onto Office 365. Whilst this may have the same username as their domain account, there is no correlation between the two and no synchronisation of passwords. Many users will try to keep their passwords in sync manually, but will ultimately fail to do so. None. All accounts are homed in Office 365.
Same sign-on The user logs into the cloud service using the same credentials and password that they use to log onto their domain device. If the password in the on-premises environment is changed, this is reflected in the cloud.

The user will generally have to enter their password once per session.

AAD Connect
Single sign-on The user connects to the cloud service using their username that they use to log onto their domain device. They do not need to re-enter their password during any authentication process. AAD Connect (With pass-through auth) or AAD Connect with ADFS.
Seamless sign-on (user initiated) The user connects to the cloud service, selects their identity for the first time only and does not need to enter their password. Having already logged onto their domain joined device, this passes through their full credentials automatically. AAD Connect (With pass-through auth) or AAD Connect with ADFS.
True seamless sign-on
(IT initiated)
Not possible… yet? ???

Achieving Nirvana(ish)

As you can see, the nirvana state is to achieve seamless sign-on, after all, my device knows who I am, surely Office 365 should? Why should I have to tell it? And this leads to our second point of understanding…

Office 365 is a multi-tenanted system, you share the cloud with millions of other users and there are certain URLs that you connect to that are used by everyone e.g. https://portal.office.com and Office 365 cannot just surmise who you are by the endpoint you connect to.

From this point on, I’m going to assume that you have deployed ADFS or at least AAD Connect with Pass-through authentication (Be warned though, AADC with PTA is currently in PREVIEW and therefore not recommended for production deployments.) and that you are logging on with a Domain joined Windows device.

If we browse to https://portal.office.com for the first time on a new machine. We’ll see the usual Office 365 California Highway screen asking for our Username and Password. If you’ve been here before, then you may be asked to select your username from a list of one or more user accounts.

image

With ADFS, Once I’ve typed in my account name and hit Tab, or I’ve clicked on my username, we’ll see Office 365 redirecting the user to the ADFS logon screens. If you’re on a trusted domain joined device, you should never actually see the ADFS screens, you should just be authenticated and returned to the Office 365 Portal landing page. (Note: This assumes that your federation portal address is configured in your users Intranet Zone in order to allow for automatic pass-through of windows credentials!)

clip_image001

This is Single sign-on in action, but it’s not completely seamless to the end user just yet! To do that we have to tell Internet Explorer to remember us.

Open a new Internet Explorer session to https://portal.office.com and if you’ve already logged in previously, click the little ellipses marker next to the account name and choose forget me. This will take the browser back to the enter user name screen.

clip_image001[7]

Back at the logon screen, BEFORE you type in the username, tick the “Keep me signed in” checkbox. Then type in the username and hit tab.

clip_image002

Now, when the user reopens their browser and clicks on the Office portal link (or any other link that uses the Office 365 logon screens), the user will be automatically passed to ADFS for authentication and then logged in.

The Caveats!

This will work until either the cookies expire or someone clears the cookies on that machine. Also if the user logs onto another machine, they’ll need to repeat the process and there’s no way to pre-tick the Keep me signed in button (which is actually a good thing as this should only be done on the users main Domain Joined machine and NEVER on a shared computer!).

4 comments

Skip to comment form

    • Lucy on Fri 21 Jul 17 at 9:49 am
    • Reply

    Really useful article but could you edit the table so its not hidden over half the page, we cant see the right hand column.

    1. Apologies Lucy, I didn’t realised my publishing package had set a fixed width. That should be readable now.

  1. The other joy of AADC with PTA is Edge is not a supported browser. Go figure.

    1. It’s not fully supported for the Seamless Sign-on docs with azure either. I’m sure it will get there.. sometime. 😎

Leave a Reply

Your email address will not be published.

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.