Azure Active Directory Pass-through Authentication: Frequently asked questions

This article addresses frequently asked questions about Azure Active Directory (Azure AD) Pass-through Authentication. Keep checking back for updated content.

Which of the methods to sign in to Azure AD, Pass-through Authentication, password hash synchronization, and Active Directory Federation Services (AD FS) should I choose?

Review this guide for a comparison of the various Azure AD sign-in methods and how to choose the right sign-in method for your organization.

Is Pass-through Authentication a free feature?

Pass-through Authentication is a free feature. You don't need any paid editions of Azure AD to use it.

Does Conditional Access work with Pass-through Authentication?

Yes. All Conditional Access capabilities, including Azure AD Multi-Factor Authentication, work with Pass-through Authentication.

Does Pass-through Authentication support "Alternate ID" as the username, instead of "userPrincipalName"?

Yes, sign-in using a non-UPN value, such as an alternate email, is supported for both pass-through authentication (PTA) and password hash sync (PHS). For more information about Alternate Login ID.

Does password hash synchronization act as a fallback to Pass-through Authentication?

No. Pass-through Authentication does not automatically failover to password hash synchronization. To avoid user sign-in failures, you should configure Pass-through Authentication for high availability.

What happens when I switch from password hash synchronization to Pass-through Authentication?

When you use Azure AD Connect to switch the sign-in method from password hash synchronization to Pass-through Authentication, Pass-through Authentication becomes the primary sign-in method for your users in managed domains. Please note that all users' password hashes which were previously synchronized by password hash synchronization remain stored on Azure AD.

Can I install an Azure AD Application Proxy connector on the same server as a Pass-through Authentication Agent?

Yes. The rebranded versions of the Pass-through Authentication Agent, version 1.5.193.0 or later, support this configuration.

What versions of Azure AD Connect and Pass-through Authentication Agent do you need?

For this feature to work, you need version 1.1.750.0 or later for Azure AD Connect and 1.5.193.0 or later for the Pass-through Authentication Agent. Install all the software on servers with Windows Server 2012 R2 or later.

Why is my connector still using an older version and not auto-upgraded to latest version?

This may be due to either the updater service not working correctly or if there are no new updates available that the service can install. The updater service is healthy if it’s running and there are no errors recorded in the event log (Applications and Services logs -> Microsoft -> AzureADConnect-Agent -> Updater -> Admin).

Only major versions are released for auto-upgrade. We recommend updating your Agent manually only if it's necessary. For example, you cannot wait for a major release, because you must fix a known problem or you want to use a new feature. For more information on new releases, the type of the release (download, auto-upgrade), bug fixes and new features see, Azure AD Pass-through Authentication agent: Version release history.

