Active Directory Federation Services (ADFS)

Federation Services were originally introduced in Windows Server 2003 R2. F provides an identity access solution, and AD Federation Services provides authenticated access to users inside (and outside) an organization to publicly (via the Internet) accessible applications. Federation Services provides an identity management solution that interoperates with WS-* Web Services Architecture–enabled security products. WS-Federation Passive Requestor Profile (WS-F PRP) also makes it possible for federation to work with solutions that do not use the Microsoft standard of identity management. The WS-Federation specification defines an integrated model for federating identity, authentication, and authorization across different trust realms and protocols. This specification defines how the WS-Federation model is applied to passive requestors such as Web browsers that support the HTTP protocol. WS-Federation Passive Requestor Profile was created in conjunction with some pretty large companies, including IBM, BEA Systems, Microsoft, VeriSign, and RSA Security.

What Is Federation?

As we described earlier in this chapter, federation is a technology solution that makes it possible for two entities to collaborate in a variety of ways. When servers are deployed in multiple organizations for federation, it is possible for corporations to share resources and account management in a trusted manner. Earlier in this chapter, we were discussing Active Directory Rights Management Server. This is just one way companies can take advantage of FS. With ADFS, partners can include external third parties, other departments, or subsidiaries in the same organization.

Why and When to Use Federation

Federation can be used in multiple ways. One product that has been using federation for quite some time is Microsoft Communication Server (previously, Live Communication Server 2005, now rebranded as Office Communication Server 2007). Federation is slightly different in this model, where two companies can federate their environments for the purposes of sharing presence information. This makes it possible for two companies to securely communicate via IM, Live Meeting, Voice, and Video. It also makes it possible to add “presence awareness” to many applications, including the Office suite, as well as Office SharePoint Server. If you want to know more about OCS and how federation works for presence, we recommend How to Cheat at Administering Office Communication Server 2007, also by Elsevier.

A little closer to home, Federation Services can also be used in a variety of ways. Let’s take an extranet solution where a company in the financial service business shares information with its partners. The company hosts a Windows SharePoint Services (WSS) site in their DMZ for the purposes of sharing revenue information with investment companies that sell their products. Prior to Active Directory Federation Services, these partners would be required to use a customer ID and password in order to access this data. For years, technology companies have been touting the ability to provide and use single sign-on (SSO) solutions. These worked great inside an organization, where you may have several different systems (Active Directory, IBM Tivoli, and Solaris), but tend to fail once you get outside the enterprise walls.

With AD FS, this company can federate their DMZ domain (or, their internal AD) with their partner Active Directory infrastructures. Now, rather than creating a username and password for employees at these partners, they can simply add the users (or groups) to the appropriate security groups in their own Active Directory (see Figure 1). It is also important to note that AD FS requires either Windows Server 2008 Enterprise edition or Datacenter edition.

Figure 1. The Active Directory Federation Services Structure

Configuring ADFS

In this exercise, we are going to create the account side of the ADFS structure. The resource is the other half of the ADFS configuration, which is the provider of the service that will be provided to an account domain. To put it in real-world terms, the resource would provide the extranet application to the partner company (the account domain).

