cancel
Showing results for 
Search instead for 
Did you mean: 

Abandon All Hope, Ye Who Enter AD FS

JCDavid
Iron II
Iron II

I recently suffered a severe ankle sprain, and I don't know what's worse between that and setting up an AD FS server farm. AD FS had its place to extend Active Directory with local and web app SSO, and IT admins can have very finite control over authentication when using it as an IdP in hybrid environments. It's just stunningly difficult to set up and costly/time consuming to maintain. The security analyst in me also can't help but think that each server component is layering on cyber attack surface area.

By its own admission: "We do not recommend this option [AD FS] unless you need federated single sign-on and on-premise password management. This path is more difficult and expensive, requires the management of multiple servers, and is only relevant for districts with complex security set-up and requirements," versus Azure AD Connect.

Maybe it's not as bad as a sprained ankle (with thanks to my dog, AJ), but my experience was mind-numbing. Here's some of the madness that occurred:

  • Server Roles and Features that wouldn't install through the Server Manager GUI but worked over PowerShell

useit1.pnguseit2.pnguse it 3.png

  • Built-in super admin accounts residing in Windows Server without passwords by default
    • The dent in my armor is that this was my first time setting up AD FS but it's *incredible* that default admin accounts remain password-less and IT admins have to take the time to set on (as well as a policy for it) as undocumented steps. Microsoft probably assumes that the servers were already fully configured prior to attempting this, but still.
  • Having to wait hours just for fresh installs of Windows Server (AD FS requires a server farm to separate the directory from AD FS service from the Web Application Proxy) to complete prior to accomplishing *anything*. I'd set a stopwatch to be pithy here, but just gave up on the whole idea after a while.

new use.png

  • Random errors and oddities that I didn't even bother to document.

This was all for a simple demo environment. Think for a moment what else a production system would entail, and please, hold tightly onto your wallet: 

  • A WAF layer (for virtual patching) and L7 rate limit protection to prevent application abuse
  • On-prem DDOS mitigation
  • Patching
  • Cert management (yet another server role, AD CS)
  • Ciphers
  • Load-balancing, sticky session, etc.

Ultimately, this was my favorite dialog:

use it last.png

There are better, more modern ways to accomplish SSO (even from Microsoft). Abandon All Hope, Ye Who Enter AD FS.

(I'll update this post with a how-to guide about how to transition away from AD FS, soon. You, my friends, deserve it.)

 

1 REPLY 1

Idan
JumpCloud Alumni
JumpCloud Alumni

So true, so frustrating and so obsolete…
David Worthington is totally on point here!
I see no reason what so ever in using ADFS for on-prem networks (or cloud) It’s just attack surface waiting to be exploited. I’ll explain - the ADFS endpoint would require a WAF layer (for virtual patching) and L7 rate limit protection to prevent application abuse (and I didn’t even mention on-prem DDOS mitigation, patching, cert management, ciphers, load-balancing, sticky session, etc)

You Might Like

New to the site? Take a look at these additional resources:

Community created scripts

Keep up with Product News

Read our community guidelines

Ready to join us? You can register here.