Inside Microsoft.comUsing Active Directory Federation Services

Jim Guthrie

Here at Microsoft we provide an extranet to give our business partners access to important internal resources. The architecture of the extranet requires that each participant outside the organization have a unique domain account for this space. This account is created and managed by Microsoft employees rather than the

partners, for obvious reasons. However, while functional, the experience for the user may be less than satisfying and the burden on Microsoft to manage all those partner users is somewhat resource-intensive.

Here’s how the extranet works now. When a customer or partner signs into an application, he is required to enter his credentials. During the same ses­sion, if that user decides to access a different resource he will again be prompted for his credentials. This continues as long as he bounces from one resource to the next. If the user were to sign into a single application that uses multiple resources, such as a financial database, he would have to authenticate to each resource independently. This can be a cumbersome and annoying experience for users.

Fortunately, by using Active Di­rec­tory® Federation Services (ADFS), we can solve the multiple-authentication problem quite easily, and so can you. ADFS is a Windows Server® 2003 R2 component that facilitates a trust between two or more organizations to allow the sharing of multiple resources while maintaining each organization’s ability to manage its own set of users. In this column, I illustrate how Microsoft plans to use ADFS to solve this multiple-resource extranet problem, which will provide you with the information you need to implement a similar solution. Before I get into the details, however, take a look at Figure 1 to familiarize yourself with some of the basic ADFS terminology.

Figure 1 ADFS terminology

An ADFS Solution

When a user attempts to access an ADFS-aware application, the browser is sent to the Federation Service Resource (FS-R) for realm discovery. Here the user will select which set of credentials she will use for the duration of the session. Based on the realm the client has chosen, she will next be redirected to the Federation Service Accounts (FS-A) server. It is at this server that she will receive a valid account token (in a cookie) that is based on the credentials she input in the form of a Windows Live™ ID (formerly a Passport account), Win­dows Integrated Authentication, or SSL authentication (see Figure 2). In this model, it is up to the individual organizations to maintain their own account federation server. In the case of the Mi­cro­soft partner servers, this removes the burden on Microsoft.com to manage every account in the environment. Of course, if you implement that level of responsibility you must carefully select the organizations with which you will federate, and ensure that they are actively managing their account information.

Figure 2** ADFS flow **(Click the image for a larger view)

The next stop on the route is back to the FS-R server to exchange the account token for a resource token. In our configuration, this token contains a complete list of the permissions the user has been granted through a claims-mapping process that is performed on the FS-R. Once the token has been received, that user gets the single sign-on (SSO) capability on ADFS-aware applications for as long as the session is open, or up to 24 hours by default (this window is configurable). The upshot is that you have enabled SSO to these ADFS-aware applications, resulting in a more secure and efficient customer experience. For a complete walkthrough of the ADFS authentication process, see Matt Steele’s article from the July 2006 issue of TechNet Magazine entitled "Simplify Single Sign-on with ADFS".

To maintain the security of Mi­cro­soft corporate resources, we have isolated the internet-facing side of the extranet from the corporate side, meaning that each server is potentially dual-homed. We allow a one-way trust from corporate internal users and utilize the servers to provide the needed protection. We also have a separate domain for the extranet space where we provide external users with access to the needed resources.

Two main areas of concern during implementation were load balancing and the ADFS policy file changes. Load balancing was a challenge at both a global and local level. Initially in production we will use global load balancing from our Content Delivery Network (CDN) partners Akamai or Savvis for the front-end Web server clusters in two regions. This will ensure availability of the system to end users even in the unlikely event a pair of regional servers go offline. This is accomplished with failover automation based on server health-checking services provided by the CDNs. Additionally, we have the ability to easily add more clusters in the future. As a cost savings, our preproduction deployments have elected not to use the CDN service.

At the regional level we have paired up the servers for local failover through network load balancing (NLB) clustering. We are not using any special load-balancing features, so this could have just as easily been accomplished with hardware; however, again we are using NLB for the cost savings. This configuration will provide the stability to ensure greater than 99.9 percent uptime in all supported environments.

