Azure AD pass-through authentication

Pass-through authentication is one of the Azure authentication methods that allows for users to use a single set of credentials to access both on-premises resources, and resources in the cloud such as Office 365, or other SaaS applications.

One of the most common ways users authenticate to Azure with their on-premises credentials is via Password Hash Synchronization. However, organisations who have strict security and compliance policies may opt to use Pass-through authentication instead, which (like Password Hash Synchronization) doesn’t require any additional licensing.

Note: This option is not available for Microsoft Azure Germany cloud or Microsoft Azure Government cloud.

This method uses on-premises software agents to validate passwords against on-premises domain controllers, rather than presenting the password to Azure AD.

Some of the benefits and capabilities of pass-through authentication include:

  • Credentials are always authenticated by on-premises domain controllers for extra security,
  • No additional licensing requirement,
  • Being able to make use of your on-premises password policies,
  • Integration with self-service password management in Azure, password write-back, and password protection, which bans the use of commonly used passwords,
  • Integration with Conditional Access policies including Azure MFA,
  • Integration with Seamless SSO is possible so that users do not have to type their password when authenticating to Azure AD,
  • Brute-force attack protection using the smart lockout feature,
  • No inbound port creation requirements, as all traffic is outbound only, making it non-essential to host the authentication agents in a DMZ,
  • Little management overhead as each agent automatically updates and applies patches to themselves,
  • High availability is easily achieved by deploying multiple agents,
  • All browser-based web applications and Microsoft Office client-side applications that use modern authentication, such as Outlook, are supported.

Contents:

General sizing requirements:


When hosted on a 4-core CPU server with 16GB RAM, an Authentication Agent can support 300 to 400 authentications per second. These servers should be situated close to your domain controllers to reduce any latency.

Firewall and proxy access:


For initial registration of an Authentication Agent, make sure the agent can access:

  • login.windows.net
  • login.microsoftonline.com

The agent must be able to communicate outbound over the following ports

  • TCP 80 – Used for downloading the certificate revocation lists while validating the SSL certificate.
  • TCP 443 – Used for all outbound communication with the authentication service in Azure.
  • TCP 8080 (optional) – Authentication Agents report their status every ten minutes using this port, if port 443 is unavailable. The health status is displayed on the Azure AD portal. Port 8080 is not used for user sign-ins.

If traffic from your Authentication Agents route through a proxy, make sure the following addresses are whitelisted:

  • *.msappproxy.net
  • *.servicebus.windows.net

If DNS whitelisting is not possible, make sure access to the Azure datacentre IP ranges listed here is allowed.

For certificate validation, allow access to the following URLs:

  • mscrl.microsoft.com:80
  • crl.microsoft.com:80
  • ocsp.msocps.com:80
  • www.microsoft.com:80

Authentication flow:

  1. User accesses a Microsoft Office client-side application such as Outlook using Modern Authentication, or a web application.
  2. If the user is not already signed in, they are redirected to the Azure AD sign-in page.
  3. User enters their username and password (the same one that they use on-premises).
  4. Azure AD receives the sign-in request and places the user’s credentials in a queue. The credentials are encrypted by using the public key of the Authentication Agents.
  5. An on-premises Authentication Agent retrieves the encrypted credentials by way of a pre-established persistent connection with Azure AD. The agent decrypts the password using its private key.
  6. The credentials are validated against Active Directory using standard Windows APIs, which follow a similar method to what AD FS uses.
  7. The domain controller that receives the request validates it, and returns a response to the agent such as success, failure, password expired, user account locked out etc.
  8. The response from the domain controller is relayed by the Authentication Agent to Azure AD.
  9. Azure AD evaluates the response, and signs the user in, or challenges the user for Multi-Factor Authentication for example if Conditional Access policies are in play.
  10. After authentication is complete, access to the application is granted.

Enabling both Pass-through Authentication and Password Hash Synchronization:


You can enable Password Hash Synchronization via the Optional features page of the Azure AD Connect wizard. This allows sign-in to complete for applications that do not support pass-through authentication. Also, if Authentication Agents fail and you are left without a working agent to process authentication requests, you can enable Password Hash Synchronization to avoid any downtime. Switching methods is not automatic, and you must manually change the sign-in method to Password Hash Synchronization from the AD Connect wizard. If the primary AD Connect server is also offline, and you have no access to a staging server, you need to call Microsoft Support to turn off pass-through authentication. Note that cloud-only users will not be affected by an outage to pass-through authentication.

