In this, the second of two blog posts (read part one here), we will look at the process of installing Azure AD Connect with the new Pass-through Authentication option. I will then touch on “modern authentication” which has been around in the Office products for about a year now, but the interaction between modern auth and pass-through auth is particularly interesting when we start to thinkg about some of the more advanced features available in Microsoft’s product line-up.
NB: At the time of writing (January 2017), the Pass-through Authentication feature is in public preview. Do not use it in production.
A very mainstream configuration of Office 365 uses synchronised identity with password sync. This means that every time a user is authenticated, that authentication happens against Azure Active Directory rather than the on-premises AD. This was the configuration in our lab environment before the changes.
In this walkthrough, we upgraded our existing Azure AD Connect to version 1.1.371.0, which is the first public version that includes the Pass-through Authentication option.
We used a dedicated Windows Server 2012 R2 VM, but in a smaller environment it’s perfectly appropriate to install the tool on an existing server provided, as always, you choose wisely.
The first couple of wizard pages are unexceptional. On the final step of the wizard, we just have the option to start synchronisation after the upgrade.
A simple click of the “upgrade button” and the new version of AAD Connect is installed. We will then need to change the configuration to use pass-through authentication.
Helpfully, the “learn more” link provides a link to a well-written document that describes the background of domain join and the option of Azure AD joining Windows 10 PCs. This optional step can unlock some of the more advanced features.
With the basics installed, we’re ready to change the user sign-in options and enable the new Pass-through Authentication feature. So, let’s click the “change user sign in” task in the wizard.
We were originally using password synchronisation, but we’re now going to turn on pass-though authentication.
In the screenshot above, note also the helpful hint that it’s a very very good idea to keep an account as a cloud-only login (i.e. were the account is in Azure AD only). You wouldn’t want to be in a situation where your administrative accounts were all on-premises in the event of a failure of the on-premises environment.
Let’s also enable the single sign-on option. Obviously in a live environment, there would be one of two things to think about before going ahead, but then this is currently a preview feature and you shouldn’t be using it in production!
There are some configuration changes that need to be made to the on-premises AD for single sign-on to work, and the wizard is going to help us out here.
With that, the final page of the wizard is just a summary of the changes that are to be made.
Here’s the agent being installed:
With all that excitement out the way, we tried logging in to the usual Office 365 resources. It just worked!
One of the changes made to Office 2013 and 2016 is the addition of “modern authentication”. Without going into detail about what modern authentication is, the best illustration is the user’s experience with a familiar-looking dialogue box.
This is the traditional login box. It merely asks for a username and password. If we wanted to introduce something like multi-factor authentication (MFA), where perhaps some more interaction is required, this dialogue box (to say nothing of the protocols and technology behind it) is not much good.
Let’s contrast this with the look and feel once modern authentication is turned on, and with multi-factor authentication switched on for the user. Incidentally, Microsoft’s implementation of MFA in the Enterprise Mobility + Security suite is very convenient for the user when set up.
With Office 2013, the feature needs to be turned on at the client (registry or group policy) and with Office 2016 it’s on by default.
Modern authentication also needs to be turned on for some Office 365 services. At the moment, it’s off by default in Exchange Online and Skype for Business Online, but on by default in Sharepoint Online. These defaults are obviously subject to change.
With that done, we’re now ready to test whether pass-through authentication is really working. Let’s temporarily turn off the machine that’s running Azure AD Connect. In our demo environment, this will break authentication for our test user.
Indeed, authentication doesn’t work anymore. We even get a helpful error message. Turning our AAD Connect machine back on immediately fixes the problem.
The next step in making the infrastructure more resilient is to deploy additional connectors. The wizard and documentation cover this and it’s a simple process. The connector is a very lightweight piece of software that could quite happily run on domain controllers in a few branch offices.
This will provide resilience against a single office’s internet link going down.
Anyone who’s deployed AD FS (Federation Services) to achieve the same goal can see how much simpler this approach is.
That’s the end of our walk-through. We will continue to test this option internally during the preview phase. If you’re thinking of deploying AD FS purely for Office 365 use, you may well want to hold off and evaluate pass-through authentication instead.
To read part one of this blog post series, click the button below.
Leave a Reply