A few days ago, an updated version of Azure AD Connect was released – 1.1.371.0 (download). This included the public preview of Passthrough Authentication and Seamless Single Sign-on which lets an internal domain connected computer authenticate against an internal domain controller and sign into Office 365 resources. This gives a great cheap option to do this rather than requiring ADFS on premise to do this or just entering user credentials to authenticate against Azure AD; but there are caveats I’ll cover below.

Install Gotcha

After you’ve updated the client (regardless of the authentication type chosen), there’s a quick ‘gotcha’: The Azure AD Connect application shows a different message when you launch it:

“Synchronization has been disabled to allow changes to your current configuration. Azure Active Directory will not receive further updates until reconfiguration is complete.”

This is very different from previous versions:

As I was testing passthrough authentication at the time, I misunderstood this message to mean that something was being configured, and I had to wait. What it actually means is that by launching the application, syncs are now paused until you go finish with this program; either by making a configuration change or just exiting.

This also means that if you leave this window open, synchronization will not occur again until it’s closed – even if you have multiple servers set up. If you get an email alert saying synchronisation hasn’t occurred for a while, this is the first thing to is to check that someone didn’t leave the application open.

Azure AD Connect Passthru Auth

I’ve been waiting all year for this option, but there is a lot of misinformation around what it actually can do. After having the privilege of speaking to the Senior Program Manager on SSO and Passthru Auth for Azure AD Connect Ross Adams for two hours (thanks Ross for your invaluable time!) I found out about these key points:

• Passthrough Authentication right now does not give you a pure automatic authentication experience. It avoids the requirement of having to retype your password, you still need to choose your account
• Azure AD App Proxy is required for Single Sign-on and Passthrough Authentication, but won’t function for actual application proxying when in this mode. You’ll need a different box running App Proxy if you use it this way.
• Appending your domain onto supported urls with WHR (Custom login page e.g. https://login.microsoftonline.com/?whr=contoso.com) will reduce the amount of clicks a user needs to get in – generally a single click to pick their account

This doesn’t quite match the experience compared to having ADFS on premise, as I confirmed with friend     Ken Goodwin. This is his explanation of the ADFS experience:

If you just go to office.com to logon, after you type in your email address it’ll redirect you to the adfs server which will automatically log you on (assuming internal). If you pre-specify the domain using https://login.microsoftonline.com/?whr=domin.com, then the logon will be automatic.

This might act differently if you’re able to enable auto-acceleration on your SharePoint sites at least which drops the WHM requirement – as long as you have Azure Active Directory Premium.

Keep in mind, Passthrough Authentication and Single Sign-On are still in public preview so this may change and improve. I’m still having a mixed experience on a few items, so don’t go too crazy with rolling this out to your live setup yet. I expect we’ll see some updates soon, and finish up with a really solid new feature to improve the experience for all.

Update: Another tip – if you disable and re-enable Pass Through Auth then your old Kerberos tickets will be invalid. Wait 10 hours or run the command “Klist purge” on an affected PCs – otherwise you’ll get weird authentication errors when trying to log into a site.