What is Azure AD (Entra) pass-through authentication?
The cert wants a one-line definition. The tenant wants you to pick PTA or Password Hash Sync and defend it in a design review. Here is both — the plain answer and the choice underneath it.
New to cloud? CAMPUX is a free, build-first course. Start here →
Pass-through Authentication (PTA) is a Microsoft Entra ID sign-in method that validates a user's password directly against your on-prem Active Directory through a lightweight agent, so the password is never stored — as a hash or otherwise — in the cloud. It is one of three ways a hybrid tenant can check passwords, alongside Password Hash Sync and federation with AD FS.
One naming note before anything else, because it trips people up in exams and job listings alike. Azure AD and Microsoft Entra ID are the same product. Microsoft renamed Azure Active Directory to Entra ID in 2023. Old docs, old tickets, and half the internet still say Azure AD. When you read "Azure AD pass-through authentication," it means Entra ID PTA — identical feature, older label.
The problem all three options are solving
Most companies did not start in the cloud. They had Active Directory on servers in a closet or a datacenter, holding every employee's account and password, long before anyone signed a Microsoft 365 contract. Now those same users need to sign in to cloud things — Outlook on the web, Teams, SharePoint, any app wired to Entra. The password lives on-prem. The sign-in happens in the cloud. Something has to bridge that gap.
That bridge is what "hybrid identity" means, and the tool that builds it is Entra Connect (the sync engine, formerly Azure AD Connect). It copies your user accounts up to Entra so the cloud knows who exists. But copying who exists is not the same as deciding where the password gets checked. That second decision is the sign-in method, and you have three choices.
The three sign-in methods, side by side
This is the table worth memorizing, because it is the entire topic. Everything else is detail hanging off these rows.
| Pass-through Auth (PTA) | Password Hash Sync (PHS) | Federation (AD FS) | |
|---|---|---|---|
| Where the password is checked | On-prem AD, in real time, via the agent | In the cloud, against a synced hash | On-prem, by your AD FS farm |
| Does password material reach the cloud? | No | Yes — a hash of the password hash | No |
| Infrastructure you run | Entra Connect + 1 lightweight agent (min. 3 recommended) | Entra Connect only | Entra Connect + AD FS servers, proxies, certs, load balancers |
| Survives an on-prem outage? | No — sign-ins fail unless PHS is enabled as backup | Yes — cloud validates on its own | No — the AD FS farm must be up |
| Leaked-credential detection | Not on its own (needs PHS) | Yes | Not on its own |
| Operational weight | Low | Lowest | High |
| Microsoft's stance | Fine when on-prem validation is required | Recommended default | Legacy — migrate off where you can |
PHS asks the cloud to check the password. PTA asks the closet server. Federation asks a whole farm you now have to babysit.
How the PTA agent actually works
The mechanism is smaller than the name suggests. You install the Authentication Agent — a small Windows service — on a server inside your network that can reach a domain controller. It makes an outbound connection to Entra and holds it open. No inbound firewall ports, no public endpoint, nothing exposed to the internet. That detail matters, and it is the part interviewers like to hear you say unprompted.
When a user signs in to a cloud app, the flow goes like this:
- Entra collects the username and password at sign-in and encrypts the password with the agent's public key.
- It drops that encrypted request into a queue the agent is already listening on over its outbound channel.
- The agent decrypts the password and hands it to on-prem Active Directory the ordinary way, using a standard Windows authentication call.
- AD says valid or not — including whether the account is locked, disabled, expired, or outside its permitted sign-in hours — and the agent relays that verdict back to Entra.
The password is validated by AD and discarded. It is never written to Entra. That is the security promise in one sentence: the credential is checked at home and never moves in.
A single agent is a single point of failure — if that server reboots for patches, cloud sign-ins stall. Microsoft recommends at least three authentication agents on separate servers so PTA survives a reboot or a dead box. This is the number-one thing teams get wrong: they pilot with one agent, ship it, and discover the fragility during the first Patch Tuesday.
The security tradeoffs, stated plainly
PTA's headline benefit is real: no password hashes in the cloud. If your security team has a written rule that password material never leaves the building, or you have on-prem controls — sign-in hours, instant disable, account lockout policy — that must apply the moment they change, PTA honors that. The check happens against live AD, so a disabled account is disabled everywhere in real time.
The cost is resilience and features. Because there is nothing in the cloud to validate against, PTA has a hard dependency on your on-prem being reachable. Domain controllers down, agents down, or the site link down, and cloud sign-ins go with them. You also lose leaked-credential detection — the Entra ID Protection signal that flags accounts whose passwords have shown up in known breach dumps — because that feature needs the synced hash that PTA deliberately does not send.
Which is why the common production pattern is not PTA alone. It is PTA with Password Hash Sync enabled as a fallback. PTA does the day-to-day validation on-prem; PHS sits quietly in the background so that when on-prem is unreachable you can flip sign-ins over to the cloud and keep the business logging in. You get the on-prem-validation posture and a safety net. Turning PHS on does not force it to be used — it just makes it available.
The gap the cert leaves you in
Here is where certified and job-ready split. The AZ-500 or SC-300 objective asks you to define pass-through authentication and maybe recognize it in a multiple-choice list. You can pass that by memorizing the table above. Good — do that.
The job asks something the exam never does: a real tenant is in front of you; which method do you turn on, and can you defend it to a security architect who will push back? That is not a definition question. It is a judgment call with money, risk, and an angry help desk on the other side of a wrong answer.
So here is the judgment, the way I would say it in the review:
- Default to Password Hash Sync. It is the simplest thing that works, it survives an on-prem outage, and it enables leaked-credential detection. If nobody can name a concrete requirement against it, PHS is the answer and the meeting is short.
- Reach for PTA only when the requirement is written down. "Compliance says no password material in the cloud." "We must enforce on-prem sign-in hours in real time." A real, sourced constraint — not a vague unease about hashes. If it exists, PTA is correct, and you enable PHS alongside it as fallback.
- Treat federation as legacy. If you are on AD FS today, the modern move is usually to migrate to PTA or PHS and retire the farm — fewer servers, fewer certs, fewer 2 a.m. renewals. Keep AD FS only for a specific capability nothing else covers.
The person who can say that — and then say why — is the person who gets the identity work. The definition gets you in the room. The tradeoff gets you the job.
None of these three is your multi-factor story. Sign-in method decides where the password is checked; MFA and Conditional Access sit on top and apply regardless of which one you pick. Do not let a PTA-versus-PHS debate distract from the fact that the password, on its own, is the weakest part of any of them.
Common questions
Is pass-through authentication the same as single sign-on?
No. PTA is a sign-in method — it decides where the password gets checked. Seamless SSO is a separate feature that silently signs in domain-joined users on the corporate network so they skip the password prompt entirely. You usually turn both on together, but they are different switches, and you can run PTA without SSO or SSO on top of Password Hash Sync.
Does pass-through authentication store passwords in the cloud?
No. That is the whole point of PTA. The password is validated against your on-prem Active Directory by the authentication agent, and no password or password hash is written to Entra ID. Password Hash Sync, by contrast, syncs a hash of the password hash into the cloud so Entra can validate sign-ins by itself.
What happens to pass-through authentication if the agent goes down?
Cloud sign-ins that depend on PTA fail, because there is nothing in the cloud to validate the password against. That is why Microsoft recommends running at least three authentication agents on separate servers, and why many teams also enable Password Hash Sync as a fallback so authentication survives an on-prem outage.
Should I use pass-through authentication or password hash sync?
Default to Password Hash Sync unless a written requirement forces the password check to stay on-prem — for example a policy that no password material may leave the building, or on-prem account controls that must apply in real time. PHS is simpler, more resilient, and enables leaked-credential detection. Choose PTA when the on-prem-validation requirement is real, and keep PHS enabled alongside it as a fallback.