Rob's Blog – Microsoft Technology Evangelist

The half-life of the Cloud is countered in moments. I am in the middle… understanding and innovating.

Rob's Blog – Microsoft Technology Evangelist

Understanding Identity with ADFS – Part 1

Posted on by

Estimated reading time: 13 minutes

Thank you for reading this post, don't forget to subscribe! Happy New Year 2024!

Identity is always something of a taboo subject and is still not clearly understood out there and the IT security landscape keeps evolving.

One of the recent changes past few years is a move away from (Access Control Lists) ACLs on files in the NTFS file system to an access control system that is based on claims.

Claims based authentication is an industry standard security protocol to authenticate users. This is the underlying WS-* standards that describe the usage of Security Assertion Mark-up Language (SAML) tokens. Claims based auth requires these tokens, and by extension an entity that can issue the token.

This is the Secure Token Service (STS). The STS server can be based on Active Directory Federation Services (ADFS) or other platforms that provide this service. This is where ADFS comes in and the highlight of this series.

Why Active Directory Federation Services (ADFS)?

When I started to work on ADFS, a number of years ago during my days as a consultant, most of my customer’s requests where simple:

“I want to federate with some application, hosted by some vendor, so that my users can login into this application without being prompted for credentials.”

This type of request may seems simple, but this where the power of the Single Sign-On (SSO) experience and the underlying technology is transformative.

So, what exactly is ADFS?
In plain English, it’s a web service that authenticates your users to Active Directory while also simultaneously providing them access to some claims-aware application (i.e. Office 365, Salesforce.com, etc.). Many times, these applications are typically used through the client’s web browser.The applications can be on-premises, off-premises, or even hosted by other companies. It doesn’t really matter where these applications live, who owns them, as long as they can accept a token with claims.

This blog post will review the history of ADFS and an overview ADFS itself. Next in the series I will cover deploying ADFS and configuring Federation with Office 365 on Nutanix in the lab. This will play into a series I am planing around Office 365 and Hybrid setup on Nutanix in the future. After that, I will cover different deployment scenarios. So sit back and enjoy the identity ride.

Active Directory Federation Services

ADFS is an identity access solution that provides client computers (internal or external to your network) with seamless SSO access to protected Internet-facing applications or services, even when the user accounts and applications are located in completely different networks or organizations. (i.e. think how you login with facebook to other services)

When an application or service is in one network and a user account is in another network, typically the user is prompted for secondary credentials when he or she attempts to access the application or service. These secondary credentials represent the user’s identity in the realm where the application or service resides. They are usually required by the Web server that hosts the application or service so that it can make the most appropriate authorization decision.

With ADFS, organizations can bypass requests for secondary credentials by providing trust relationships (federation trusts) that these organizations can use to project a user’s digital identity and access rights to trusted partners. In this federated environment, each organization continues to manage its own identities, but each organization can also securely project and accept identities from other organizations.

Below is an example of a typical Office 365 Deployment with ADFSADFS-O365

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

ADFS 1.0

  • ADFS 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!
    ADFS-2K3

ADFS 1.1

  • ADFS 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 ADFS either.  It’s missing features most federation partners are expecting.
  • If you want to install ADFS on Windows Server 2008 do NOT do it from Server Manager (unless you know you need AD FS 1.1).
    ADFS-2K8

ADFS 2.0

  • ADFS 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.
  • ADFS 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.
    ADFS-RTW

ADFS 2.1

  • ADFS 2.1 is included with Windows Server 2012 and can once again be installed through server manager.
    ADFS-2K12

ADFS 2012 R2 (Official Name)

  • ADFS 2012 R2 is included with Windows Server 2012 R2 and can once again be installed through server manager.
Great, now that we understand what we’ve got to work with, let’s talk about what ADFS is used for. The rest of this blog post will focus on ADFS 2.x2012 R2.  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 I will discuss ADFS in relation to it.
Ultimately, ADFS 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 ADFS CANNOT authenticate a user by itself, it must rely on a DC for authentication to Active Directory.  Once authentication occurs, ADFS does the same thing a DC would do; verify users and issue security tokens
Q: If they’re so similar, why do we need ADFS?
A: There are specific scenarios in which Active Directory Domain Controllers don’t meet modern needs.
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 iphone, ipad or 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, it may not support IWA (most likely).
  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 :cry:!).  The middle one trumps them both anyway.

Let’s consider another typical Microsoft 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:

  • Setup an Active Directory trust relationship between the AD Domains
  • 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 VPN tunnel (or something else) like the article mentions, but there are other security related concerns with an AD trust as well. Too many to mention in this blog post.  😥

Creating shadow accounts isn’t much better.  You could use a product to synchronize forests (such as Forefront Identity Manager) or you could manually add and remove the shadow accounts. All which is a pain to manage in either case.

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.

That is where ADFS comes in……

Using ADFS, we can get around each of these issues:

  • The client doesn’t need to access a DC from the internet because an ADFS proxy server can be used.  The ADFS proxy is typically NOT joined to the corporate forest for security reasons. It proxies the requests to the ADFS server, in other words, no direct contact to your ADFS server.
  • ADFS can use forms based authentication, which means the type of client becomes irrelevant, since the username and password is entered in a webpage:
    ADFS-Login
  • All of the authentication is done over a TLS (SSL) tunnel (port 443 by default) so no need to open additional ports.
  • ADFS 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).
  • 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 ADFS thing sounds pretty awesome huh…?!  And I’m only looking at the benefits from an infrastructure standpoint.
As with anything, there are also some downsides…ADFS does NOT work for traditional Windows NT token based applications!  What does that mean?
    • ADFS will NOT allow you to
      • access file shares or print servers
      • access Active Directory resources
      • connect to servers using RDP
    • ADFS will NOT authenticate you to “older” web applications

There are plenty of benefits for developers also. Ok then, what does Active Directory Federation Services help you with in DevOps you ask?  This gets us back to those terms used at the beginning of the blog post, specifically, Claims-Aware, WS-Trust, WS-Federation, and SAML.

Here is 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 Active Directory Federation Services, the application or organization ADFS 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.
  • ADFS 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 ADFS does support its use.

To end this blog post on Understanding ADFS, I’d like to finish with a diagram that should help explain the traffic flow when using ADFS 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.

(ADFS proxy servers left out for diagram simplicity)ADFS overview

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

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

  • The Fabrikam web server trusts the Fabrikam ADFS server.
  • The Fabrikam ADFS server trusts the Contoso ADFS 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. But they are interchangeable as you can see. Think of it like this:

Standard Industry Terminology

MS ADFS Terminology

Identity Provider (IdP)

Claims Provider (CP)

Service Provider (SP)

Relying Party (RP)
Here are a few additional resources for reference:
TechNet – Active Directory Federation Services Overview

Windows Server 2012 R2 AD FS Deployment Guide

I hope this post gives you a good understanding of ADFS and the benefits it can provide.  In the next posts in this series, we’ll look more closely at deployment with Office 365, and different  deployment scenarios.

Until next time, Rob

Leave a Reply

Your email address will not be published. Required fields are marked *

Discover more from Rob's Blog - Microsoft Technology Evangelist

Subscribe now to keep reading and get access to the full archive.

Continue reading