You’ve been reading about cloud computing, and how you can use identity federation to securely extend your internal identity systems to cloud service providers. You’ve been studying the dance of many steps that comprises claims-based authentication within federation. But it’s not the same as doing it yourself. How do you gain some hands-on experience with federation? In a Windows shop, one option is to spend time with the AD FS 2.0 Step-by-Step and How To Guides. I’ve been working through these guides recently; the experience highlights not only how little Active Directory Federation Services (AD FS) shares with AD but also what the average AD administrator’s skill set looks like.

In fact, about the only thing that AD FS shares with AD are the words Active Directory. AD FS is grouped with Active Directory Domain Services (AD DS) because—along with Forefront Identity Manager (FIM), Active Directory Certificate Services (AD CS), Active Directory Rights Management Services (AD RMS), and Active Directory Lightweight Directory Services (AD LDS, though everyone stills calls it ADAM)—it’s an important component of Microsoft’s overall identity and access management (IAM) portfolio. These products are listed as peers on the Windows Server 2008 R2 AD page, but if you think of your IAM strategy in layers, AD FS is built on top of AD DS and AD CS. Therefore, you should think of it as an additional skill set on top of these two technologies. This also means that if you’ve never gotten around to learning about how public key infrastructure (PKI) and certificates work, now’s the time to get started.

Information about AD FS is scattered across a number of locations on the Microsoft website, so it’s easy to get confused about where to start. An important point to remember is that you’ll be working with AD FS 2.0 (code-named Geneva in beta, so you’ll see a number of Geneva references), which is a major improvement from the original 1.0 version. The AD FS 2.0 Step-by-Step and How To Guides contain twelve guides. Some show you how to use AD FS with Microsoft Business Productivity Online Suite (BPOS)/Office 365, Windows Azure, and Microsoft SharePoint. A key tenet of federation is its ability to work with other federation products that use the standard Security Assertion Markup Language (SAML) protocol, so other guides show how to interoperate AD FS with PingFederate, Shibboleth 2, CA Federation Manager, and IBM Tivoli Federated Manager.

The best place to get started is the second-from-last walkthrough, Federated Document Collaboration Using Microsoft Office SharePoint Server 2007 and AD FS 2.0. Although it's the most complicated lab—and certainly the most complicated lab setup—it’s where you need to start so that you can work with all the moving parts of federated identity. There are two ways to approach this lab. The first way is to build it up yourself. Just below the SharePoint step-by-step guide is the How to Set Up the AD FS 2.0 VM Lab Environment for Federated Collaboration guide, which helps you build the SharePoint lab environment. No trivial exercise, this 50-page document guides you precisely through building four virtual machines (VMs), two domains, and the associated services necessary (which I’ll describe shortly). Get one sentence wrong, and you’ll have to go back and fix it somewhere down the line. It’s time-consuming, and it requires licenses for Windows Server 2008 R2, SharePoint 2007, SQL Server 2005 and 2008 R2, and Office Professional 2007. However, the best way to learn a new technology is often to build up the environment to become familiar with its underpinnings. (I’ve posted an annotated PDF version of this guide here.)

The other way to approach this lab is hidden in the SharePoint walkthrough: Download preconfigured Hyper-V VMs. This method will save you a lot of time on the front end, allowing you to focus on testing the federation scenarios. Be aware, though, that you won’t get the experience of actually installing AD FS, and because this preconfigured lab (and we’re talking about four OS instances and four server products that require license keys) contains nothing but trial versions, once you set up the lab you need to take your test drive quickly before it pulls a Mission Impossible and self-destructs. (Tip: You can extend the life of the OS instances by running Slmgr.vbs –rearm from an administrative command prompt. Doing so will extend the evaluation period by 60 days.)

The SharePoint federation lab is a business-to-business (B2B) scenario between two pharmaceutical companies, Fabrikam and Contoso Pharmaceuticals, as Figure 1 shows. Fabrikam is a pharmaceutical supply company, and Contoso is a drug manufacturer. Some Fabrikam employees need access to audit Contoso’s drug-trial information, which is stored on a SharePoint 2007 service that’s been made claims-aware by installing the Microsoft Federation Extensions for SharePoint. The lab shows how—by using AD FS to federate identities between Fabrikam and Contoso—Fabrikam drug-trial auditors can access the Contoso drug-trial documents on SharePoint without needing a separate account on Contoso.