To manually upgrade a connector:

  • Download the latest version of the Agent. (You will find it under Azure AD connect Pass-through Authentication on the Azure portal. You can also find the link at Azure AD Pass-through Authentication: Version release history | Microsoft Docs..
  • The installer restarts the Microsoft Azure AD Connect Authentication Agent services. In some cases, a reboot of the server might be required if the installer cannot replace all files. Therefore we recommend closing all applications (i.e. Event Viewer) before you start the upgrade.
  • Run the installer. The upgrade process is quick and does not require providing any credentials and the Agent will not be re-registered.

What happens if my user's password has expired and they try to sign in by using Pass-through Authentication?

If you have configured password writeback for a specific user, and if the user signs in by using Pass-through Authentication, they can change or reset their passwords. The passwords are written back to on-premises Active Directory as expected.

If you have not configured password writeback for a specific user or if the user doesn't have a valid Azure AD license assigned, the user can't update their password in the cloud. They can't update their password, even if their password has expired. The user instead sees this message: "Your organization doesn't allow you to update your password on this site. Update it according to the method recommended by your organization, or ask your admin if you need help." The user or the administrator must reset their password in on-premises Active Directory.

The user logs on to Azure AD with his credentials (username, password). In the meantime the user’s password expires, but the user can still access Azure AD resources. Why does this happen?

The password expiry does not trigger the revocation of authentication tokens or cookies. Until the tokens or cookies are valid, the user will be able to use them. This applies regardless of the authentication type (PTA, PHS and federated scenarios).

For more details please check the documentation below: Microsoft identity platform access tokens - Microsoft identity platform | Microsoft Docs

How does Pass-through Authentication protect you against brute-force password attacks?

What do Pass-through Authentication Agents communicate over ports 80 and 443?

  • The Authentication Agents make HTTPS requests over port 443 for all feature operations.

  • The Authentication Agents make HTTP requests over port 80 to download the TLS/SSL certificate revocation lists (CRLs).

    Note

    Recent updates reduced the number of ports that the feature requires. If you have older versions of Azure AD Connect or the Authentication Agent, keep these ports open as well: 5671, 8080, 9090, 9091, 9350, 9352, and 10100-10120.

Can the Pass-through Authentication Agents communicate over an outbound web proxy server?

Yes. If Web Proxy Auto-Discovery (WPAD) is enabled in your on-premises environment, Authentication Agents automatically attempt to locate and use a web proxy server on the network.

If you don't have WPAD in your environment, you can add proxy information (as shown below) to allow a Pass-through Authentication Agent to communicate with Azure AD:

  • Configure proxy information in Internet Explorer before you install the Pass-through Authentication Agent on the server. This will allow you to complete the installation of the Authentication Agent, but it will still show up as Inactive on the Admin portal.
  • On the server, navigate to "C:\Program Files\Microsoft Azure AD Connect Authentication Agent".
  • Edit the "AzureADConnectAuthenticationAgentService" configuration file and add the following lines (replace "http://contosoproxy.com:8080" with your actual proxy address):
   <system.net>
      <defaultProxy enabled="true" useDefaultCredentials="true">
         <proxy
            usesystemdefault="true"
            proxyaddress="http://contosoproxy.com:8080"
            bypassonlocal="true"
         />
     </defaultProxy>
   </system.net>

Can I install two or more Pass-through Authentication Agents on the same server?

No, you can only install one Pass-through Authentication Agent on a single server. If you want to configure Pass-through Authentication for high availability, follow the instructions here.

Do I have to manually renew certificates used by Pass-through Authentication Agents?

The communication between each Pass-through Authentication Agent and Azure AD is secured using certificate-based authentication. These certificates are automatically renewed every few months by Azure AD. There is no need to manually renew these certificates. You can clean up older expired certificates as required.

How do I remove a Pass-through Authentication Agent?

As long as a Pass-through Authentication Agent is running, it remains active and continually handles user sign-in requests. If you want to uninstall an Authentication Agent, go to Control Panel -> Programs -> Programs and Features and uninstall both the Microsoft Azure AD Connect Authentication Agent and the Microsoft Azure AD Connect Agent Updater programs.

If you check the Pass-through Authentication blade on the Azure Active Directory admin center after completing the preceding step, you'll see the Authentication Agent showing as Inactive. This is expected. The Authentication Agent is automatically dropped from the list after 10 days.

I already use AD FS to sign in to Azure AD. How do I switch it to Pass-through Authentication?

If you are migrating from AD FS (or other federation technologies) to Pass-through Authentication, we highly recommend that you follow our detailed deployment guide published here.

Can I use Pass-through Authentication in a multi-forest Active Directory environment?

Yes. Multi-forest environments are supported if there are forest trusts (two-way) between your Active Directory forests and if name suffix routing is correctly configured.

Does Pass-through Authentication provide load balancing across multiple Authentication Agents?

No, installing multiple Pass-through Authentication Agents ensures only high availability. It does not provide deterministic load balancing between the Authentication Agents. Any Authentication Agent (at random) can process a particular user sign-in request.

How many Pass-through Authentication Agents do I need to install?

Installing multiple Pass-through Authentication Agents ensures high availability. But, it does not provide deterministic load balancing between the Authentication Agents.

Consider the peak and average load of sign-in requests that you expect to see on your tenant. As a benchmark, a single Authentication Agent can handle 300 to 400 authentications per second on a standard 4-core CPU, 16-GB RAM server.

To estimate network traffic, use the following sizing guidance:

  • Each request has a payload size of (0.5K + 1K * num_of_agents) bytes; i.e., data from Azure AD to the Authentication Agent. Here, "num_of_agents" indicates the number of Authentication Agents registered on your tenant.
  • Each response has a payload size of 1K bytes; i.e., data from the Authentication Agent to Azure AD.

For most customers, two or three Authentication Agents in total are sufficient for high availability and capacity. You should install Authentication Agents close to your domain controllers to improve sign-in latency.

Note

There is a system limit of 40 Authentication Agents per tenant.

Why do I need a cloud-only Global Administrator account to enable Pass-through Authentication?

It is recommended that you enable or disable Pass-through Authentication using a cloud-only Global Administrator account. Learn about adding a cloud-only Global Administrator account. Doing it this way ensures that you don't get locked out of your tenant.

How can I disable Pass-through Authentication?

Rerun the Azure AD Connect wizard and change the user sign-in method from Pass-through Authentication to another method. This change disables Pass-through Authentication on the tenant and uninstalls the Authentication Agent from the server. You must manually uninstall the Authentication Agents from the other servers.

What happens when I uninstall a Pass-through Authentication Agent?

If you uninstall a Pass-through Authentication Agent from a server, it causes the server to stop accepting sign-in requests. To avoid breaking the user sign-in capability on your tenant, ensure that you have another Authentication Agent running before you uninstall a Pass-through Authentication Agent.

I have an older tenant that was originally setup using AD FS. We recently migrated to PTA, but now are not seeing our UPN changes synchronizing to Azure AD. Why are our UPN changes not being synchronized?

Under the following circumstances your on-premises UPN changes might not synchronize if:

  • Your Azure AD tenant was created prior to June 15, 2015.
  • You initially were federated with your Azure AD tenant using AD FS for authentication.
  • You switched to having managed users using PTA as authentication.

This is because the default behavior of tenants created prior to June 15, 2015 was to block UPN changes. If you need to un-block UPN changes you need to run the following PowerShell cmdlet:

Set-MsolDirSyncFeature -Feature SynchronizeUpnForManagedUsers -Enable $True

Tenants created after June 15, 2015 have the default behavior of synchronizing UPN changes.

How do I capture the PTA Agent ID from Azure AD sign-in logs and the PTA server to validate which PTA server was used for a sign-in event?

To validate which local server or authentication agent was used for a specific sign-in event:

  1. In the Azure portal, go to the sign-in event.

  2. Select Authentication Details. In the Authentication Method Detail column, Agent ID details are shown in the format "Pass-through Authentication; PTA AgentId: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX".

  3. To get Agent ID details for the agent that's installed on your local server, log in to your local server and run following cmdlet:

    Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Azure AD Connect Agents\Azure AD Connect Authentication Agent' | Select *Instance*

    The GUID value that's returned is the Agent ID of the authentication agent that's installed on that specific server. If you have multiple agents in your environment, you can run this cmdlet on each agent server and capture the Agent ID details.

  4. Correlate the Agent ID that you get from the local server and from the Azure AD sign-in logs to validate which agent or server acknowledged the sign-request.

Next steps