Azure AD Pass-through Authentication — Azure AD PTA, and its companion feature Seamless Single Sign-On — moved from public preview to general availability at Ignite last month, and the question we have fielded in nearly every identity conversation since is some version of pass-through authentication vs ADFS: now that PTA is a supported, production-grade sign-in method, does a shop already running a federation farm still need one?
We are not neutral on this question, because we operate one of the larger ADFS farms we know of, in production, right now: seven federated domains behind two ADFS 3.0 nodes and a pair of Web Application Proxy servers in the DMZ, built last year for a state government agency's 15,000-mailbox Office 365 tenant. That farm has been solid. It has also been, at every certificate rollover and every DMZ firewall review, exactly the kind of tier-0 dependency you would rather not operate if you did not have to. So when Microsoft shipped a credible third option last month, we did what we would tell any client to do with their own infrastructure: we asked, honestly, whether we still need it.
This post is that evaluation: how PTA actually works, what a federation farm buys you that PTA and Password Hash Sync do not, the decision tree we are now running with every hybrid-identity client, and the migration path for the estates where the honest answer is yes, decommission it. The short version — PTA is a genuinely good default for new work. The farm we built in 2016 earned its keep for three specific reasons, and last month's announcement quietly satisfied two of them. The third is the one nobody expects, and it is the one keeping our client's DMZ servers racked.
Pass-through authentication vs ADFS: the three sign-in options in 2017
Azure AD has offered exactly two supported sign-in models for hybrid identity for the last couple of years. Federation hands authentication to an on-premises identity provider — almost always ADFS in a Microsoft shop — and Azure AD never sees a credential at all; it trusts a signed token instead. Password Hash Synchronization has Azure AD Connect replicate a hash of a hash of each user's password to Azure AD, and authentication then happens entirely in the cloud against that synced value. As of last month there is a third option: Pass-through Authentication, in which Azure AD accepts the sign-in attempt but validates the username and password against your on-premises domain controllers in real time, through a lightweight Authentication Agent, without ever storing password data in the cloud.
The honest comparison, stripped of vendor adjectives:
| Sign-in method | Where the password is actually checked | On-prem footprint | Revocation speed |
|---|---|---|---|
| Federation (ADFS) | On-prem, inside the ADFS claims pipeline | ADFS farm plus WAP proxies in the DMZ | Immediate — every token issuance re-checks AD |
| Password Hash Sync | In Azure AD, against a synced hash | Azure AD Connect server only | Tied to the sync cycle |
| Pass-through Authentication | On-prem, by the Authentication Agent, per sign-in | One or more lightweight agents, no DMZ | Immediate — every sign-in re-checks AD |
Seamless Single Sign-On layers on top of either PHS or PTA and gets you back the type-your-username-and-skip-the-password-prompt experience that domain-joined machines used to get from ADFS's Windows Integrated Authentication, without the WAP farm underneath it. For a shop already running ADFS well, none of the mechanics above are news — PTA has been in public preview for the better part of a year and we have had it running in a lab since spring. What changed at Ignite is that Microsoft called it finished: generally available, supported, and safe to put a production tenant on.
How Azure AD PTA actually works: agents, high availability, and a DMZ you get to shut down
The Authentication Agent installs on the Azure AD Connect server by default, and — this is the detail that matters operationally — on as many additional plain member servers as you want beyond that. Each agent makes only outbound connections to Azure AD, on ports 443 and 80, and registers itself to receive authentication requests over that outbound channel. Nothing initiates inbound. Nothing needs a DMZ. The agent shares its outbound relay plumbing with Azure AD Application Proxy, so the same family of msappproxy.net and servicebus.windows.net endpoints shows up on the firewall change request, not a new inbound rule with a certificate behind it.
That is worth sitting with, because it is the mirror image of a failure mode we have lived with for a year on the WAP side: let a DMZ firewall rule lapse and you are re-running Install-WebApplicationProxy on a Saturday to re-establish the proxy trust. PTA does not have an inbound proxy trust to lose. It has outbound reachability to lose, which is a far easier thing to monitor and a far harder thing to accidentally break during a routine firewall audit.
High availability is just "install more agents." We stood up the agent on two member servers away from the Azure AD Connect box itself, specifically so that server is not a single point of failure for sign-in when it does not need to be. Azure AD load-balances across whichever agents report healthy; killing either one mid-test produced no user-visible failure, just quieter logs on the one we killed.
Seamless SSO is a separate, smaller piece of plumbing. Enabling it creates a computer account named AZUREADSSOACC in the on-premises forest, and domain-joined, on-network machines use a Kerberos ticket against that account to authenticate silently at Azure AD's sign-in page, once the SSO URL is pushed into the browser's intranet zone by group policy.
# Confirming the Seamless SSO computer account landed correctly during the pilot
Get-ADComputer -Identity 'AZUREADSSOACC' -Properties whenCreated, servicePrincipalName
Off-network or non-domain-joined devices still get prompted for a password, which is functionally identical to how Windows Integrated Authentication against the internal ADFS farm behaved for the same population. Nobody loses anything here. They just stop needing a WAP proxy to get it.
What you still cannot do without ADFS
None of the above is an unqualified win, and this is where our agency client's 2016 design decision gets interesting in hindsight. We federated all seven of that agency's domains for three stated reasons: no derivative of a domain credential could ever leave the state network; disabling an account in Active Directory had to take effect immediately, not on the next sync cycle; and an active smart card pilot, plus existing logon-hours restrictions, had to keep working — and both of those live in ADFS claims rules, not in sync plumbing.
Read that list again next to what PTA actually does. Reason one: satisfied. PTA never places a password or a hash in the cloud, full stop — the validation happens on-premises, every time. Reason two: satisfied, and arguably improved. PTA checks the live account state against a domain controller on every single sign-in, the same real-time guarantee ADFS gave us, without forcing us to relitigate the sync-cycle argument PHS would have reopened. Reason three is the one PTA does not touch at all. There is no way, in the product as shipped last month, to authenticate a smart card to Azure AD without ADFS sitting in the pipeline, and there is no way to enforce a logon-hours claim at the token layer either — both are claims-side behaviors that simply do not exist on the managed-authentication side of the house yet.
A few more items belong on this list, in roughly the order they actually bite:
- Third-party relying parties. If your ADFS farm is also the SAML identity provider for a benefits portal, a vendor extranet, or some other application that has nothing to do with Office 365, converting your Office 365 domain to PTA does not retire the farm. It just removes one relying party from a farm that still has other work to do.
- Complex or custom claims rules. Issuance transform rules that rewrite a UPN, augment a claim from an attribute Azure AD cannot see, or trigger different behavior for different groups are exactly the kind of thing that accretes quietly over a few years and becomes load-bearing without anyone deciding it should. PTA has no claims pipeline to carry that logic forward.
- A fully custom sign-in page. ADFS's onload.js customization gives you real HTML, CSS, and JavaScript control over the login page. Azure AD's native sign-in customization in 2017 is genuine but limited to a logo, a background image, and some text. If your marketing team has opinions about the login screen, that is a small but real vote for keeping federation.
So two of the three reasons our own farm exists evaporated overnight, and the third is now doing all the remaining work. That is a very different farm, architecturally, than the one we designed in 2016 — even though not one server in it has changed.
The decision tree we use with clients
Stripped to the logic we actually walk through in a workshop:
- Any certificate-based or smart card authentication requirement against Azure AD? ADFS stays, full stop, until that changes. Nothing else on this list matters yet.
- Does the farm serve relying parties beyond Office 365 and Azure AD? Then it survives your Office 365 conversion regardless, and decommissioning becomes a separate, later conversation about those other applications.
- Is there a genuine regulatory or contractual requirement that no credential-adjacent artifact ever leave the network? PTA satisfies this in our own reading — no password, no hash, ever reaches the cloud — but if your auditors have not blessed PTA specifically by name, get that in writing before you convert a single domain, not after.
- Do you need the no-password-prompt experience for on-network, domain-joined machines? Seamless SSO gives you that on top of either PHS or PTA. It stopped being a reason to keep federation the day it shipped.
- Does anyone have a real opinion about custom branding on the sign-in page? Weigh it honestly; it is usually smaller than it feels in the room.
- None of the above? Convert to PTA with Seamless SSO, and start planning the WAP decommission on your own schedule rather than your certificate's.
Our agency client stops at step one. Every other client we have run this tree against this month has kept going all the way to step six.
Migrating off federation without a big-bang cutover
For clients who land on "convert," we run the same staged discipline we would insist on for any tier-0 identity change:
- Install Authentication Agents ahead of any cutover, on member servers separate from Azure AD Connect, and let them sit and report healthy for a few days before anything depends on them.
- Enable Seamless SSO first, in the pilot forest, and confirm the
AZUREADSSOACCobject and the group policy landed before touching authentication for a single user. - Convert one domain, not seven, in the first pass. Azure AD Connect's "Change user sign-in" task can flip a tenant's sign-in method directly, or you can move a single domain from federated to managed authentication explicitly:
# Converting one pilot domain from federated to managed (PTA-backed) authentication,
# only after the Authentication Agents are installed and reporting healthy
Convert-MsolDomainToStandard -DomainName pilot.agency.example -SkipUserConversion $true
- Watch sign-in logs through a defined bake period, and keep the ADFS farm fully running in parallel as a fallback. The rollback is
Convert-MsolDomainToFederatedon the same domain, and it should stay a realistic option, not a theoretical one, until the bake period ends cleanly. - Decommission WAP and the ADFS nodes only after every domain has converted, the bake period has passed, and you have confirmed nothing else relies on the farm as a SAML identity provider.
Our own pilot, run against two of the agency's seven domains, caught exactly the kind of thing a phased approach exists to catch. PTA rejected sign-in for a small population ADFS had been quietly waving through for a year: eleven service accounts whose Active Directory UPN did not match the identity they signed in with, papered over by an issuance transform rule nobody had touched since the original 2016 build. ADFS's claims pipeline was silently rewriting the mismatch on the way out. PTA has no claims pipeline and nothing to rewrite — it checks exactly what you hand it against exactly what is in the directory. That is arguably the more honest behavior, but it is a fix-it-before-cutover finding rather than a fix-it-after one, and it is precisely the kind of thing a domain-by-domain conversion surfaces quietly, while a big-bang conversion turns it into a Monday-morning war room.
If you're facing this
If you are running ADFS today and last month's PTA announcement has you rethinking the architecture, the honest answer takes about a day to reach: an inventory of what actually depends on your farm beyond Office 365 sign-in, and a clear-eyed read of whether anyone genuinely needs certificate or smart card authentication. We run that assessment, and the decision tree above, with clients now, and we will tell you plainly if the right answer is to keep every server you already have. Get in touch if you want a second opinion before you touch a production federation trust.