Figure 1: The SharePoint federation lab




To minimize confusion in often-complicated federation scenarios, I always try to think of myself as being in the identity provider’s role, and that role is always on the left side of the architecture diagram. Remember, the identity provider is the one that contains the identities (in this case, from AD) that will be extended to the service (in this case, Contoso’s SharePoint server).


The SharePoint federation lab document is 96—that’s right, 96—pages long. And it's primarily made up of steps to be taken after you’ve either downloaded the VMs or gone through the 50-page lab-build document. The good news is that (unlike the lab-build document) the SharePoint document is made up primarily of screenshots. This makes the exercise much easier that it would have been otherwise, as in this case a picture really is worth a thousand words—and reduces tenfold the chance you might goof something up midway through the lab.

This lab is also easier than it might first appear because you don’t have to go through the entire document if you want to just see how federation works. (Watching federation work, by the way, is hugely anticlimactic. Because it’s single sign-on, federation is working correctly when, well, nothing happens. The cool part is that this "nothing" happens across security boundaries where something used to happen—like a credentials prompt—or you simply weren’t able to do it at all.) The SharePoint lab contains 11 steps, but you only need to get through step 7 if you just want to watch federation in action.

If you’ve gone to all the trouble to get this far, however, you really should step through the rest of the lab. Step 8 shows how you can also use a SQL Server database as an attribute store that AD FS can access to generate claims. Step 9 shows how to configure AD FS and SharePoint to use AD RMS for digital rights management of documents. Finally, step 10 shows how to configure a second document library to use strong authentication to access its documents.

The two key VMs in this lab are FABRIKAMSRV01 and CONTOSOSRV01. They fulfill multiple roles for the lab, whereas FABRIKAMSRV02 is essentially an Office 2007 user (though it’s installed on a server) and CONTOSOSRV02 is a SharePoint server (which requires IIS and SQL Server as components). First, FABRIKAMSRV01 and CONTOSOSRV01 provide domain services through AD DS to create the FABRIKAM and CONTOSO domains. Note that because these lab domains have only one DC each, you don’t have to worry about problems such as replication failing between DCs because the machines have been shut down, saved, or paused for greater than the tombstone lifetime. Second, they have DNS installed to support AD DS.

Third, FABRIKAMSRV01 and CONTOSOSRV01 both have AD FS installed. FABRIKAMSRV01’s AD FS runs the claims provider STS (security token service—the service that generates SAML tokens) in this scenario. It’s called the claims provider because it generates the claims necessary for SharePoint access from the user’s AD attributes. Confusingly, STS is often used interchangeably with federation server or AD FS. CONTOSOSRV01’s AD FS runs the relying-party STS—so called because it relies on the claims coming from the claims provider.

Fourth, AD CS is also installed on FABRIKAMSRV01 and CONTOSOSRV01. This service provides each domain with a certificate authority (CA), which will generate certificates to prove the authenticity of the claims that each domain’s STS will issue. Finally, IIS is installed on each to support both AD CS and AD FS.

If you have any intention of keeping up to date with identity and its future direction, I highly recommend that you install and work through at least the AD FS SharePoint lab. Doing so will show you the foundations on which AD FS is built, as well as a typical B2B scenario that you can use AD FS for. The lab also provides hands-on, guided experience working with claims as they make their way from the identity provider’s STS to the service provider’s STS to the claims-aware application. Finally, it highlights the areas you need to learn or brush up on, such as IIS or Certificate Services. Though it’s an identity technology, federation in general and AD FS in particular isn't something you learn overnight. Get a head start on understanding this important identity component by getting started on this lab.

Sean writes about cloud identity, Microsoft hybrid identity, and whatever else he finds interesting at his blog on Enterprise Identity and on Twitter at @shorinsean.