Configuring Pass-through Authentication:

⮩ Planning:

  • When installing the pass-through Authentication Agent, you must install the first agent on an AD Connect server, which is running Windows Server 2012 R2 or higher. You should also take this opportunity to update AD Connect if automatic updates are not enabled.
  • Additional agent servers must be running Windows Server 2012 R2 also. Microsoft recommend you have a minimum of 3 Authentication Agents running on your tenant. The maximum number possible against a single tenant is 12.

⮩ Installing:


To enable Pass-through authentication against your tenant, you must run a Custom installation of AD Connect. Alternatively, you can re-run the wizard after initial configuration and choose Change user sign-in, enter global admin credentials and then select Pass-through authentication -> Next.

Note: Enabling pass-through authentication applies this method tenant wide. Meaning, for all custom domains under your tenant that are Managed, pass-through authentication will be used. Note that Federated domains can continue to use AD FS, or other third-party solutions.

Click Configure.

Click Exit.

This process will install the first Authentication Agent in your environment, which will sit alongside your AD Connect server. You can see the three new packages that have been installed via Programs and Features.

Navigate to your Azure portal -> Azure Active Directory -> Azure AD Connect and click on Pass-through authentication, which should show as being Enabled.

Here you will see a list of servers in your environment that are acting as Authentication Agents. You can also see the IP, status, and deploy more agents by downloading the agent software. Click Download.

Note: You can also directly download the agent software from https://aka.ms/getauthagent

Click Accept terms & download.

After downloading of the agent has complete, run the installer on your next elected Authentication Agent server.

Click Install.

Enter credentials to your tenant’s global administrator account and click Next.

Click Close to complete the install.

After a few moments, your new Authentication Agent server will show in the Azure AD portal.

The warning symbol will also dissapear in the Azure AD portal beside Pass-through authentication, because you now have high availability between your agents.

Troubleshooting:


There are a number of ways to troubleshoot pass-through authentication, such as:

  • Viewing event logs under Application and Services Logs -> Microsoft -> AzureAdConnect -> AuthenticationAgent -> Admin.
  • Viewing the status of agent servers from the Azure AD portal under Azure Active Directory -> AD Connect.
  • Checking AD Connect logs under %ProgramData%\AADConnect\trace-*.log for errors related to installation.
  • Checking detailed trace logs under %ProgramData%\Microsoft\Azure AD Connect Authentication Agent\Trace\.

8 Comments

  • Fabian

    September 25, 2019

    Hello.

    I do have a forest functional level in 2003. PTA is supported under this scenario?

    Regards,

    Reply
    • George Spiers

      September 29, 2019

      Yes.

      Reply
  • Fabian

    September 25, 2019

    Hello.

    I do have a forest functional level in 2003. PTA is supported under this scenario? –sorry if duplicated.

    Regards,

    Reply
  • Pingback: To keep using ADFS or not to keep using ADFS, that is the question | Modern Workplace Blog

  • Jack

    December 13, 2019

    Hey , just stumbled on this article and found it very helpful, great and concise so just what i was after.
    just a quick question with Password hash and how it compares with PTA – how does that affect password requirements such as password length, complexity, logon hours etc?

    Reply
  • Rick

    February 4, 2020

    Hello, I know this is an old article but it is very relevant and well written, Thank you very much for that! My company is currently running password hash sync only in Azure AD. One of my goals to to turn on PTA for several apps but mostly for O365 so users don’t have to manually enter their password a second time when they log into a new computer or change their domain password (Which is how I found this article). My biggest concern of course is the impact. While I know it will impact the entire tenant, will reconfiguring AD connect to use PTA cause any potential issue if the process and ad agent isn’t deployed out right away?

    Thank you for any advice.

    Reply
  • Pingback: Ask yourself if you still really need ADFS | Modern Workplace Blog

  • Eugen Wagner

    October 28, 2021

    Do you know, what happens if both agents are not available due to an Outtage? Is it possible to Log on to M365 Services if the Agents are not Reachable?

    Regards

    Reply

Leave a Reply