Two New Microsoft Hybrid Services Dramatically Simplify Connecting your Active Directory to Azure

Microsoft recently announced the public preview of two major new capabilities that will make integrating your on-premises Active Directory to Azure AD much, much easier. Passthrough authentication (PTA) and Seamless Single Sign-On (I’m choosing to call it 3SO) will allow your users to easily access Azure AD applications such as Office 365 without installing a complicated Active Directory Federation Services (AD FS) farm in your data center or syncing user password hashes with Azure AD.

Or in this case of 3SO, installing anything extra at all.

Hybrid Authentication Choices Until Now (and their limitations)

The vast majority of enterprises today have Active Directory as a bedrock identity service, and it’s not going away any time soon. Thus, a basic first task when planning to use any of Microsoft’s online services is to integrate your on-premises Active Directory with Azure AD for two capabilities. First, you must get AD accounts and groups synchronized with Azure AD using Azure AD Connect. Second, once the accounts are in Azure AD, you must choose how to authenticate users there. I’m focusing on the user authentication bits in this post.

Today you have two authentication choices from Microsoft: AD FS, which provides identity federation (and a number of other capabilities) for SSO, and password synchronization (“PHS” in the charts below). This second choice, known to the digerati as password hash synchronization (hence the “H”), provides a “same signon” capability where the user must enter credentials a second time to signon to Azure AD, but they’re the same userid and password they use for Active Directory.

Microsoft passthrough authentication program manager Ross Adams represents the differences between these solutions in this clever benefits / pain graph (Figure 1):

In increasing order of complexity and value, we have

• Cloud only accounts: User accounts are maintained and authenticated in Azure AD. We’re talking about hybrid solutions in this post, so we’ll leave this alone.
• AAD Connect / Cloud Accounts: You can use Azure AD Connect to sync user accounts into Azure AD so the login id (usually the user’s email address) is the same, but the users must maintain their own passwords in the cloud service. I don’t see anyone doing this.
• AAD Connect + PHS: When you turn on the password hash synchronization optional feature in Azure AD Connect, the user password hashes stored in your on-premises Active Directory will be synchronized into Azure AD, thus enabling same signon.
• AAD Connect + AD FS: The most complete and most complex solution by a good margin, this combination will provide SSO to Azure AD, authenticating against the accounts in your local Active Directory.

As you can see, there’s a large gap in deployment complexity to get true SSO into your organization. Third party solutions from Okta, Ping Identity, OneLogin, Centrify, OptimalIDM and others offer simpler methods for authentication that fit into this gap, and that is one of the reasons for their popularity.

Domain joined Windows…and everything else

To understand what these two new solutions in public preview are providing, it helps to group authentication use cases into two buckets:  the client to be authenticated by Azure AD has a Kerberos ticket, or they don’t have one.

The first is the classic Windows corporate authentication scenario, known as Integrated Windows Authentication (IWA). A user that’s logged on to their domain joined Windows workstation with an AD account, on the corporate network (i.e. the workstation can find a domain controller) and therefore has a Kerberos ticket, gets seamless access to AD-aware resources without being prompted to enter their password. This scenario has been around since Active Directory was invented.

The second bucket represents the other authentication scenarios that have evolved since:

• A domain joined workstation trying to authenticate from outside the network (the notebook)
• A browser based client, whether it’s on a desktop or mobile client (the web browser)
• An API-based client, such as an Office app (the mobile app)

Let’s look at the domain joined workstation scenario first, and Microsoft’s elegant solution using 3SO.

What is Seamless Single Sign-On?

3SO is designed to work with the first bucket – the domain joined PC on the corporate network. The elegance of the 3SO solution can be summed up in just a few words: Azure AD can now support Kerberos authentication.

That’s it. Boiled down to its essence, AD FS’s main purpose is to transform a Kerberos ticket into a modern SAML or OAuth security token that a relying party such as Azure AD can use. If Azure AD can understand a Kerberos ticket – specifically a service ticket for an Azure resource – you don’t need the AD FS middleman to do the translation.

Figure 2 shows how this is done. Azure AD is represented in your local AD as just another computer; AD doesn’t know the difference. A computer account (AZUREADSSOACCT) is added to your AD, and with it two SPNs (service principal names) that contain URLs needed to perform the authentication. The Kerberos secret key for the workstation account is securely shared with Azure AD. From this point on, clients use IWA to access Azure resources just as they might access an IIS server in your local data center.