Another challenge we faced was ensuring that the ADFS policy file, the backbone of ADFS, was correctly distributed throughout our environment and that changes to it are replicated as well. To achieve this, we leverage another built-in feature of Windows Server 2003 R2—Distributed File Sys­tem-Replication (DFS-R), a new state-based multi-master replication engine. On each of the back-end servers we have enabled a DFS-R group membership with a 24-hour, full-mesh replication. Now, no matter where the change to the policy file happens, it will be distributed to all servers. As long as we control who can change the file, we have a stable, highly available service.

We have tried to ensure that all changes be made through the ADFS snap-in. However, in practice we found we must occasionally update this file manually. When updating manually it’s important to remember that ADFS tracks the version of this file. Therefore you must increment the file so your changes will be reflected in the environment:

<TrustPolicyEntryUri>urn:federation:parttestint</TrustPolicyEntryUri> 
<TrustPolicyVersion>127
</TrustPolicyVersion> 

You also have to remember that, like all XML, the policy XML file is case sensitive. Throughout the policy XML file there are many references to the applications or other ADFS servers and in all cases they must be copied verbatim from server to server. Please note the following common examples where the first, RevocationCheckFlags, was manually entered and the second is a trusted application URL modified from the UI:

<RevocationCheckFlags>None
</RevocationCheckFlags>
<TrustPolicyEntryUri>https://adfstest.parttest.extranettest.microsoft.com/NTApp/
</TrustPolicyEntryUri>

For an additional level of security we use another component of ADFS, the Federation Service Proxy (FS-P), which ensures that the FS-Rs remain a layer removed from direct access from incoming Internet requests. A unique way we have implemented proxies at Microsoft.com is through the use of a single set of proxies to host several ADFS environments in our preproduction area. Interestingly, during the initial ramp-up on the technology we discovered that we needed to make a simple registry key modification in order for this to happen. The key is located at HKLM\Software\Micro­soft\WebSSO. Simply changing the value of the initial directory in this key will allow you to use the proxy for several environments. The default was:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttestint”

To switch environments, the key would change like so:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttest”

Creating a batch file can simplify the management of this process. Un­for­tunately the current version of the MMC snap-in for ADFS doesn’t support switching environments as there is a one-to-one relationship between the proxy and the resource or account server. This is the only way to maximize the utilization of the proxy servers. The end result is that this is a tremendous cost savings as it limits the number of physical servers required no matter how many different environments you choose to host.

From an architectural standpoint we are running our preproduction environment with virtual machines—another cost-saving measure. This eliminates the need to purchase and house six additional servers. To date, we have had no performance problems. However, to meet the significantly increased demand in the production environment we have elected to use higher-performing physical machines.

Not Just for Active Directory

Not only is Microsoft.com using Active Directory accounts for authentication, but we have also successfully integrated with Windows Live ID accounts. We’ve found that by using Windows Live ID (WLID) 4.5, we can use an individual’s Windows Live ID account to delegate access to Microsoft resources using a custom claims transform. This is a huge win for achieving the SSO authentication as we no long­er require a specific domain account.

Remaining Challenges

The biggest challenge we are facing right now is the management of ADFS for sharing token-signing certificates. We are using standard certificates that remain valid typically for one year before requiring renewal. At renewal time each of the appropriate servers will need to be updated accordingly, which will have significant impact on the FS-Rs. While marginally manageable with 15 or 20 federations, the scale we would like to think about is at least in the hundreds if not thousands. This would require full-time staffing for the management of SSL certificates for a single environment. We have several teams looking at the best methods to automate this solution but have not settled on a course of action.

Another remaining challenge is that not all applications are ADFS-aware out of the box. There will be some programming required for the sites to take advantage of the ADFS opportunity. We are working closely with the Microsoft® Office SharePoint® Services team to ensure that the next generation of SharePoint will support our implementation needs for ADFS.

Conclusion

There are a number of factors to consider in making the decision to move to an ADFS model. One is the number of resources customers will access. The process of setting up a federated trust between organizations can be a trivial task, but it takes time and effort to write, review, and execute acceptable access policies. So if you have just one resource your customers will access, you will have to decide if it’s worth the effort. However, as the number of resources grows, the benefits increase.

If you’re looking for more information, see the ADFS Overview and Active Directory Federation Services: A Path to Federated Identity and Access Management.

Jim Guthrie works for Microsoft on the Microsoft.com Operations team where, in addition to working with ADFS, he is a Systems Engineer with the Enterprise Portal Platform Support team.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.