Originally posted on Lucian.Blog. 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.


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.


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

Originally posted on Lucian.Blog. Follow Lucian on Twitter: @LucianFrango.

ADFS, Azure Infrastructure, Azure Platform, Office 365
, ,

Join the conversation! 18 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

  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?

  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.

  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.

    • 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!?!

  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.

  6. Not sure why “security managers” would be happy about this new mode.
    The pass-thru authentication means that:
    1. All your local authentication tokens (NTLM or Kerberos) will travel thru an external cloud
    2. You need to open ports to inbound traffic from Internet to Active Directory DCs
    The both things are big “no-no”s in companies that are serious about security.
    I am not even talking about government.
    May be a good option for PME that do not have resources to support ADFS but want SSO…

    • Is that still an issue? The ports are only open to outbound traffic, at least in the current version.

    • Pass through authentication doesn’t require you to neither send any kerberos tickets (or NTLM) to the cloud, and doesn’t require you to open any ports to inbound traffic from the internet (only external).
      In contrast, Seamless Single Sign On will send kerberos tickets to the cloud. But these are tickets which are specific to a service account which is only used for seamless sso.

  7. Hello
    I want the Azure Ad authentication with SAML protocol using SSO but not want to use any ADFS agent or some other.
    Is it possible that can we make authentication directly?

  8. I’m currently rolling out an internal application that requires AD FS internally for authentication. We don’t have AD FS on premise, but have the Azure AD Connect utility already syncing with Azure and doing pass-through authentication to log us into Office online.
    For my new internal app, can I use any of the pieces of Azure, AD connect, etc that I’ve already got to replace AD FS?

    • Hi Lucas, if you have the app configured as “app registration” in Azure (essentially like and AD FS RPT, but, in Azure), and if the app uses modern authentication (ADAL), then i would imagine this would work for you. If the app is not modern auth compatible, then it’s likely going to need AD FS.

      • Also, the app would need to sign in with either a UPN or possibly (if i remember reading correctly) an “alternate ID” attribute that is configured in AADC. Anything else, then this wouldn’t work either- again, go back to AD FS.

  9. Hi Lucian,
    I am looking to move from on-premise ADFS to Azure Cloud.
    What we have now is two ADFS servers for internal using integrated type and two ADFS proxy for external using forms type. The internal domain computer/user does not need to enter emial and password when accessing to Office 365. It will be automatic. When they are outside, they need to enter their email address and password.
    How does this work with AADC when the authentication is integrated for domain computer/user?

  10. Hi All,
    I am planning to migrate my On Premises AD to Azure AD. Once i migrated Azure AD i will decommission my On Premisses AD.I need some Technical Assistance on below specified Queries

    1. How my On Premisses user will authenticate the Azure AD.
    2. How to Join the Workstation to Azure AD
    3. How to implement the Group Policies through Azure AD.
    4. How to implement the Pass through Authentication on Azure AD
    5. What is the disadvantage if i decommission my On Premisses AD

    Please let know you valuable suggestion and thoughts regarding my queries .

    Thanks and Regards
    Kiran Varupalli

Comments are closed.