I’m preparing a post about Active Directory Federation Services (ADFS) 2.0 and SharePoint 2010 Integration, to tie in to my previous claims based authentication article.  Here’s a step by step guide to installing Active Directory Federation Services 2.0.

You can download ADFS 2.0 here: http://www.microsoft.com/downloads/details.aspx?FamilyID=118c3588-9070-426a-b655-6cec0a92c10b&displaylang=en

Installation went as follows, on a Windows 2008 R2 box. (This requires that Active Directory Domain Services is already up and running.)

Then the End-User License Agreement (EULA)

Now to choose between a Federation server and a Proxy. We want the first.  The options are Federation server, which is the main server, and a proxy which is designed to sit on the barrier of a firewall and which talks to the main federation server. Microsoft describes the federation server proxy as "an authentication and trust management provider that issues security tokens to enable access to claims based applications in your organization or in federated partner organizations."

Installation of prerequisites follows. (Windows PowerShell, .NET Framework 3.5 SP1, Web Server IIS, and Windows Identity Foundation)

The installer then checks that prerequisites are installed.

.. and installs Windows Identity Foundation (WIF) and then AD FS 2.0.

Now that ADFS 2.0 is installed, you’ll need to reboot your computer. Once it starts up again, go to Server Manager by clicking Start->Administrative Tools->Server Manager . Select the Server in the left tree view and then, in the Roles Summary section, click “Add Roles”

After selecting Add Roles, click next then tick the Active Directory Federation Services role, then hit next.

For this tutorial we will install the Federation Service, which is the main AD FS service, and also the AD FS Web Agents: Claims-aware Agent and Windows Token-based Agent.

Now we need to configure a certificate.

What are certificates? Basically they work as a key that is used to mathematically prove that a server is who it claims to be and to encrypt traffic. Certificates, or at least some way of proving identity, are essential in establishing trust.

As is standard with SSL Certificates the subject name must match the host name. Generally on a public network (internet or cloud) you will want to use a certificate issued by an external certification authority (CA), while on internal networks you will want your own certification authority.

On the server I’m using, many already existed, but in a testing environment you may select to create your own.

Next we do the same for assigning a certificate for the purpose of Token-Signing . This is used to prove that  generated tokens really were generated by a trusted federation server.

For the ADFS Web Agents we need to specify which federation server they should use. For this scenario I am pointing the Web Agents at the same server.

Now we need to create a Trust Policy, which defines what types of claims will be issued and accepted.

For this tutorial we’ll create a new Trust Policy, typically the step taken when creating a new farm.

Microsoft’s help files talk about using an existing trust policy across servers within a federation farm by placing the trustpolicy.xml in a shared folder secured through file system permissions. MS also cautions againt manually editing the file.

Finally we get a confirmation screen:

If all goes well, you’ll be presented with a successful installation results screen:

Now you can start configuring AD FS 2.0 in server manager. You may note the Active Directory Federation Services Role, in which you can configure the Federation Service, and the associated Trust Policy. It is broken into two elements:

• “My Organization”, which shows the Organization Claims, Account Stores, and Applications within your Organization; and
• “Partner Organizations” which is where you configure AD FS trust relationships.Including incoming and outgoing claims (Account Partners and Resource Partners)
• The default Organization Claims are Common  Name, E-mail, and User Principal Name.