Configuring Federation Services 1. Click Start | Administrative Tools | Server Manager. 2. Scroll down to Role Summary, and then click Add Roles. 3. When the Before You Begin page opens, click Next. 4. On the Select Server Roles page, select Active Directory Federation Services (see Figure 2) from the list and click Next. Figure 2. Selecting the Role 5. Click Next on the Active Directory Federation Services page. 6. In the Select Role Services window, select Federation Service, and then click Next. If prompted, add the additional prerequisite applications. 7. Click Create A Self-Signed Certificate For SSL Encryption (Figure 3), and then click Next. Figure 3. Creating a Self-Signed Token-Signing Certificate 8. Click Create A Self-Signed Token-Signing Certificate, and then click Next. 9. Click Next on the Select Trust Policy page. 10. If prompted, click Next on the Web Server (IIS) page. 11. If prompted, click Next on the Select Role Services page. 12. On the Confirm Installation Selections page, click Install. 13. When the installation is complete, click Close. The next step in configuring AD FS is to configure IIS to require SSL certificates on the Federation server: 1. Choose Start | Administrative Tools | Internet Information Services (IIS) Manager. 2. Double-click the server name. 3. Drill down the left pane to the Default Web Site and double-click it. 4. Double-click SSL Settings and select Require SSL. 5. Go to Client Certificates and click Accept. Then, click Apply (Figure 4). Figure 4. Requiring Client Certificates 6. Click Application Pools. 7. Right-click AD FS AppPool, and click Set Application Pool Defaults. 8. In the Identity pane (Figure 5), click LocalSystem, and then click OK. Figure 5. Setting Application Pool Defaults 9. Click OK again. 10. Before we close IIS, we need to create a self-signed certificate. Double-click the server name again. 11. Double-click Server Certificates. 12. Click Create Self-Signed Certificate. 13. In the Specify Friendly Name field, enter the NetBIOS name of the server and click OK. Next, we need to configure a resource for use with AD FS. In this case, we are going to use the same domain controller to double as a Web server. What we will be doing is installing the AD FS Web Agent, essentially adding an additional role to the server, as part of the AD FS architecture. This will allow us to use our federated services within a Web application. 1. Choose Start | Administrative Tools | Server Manager. Scroll down to Role Summary, and then click Add Roles. 2. When the Before You Begin page opens, click Active Directory Federation Services. 3. Scroll down to Role Services and click Add Role Services. 4. In the Select Role Services window, select Claims-aware Agent (Figure 6), and then click Next. Figure 6. Setting Services 5. Confirm the installation selections (Figure 7), and then click Install. Figure 7. Confirming the Installation 6. When installation is complete, click Close. Now we need to configure the trust policy which would be responsible for federation with the resource domain. 1. Choose Start | Administrative Tools | Active Directory Federation Services. 2. Expand Federation Service by clicking the + symbol (see Figure 8). Figure 8. AD FS MMC 3. Right-click Trust Policy, and then choose Properties. 4. Verify the information in Figure 9 matches your configuration (with the exception of the FQDN server name), and then click OK. Figure 9. Trust Policies 5. When you return to the AD FS MMC, expand Trust Policy and open My Organization. 6. Right-click Organization Claims, and then click New | Organization Claim. 7. This is where you enter the information about the resource domain. A claim is a statement made by both partners and is used for authentication within applications. We will be using a Group Claim, which indicates membership in a group or role. Groups would generally follow business groups, such as accounting and IT. 8. Enter a claim name (we will use PrepGuide Claim). Verify that Group Claim is checked as well before clicking OK. 9. Create a new account store. Account stores are used by AD FS to log on users and extract claims for those users. AD FS supports two types of account stores: Active Directory Domain Services (AD DS) and Active Directory Lightweight Directory Services (AD LDS). This makes it possible to provide AD FS for full Active Directory Domains and AD LDS domains. 10. Right-click Account Store and choose New | Account Store. 11. When the Welcome window opens, click Next. 12. Since we have a full AD DS in place, select Active Directory Domain Services (AD DS) from the Account Store Type window (Figure 10), and then click Next. Figure 10. The Account Store Type Window 13. Click Next on the Enable This Account Store window. 14. Click Finish on the completion page. Now, we need to add Active Directory groups into the Account Store. 1. Expand Account Stores. 2. Right-click Active Directory, and then click New | Group Claim Extraction. 3. In the Create A New Group Claim Extraction window (Figure 11), click Add and click Advanced. Figure 11. The Create A New Group Claim Extraction Window 4. Click Object Types, remove the checkmarks from everything except Groups, and then click OK. 5. Click Find Now. 6. Select Domain Admins from the list of groups by double-clicking. 7. Click OK. 8. The Map To This Organization Claim field should show the claim we created earlier. Click OK to close the window. Finally, we will work to create the partner information of our resource partner, which is prepguides.ads. 1. Expand Partner Organizations. 2. Right-click Resource Partners, and then select New | Resource Partner. 3. Click Next on the Welcome window. 4. We will not be importing a policy file, so click Next. 5. In the Resource Partner Details window (Figure 12), enter a friendly name for the partner, and the URI and URL information of the partner. Note it is identical to what we entered earlier in Figure 9. When the information is complete, click Next. Figure 12. Resource Partner Details 6. Click Next on the Federation Scenario page. This is the default selection, which is used for two partners from different organizations when there’s no forest trust. 7. On the Resource Partner Identity Claims page, check UPN Claim and click Next. A UPN Claim is based on the domain name of your Active Directory structure. In our case, the UPN is uccentral.ads. 8. Set the UPN suffix. Verify that Replace All UPN Suffixes With The Following: is selected and then enter your server’s domain name. This is how all suffixes will be sent to the resource partner. Click Next. 9. Click Next to enable the partner. 10. Click Finish to close the wizard. We’re almost at the end of our account partner configuration. The last thing we need to do is create an outgoing claim mapping. This is part of a claim set. On the resource side, we would create an identical incoming claim mapping. 1. Expand Resource Partners. 2. Right-click your resource partner, and then choose New | Outgoing Group Claim Mapping. 3. Select the claim we created earlier, enter PrepGuide Mapping, and then click OK.

As you can imagine, this process would be duplicated on the resource domain, with the exception that the outgoing claim mapping would be replaced with an incoming mapping.