So this will be the start of the end of ADFS for O365. https://t.co/5lV4gyCIEL— 365 Dude (@365dude) December 8, 2016
I tweeted something about how this would be the start of the end of ADFS for Office 365, but is it? Time to take this new options for a test drive!
First, some side-notes. The new functions are in public preview, which means it’s ‘beta’ and SLA is non-existent. You should therefore not use it in production environments. But I guess you’re smart enough to know that.
Setting up the test
So, for the test I created a simpel AD domain 365dude.local, with one user: Mr. Dude. This will be the user I will be syncing to my existing Office 365 tenant that houses 365dude.nl. To make synchronisation easier, I added 365dude.nl to the list of UPN-suffixes in my AD domain and changed the UPN of this user to firstname.lastname@example.org.
I enabled the dirsync functionality on my Office 365 tenant using PowerShell:
After that, I start with installing the Azure AD Connect tool
I guess you’re smart enough to know how to install AADConnect, so I’ll just focus on the new and shiny stuff here.
In the ‘user sign in’ screen, we can select how we want to handle sing in requests for our synced users. Of course we can use password sync or ADFS, but we’ll choose the new ‘pass-through authentication’ option.
So, what does this new pass-through authentication mechanism do? It relies on a connector which runs in local network. When you authenticate through the Office 365 portal (or a supported client app), your authentication request is sent to the connector over a secure channel. The connector will then check your credentials against your on-prem AD. So, no more syncing of password hashes to the cloud and using AAD as your authentication source: you authenticate directly to your on-prem AD. Just like you would when using ADFS, but without the need for the complete ADFS infrastructure.
On the ‘optional features’ tab, you can still choose to do password sync. This way the on-prem passwords are still synced to AAD, so you can easily fall back to authenticating to AAD if you want to, because the passwords are already in place.
In this screenshot, I also selected the ‘password write-back’ option. To use this, you need an AD Premium license.
You get some information on what the software will do, and the installation will continue.
Once completed, I can find the user from my on-prem AD in the active users overview of Office 365 and assign a license.
Remember, with pass-through authentication when you sign in to Office 365, your authentication is routed through the connector in your local network and your credentials are verified against your on-prem AD. Thus, you can find eventlog messages for your sign-in request with Office 365.
So, will this be the end of ADFS? In some ways it will, I guess. You can get the same functionality, without the need of the complete ADFS infra. And ofcourse, with the pass-through authentication mechanism in place, you don’t need to sync your (hashed) passwords to the cloud to get the same sign-in experience, which could please your security officers. On the other hand, many (larger) organizations already have the ADFS infrastructure in place to get single sign-in functionality with other LOB applications. If you already went down that road, you can simply use that to connect Office 365, too. Another disadvantage is that when you use directory synchronisation to connect your on-prem AD to AAD, you’ll need an on-prem Exchange Server to perform certain management tasks, such as adding aliases to a mail enabled user. For smaller organizations, this can be reason to not choose the directory sync option all, be it with or withou pass-trough authentication. I expect this will be something that Microsoft will fix somewhere in the next year, but that’s just a guess.
Want more information on this new (preview) functionality in AAD Connect and Office 365? Be sure to check out the official documentation.