You guys have any experience with ADFS?

People often ask me if we have experience with ADFS. Seems a lot of organizations out there were sold on the idea that hybrid identity meant leveraging on-prem authentication to get best-in-class performance and security for Office 365. Still others invested in ADFS to support other projects and decided to leverage the deployment to support O365. Some even operate under the misunderstanding that if you have ADFS at all, you must use it for O365. Do we have experience? Yes. But the nature of that experience has been an interesting evolution over the years, and now the relevant question is “do you have experience REMOVING it?” To which the answer is an overwhelmingly thunderous “yes,” possibly followed by confetti and ticker-tape.

We have done a number of ADFS deployments for organizations of various sizes. But we’ve done at least twice as many removals, and that was before Ignite 2018, when Microsoft officially declared that ADFS is less ideal than “Seamless SSO with Password Hash Sync.” And now the British Government is onboard, having posted on Valentine’s Day this year (2019) that cloud-native authentication is preferred to ADFS.

Why all the hate? There are a number of reasons, but the biggest one is complexity. A proper ADFS configuration requires geo-redundancy and at least 6 servers—not the standard 4 that most folks talk about. There are 2 proxies, 2 ADFS servers, and a CA infrastructure that, properly configured, requires a root CA to be offline 99% of its life. Additionally, depending on how you choose to configure that CA, there’s the cost of certificate renewals...assuming your admins remember to do them.

Consider the Worst Day of My Career, ca. 2005: at a government agency with 3500 users, an enterprise AD architect had forgotten to set a reminder to renew the enterprise root certificate. We all came to work to discover there was no Active Directory at all. And the phone system was tied to it, along with everybody’s contact info, so we just sat at our desks and waited for him to show up to work. And he had nothing to suggest. So then we waited for the backups person to roll in, and since that system was NOT on Windows, they were able to restore the environment to a date prior to the expiration. But the whole CA environment had to be torn down, key ceremonies in the OCSP environment completely redone, and the whole day was a wash for literally every user at the facility.

If you can believe it, my story isn’t even close to unique. It’s really easy to get excited about ADFS and forget about its dependencies. I’ve heard too many horror stories of ADFS going belly-up because of certificates, upgrade glitches, and configuration creep.

None of that is an issue with cloud-native authentication. Microsoft maintains the certificates for your domains on your behalf (including the costs and certificate purposes), and you get to potentially decommission 6 servers.

Or is that 7? Because if you want to support multi-factor authentication with Azure AD and ADFS, you will need to configure an Azure MFA server on-prem. Cue the usual refrain from IT managers: “I thought I was going to the cloud to GET RID OF servers.”

And what are you really getting from those 7 servers? The assurance that your authentication is happening on your network? What is the actual value of that? Serious question. Because pass-through authentication actually supports real on-premises authentication for users who are actually on-prem, but without those 7 servers. If a user has line-of-sight to a DC, AAD Connect will allow them to authenticate to a real live DC and pass that session to Azure. I don’t know about you, but I’m not sure I want a user in a questionable Internet café to hit my actual real network IP addresses with anything.

But what about those pesky password hashes? It’s been reported numerous times, but somehow the message never seems to land, that the NT hashes are re-hashed by AAD Connect en route to Azure AD, meaning that even if someone could intercept the hashes in transit, they would not be able to replay those hashes at your AD to gain entry.

“But what about all my custom federations I’ve built over the years? ADFS is handling more than just O365!” No problem: you do you. There is absolutely no dependency that states ADFS must do all things for all potential systems. There is, however, support for rebuilding SAML federations natively from Azure, even for applications that are not listed in the Azure application gallery.

Of course, organizations that allow self-service password reset and write-back from Azure AD get next-level authentication super powers. Azure AD’s password filters are far and above what Active Directory can control. Character limits and complexity? Please. How about not allowing users to use known compromised or weak passwords (irrespective of complexity, i.e., p@ssword1)? Prohibiting the use of the winning sports team’s name? AD can’t even block a keyboard-run without the help of a 3rd party tool$et.

And allowing self-service password has been shown to reduce help desk call volumes by 30%, while eliminating a pair of serious attack vectors: the help desk knowing a user’s password—even for a short while—and users failing to reset their passwords to a permanent value until their next trip to the office, which gives the bad guys plenty of time to attack with that temporary p@ssw0rd.

So do we have experience with ADFS? Sure: plenty, and we’d be happy to help you get it up and running. But keep us on speed dial for when you’re ready to tear it back out.