Security details for Azure Active Directory Pass-through Authentication - Microsoft Entra (2023)

This article describes in more detail how Azure Active Directory (Azure AD) Pass-through Authentication works. It focuses on the security aspects of the feature. This article is intended for security and IT administrators, chief compliance and security officers, and other IT professionals responsible for IT security and compliance in an organization or enterprise of any size.

Topics covered include:

• Detailed technical information on the installation and registration of the authentication broker.
• Detailed technical information about password encryption during user login.
• Channel security between the on-premises authentication broker and Azure AD.
• Technical details on how to secure authentication proxy operations.

key pass-through authentication security features

Pass-through Authentication has the following key security features:

• It is built on a secure multi-tenant architecture that isolates login requests between tenants.
• Local passwords are never stored in the cloud in any form.
• Local authentication brokers that listen to and respond to password verification requests make outgoing calls only within your network. You don't need to be on a perimeter network (also known asdemilitarized zone,demilitarized zone, Ishielded subnet) As a best practice, treat all servers running authentication brokers as level 0 systems (seereference).
• Only standard ports (port 80 and port 443) are used for outbound communication from the authentication broker to Azure AD. There is no need to open incoming ports in the firewall.
  • Port 443 is used for all authenticated outbound communications.
  • Port 80 is only used for retrieving certificate revocation lists (CRLs) to ensure that none of the certificates used by this function have been revoked.
  • For a complete list of network requirements, seeQuickstart for Azure Active Directory Pass-through Authentication.
• Passwords provided by users at login are encrypted in the cloud before being accepted by the local authentication broker for authentication with Windows Server Active Directory (Windows Server AD).
• The HTTPS channel between Azure AD and the on-premises authentication broker is secured using mutual authentication.
• Pass-through authentication is passed usingAzure AD Conditional Access policiesincluding multi-factor authentication (MFA),Block legacy authentication, passFilter brute force attacks on passwords.

Components involved in pass-through authentication

For general information on Azure AD operations, services, and data security, seeTrust Center.When you use pass-through authentication for user login, the following components are involved:

• Azure AD Security Token Service (Azure AD STS): A stateless STS that handles login requests and issues security tokens to user, client, or service browsers as needed.
• Azure Service Bus: Provides cloud-based communications via enterprise messaging and push-through communications to help you connect your on-premises solutions to the cloud.
• Azure AD Connect authentication broker: a local component that listens for and responds to password verification requests.
• Azure SQL database: Stores information about tenant authentication brokers, including their metadata and encryption keys.
• windows server ad: local Active Directory where user accounts and passwords are stored.

Installation and registration of the authentication broker

The Authentication Broker is installed and registered with Azure AD when you do one of the following:

• Enable pass-through authentication with Azure AD Connect
• Add more authentication brokers to ensure high availability of login requests

Launching the Authentication Broker includes three main phases:

• install
• register
• initialization

The following sections discuss these phases in detail.

Authentication broker installation

Only a hybrid administrator account can install the Authentication Broker on an on-premises server (using Azure AD Connect or a standalone instance).

Install adds two new entries to the listcontrol panel>program>Programs and functions:

• The authentication broker application itself. This app worksInternet serviceprivilege.
• An updater application to automatically update authentication brokers. This app workslocal systemprivilege.

Authentication agent registration

After the Authentication Agent is installed, it registers with Azure AD. Azure AD assigns each authentication broker a unique digital identity certificate that they can use to securely communicate with Azure AD.

The registration process also binds the authentication broker to the tenant. Azure AD then knows that this particular authentication proxy is the only one authorized to handle password verification requests for your tenant. Repeat this process for each new captive agent registered.

The Authentication Broker registers with Azure AD by doing the following:

1. Azure AD first requests the hybrid admin to sign in to Azure AD with their credentials. At login, the Authentication Broker obtains an access token that it can use on behalf of the user.
2. The authentication broker then generates a public key and a private key pair.
   • Key pairs are generated using standard RSA 2048-bit encryption.
   • The private key is stored on the local server where the authentication broker is located.
