Passwordless Security and the Evolution of Authentication
I still remember the first password I ever had; it was for my GeoCities account in the late ‘90s...
One of the most important aspects of moving to a cloud solution like Office 365 is to provide a way for users to authenticate to their cloud resources. Organizations typically want to reduce administrative overhead and user confusion by managing only one directory, be it the on-premises directory (AD) or the cloud directory (Azure AD).
Unless your greenfield organization was born in the cloud, you'll probably be starting with a hybrid configuration where existing Active Directory objects (and possibly passwords) on-premises sync to Azure AD using Azure AD Connect. If you're using one of the older directory synchronization products, DirSync or AAD Sync, you really need to upgrade to AAD Connect because this is where all the new features and investments are being made.
Once AAD Connect is installed, you can configure the authentication methods for your organization. These options include:
Azure pass-through authentication routes authentication requests from Office 365 through a simple connector deployed on-premises to your on-prem Active Directory. The connector uses only secure outbound communications, so no DMZ or Internet-facing endpoint is required. The connector operates similar to Exchange ActiveSync, in that it creates long-running outbound requests to Azure AD to service any authentication requests as they are created. This outbound connection is encrypted via SSL certificates in Azure AD. And because the connector only communicates outbound, there are no certificate or DNS requirements for you to worry about.
Pass-through Authentication uses Kerberos authentication between the on-prem connector and AD, so it offers a true SSO experience for users on domain-joined computers. For example, those users can go directly to portal.office.com or outlook.office365.com using their signed-on domain credentials without having to reauthenticate. Users on workgroup computers will only need to authenticate once per browser session using their on-prem credentials.
PTA is deployed as part of Azure AD Connect build 1.1.371.0 or later. You install it by simply enabling the "Pass-through authentication" radio button when installing and configuring ADD Connect. SSO can be enabled by clicking the "Enable single sign on" check box. If you're upgrading from a previous version of AAD Connect, simply run Azure AD Connect and select "Change user sign-in" to change the authentication type.
Configuring Pass-Through Authentication in AAD Connect
You should understand that if PTA is configured in AAD Connect, users will be unable to authenticate if the on-prem connector(s) cannot contact Azure AD. For this reason, you will probably want to deploy additional connectors in your environment. It is recommended to use a cloud-only admin account when configuring the PTA connectors so you can manage the configuration of your tenant should your on-premises services fail or become unavailable.
PTA load balances authentication requests between connectors installed in your environment without requiring additional infrastructure. The connector is super lightweight and can be installed on any domain server, even your domain controllers. The installer is located at C:\Program Files\Microsoft Azure Active Directory Connect\SetupFiles\AADApplicationProxyConnectorInstaller.exe on the same server where AAD Connect is installed.
Installing the Pass-Through Authentication Connector
Simply run the AADApplicationProxyConnectorInstaller and it will prompt you for credentials. Here, you enter the credentials of your onmicrosoft.com tenant account. It even works with MFA. When the installer finishes, you will have the option to run the Connector Troubleshooter. If you run it, it will download the most current version of the Connector Troubleshooter from Office 365, run diagnostics and display any issues the connector may have.
Azure pass-through authentication is ideal for those customers who want to manage authentication and passwords for Office 365 from their on-prem Active Directory without needing to deploy a full AD FS infrastructure.
AD FS is still a better fit for organizations that require claims-based rules, since PTA relies on Kerberos authentication rather than claims. For example, if you need to prevent access to email from outside the corporate network, that requires a claims-based rule.
Also, know that PTA only works with Office 365. If your organization requires an authentication solution that also works with other claims-based cloud applications like Salesforce or Workday, you'll need to use a claims-based solution like AD FS.
If you currently have AD FS in place you probably have reasons to use it, as mentioned above. However, if you still want to use pass-through authentication instead, you'll need to reconfigure your tenant from a federated domain to a standard domain using the Convert-MsolDomainToStandard cmdlet. See TechNet for details. Once that's complete and all users have been converted to standard cloud users, you can configure Azure pass-through authentication, test it and then decommission your AD FS infrastructure. Be aware that this process can take some time.
PTA does not rely on or perform password synchronization with Azure AD. If your organization previously used password sync with AAD Connect, the synced password hashes still exist in Office 365, but will no longer be used or updated while pass-through authentication is configured.
Upgrading AAD Connect and enabling PTA is simple. Download the latest version of Azure AD Connect from http://aka.ms/aadconnect and run it on your existing AAD Connect server. Click "Configure" on the welcome screen, enter your Azure AD credentials (and verify MFA, if required) then click Next.
The upgrade should only take a minute or so. Next, you'll need to configure Azure pass-through authentication. Run the Azure AD Connect application, click Configure on the welcome screen, select "Change user sign-in" then click Next.
Enter your Azure AD credentials, making sure to use a dedicated cloud admin account for your tenant (i.e., admin@contoso.onmicrosoft.com). Verify MFA if necessary. Now select the "Pass-through authentication radio button" and check the "Enable single sign on" checkbox if desired. Then click Next. If you enable SSO, the next screen will prompt you for your on-prem domain admin credentials. Review the settings and click Configure.
Review the New AAD Configuration and Perform a Sync
If you enabled SSO, AAD Connect will create a new computer account in the on-prem AD Computers container called AZUREADSSOACC. This computer account is used as an alternate service account (ASA) credential for Kerberos authentication. AAD Connect will also register several SPNs for this account in AD. If you decide to disable SSO later, you will need to manually delete this computer account and its SPNs.
When the authentication reconfiguration is complete, AAD Connect will run a delta synchronization with Azure AD, and the pass-through authentication and SSO configuration is complete.
Azure pass-through authentication provides businesses of all sizes a safe easy way to provide authentication and true single sign-on for Office 365, without all the infrastructure required by AD FS. It's ideal for Office 365 customers who want to manage and keep their passwords on premises. If you need to provide SSO for other cloud services, you're probably still going to need another solution like AD FS, AAD Premium or a third-party claims-based authentication solution.
I still remember the first password I ever had; it was for my GeoCities account in the late ‘90s...
Ignite is Microsoft’s major conference for new announcements and training aimed at IT...