1. A user attempts to access an Azure AD resource such as Office 365. Azure AD challenges the user to provide a Kerberos service ticket.
2. The client presents its TGT (ticket-granting ticket) and the SPN of the target server (an Azure AD URL in this case) to its domain controller.
3. The ticket granting service (TGS) inside the domain controller’s key distribution center (KDC) creates a service ticket for the Azure AD resource and returns it to the client.
4. The client presents the service ticket to Azure AD. Assuming the ticket is valid, the user is authenticated.

Note this process doesn’t mean the user is authorized to access the resource; just that they’ve authenticated who they are. The result is that an on-network corporate Windows user isn’t prompted to enter a password to access Azure AD resources, and AD FS isn’t required. Pretty slick, eh?

3SO installation is about as simple as it gets; you simply check an “Enable single sign on” checkbox in the custom configuration of the latest version of AD Connect.

Supported clients

There are a couple of supported configurations for 3SO. First, it must be a client that supports Kerberos, such as Windows. Second, it works for accessing Azure AD resources via browser (for example https://outlook.office.com) or from an Office client that support modern authentication. You can see the list of supported clients, but essentially it’s supported on all major browsers (IE, Chrome, Firefox) except Edge, and all supported Microsoft client OSes. Microsoft recommends turning 3SO on for all clients; if the user is in an unsupported configuration, the worst thing that will happen is that they’ll receive a password prompt.

What is Passthrough Authentication?

PTA is designed for the use case where the client doesn’t have a Kerberos ticket, either because the Kerberos client can’t reach a DC (for example when an employee is working from home on their corporate notebook) or because the client doesn’t support Kerberos (for example a mobile browser or app that doesn’t support modern authentication).

I won’t talk about how to install PTA here, but essentially you deploy one or more on-premises lightweight connectors, much like the Azure AD Application Proxy connector, on domain-joined servers where they can communicate with a DC.

At a high level, the PTA authentication process is much like the AD FS authentication process: Azure AD recognizes that the authentication request is delegated to an on-premises Active Directory via a proxy. For AD FS, it acts as the proxy. For PTA, the connectors act as the proxy (Figure 3).

1. Azure AD prompts the user to authenticate, and the user enters their email address and password.
2. Azure AD determines that the user’s domain is configured for PTA; Azure AD notifies the connector which retrieves the credentials.
3. The connector authenticates the user against AD using the same Windows API that AD FS uses.
4. The response is returned to the connector.
5. The connector forwards the response to Azure AD.
6. Azure AD issues a token to the user.

You can see this has a lot of advantages over AD FS:

• Connectors can be installed on existing, domain joined servers or DCs.
• When multiple connectors are installed (recommended), PTA automatically load balances across them
• All Azure connections are outbound, and no unauthenticated end points are exposed to the internet
• It’s very simple to manage from the Azure portal, and there are no certificates to manage

When would you still want to use AD FS?

Make no mistake; AD FS has by no means been pushed aside. PTA is a very specialized arrow for a single target: it allows Azure AD to authenticate Active Directory users against their corporate AD, period. You still need AD FS if

• You want to use smartcards for authentication
• You want to use third party MFA providers
• Your corporate security policy requires that passwords always remain on premises (unlike AD FS, in PTA the user’s password is entered into Azure AD before it goes on premises)
• You use AD FS additional authentication rules to enforce conditional access
• You use on-premises Windows 10 conditional access based on device

And of course, you must have AD FS if you have relying parties locally configured to provide SSO that you don’t wish to move to Azure AD.

AD FS 2016 also offers new features such as built-in Azure MFA support; if you have an existing AD FS deployment, look very carefully at your future needs and what AD FS can do before you consider ripping it out as a cost savings measure.

Hybrid Authentication Choices Now

Microsoft now offers a much more well-rounded set of hybrid authentication options (Figure 4):

The original options are still available, but you can now get great value with very little extra complexity. If you’re using password synchronization, adding 3SO will eliminate password challenges for your on-network corporate users. If instead you enable PTA along with 3SO, you have practically the same value as AD FS for the specific Azure AD authentication use case.

With the public preview of 3SO and passthrough authentication, Microsoft has dramatically lowered the barrier to adopt a hybrid identity strategy using the company’s native tools. In fact, these tools are even simpler to use than third party offerings that have been taking advantage of AD FS’s complexity.

And in case it’s not clear, all of this is free. Microsoft has bet its future on its Azure cloud services. The company wants to make adoption of these services as easy as possible, and in today’s Active Directory-centric world that means making AD integration with Azure AD quick and painless. It’s taken forever to bring these capabilities to the light of day, but I predict they will quickly become the most popular identity bridge between on-premises Microsoft identity and in-the-cloud Microsoft identity.