An Introduction to AD FS We Can All Understand

Hi everyone, I’m Sean Ivey, a Premier Field Engineer based in Charlotte NC.  In an attempt to simplify some of the changes that are going on in the industry (have you heard of this cloud thing?) I thought I’d write an “intro” blog about Active Directory Federation Services, or AD FS.  “Why would I do this?” you ask, when there’s already an “Introducing AD FS 2.0” article on TechNet?  Go ahead, click the link.  I’ll wait.  Done?  How’d you like that first line?

“Active Directory Federation Services (AD FS) 2.0 provides support for claims-aware identity solutions that involve Windows Server® and Active Directory technology. AD FS 2.0 supports the WS-Trust, WS-Federation, and Security Assertion Markup Language (SAML) protocols.”

Claims-aware, WS-Trust, WS-Federation, and SAML…I don’t know about you, but when I first read that I thought “Thanks for introducing four more technologies I know nothing about!”

So here we go.  Let’s start with the basics.  There are currently 4 versions of AD FS, and understanding where to get each can be a bit tricky…

AD FS 1.0

• AD FS 1.0 was first introduced with Windows Server 2003 R2 and it was installed as a Windows Feature.
• Avoid using this version.  If for no other reason, 2003 R2 fell out of mainstream support in 2010!

AD FS 1.1

• AD FS 1.1 was included with Windows Server 2008 and 2008 R2 and can be installed through Server Manager.
• Obviously 2008 R2 has a longer shelf life than 2003 R2, but that doesn’t mean you should use this version of AD FS either.  It’s missing features most federation partners are expecting.
• If you want to install AD FS on Windows Server 2008 do NOT do it from Server Manager (unless you know you need AD FS 1.1).

AD FS 2.0

• AD FS 2.0 was a release to web (RTW).  It was NOT included with any OS.  It must be downloaded and installed on either Windows Server 2008 SP2 or 2008 R2.
• AD FS 2.0 has seen three update rollups.  If you don’t want to go with Windows Server 2012 yet, make sure to install the latest update rollup.

AD FS 2.1

• AD FS 2.1 is included with Windows Server 2012 and can once again be installed through server manager.

(The above screenshots are exactly that, just screenshots...Please do not install AD FS on a Domain Controller!)

Great, now that we understand what we’ve got to work with, let’s talk about what AD FS is used for. The rest of this article will focus on AD FS 2.x.  For me the easiest way to understand a new technology is to understand its purpose in relatable terms.  I’ll make an assumption that most of you understand Active Directory and discuss AD FS in relation to it.

Ultimately, AD FS is just a Security Token Service (STS).  In other words, it generates security tokens for users to present to applications.  If you work with Active Directory often, this should sound familiar.  One of the roles of a Domain Controller is that of a Key Distribution Center (KDC).  Whether you call it a key or a token, STS’s and KDC’s are similar in nature.  It’s important to realize that AD FS CANNOT authenticate a user by itself, it must rely on a DC for authentication to Active Directory.  Once authentication occurs, AD FS does the same thing a DC would do; verify users and issue security tokens. 

Q: If they’re so similar, why do we need AD FS?

A: There are specific scenarios in which Active Directory Domain Controllers could use some help.

Without going into too much detail, generally a DC uses Integrated Windows Authentication (IWA, usually Kerberos or NTLM) to authenticate a user to the application they are trying to access.

Q: What happens though, when that application is a web application?  And the user is at home on their tablet?

A: IWA doesn’t work so well in that scenario for a few reasons:

1. The client doesn’t have access to a domain controller from the internet (at least I hope not).
2. Whatever device they’re using, may not support IWA.
3. Ports for HTTP and/or HTTPS are likely the only ports open between the client and the server.

The first means Kerberos won’t work (the client has to get a ticket from a DC).  The third means NTLM won’t work (NTLM uses RPC, yay!).  The middle one trumps them both anyway. 

Let’s consider another scenario: I work for Contoso and need to access a web application at Fabrikam.  Each organization has its own Active Directory forest, and there isn’t a trust relationship between them.  Traditionally I have two options:

1. Setup an Active Directory trust relationship.
2. Create a “shadow” account in Fabrikam’s forest for my Contoso user account.

Setting up a trust can be a pain because of the port requirements for AD trusts.  Just look at them all!  You can always establish those over a PPTP tunnel (or something else) like the article mentions but there are other security related concerns with an AD trust as well.

Creating shadow accounts isn’t much better.  You could use a product to synchronize forests (such as FIM) or you could manually add and remove the shadow accounts.

Q: What happens when a user at Contoso is fired?  Is there a defined process for making sure that user is deleted on the Fabrikam side?  If not, they’ll still have access to whatever applications they had access to before.

Enter AD FS.  Using AD FS, we can get around each of these issues:

1. The client doesn’t need to access a DC from the internet because an AD FS proxy server can be used.  The AD FS proxy is typically NOT joined to the corporate forest for security reasons.
2. AD FS can use forms based authentication, which means the type of client becomes irrelevant, since the username and password is entered in a webpage:
    
3. All of the authentication is done over a TLS (SSL) tunnel (port 443 by default) so no need to open additional ports.
4. AD FS can setup a trust relationship from company to company without ANY ports being open.  Everything is accomplished through the exchange of x509 certificates (in an email if you’d like).
5. Once the trust is established, there’s no need to create shadow accounts for users from one organization to access resources at another.

So far this AD FS thing sounds awesome doesn’t it?!  I’m only looking at the benefits from an infrastructure stand point.  There are plenty of benefits for developers too.

There is a down side though…AD FS does NOT work for traditional Windows NT token based applications!  What does that mean?

• AD FS will NOT allow you to access file shares or print servers
• AD FS will NOT allow you to access Active Directory resources
• AD FS will NOT allow you to access Exchange (O365 excepted)
• AD FS will NOT allow you to connect to servers using RDP
• AD FS will NOT authenticate you to “older” web applications

Note: AD FS federation and Lync federation are two different things

Ok then, what does AD FS help you with?  This gets us back to those terms used at the beginning of the article, specifically, Claims-Aware, WS-Trust, WS-Federation, and SAML.  Let’s start with a high level explanation of each:

Claims-Aware is the most ambiguous of the terms mentioned.  All it really means is that an application is written to use “claims” presented in a token to make authorization decisions.  From a Microsoft standpoint this typically indicates it’s a .NET application written with the Windows Identity Foundation (WIF) SDK (which is now a part of .NET 4.5).  A “claim” is nothing more than information about a user or some other identity.  You can think of claims as group memberships in Active Directory, only a lot more flexible.  For example, I could have a claim called “Age” with the value of “65”.  An application could then decide to let me into the “retirement” section.  That’s a very generic example but hopefully it gets the point across.

WS-Trust is a bit more specific.  Just like Kerberos is a defined authentication protocol, WS-Trust is a defined OASIS (Organization for the Advancement of Structured Information Standards) standard.  You can find the WS-Trust standard here.  Basically WS-Trust defines a way for applications to build trusted tokens for authentication and authorization purposes.

WS-Federation is really just an extension of other WS-* standards.  The biggest difference is: “WS-Federation defines a mapping of these mechanisms, and the WS-Trust token issuance messages, onto HTTP such that WS-Federation can be leveraged within Web browser environments.”  In other words, it makes all of this work in a web browser (which incidentally is still probably the biggest use case).

SAML (Security Assertions Markup Language) is yet another OASIS specification mostly unrelated to the WS-* standards even though it achieves roughly the same thing.  You can find all three versions defined here.

Great, now let’s outline a few important points from this information:

• If you want to use AD FS, the application or organization AD FS is to federate with must follow the WS-Trust, WS-Federation, or SAML standard.
• The SAML standard defines a token type referred to as a SAML token.  WS-Trust and WS-Federation can use many token types including SAML tokens.  Don’t be confused if an application is WS-Federation even though it’s using SAML tokens.
• AD FS can federate with applications (that follow one of the standards above) AND with other federation service providers.  Federating with other partners establishes the trust relationship necessary for users in one organization to access resources in another.
• WS-Federation is mostly used by websites designed to interact with a browser (SharePoint is a good example).
• WS-Trust is typically used by web services designed to interact with a thick client (Lync with Office 365 is a good example)
• SAML is typically used by products from companies other than Microsoft but AD FS does support its use.

To end this AD FS introduction, I’d like to finish with a diagram that should help explain the traffic flow when using AD FS to protect applications.  This is what a client would go through if the application the client is accessing is written with WS-Federation or SAML SP-Initiated sign on in mind.

(AD FS proxy servers left out for diagram simplicity)

Notice that the user is a Contoso employee with an account in the contoso.com domain.  This user is accessing a resource in the fabrikam.com domain.  Because the account resides at Contoso, Contoso’s AD FS server is considered the Identity Provider (IdP) or Claims Provider (CP) to the Fabrikam AD FS server.  The resource the user is trying to access is located in Fabrikam, so the Fabrikam AD FS server is the Service Provider (SP) or Relying Party (RP) to the Contoso AD FS server.  Going a step farther, the Fabrikam AD FS server is the IdP or CP to the web server, while the web server is the SP or RP to the Fabrikam AD FS server.  Make sense?  The yellow bar should help.

The yellow bar in the diagram does not indicate network connectivity, but instead the trust relationships:

• The Fabrikam web server trusts the Fabrikam AD FS server.
• The Fabrikam AD FS server trusts the Contoso AD FS server.
• In both instances, the trust is established by trusting what’s called a token-signing certificate (or trusting the root it chains to).

The terms identity provider, claims provider, service provider and relying party can get a bit confusing.  Think of it like this:

Finally, a few additional links that should help get you started:

AD FS 2.0 Terminology

Understanding Key Concepts Before You Deploy AD FS 2.0

AD FS 2.0 Step-by-Step and How To Guides

AD FS 2.0 Content Map

I hope this post helps you understand AD FS and the benefits it can provide to your organization.  In the future we’ll look more closely at deployment best practices, troubleshooting, etc. but I thought this first article would be a great way to level set everyone exploring the implementation of AD FS.

-Sean Ivey