Deploying ADFS on Nutanix – Installing and Configuring – Part 2

Deploying and configuring Active Directory Federation Services (ADFS) 2012 R2 for Office 365 can be broken down into 4 blog posts:

  1. Install and Configuring ADFS (this post)
  2. Configuring Name Resolution and additional nodes
  3. Install ADFS Proxy (Coming Soon)
  4. Leverage ADFS with Office 365 (Coming Soon)
  5. New automated methods of setting up ADFS with Office 365 (Coming Soon)

Planning And Prerequisites, and Other Fun Details


Here are is the list of prerequisites from TechNet. But in general, you need to make sure you have a SSL certificate. The certificate must be trusted publicly (chained to a public root certification authority) or explicitly trusted by all computers that require access to the federation service. A wildcard certificate would work or a standard web certificate with the name you desire (i.e. – FS = federation service)
For this lab, you will need a Windows 2012 R2 Server with 4 cores, 4 Gigs of RAM and 100 Gig OS drive.

ADFS Role Planning

The ADFS role should be deployed within the corporate network, and not in the DMZ.  The ADFS proxy role is intended to be installed into the DMZ.
The default topology for Active Directory Federation Services is a federation server farm, using the Windows Internal Database (WID), that consists of up to five federation servers hosting your organization’s Federation Service. In this topology, ADFS uses WID as the store for the configuration database for all federation servers that are joined to that farm. The farm replicates and maintains the Federation Service data in the configuration database across each server in the farm.

Since the availability of Office 365 relies upon the availability of ADFS when the domain is federated there is a strong recommendation to have at least two ADFS servers with a redundant proxy infrastructure. On Nutanix, make sure the ADFS servers are running on different nodes and/or cluster’s for complete site resilience. Running Active Directory Federation Services on Windows 2012 R2 is fully supported across all hypervisors including Acropolis Hypervisor (AHV).

For more information on different designs, please review the design guidance information on TechNet.

Step by Step Install Guide

ADFS is installed as a role as shown below:ADFS-step1 ADFS-step2 ADFS-step3 ADFS-step4 ADFS-step5

Ok, that’s the easy part, now on to configuration.;)

Step by Step Configuration Guide

Welcome Active Directory Federation Services Configuration Wizard…!!
Before you begin your configuration, you must have the following:

  • An Active Directory domain administrator account.
  • A publicly trusted certificate for SSL server authentication installed in IIS before starting wizard.

AD FS prerequisites

ADFS-config-step1 ADFS-config-step2 ADFS-config-step3 ADFS-config-step4 ADFS-config-step5

This server will be configured as the primary server in a new AD FS farm ‘fs.poc.lan’. The configuration will be stored in Windows Internal Database. Windows Internal Database feature will be installed on this server if it is not already installed. All existing configurations in the database will be deleted. A group Managed Service Account POC\adfs$ will be created if it does not already exist and this host will be added as a member. Federation service will be configured to run as POC\adfs$.

If you click on View script, you can see the automated version:

# Windows PowerShell script for AD FS Deployment
Import-Module ADFS
-FederationServiceDisplayName:"ADFS POC" `
-FederationServiceName:"fs.poc.lan" `
-GroupServiceAccountIdentifier:"POC\adfs`$" `
The root key for the group Managed Service Account was created just before running the wizard.. If you have more than one domain controller in your Active Directory forest, the key may not yet have replicated to all domain controllers and therefore the service may not successfully install or start. To avoid service startup problems, wait 10 hours to ensure the key has replicated to all DCs before completing the Active Directory Federation Services Configuration Wizard, executing Install-AdfsFarm or Add-AdfsFarmNode on any other servers in your network, or restarting any AD FS service.


Verifying that AD FS is working fine:

Checkout your (IdentityProvider) IdP Sign-on landing page by navigating to https://fs./adfs/ls/IdpInitiatedSignon.aspx



And that’s how the is ADFS is initially setup, no matter you are a large or small environment, …Next up….Configuring Name Resolution and additional nodes…

Until next time….Rob

Understanding Identity with ADFS – Part 1

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,, 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 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 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 2.1

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

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.x\2012 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:
  • 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 AD domain.  This user is accessing a resource in the AD 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