What Does Pass-through authentication Mean?
This page mentions older exam versions. See the Current Exam Context and Legacy Exam Context sections below for the updated mapping.
On This Page
Quick Definition
Pass-through authentication lets you use your existing on-premises usernames and passwords to sign in to Microsoft cloud services like Office 365. When you type your password, it is sent directly to your company's local server for validation, not stored in the cloud. This means your passwords never leave your own network, making it a good choice for security-conscious organizations. It works alongside password synchronization as an alternative authentication method.
Commonly Confused With
Password hash synchronization stores a cryptographic hash of the user's on-premises password in Azure AD, which allows Azure AD to validate credentials directly. Pass-through authentication does not store any password material in the cloud. Password hash sync is simpler to deploy, does not require on-premises agents, and provides a fallback authentication method if on-premises servers are unreachable. However, it stores password hashes in the cloud, which may violate some compliance policies.
A company that wants to avoid any password data in the cloud chooses PTA. A company that wants the simplest setup with automatic fallback during an outage chooses password hash sync.
AD FS is a full-federation identity solution that allows users to sign in to cloud applications using on-premises credentials. It uses claims-based authentication and can integrate with non-Microsoft identity providers. Pass-through authentication is simpler, requires less infrastructure, and is easier to configure. AD FS is typically chosen when an organization needs to support smart card authentication, SAML 2.0 protocols, or complex claims rules. PTA is better when simplicity and avoiding password storage are the main goals.
A government agency that needs smart card authentication for all users would use AD FS. A small business that just wants to use existing passwords for Office 365 would use PTA.
Seamless SSO is not an authentication method itself; it is a feature that provides automatic sign-on to Azure AD for users on domain-joined devices within the corporate network. When Seamless SSO is enabled, users are not prompted for passwords. Pass-through authentication is a method of validating passwords against on-premises AD. They serve different purposes and are often used together: PTA handles password validation, while Seamless SSO handles automatic sign-in.
A user logs into their domain-joined work PC at the office and opens Outlook. Seamless SSO automatically signs them into Office 365 without a password prompt, while PTA checks the password in the background for the initial sign-in to the device.
Must Know for Exams
Pass-through authentication is a core objective in several Microsoft certification exams, particularly those focused on hybrid identity and Microsoft 365 administration. The most relevant exams are MS-100 (Microsoft 365 Identity and Services) and MS-101 (Microsoft 365 Mobility and Security), where PTA appears under the Identity and Authentication section. In these exams, you are expected to understand the authentication flow, the role of the Authentication Agent, and how PTA compares to password hash synchronization and Active Directory Federation Services (AD FS). Typically, you will be given a scenario describing an organization's security requirements, compliance needs, or existing infrastructure, and you must select the appropriate authentication method. For example, if a scenario says the company cannot store password hashes in the cloud due to regulatory reasons, PTA is often the correct choice.
In the AZ-800 (Administering Windows Server Hybrid Core Infrastructure) and AZ-801 (Configuring Windows Server Hybrid Advanced Services) exams, PTA is covered in the context of integrating on-premises Active Directory with Azure AD. These exams test your ability to deploy and manage the Authentication Agent, configure Azure AD Connect for PTA, and troubleshoot common issues like agent connectivity failures or certificate expiration. You may encounter questions that ask which ports must be open, how many agents are needed for high availability, or what happens if all agents are unavailable.
Outside of Microsoft exams, PTA appears in general IT certification exams like CompTIA Cloud+ (CV0-003) under the objective 'Identity and Access Management' and in the Certified Cloud Security Professional (CCSP) by (ISC)² when discussing authentication federation and cloud identity management. These exams are less likely to require granular technical details but expect a conceptual understanding of how on-premises authentication can be extended to the cloud without exposing credentials.
Exam questions about PTA typically fall into three categories. The first is design scenario questions where you choose between PTA, password hash sync, federation, or cloud-only accounts based on business requirements. The second is configuration questions where you need to know the correct Azure AD Connect settings to enable PTA and specify the number of agents required. The third is troubleshooting questions where you diagnose why PTA is failing in a given topology, such as a blocked port or a missing certificate.
One exam trap to watch for is confusing pass-through authentication with seamless single sign-on (Seamless SSO). They often work together and are mentioned in the same exam objectives, but they are distinct features. PTA handles password validation, while Seamless SSO provides automatic sign-on for domain-joined devices. Another common trap is thinking that PTA requires inbound firewall rules; it actually requires only outbound connections from the agents. Also, remember that PTA does not support all Azure AD scenarios, such as device registration for Windows Hello for Business without additional configuration.
To succeed in exams, focus on memorizing the authentication flow, the number of agents needed (minimum 2 for production), the protocols used (NTLM/Kerberos), the ports required (outbound 443 to Azure, LAN ports 445 and 135 to domain controllers), and the limitations (no smart card, no password hash storage). Being able to quickly differentiate PTA from other methods by reading scenario clues will help you answer questions correctly.
Simple Meaning
Think of pass-through authentication like having a security guard at your office building who checks your ID against a physical list of employees kept at the front desk. Instead of making a copy of your ID and storing it somewhere else, the guard just looks at the original list every time you come in. That is exactly what pass-through authentication does for your passwords when you access Microsoft cloud services.
Imagine you work for a company that uses Office 365 in the cloud but keeps all employee accounts on a local server in the basement. Without pass-through authentication, your password would need to be copied to the cloud so Microsoft can check it when you log in. With pass-through authentication, your password always stays on your company's local server. When you type your password into the Office 365 login page, it is sent securely to a small agent on your company's network, which then checks it against your local Active Directory. The cloud never learns what your password is.
This is especially useful for companies that have strict security policies about not storing passwords outside their own network. It is also helpful during migrations, because users can keep using their existing local passwords without any changes. The authentication agent acts like a trusted messenger that shuffles back and forth between the cloud and your on-premises server, always carrying your password request but never leaving a copy behind.
One important thing to understand is that pass-through authentication is a feature of Azure Active Directory (Azure AD). It is one of four main ways Microsoft lets you connect your local user accounts to cloud services. The other options are password hash synchronization, federation services (like AD FS), and seamless single sign-on. Pass-through authentication is often chosen when an organization wants the simplicity of cloud apps but cannot or will not store password hashes in the cloud due to compliance, regulatory, or security reasons.
Full Technical Definition
Pass-through authentication (PTA) is an Azure Active Directory authentication method that validates user credentials against on-premises Active Directory (AD) without storing any password hashes in Azure AD. It is part of Microsoft's hybrid identity solutions, allowing organizations to extend their on-premises identity infrastructure to cloud-based services such as Microsoft 365, Azure AD-integrated applications, and other SaaS offerings.
When a user attempts to sign into an Azure AD-protected resource, the authentication flow proceeds as follows. The user enters their User Principal Name (UPN) and password on the Microsoft sign-in page, for example at login.microsoftonline.com. Azure AD receives this request and, because the tenant is configured for pass-through authentication, Azure AD does not attempt to validate the password locally. Instead, it encrypts the password using the public key of the on-premises Authentication Agent and places the encrypted credential onto a queue within the Azure Service Bus, a reliable messaging infrastructure.
An on-premises Authentication Agent, which is a lightweight software component installed on a Windows server inside the organization's network, constantly polls the Azure Service Bus for pending authentication requests. When the agent retrieves a request, it decrypts the password using its own private key. The agent then validates the username and password against the on-premises Active Directory using standard Windows API calls, specifically the LogonUser function. This function verifies the password against the local AD domain controller using the NTLM or Kerberos authentication protocols, depending on domain configuration. The result, a success or failure response, is sent back to Azure AD via the same Service Bus queue. Azure AD then either grants or denies access to the requested resource.
To ensure high availability and fault tolerance, organizations are required to install at least two Authentication Agents. These agents register independently with Azure AD and each can handle requests. If one agent goes offline, the remaining agents continue processing authentication requests seamlessly. The agents do not require any inbound firewall rules because they only make outbound connections to Azure over HTTPS on port 443. They communicate with a defined set of Azure datacenter IP ranges which are documented by Microsoft.
Several key protocols and standards support PTA. The encryption uses RSA 2048-bit keys for the initial exchange and AES-256 for the actual password payload. Communication between the agent and Azure AD is secured by TLS 1.2. The agent must have network access to the on-premises domain controllers on port 445 (SMB) and port 135 (RPC) for authentication operations. The agent requires access to a local SQL Server database (SQL Server Express is installed by default) which caches credentials for resilience and performance.
Pass-through authentication does not require any changes to the on-premises Active Directory schema. It works with any on-premises AD domain that is at the Windows Server 2008 or later functional level. User accounts can be synchronized from on-premises AD to Azure AD using Azure AD Connect, but PTA specifically bypasses the password hash synchronization step. Password writeback can be configured alongside PTA to allow users to reset their passwords from the cloud, though this is a separate feature.
One important technical consideration is that PTA is not supported for users who have been configured for smart card authentication or certificate-based authentication in on-premises AD. PTA does not support sign-in with only a UPN suffix that is not verified in Azure AD. For organizations that require seamless single sign-on on domain-joined devices, PTA can be combined with Azure AD Seamless SSO, which uses Kerberos delegation to automatically authenticate users when they are on the corporate network.
Real-Life Example
Think about using a hotel key card to access your room. When you check in, the front desk gives you a card that has a special code written on it. That code matches what the hotel's central computer knows about your room. Every time you swipe your card at the door, the lock checks the code against the hotel's central system. If the code matches, the door opens. Now imagine that instead of storing all the codes in a central computer somewhere offsite, the hotel decides to keep a physical binder at the front desk with every guest's code written on paper. When you swipe your card, the door lock sends a message to the front desk, a receptionist finds your code in the binder, and confirms it matches. The door then opens. The lock never learns your actual code.
This is exactly how pass-through authentication works. The hotel is your company, the guest codes are user passwords, the central computer is your on-premises Active Directory server, and the offsite system is the Microsoft cloud. With pass-through authentication, your password is never stored in the cloud. The cloud sends your password request to an on-premises agent (the receptionist), which checks it against the local directory (the binder) and sends back a yes or no answer.
Another analogy is a bouncer at a club who has a printed list of VIP guests. Instead of memorizing every name or making a copy of the list, the bouncer uses a walkie-talkie to call a manager inside who checks a master list physically stored in the office. The bouncer only knows if the person is on the list, never sees the full list themselves. Similarly, the Microsoft cloud only learns whether your password is correct, never what the actual password is. This gives organizations peace of mind that their most sensitive credential data remains under their own control.
Why This Term Matters
For IT professionals, understanding pass-through authentication is critical because it directly addresses a fundamental tension in modern identity management: the need to move to cloud services while maintaining strict control over credential data. Many organizations operate in regulated industries such as finance, healthcare, or government, where compliance frameworks like PCI-DSS, HIPAA, or GDPR explicitly restrict where and how user passwords can be stored. Pass-through authentication offers a pragmatic bridge because it allows these organizations to use Microsoft 365 and other cloud applications without copying password hashes to the cloud, thus staying compliant.
From a security perspective, PTA reduces the attack surface in several ways. Because no password hashes are stored in Azure AD, a breach of Microsoft's cloud infrastructure would not expose credential data that could be used for on-premises lateral movement. Even if an attacker gains access to Azure AD, they cannot extract password hashes. PTA allows organizations to enforce their on-premises password policies, account lockout policies, and logon hour restrictions directly during cloud sign-in. Changes made to an account in on-premises AD, such as disabling a user, take effect immediately for cloud access because each authentication request is validated live.
Operationally, PTA simplifies the user experience. Users continue signing in with the same passwords they use for domain logon. There is no need to resync passwords or require users to remember a separate cloud password. This reduces help desk calls related to password resets and account lockouts. The authentication agents are lightweight and do not require significant hardware resources. A standard Windows Server VM with 4 GB of RAM and two CPU cores can comfortably run multiple agents for redundancy.
However, PTA is not without trade-offs. It introduces a dependency on network connectivity between the authentication agents, Azure, and on-premises domain controllers. If the agents lose connectivity to the on-premises domain controllers, cloud authentication fails. Similarly, if the agents cannot reach Azure, no cloud sign-ins are possible. Organizations must plan for agent redundancy and monitor agent health. Microsoft provides health monitoring via the Azure AD Connect portal, and alerts can be configured for agent downtime.
For exam purposes, pass-through authentication is a frequently tested concept in identity-related sections of Microsoft certifications such as MS-100, MS-101, AZ-800, and AZ-801. It also appears in general IT certification exams like CompTIA Cloud+ when discussing hybrid identity models. Understanding when to choose PTA versus password hash sync or federation is a common exam objective. The key factors are security requirements (password hash storage), user experience (SSO integration), and infrastructure complexity (on-premises servers needed for PTA).
How It Appears in Exam Questions
In certification exams, questions about pass-through authentication often begin with a scenario that describes an organization's identity requirements. A typical scenario question might read: 'Contoso Ltd. is a financial services company that is migrating to Microsoft 365. The company has a strict security policy that prohibits storing password hashes in the cloud due to regulatory compliance. Users currently sign in to on-premises applications using Active Directory. You need to choose an authentication method that meets the compliance requirement and provides a seamless sign-in experience for cloud apps.' The correct answer in this scenario is pass-through authentication, because it does not store password hashes in Azure AD and allows users to use their existing passwords.
Another common question pattern is configuration-focused: 'You are deploying Azure AD Connect for a hybrid identity environment. You have installed the Authentication Agent on a single server. What should you do to ensure high availability for pass-through authentication?' The correct answer is to install at least one additional Authentication Agent on a separate server. The exam may also ask about the minimum number of agents required for production, which is two.
Troubleshooting questions often present a symptom such as: 'After configuring pass-through authentication, users report that they cannot sign in to Microsoft 365. The Authentication Agent is running, and network connectivity to Azure is confirmed. What is the most likely cause?' The answer could involve the agent not being able to reach the domain controller because port 445 is blocked, or the agent's certificate has expired. Another troubleshooting scenario: 'Users can sign in from within the office network but fail when connecting from external networks. You verify that Azure AD Connect is configured correctly and agents are healthy. What is missing?' In this case, the answer is that Seamless SSO is not configured, and users outside the domain cannot benefit from Kerberos delegation-they need to enter credentials manually, which should still work. If external access fails completely, the issue might be a firewall blocking the agent's outbound connection to Azure.
Some questions test the boundaries of PTA: 'A company uses pass-through authentication. They want to enable password reset from the cloud. What additional feature must be configured?' The answer is password writeback. 'Can pass-through authentication be used together with password hash synchronization?' The answer is yes, password hash sync can be enabled as a backup, but it is not required.
Exam questions may also present deceptive options that confuse PTA with federation. A common trap is offering 'Active Directory Federation Services (AD FS)' as an answer when the scenario does not require claims-based authentication or third-party identity provider support. AD FS is more complex and appropriate when you need to integrate with non-Microsoft identity providers or use smart cards. PTA is simpler and does not require the additional infrastructure of AD FS.
Finally, remember that exam objectives often group PTA under 'Hybrid Identity' or 'Authentication Methods' and expect you to know the pros and cons of each method. Practice by creating a comparison table in your mind: PTA (no password in cloud, requires agents, low complexity), password hash sync (passwords stored as hash in cloud, no agents, high availability with synchronization), AD FS (full federation, highest complexity, supports third-party IdPs, requires on-premises infrastructure). Questions that ask 'which method provides the strongest security for passwords?' often have PTA as the answer because passwords are never stored in the cloud.
Practise Pass-through authentication Questions
Test your understanding with exam-style practice questions.
Example Scenario
You work for a medium-sized company called GreenLeaf Enterprises. The company has 500 employees and uses Microsoft 365 for email and collaboration. The IT department wants to allow employees to use their existing domain username and password to access cloud services, but the company's security policy explicitly prohibits storing any password data outside the corporate network. The IT manager has heard about pass-through authentication and decides to implement it.
First, the IT team uses Azure AD Connect to synchronize all user accounts from the on-premises Active Directory to Azure AD. During the configuration, they select the pass-through authentication option instead of password hash synchronization. They leave password hash sync disabled because the security policy forbids it. Azure AD Connect automatically installs the first Authentication Agent on the same server where the tool is running. The team then installs a second Authentication Agent on a different server in a separate datacenter to ensure high availability.
Next, they configure the firewall to allow the Authentication Agents to make outbound HTTPS connections to Azure on port 443. They also ensure the agents can communicate with their domain controllers on the local network using ports 445 (SMB) and 135 (RPC). The domain controllers are running Windows Server 2019 and the Active Directory functional level is Windows Server 2016.
After the initial setup, the team tests the configuration. Sarah, a sales representative, opens her laptop at the office and navigates to the Microsoft 365 login page. She enters her username (sarah@greenleaf.com) and her usual domain password. The authentication request goes to Azure AD, which forwards the encrypted password to the Authentication Agent. The agent decrypts the password and validates it against the on-premises domain controller using NTLM. The domain controller confirms the password is correct, and the agent sends back a success response. Sarah is now signed in to Microsoft 365. She notices no difference in the login process compared to before.
The next day, one of the Authentication Agent servers experiences a hardware failure and goes offline. The second agent, running in another location, automatically picks up all authentication requests. Users continue to sign in without interruption. The IT team receives an alert from the Azure AD Connect health portal and replaces the failed server within four hours.
Later, a remote employee tries to sign in from a home computer. The same PTA flow occurs. The agent decrypts the password and checks it against the domain controller. Because the domain controller is reachable through the VPN into the corporate network, the authentication succeeds. If the VPN were down, the agent would still be able to contact the domain controller as long as the agent's network path to the domain controller is open. However, if the employee's home network has no VPN access, they could still sign in if the organization has configured a DirectAccess or an always-on VPN to maintain connectivity between the agent and the domain controller.
If the organization later decides to allow users to reset their own passwords from the cloud, they would simply enable the password writeback feature in Azure AD Connect. This would allow password changes made in Azure AD to be written back to the on-premises Active Directory, but the actual authentication would still happen via PTA against the on-premises directory.
Common Mistakes
Assuming pass-through authentication stores password hashes in Azure AD as a backup.
Pass-through authentication explicitly does not store any password hashes in Azure AD. The authentication is validated live against on-premises Active Directory. If you want a backup in case of network failure, you must enable password hash synchronization separately.
Understand that PTA uses a pass-through model, not a store-and-validate model. If cloud authentication needs to work during an on-premises outage, enable password hash sync as a complementary fallback method.
Thinking that pass-through authentication requires inbound firewall ports.
The Authentication Agent only makes outbound connections to Azure on port 443. Azure does not initiate connections to the agent. No inbound ports are required, which reduces the attack surface.
Remember that the agent is a client that polls Azure. It pulls authentication requests from a queue. There is no need to open any inbound firewall rules for the agent.
Believing that a single Authentication Agent is sufficient for production.
A single agent creates a single point of failure. If that agent goes down, no cloud authentication is possible. Microsoft recommends a minimum of two agents for high availability, and three or more for larger environments.
Always plan for redundancy. Install at least two Authentication Agents on separate servers, preferably in different locations or Availability Zones.
Confusing pass-through authentication with seamless single sign-on (Seamless SSO).
PTA is a password validation method that checks credentials against on-premises AD. Seamless SSO is a feature that automatically logs users into Azure AD when they are on a domain-joined device and connected to the corporate network, without prompting for credentials. They can work together but serve different purposes.
Memorize that PTA is about how passwords are validated, while Seamless SSO is about automatic sign-in. They are separate toggles in Azure AD Connect.
Thinking that pass-through authentication works with all Azure AD features out of the box.
Some Azure AD features, such as Windows Hello for Business device registration and Azure AD join for hybrid devices, have specific requirements when using PTA. For example, hybrid Azure AD join may require additional configuration like setting up a service connection point (SCP) in Active Directory.
Always verify feature compatibility when planning an identity solution. Check Microsoft documentation for each scenario, as PTA may impose additional prerequisites for certain features.
Exam Trap — Don't Get Fooled
{"trap":"The exam presents a scenario where an organization wants to avoid storing passwords in the cloud for compliance reasons and also wants to provide automatic sign-in for users on domain-joined devices. The options include pass-through authentication, password hash synchronization, federation services, and Seamless SSO alone. Learners often choose 'pass-through authentication with Seamless SSO' but incorrectly think that Seamless SSO alone is enough, or they choose 'federation services' because it seems more comprehensive."
,"why_learners_choose_it":"Learners see the requirement for no password storage in the cloud and immediately think of PTA, but they also see the requirement for automatic sign-in and assume that PTA alone provides that. They may confuse Seamless SSO as a required companion to PTA for automatic sign-in, which is actually correct. However, they might also mistakenly choose federation services because they associate it with single sign-on, not realizing the complexity is unnecessary.
Another mistake is selecting password hash synchronization because they think it includes SSO features, but it stores hashes in the cloud.","how_to_avoid_it":"Break down the question into two distinct requirements: authentication method (no password storage) and seamless sign-on experience. For authentication, PTA is the only method that does not store any password data in Azure AD.
For seamless sign-on, Seamless SSO must be enabled alongside PTA. Learn that Seamless SSO is a separate feature that works with both PTA and password hash sync. Federation services are overkill unless the organization needs claims-based authentication or third-party IdP integration.
Always match each requirement to the specific feature, not to the whole solution."
Step-by-Step Breakdown
User initiates sign-in
The user enters their User Principal Name (UPN) and password on an Azure AD sign-in page, such as the Microsoft 365 login screen. This triggers an authentication request that is sent to Azure AD over HTTPS.
Azure AD identifies tenant configuration
Azure AD checks the tenant's authentication methods. If pass-through authentication is enabled, Azure AD knows not to validate the password locally. Instead, it prepares to forward the request to the on-premises environment. This prevents the need for password hash storage.
Password is encrypted and queued
Azure AD encrypts the user's password using the public key of the on-premises Authentication Agent. The encrypted credential is placed into a queue within the Azure Service Bus, which is a reliable messaging service. This ensures the request is not lost even if the agent is temporarily busy or offline.
Authentication Agent retrieves the request
The Authentication Agent, installed on a Windows server in the company's network, regularly polls the Azure Service Bus via an outbound HTTPS connection. The agent picks up the encrypted request and uses its private key to decrypt the password. The agent never stores the password after use.
Agent validates password against on-premises AD
The agent calls the Windows LogonUser API, which sends the credentials to a domain controller using NTLM or Kerberos protocols. The domain controller checks the username and password against its Active Directory database and returns a status of success or failure.
Response is sent back to Azure AD
The agent sends the authentication result (success or failure) back to Azure AD through the same Service Bus queue. Azure AD receives the response and either grants or denies the user access to the requested cloud resource. The user sees the appropriate sign-in outcome.
Failover and redundancy handling
If one Authentication Agent is unavailable, other registered agents pick up the pending requests from the queue. Azure AD distributes authentication requests among healthy agents. This ensures continuous service even during agent maintenance or failure. Administrators can monitor agent health in the Azure AD Connect portal.
Practical Mini-Lesson
To implement pass-through authentication in a real-world environment, you start by ensuring your infrastructure meets the prerequisites. You need an Azure AD tenant, Azure AD Connect installed on a server that can reach the internet, and at least one domain controller running Windows Server 2008 or later. The Authentication Agent requires Windows Server 2012 R2 or newer, .NET Framework 4.6.1 or higher, and network connectivity. You also need a global administrator account in Azure AD and an Enterprise Admin account in on-premises AD for configuration.
When you run Azure AD Connect, you choose the Custom Installation option to select pass-through authentication. During the process, Azure AD Connect installs the first Authentication Agent on the same server. After the installation completes, you should immediately install additional agents. You download the agent installer from the Azure AD Connect portal, which is a separate MSI file for the agent. Install it on other servers, preferably in different physical locations or Availability Zones. Each agent registers itself with Azure AD using credentials from a global administrator account.
Once agents are running, you need to monitor them regularly. The Azure AD Connect Health portal provides a dashboard showing agent status, authentication latency, and error events. You can set up alerts for when agents go offline or when authentication failure rates exceed a threshold. A common operational task is renewing the agent's certificates. Each agent has a certificate that expires after a certain period. The agent automatically attempts to renew the certificate when it is about to expire, but if the renewal fails due to network issues, you may need to manually reinstall the agent.
In practice, pass-through authentication works well for organizations with stable on-premises Active Directory and reliable network connectivity. However, one significant risk is a complete network outage that disconnects all agents from Azure. In that case, users cannot sign in to any Azure AD-integrated cloud applications. To mitigate this, many organizations enable password hash synchronization as a fallback, even if their primary policy prefers not to store hashes. This can be configured in Azure AD Connect by enabling 'password hash synchronization' alongside 'pass-through authentication.' Azure AD will then have the password hashes available, and if PTA fails, the fallback method auto-activates for the same users. The trade-off is that password hashes are stored in Azure AD, which may conflict with strict regulatory requirements.
Troubleshooting common PTA issues involves checking the following: ensure the Authentication Agent service is started (the service name is 'Azure AD Connect Authentication Agent'), verify that outbound connectivity to *.servicebus.windows.net on port 443 works from the agent server, confirm that the agent can access domain controllers on ports 445 and 135, and check the event logs on the agent server for errors from the source 'Azure AD Connect Authentication Agent.' If authentication fails, test directly on the agent server using the LogonUser API or a tool like 'runas' to ensure domain authentication itself is working. Also, verify that the user account is synchronized to Azure AD and that the UPN is correctly configured in both on-premises AD and Azure AD.
A practical configuration tip: if your organization uses multiple UPN suffixes, you must add each verified domain to Azure AD. Users with unverified UPN suffixes will not be able to authenticate via PTA. Do not configure the agent on a domain controller itself, as this can cause performance issues and security concerns. Dedicate a separate member server for each agent.
Finally, remember that PTA does not support modern authentication scenarios like Microsoft Authenticator app passwordless authentication or FIDO2 security keys by itself. For those features, you need to combine PTA with Azure AD Multi-Factor Authentication (MFA) or use passwordless methods directly with Azure AD. PTA is strictly for password-based authentication against on-premises AD.
Memory Tip
Think PTA: Passwords Travel Away from cloud, Authenticated Against on-premises. No hash in cloud = no cloud password breach.
Covered in These Exams
Current Exam Context
Current exam versions that test this topic — use these objectives when studying.
Legacy Exam Context
Older materials may mention these exam versions, but learners should use the current objectives for their target exam.
MS-100MS-102(current version)MS-101MS-102(current version)Related Glossary Terms
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
802.1X is a network access control standard that authenticates devices before they are allowed to connect to a wired or wireless network.
An A record is a type of DNS resource record that maps a domain name to an IPv4 address.
AAA (Authentication, Authorization, and Accounting) is a security framework that controls who can access a network, what they are allowed to do, and tracks what they did.
Frequently Asked Questions
Does pass-through authentication store my password in the cloud?
No, pass-through authentication does not store any password hashes in Azure AD. The password is validated live against your on-premises Active Directory. Only the authentication result (success or failure) is sent back to Azure AD.
How many Authentication Agents do I need for high availability?
Microsoft recommends a minimum of two Authentication Agents for production environments. This ensures that if one agent fails, the other can continue processing authentication requests without interruption.
Can I use pass-through authentication together with password hash synchronization?
Yes, you can enable both methods in Azure AD Connect. If pass-through authentication fails due to an on-premises outage, Azure AD will automatically fall back to password hash synchronization as a backup method. However, this stores password hashes in Azure AD.
What ports need to be open for pass-through authentication?
The Authentication Agent needs outbound HTTPS (port 443) to Azure. For on-premises communication, it needs access to domain controllers on ports 445 (SMB) and 135 (RPC). No inbound ports are required from the internet.
Does pass-through authentication support smart card or certificate-based authentication?
No, pass-through authentication only supports username and password authentication. For smart card or certificate-based authentication, you would need Active Directory Federation Services (AD FS) or another federation solution.
Can I use pass-through authentication for all Azure AD features?
Pass-through authentication works for most Azure AD features, but some features like hybrid Azure AD join or Windows Hello for Business may require additional configuration. Always check the specific feature's documentation for compatibility.
What happens if all Authentication Agents go offline?
If no agents are available, users will not be able to authenticate to cloud services using only PTA. If you have enabled password hash synchronization as a fallback, Azure AD will automatically use that method. Otherwise, you must restore agent connectivity.
Summary
Pass-through authentication is a hybrid identity method that allows organizations to use cloud services like Microsoft 365 while keeping password verification on their own on-premises Active Directory. It works by installing lightweight agents on domain-joined Windows servers that maintain outbound connections to Azure AD. When a user enters their password, Azure AD sends it through the agent to the local domain controller for real-time validation. The password is never stored in the cloud, which satisfies strict compliance requirements.
For IT professionals, PTA offers a simpler alternative to federated identity systems while providing stronger security for password data than password hash synchronization. The trade-off is a dependency on network connectivity to on-premises infrastructure, so Microsoft recommends enabling password hash sync as a fallback method. In real-world deployments, proper agent redundancy and monitoring are essential for availability.
For exam preparation, focus on understanding when to choose PTA over other methods, the number of agents required, the fallback behavior, and the fact that it does not require inbound ports. Scenario-based questions are common, so practice matching business requirements to the correct authentication method. Remember the key exam trap: if a question says "do not store passwords in the cloud," the answer is almost always pass-through authentication.