Active Directory Federation Services (AD FS) makes it possible for local users and federated users to use claims-based single sign-on (SSO) to Web sites and services. You can use AD FS to enable your organization to collaborate securely across Active Directory domains with other external organizations by using identity federation. This reduces the need for duplicate accounts, management of multiple logons, and other credential management issues that can occur when you establish cross-organizational trusts.

For more information about AD FS, see the Active Directory Federation Services TechCenter web page (http://go.microsoft.com/fwlink/?LinkId=194245).

What is ADFS 2.0?

Active Directory Federation Services (AD FS) 2.0 simplifies access to systems and applications by using a claims-based access (CBA) authorization mechanism to maintain application security. AD FS supports web SSO technologies that help information technology (IT) organizations collaborate across organizational boundaries. AD FS 2.0 is a downloadable Windows Server 2008 update that is the successor to AD FS 1.0, which was first delivered in Windows Server 2003 R2, and AD FS 1.1, which was made available as a server role in Windows Server 2008 and Windows Server 2008 R2. Previous versions of AD FS are referred to collectively as AD FS 1.x.

Note
The version of AD FS that is available as a server role in Server Manager is a previous version of AD FS, AD FS 1.x. To maximize the benefits described here for your AD FS deployment, we recommend that, wherever possible, you download and install the updated AD FS 2.0 release as a Windows Server update for use with Windows Server 2008 and Windows Server 2008 R2. Do not attempt to add the AD FS server role in Server Manager when your intended goal is to evaluate or deploy AD FS 2.0 in your organization.

An AD FS 2.0 system includes a Windows Server 2008–based server or a Windows Server 2008 R2–based server running AD FS 2.0—a freely available, downloadable release. Deploying an AD FS 2.0 system provides the following benefits to your organization:

• Secure, federated collaboration. Applications such as word processors, e-mail clients, and line-of-business applications can be AD RMS-enabled to help safeguard sensitive information Users can define who can open, modify, print, forward, or take other actions with the information. Organizations can create custom usage policy templates such as "confidential - read only" that can be applied directly to the informAD FS makes it possible for organizations to collaborate securely across Active Directory domains by using identity federation. Federated identity provides identity portability and the assembly of an identity metasystem by enabling linking of multiple identity sub-systems together.
• Less administrative overhead. By using federated trust to manage access to resources across the secure boundaries that separate two organizations, you can reduce the need for duplicate accounts and other credential management overhead. AD FS streamlines setup and teardown by allowing you to making secure federated trusts that enable SSO across organizations, platforms, and applications and then as needed, remove such trusts.
• Identity delegation. Identity delegation is a feature of AD FS 2.0 that allows administrator-specified accounts to impersonate users. With identity delegation, applications can be authorized to impersonate their users when they access infrastructure services, even when the original users do not have local accounts. For more information, see When to Use Identity Delegation.
• Step-up authentication. You can use step-up authentication for multi-factor authentication processing, which can enhance security for authorization and access in your identity partnerships. For example, with step-up authentication websites can easily request smart-card authentication for particular operations.

AD FS 2.0 provides all of the same features of AD FS 1.x, along with an updated Microsoft Management Console (MMC) snap-in and a new command-line interface that enables full management of an AD FS federation server using Windows PowerShell cmdlets. These tools help you manage all aspects of your AD FS deployment, such as token signing, encryption, claims provisioning, and a full processing engine for issuing and transforming claims-based requests. So that you can create customized AD FS solutions, an AD FS software development kit (SDK) is also available.

Advantages of Deploying AD FS

The primary advantage of AD FS is that it enables organizations to use federated partnerships when they plan for cross-organizational identity. You can think of federation as a two organizations agreeing to facilitate user access and support sharing of collaborative applications, with each organization retaining responsibility for managing their own IT assets and user accounts.

This section describes some of the reasons why you might want to deploy AD FS 2.0 to help develop federated identity management solutions.

SSO

SSO simplifies access for trusted users, enabling them to reuse the session credentials that they have already applied and authenticated to reauthorize access to all other resources in a networked environment. Traditionally, organizations have benefited from SSO within the secure boundaries of intranets.
For example, in a typical Active Directory, single-forest deployment, users are often able to use integrated Windows authentication seamlessly to access internal sites and applications that accept their current domain user security context. But with business-to-business (B2B) and other scenarios in which access crosses secure boundaries, SSO as a feature is often lost or compromised.

To preserve SSO functionality when enabling sign-on across secure organizational boundaries, AD FS provides an SSO implementation that has the following benefits:

• Opportunities for passwords to be “phished” (learned) are minimized.
• The need for redundant logon exchanges can be reduced.
• Token-based authentication mechanisms are used that are cryptographically strong.
• There is less repeating and resubmitting of user names and passwords that can lead to fatigue or higher helpdesk support costs.

Increased support for open and industry-standard identity protocols

AD FS 1.x addressed web SSO needs by offering support for passive clients (that is, web browsers) with open and interoperable standards, such as the WS-Federation and WS-Trust protocols. AD FS 2.0 extends standards support by providing interoperability with the SAML 2.0 protocol and support for active clients (that is, Web services).

Compatibility with a wider assortment of identity platforms and products.

By adding support for SAML 2.0, as well as successfully completing interoperability testing for AD FS 2.0 with the Liberty Alliance (a group of vendors that have agreed to support SAML 2.0), Microsoft has enabled Windows Systems that run AD FS 2.0 to work with a wider range of federated identity products.

Claims-based access

In the context of digital identities, claims are statements that one party (a person, organization, or thing) makes about itself or another party. For example, claims can be made about the name, age, role, or other characteristics of a person. These claims can be made by a person directly or provided to others by a third party. Other parties can rely on the values of the claims to perform a process of digital identification.

Claims and their use in computing are not new. They have been around since the earliest days of computing. For example, whenever an operating system prompts a user for their name and password for login, the information is passed to each new application that requests verification of the user as a claim about that user. In a closed computing system, the request for claims and processing of them can be handled directly and a built-in level of trust can often be presumed.

But as systems have become more complex, using multiple networks, products, and vendors, the need to identify and validate "claimants" (users who present claims about themselves) across multiple computers has greatly increased. This demand has spurred numerous attempts to define how access is accomplished—in a way that is open and standard for multiple systems and yet highly secure.

A number of mechanisms and services have been introduced to help authenticate users and provide access and, subsequently, provide claims to any applications that request or rely on claims. Examples of claims-based authentication technologies include NTLM, Kerberos, Public Key Infrastructure (PKI), and the Security Assertion Markup Language (SAML).

If claims are not new, what is it about working with claims that AD FS provides that is different? It's the ability to work with claims across a mixture of these authentication technologies and others in a more secure and effective way. At its most basic level, AD FS 2.0 works with claims and uses its Federation Service in the following ways:

• When a Federation Service is configured in the claims provider role, it serves as a claimsproducer—authenticating users and issuing outgoing claims on their behalf. In this role, the Federation Service can retrieve claims data from an attribute store and then send that information back in the form of tokens.
• When a Federation Service is configured in the relying party role, it can also serve as a claimsconsumer—processing and trusting the incoming tokens that other claims providers pass to it. While relying parties often can simply be applications that are claims aware and that are able to process these tokens, in this role, AD FS 2.0 also supports federated identity scenarios in which a relying party validates or handles claims that another claims provider issues. More precisely, a Federation Service in the relying party role looks at and validates claims that some other Federation Service asserts and, upon successful validation, it either reaffirms those claims to its relying parties or it asserts additional or even different claims in the token that it issues.

The benefit of using claims-aware identity are that it:

• Makes it possible for developers of private or internal applications within organizations to simplify identity issues that they must resolve to meet business requirements. Using a claim-based approach, a developer can incorporate an open, flexible process for authenticating and verifying users.
• Makes it possible for IT professionals to extend access privileges to other people outside their organization—either in a trusted partner organization or to users on the Internet—without incurring the overhead of creating and managing new user accounts for external users or reducing service isolation and the overall security of their deployments.

For more information about how claims work, see The Role of Claims (http://go.microsoft.com/fwlink/?LinkId=182444) in the AD FS 2.0 Design Guide.

Features in AD FS

AD FS 2.0 includes the following features.

An enterprise claims provider for claims-based applications

Applications that are built on the claims-based identity model have several advantages for IT professionals. These applications:

• Provide an SSO experience across multiple claims-aware applications.
• Provide access to a claims-aware application to users in another organization.
• Reduce concern about developers of custom applications making processor-intensive authentication requests that unexpectedly burden an organization’s directory services.

A Federation Service for identity federation across domains

You can configure AD FS 2.0 in the Federation Service role so that web browser and web service applications can use federated web SSO across domains. This helps reduce administrative overhead, reduce security vulnerabilities as a result of lost or stolen passwords, and improve user productivity through SSO.

Improved support for federation trusts

AD FS 2.0 has improved support for federation trusts that can speed up the process of establishing the trusts. AD FS 2.0 uses industry-standard metadata formats when it establishes trusts between federation partners. This makes it possible for you to add trusts quickly. It also makes certificate management easier between partners because AD FS 2.0 automatically provides the appropriate certificates to the partner when it creates the trust. For more information, see Claims Providers (http://go.microsoft.com/fwlink/?LinkId=194249) and Relying Parties (http://go.microsoft.com/fwlink/?LinkId=194250).

An enhanced snap-in management console

The AD FS 2.0 Management snap-in is a single MMC 3.0 snap-in. It provides a graphical user interface (GUI) for configuring service and policy settings that are used most commonly with AD FS 2.0.

Hardware and software considerations

AD FS runs on a computer running the Windows Server 2008 or Windows Server 2008 R2 operating systems. When AD FS 2.0 is installed or the AD FS server role is added, all required services are installed, one of which is Internet Information Services (IIS). AD FS also requires an Active Directory Domain Services (AD DS) forest and a configuration database, such as Windows Internal Database or Microsoft SQL Server, which you can run either on the same server as AD FS or on a remote server.

The following table describes the minimum hardware requirements and recommendations for running Windows Server 2008–based servers and Windows Server 2008 R2–based servers with the AD FS server role.

Requirement	Recommendation
Single-core 1 GHz processor or higher	Quad-core 2 GHz processors or higher
1 GB of RAM	4 GMB of RAM
50 MGB of free hard disk space	100 MB of free hard disk space

To assist with your hardware considerations, use testing in a lab environment, data from existing hardware in a production environment, and pilot roll-outs to determine the necessary capacity for your server.

The following table describes the software requirements for running Windows Server 2008–based servers and Windows Server 2008 R2–based servers with the AD FS server role. For requirements that can be met by enabling features on the operating system, installing the AD FS server role configures those features as appropriate, if they are not already configured.

Software	Requirement
Operating system	Windows Server 2008 or Windows Server 2008 R2, except for Windows Web Server 2008 or Windows Web Server 2008 R2
Active Directory Domain Services	AD FS 2.0 must be installed on a member server in an Active Directory domain.
Database server	AD FS 2.0 requires a database server, such as Windows Internal Database or Microsoft SQL Server for storing configuration data. Other database options, such as AD DS or AD LDS, are available for storing attributes.
Web services	IIS 7 is required for AD FS 2.0.
Additional updates	A number of updates to Windows Server 2008 are required for installation of AD FS 2.0. For more information, seeInstall the AD FS 2.0 Software (http://go.microsoft.com/fwlink/?LinkId=194251).

For more detailed information about hardware and software considerations for AD FS 2.0, see Appendix A: Reviewing AD FS 2.0 Requirements in the AD FS 2.0 Design Guide (http://go.microsoft.com/fwlink/?LinkId=192810).

For more information about hardware and software requirements for the previous version of AD FS that was delivered in Windows Server 2008 and Windows Server 2008 R2, seeRequirements for AD FS (http://go.microsoft.com/fwlink/?LinkId=194253).

Installing AD FS

The process for installing AD FS 2.0 is different than the one provided for adding previous versions of AD FS that are part of Windows Server 2008 or Windows Server 2008 R2. Be sure to use the instructions that are appropriate to the version of AD FS you are choosing to deploy in your environment.

Install AD FS 2.0

To install AD FS 2.0, refer to the instructions provided in Install the AD FS 2.0 Software (http://go.microsoft.com/fwlink/?LinkID=194251). For detailed instructions about installing and configuring AD FS 2.0 in a test environment, see the AD FS 2.0 Federation with a WIF Application Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkID=193997).

Install AD FS 1.x

After you finish installing the operating system, you can use Initial Configuration Tasks or Server Manager to install server roles. To install AD FS, in the list of tasks, click Add roles, and then click the Active Directory Federation Services check box.

For detailed instructions about installing and configuring AD FS 1.x in a test environment using Windows Server 2008, see the AD FS Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkID=194254). For an updated version of these instructions that is specific to installing AD FS 1.x in a test environment using Windows Server 2008 R2, see the AD FS in Windows Server 2008 R2 Step-by-Step Guide (http://technet.microsoft.com/en-us/library/dd378921(WS.10).aspx).

Managing AD FS

You can use an MMC snap-in to manage server roles, including AD FS.

Manage AD FS 2.0

Use the AD FS 2.0 console to manage AD FS 2.0. To open the AD FS 2.0 console, click Start, point to Administrative Tools, and then click AD FS 2 .0.

Manage AD FS 1.x

Use the Active Directory Federation Services console to manage AD FS 1.x. To open the Active Directory Federation Services console, click Start, point to Administrative Tools, and then click Active Directory Federation Services.  

For more information

To learn more about AD FS, you can view the Help on your server. To view the Help, open the AD FS 2.0 or Active Directory Federation Services console, and then press F1, or visit the Active Directory Federation Services TechCenter (http://go.microsoft.com/fwlink/?LinkID=194245). For information about AD FS 1.0 for Windows Server 2003 R2, see the Step-by-Step Guide for Active Directory Federation Services (http://go.microsoft.com/fwlink/?LinkId=49531).