Originally posted on Lucian’s blog at clouduccino.com. Follow Lucian on Twitter: @LucianFrango.

***

Yesterday I received a notification email from Alex Simons (Director of PM, Microsoft Identity Division) which started like this:

Todays news might well be our biggest news of the year. Azure AD Pass-Through Authentication and Seamless Single Sign-on are now both in public preview!

So I thought I’d put together a streamlined overview of what this means for authentication with regards to the Microsoft Cloud and my thoughts on if I’d use it.

Before:

2016-12-09-before-01

What is Azure AD pass-through auth?

When working with the Microsoft Cloud, organisations from small to enterprise leverage the ability to have common credentials across on-premises directories (ADDS) and the cloud. It’s the best user experience, it’s the best IT management experience as well. The overhead of facilitating this can be quite a large endeavour. There’s all the complexities of AD FS and AADConnect to work through and build with high availability and disaster recovery in mind as this core identity infrastructure needs to be online 24/7/365.

Azure AD Pass-through authentication (public preview) simplifies this down to Azure AD Connect. This new feature can, YES, do away with AD FS. I’m not in the “I hate AD FS” boat. I think as a tool it does a good job: proxying authentication from external to ADDS and from Kerberos to SAML. For all those out there, I know you’re out there, this would be music to your ears.

Moreover, if you wanted to enjoy SINGLE SIGN ON, you needed AD FS. Now, with pass-through authentication, SSO works with just Azure AD Connect. This is a massive win!

So, what do I need?

Nothing too complicated or intricate. The caveat is that the support for this in public preview feature is limited, as with all preview offerings from Azure. Don’t get to excited and roll this out into production as yet! Dev or test it as much as possible and get an understanding of it, but, don’t go replacing AD FS just yet.

Azure AD Connect generally needs a few ports to communicate with ADDS on-premises and Azure AD in the cloud. The key port being TCP443. With pass-through authentication, there are ~17 other ports (with 10 of which included in a range) that need to be opened up for communication. While this could be locked down at the firewall level to just Azure IP’s, subnets and hosts, it will still make security question and probe for details.

The version of AADConnect also needs to be updated to the latest, released on December 7th (2016). From version 1.1.371.0, the preview feature is now publicly available. Consider upgrade requirements as well before taking the plunge.

What are the required components?

Apart from the latest version of Azure AD Connect, I touched on a couple more items required to deploy pass-though authentication. The following rapid fire list outlines what is required:

  • A current, latest, version of Azure AD Connect (v 1.1.371.0 as mentioned above)
  • Windows Server 2012 R2 or higher is listed as the operating system for Azure AD Connect
    • If you still have Server 2008 R2, get your wiggle on and upgrade!
  • A second Windows Server 2012 R2 instance to run the Azure App Proxy .exe to leverage high availability
    • Yes, HA, but not what you think… more details below
  • New firewall rules to allow traffic to a couple wildcard subdomains
  • A bunch of new ports to allow communication with the Azure Application proxy

For a complete list, check out the docs.microsoft.com article with detailed config.

What is this second server business? AADConnect has HA now?

Much like AD FS being designed to provide high availability for that workload, there is the ability to provide some HA around the connectors required for the pass-through auth process. This is where it gets a little squirly. You won’t be deploying a second Azure AD Connect server and load balance the two.

The second server is actually an additional server, I would imagine a vanilla Windows Server instance, in which a deployment of Azure AD Application Proxy is downloaded, executed and run.

The Azure Application Proxy is enabled in Azure AD, the client (AADApplicationProxyConnectorInstaller.exe) downloaded and run (as mentioned above). This then introduces two services that run on the Windows Server instance and provide that connector to Azure AD. For more info, review the docs.microsoft.com article outlines the setup process.

After:

2016-12-09-after-01

Would I use this?

I’ll answer this in two ways, then I’ll give you my final verdict.

Yes, I would use this. Simplifying what was “federated identity” to “hybrid identity” has quite a few benefits. Most importantly the reduced complexity and reduced requirements to maintain the solution. This reduced overhead can maintain a higher level of security, no credentials (rather passwords), being stored in the cloud at all. No hashes. Nadda. Zilch. Zero. Security managers and those tightly aligned to government regulations: small bit of rejoice for you.

No, I would not use this. AD FS is a good solution. If I had an existing AD FS solution that tied in with other applications, I would not go out of my way to change that just for Office 365 / Azure AD. Additionally, in preview functionality does not have the same level of SLA support. In fact, Azure in preview features are provided “as is”. That is not ideal for production environments. Sure, I’d put this in a proof of concept, but, I wouldn’t recommend rolling this out anytime soon.

Personally, I think this is a positive piece of SSO evolution within the Microsoft stack. I would certainly be trying to get customers to proof of concept this and trial it in dev or test environments. It can further streamline identity deployments and could well defer customers from ever needing or deploying AD FS, thus saving in instance cost and managed services cost supporting the infrastructure. Happy days!

Final thoughts

Great improvement, great step forward. If this was announced at Microsoft Ignite a couple of months back, I think it would have been big news. Try it, play with it, send me your feedback. I want to always been learning, improving and finding out new gotchas.

Best,

Lucian

Category:
ADFS, Azure Infrastructure, Azure Platform, Office 365
Tags:
, ,

Join the conversation! 9 Comments

  1. Hi
    I also read the post few days ago but was interested in what this DOES NOT do
    so I think piv authentication(without contintional access) it doesn’t do
    and granual policies(without contintional access which most don’t have or don’t want to pay for:)) it also doesn’t do.
    so like adfs special policies(use multi factor here don’t use it over there , that group that kind of auth, external/internal)
    so bottom line as is(with the limited info there is) I think its great BUT for very simple deployments that don’t want to sync passwords to cloud.
    but we shall see
    always interesting btw
    Thanks again

    Reply
  2. Any idea if you can bypass MFA for users with PTA? We’re thinking about rolling out ADFS to allow authenticated users not to have to use MFA wherever they are (we use IP whitelisting for users in the corporate network). Will PTA allow bypassing of MFA?

    Reply
  3. I’m trying to figure out how PS with SSO differs from Azure AD Join Desktop SSO for windows 10 onpremAD-domain-joined workstations.

    We have Azure AD Join Desktop SSO working, but it only works with Outlook 2016 and IE… Not Chrome as it appears this does.

    Can the two work in concert, or should I disjoin machines from AAD if we’re going to use this new Azure AD Seamless SSO?

    We are 100% windows 10/win2016.

    Thanks!

    Reply
  4. How would this work in Disaster recovery scenarios where the on premise domain controller is unavailable – how would users be able to sign into cloud services and how does this work / affect mobile logins to Microsoft cloud services such as Office 365 where the login is happening on a mobile phone. Currently we’re using password sync to Azure.

    Reply
    • Hi Chris,
      DR would is limited to much the same way AADConnect is limited.
      There is some HA with a secondary authentication process that can be run on a secondary server, but, again DR is limited to AADConnects design.
      The login process would be much the same as AD FS.
      Auth happens in cloud first, is proxied to on-premises, auth granted and token sent back to cloud and then to the device.

      This solution works well if you don’t really have a need for AD FS, other than federated identity, or you have security policies that state no passwords, not even hash of passwords, can reside outside the corporate environment.

      Hope that helps!?!

      Reply
  5. I wonder is this works with Smart Links. I have a few customers now that use smart links for SharePoint online so that the browser opens with a SharePoint page as the Intranet page.

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: