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…
(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:
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:
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:
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?
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:
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 terms identity provider, claims provider, service provider and relying party can get a bit confusing. Think of it like this:
AD FS Terminology
Identity Provider (IdP)
Claims Provider (CP)
Service Provider (SP)
Relying Party (RP)
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.