In an earlier blogpost I wrote about the new ‘pass-through authentication’ feature that is in public preview in the new Azure AD Sync client.
One of the most common reasons to use ADFS in an Office 365 setup, is that it allows you to do Single Sign-On. You only have to authenticate once, when you log on to your domain joined device, and your Kerberos ticket is used to authenticate you against Azure AD and therefore Office 365.
With the pass-through authentication feature, you get the same benefits. Because the PTA agent authenticates you against your on-premises Active Directory, you can use PTA to do single sign-on as well. So lets take this setup for a test-drive!
Basis of this test is the setup from my previous blog: an on-premises AD with PTA enabled in Azure AD Connect combined with the 365Dude Office 365-tenant. I added a Windows 10 machine to the mix, and domain-joined it to the on-premises AD. I use the Mr. Dude account to log on to this machine.
There are a few prerequisites to take into account when doing SSO. Mainly, they regard the OS and browser used. It is required to use a Windows machine, as it uses Kerberos for the underlying authentication. When using Windows 10, 8.1 or 8 clients, Internet Explorer, Chrome and Firefox are supported, where Edge isn’t. Lower Windows-versions aren’t supported. When installing Azure AD Connect with the PTA / SSO option, a computer account is created in AD to handle your authentication requests.
First, we need to make sure that the Office 365 tenant is configured to allow OAuth. We do this with one single line of PowerShell:
|
|
Furthermore, we need to add the Microsoft authentication servers to the Intranet zone of the browser’s security settings. They need to be explicitly added to the machine’s Intranet zone, so that the browser will automatically send the currently logged in user’s credentials in the form of a Kerberos ticket to Azure AD. The easiest way to add the required URLs to the Intranet zone is to simply create a group policy in Active Directory.
There are two URL’s that need to be configured here:
https://autologon.microsoftazuread-sso.com
https://aadg.windows.net.nsatc.net
When done, the GPO should look as follows:
That’s it! After configuring our tenant and setting up the URL’s to be in the Intranet zone, you can ‘single sign-on’ to your Office 365 service.
So, what’s the user experience here? Let’s check it out.
After logging on the machine, we open IE and navigate to the https://outlook.office.com URL.
We are prompted to enter username and password. After we enter the username part, and navigate to the password field, the computer checks for a Kerberos ticket for this username. When it exists, the client is automatically logged on without the need of entering the password.
Well, it’s a bit hard to capture that on a screenshot. But you catch my drift, right? 😉 When the login completes, we just find our Outlook for the Web logged on and ready to use.
So that’s the webmail part. Most of my clients however, prefer to use Outlook as part of the Office suite for their e-mail work. How does SSO work there? Well, almost in the same way.
Prerequisite for SSO to work with client apps, is that the apps support modern authentication. So for our Windows-based clients, that will be Office 2013 and 2016. For this test, I used Office 2016.
When first starting Outlook, we are prompted to connect to Office 365.
So lets do just that. When we click the ‘connect’ button, we get a login screen equal to the one being used in the Outlook for the Web based interface.
And there we are. After checking the username and navigating to the ‘password’ field, the dialog box checks to see if a Kerberos tickets exists for this account and when it does, it uses that to log on to the Office 365 service. No further user interaction is required, It Just Works.
So, it’s a wrap. This single sign-on functionality provides you with all the ease of use you have with ADFS, without the need of a complete ADFS infrastructure. Ofcourse, when you plan on (or need to be) running ADFS in your environment for single sign-on with other applications, such as CRM or ERP software for example, there is no use in using PTA with SSO for Office 365, you just take the ADFS route. If you however want to provide your user with the same experience without the need for the infrastructure, PTA with SSO can be a great alternative!