3. The authentication broker sends a registration request to Azure AD over HTTPS with the following components:
   • The access token obtained by the proxy server.
   • Generated public key.
   • Certificate signing request (Corporate Social ResponsibilityLubcertificate applicationThis request requests a digital identity certificate with Azure AD as the Certificate Authority (CA).
4. Azure AD verifies the access token in the registration request and verifies that the request is from a hybrid identity administrator.
5. Azure AD then signs the digital identity certificate and sends it back to the authentication broker.

   • The root CA in Azure AD is used to sign the certificate.

     notes

     This CA isNOIn the Windows Trusted Root Certification Authorities store.

     See Also

     Azure AD Connect: Configure preferred data locations for your Microsoft 365 - Microsoft Entra resourcesAzure AD Connect: Troubleshoot pass-through authentication - Microsoft EntraWhat is Azure AD Connect version 2.0? - Microsoft PortalTotal Identity Compromise: Microsoft's Incident Response Course on Securing Active Directory

   • The CA is only used by Pass-through Authentication. The CA is only used to sign the CSR when registering the authentication broker.

   • No other Azure AD services use this CA.

   • Certificate subject (also known asThe correct nameLubDN) to the tenant ID. This distinguished name is a GUID that uniquely identifies the tenant. This distinguished name restricts the certificate to your tenant only.

6. Azure AD stores the authentication agent's public key in a database in Azure SQL Database. Only Azure AD can access the database.
7. The issued certificates are stored in the Windows certificate store on the local server (in particular, inCERT_SYSTEM_STORE_LOCAL_MACHINE) This certificate is used by the Authentication Agent and Updater application.

Authentication broker initialization

When the Authentication Broker first starts after registration or after a server restart, it needs a way to securely communicate with Azure AD before it can start accepting password verification requests.

Here's how the authentication broker is initialized:

1. The authentication broker sends an outbound bootstrap request to Azure AD.

   This request is sent over port 443 and a mutually authenticated HTTPS channel. The request uses the same certificate that was issued during Authentication Broker registration.

2. Azure AD responds to the request by providing a Service Bus queue access key that is unique to your tenant and identified by your tenant ID.

3. The authentication broker establishes a persistent outgoing HTTPS connection (over port 443) to the queue.

The authentication broker is now ready to retrieve and process password authentication requests.

If you have multiple authentication brokers registered in your tenant, the initialization process ensures that each broker connects to the same Service Bus queue.

How pass-through authentication handles sign-in requests

The following diagram shows how Pass-through Authentication handles user login requests:

How pass-through authentication handles user logon requests:

1. The user tries to access the application, e.g.Outlook web app.

2. If the user is not already signed in, the app will redirect the browser to the Azure AD sign-in page.

3. Azure AD STS responseUser loginSide.

4. user wUser loginpage and selectNextbutton.

5. user wUser loginpage and selectLog inbutton.

6. The username and password are sent to Azure AD STS in the HTTPS POST request.

7. Azure AD STS retrieves the public keys of all authentication brokers registered in your tenant from Azure SQL Database and encrypts passwords with these keys.

   See Also

   How to join QNAP NAS to Microsoft Active Directory (AD)?Managed Instance - List - REST API (Azure SQL Database)Managed Instance - List by Resource Group - REST API (Azure SQL Database)

   Generates an encrypted password value for each authentication broker registered in your tenant.

8. Azure AD STS places password authentication requests (containing username and encrypted password values) in a Service Bus queue specific to your tenant.

9. Because the initialized authentication broker is hard-wired to the Service Bus queue, one of the available authentication brokers retrieves the password authentication request.

10. The ID is used by the authentication broker to locate the encrypted cryptographic value specific to its public key. It decrypts the public key with its own private key.

11. The authentication broker tries to authenticate the username and password using Windows Server ADWin32 User Login APIIdw login typeparameter is set toLOGON32_LOGON_NETWORK.

    • This is the same API that Active Directory Federation Services (AD FS) uses to sign in users in a federated sign-in scenario.
    • This API relies on the standard Windows Server resolution process to locate domain controllers.

12. The authentication broker receives results from Windows Server AD, such as success, invalid username or password, or expired password.

    notes

    If the authentication agent fails during the logon process, the entire logon request will be rejected. Login requests are not forwarded from one local authentication broker to another. These agents only communicate with the cloud and not with each other.

13. The authentication proxy forwards the results back to Azure AD STS via the outbound mutual authentication HTTPS channel on port 443. Mutual authentication uses certificates issued to the authentication broker during registration.

14. Azure AD STS checks that this result is associated with the specified tenant login request.

15. Azure AD STS continues the configured sign-in process. For example, the user may be prompted for an MFA or redirected back to the app if the password verification is successful.

Authentication broker operational security

To ensure Pass-through Authentication remains operationally secure, Azure AD periodically renews Authentication Broker certificates. Azure AD triggers renewal. Renewals are not related to the authentication broker itself.

Update the Azure AD Authentication Broker trust:

1. The authentication broker pings Azure AD every few hours to see if it's time to renew the certificate. Certificates are renewed 30 days before expiration.

   This check is done over a mutually authenticated HTTPS channel and uses the same certificate issued during registration.

2. If the service indicates that an update is required, Authentication Broker generates a new key pair: a public key and a private key.

   • These keys are generated using standard RSA 2048-bit encryption.
   • Private keys never leave the local server.

3. The authentication broker then sends a certificate renewal request to Azure AD over HTTPS. The request contains the following elements:

   • An existing certificate retrieved from CERT_SYSTEM_STORE_LOCAL_MACHINE in the Windows certificate store. No global administrator is involved in this process, so global administrators do not need an access token.
   • The public key generated in step 2.
   • corporate social responsibility. This request requests a new digital identity certificate with Azure AD as the CA.

4. Azure AD checks the existing certificate in the certificate renewal request. It then checks that the request is from an authentication broker registered with the tenant.

5. If the existing certificate is still valid, Azure AD signs the new digital identity certificate and sends the new certificate back to the authentication broker.

6. Azure AD removes the authentication broker from the list of registered tenant authentication brokers if the existing certificate has expired. The global or hybrid admin must then manually install and register a new Authentication Broker.

   • Use the Azure AD root CA to sign the certificate.
   • Set the certificate DN to Tenant ID, which is a GUID that uniquely identifies your tenant. The distinguished name restricts the certificate to your tenant only.

7. Azure AD stores the authentication agent's new public key in a database in Azure SQL Database that only it has access to. It also invalidates the old public key associated with the authentication broker.

8. The new certificate (issued in step 5) is then stored in the Windows certificate store on the server (specifically inCERT_SYSTEM_STORE_CURRENT_USERPlace).

   Because the trust update process is non-interactive (there are no global or hybrid administrators), the Authentication Broker no longer has permission to update existing certificates in the CERT_SYSTEM_STORE_LOCAL_MACHINE location.

   notes

   This procedure does not remove the certificate itself from the CERT_SYSTEM_STORE_LOCAL_MACHINE location.

9. From then on, new certificates are used for authentication. Each subsequent renewal of the certificate replaces the certificate in the CERT_SYSTEM_STORE_LOCAL_MACHINE location.

Automatic authentication broker updates

The Updater application automatically updates the Authentication Broker when a new version is released (bug fixes or performance improvements). Updater doesn't support any password verification requests for your tenant.

Azure AD supports the new version of the software as a signed Windows Installer (MSI) package. MSI is signed usingMicrosoft verification codeUse SHA-256 as the hash algorithm.

Automatically update the authentication proxy:

1. The updater pings Azure AD every hour to check for a new version of the Authentication Broker.

   This check is done over a mutually authenticated HTTPS channel using the same certificate issued during registration. The authentication broker and updater provide certificates stored on the server.

2. If a new version is available, Azure AD returns the signed MSI to the updater.

3. The updater checks that the MSI file is signed by Microsoft.

4. The updater runs the MSI file. During this process, the Updater application:

   notes

   The updater workslocal systemprivilege.

   1. Stop the Authentication Broker service.
   2. Install the new version of Authentication Broker on the server.
   3. Restart the Authentication Broker service.

next step

• current limit: Find out which scenarios are supported.
• quick start: Configure Azure AD pass-through authentication.
• Migrating from AD FS to Pass-through Authentication: Refer to this step-by-step guide to help you migrate from AD FS or other federated technologies to Pass-through Authentication.
• smart lock: Set up Smart Lock on your tenant to secure user accounts.
• how it's working: Understand the basics of how Azure AD Pass-through Authentication works.
• Frequently asked questions: Find answers to frequently asked questions.
• Troubleshooting: Learn how to troubleshoot common Pass-through Authentication issues.
• Seamless single sign-on to Azure AD: Learn more about the complementary Azure AD feature, Seamless SSO.