Appendix A: Reviewing ADFS Requirements

Applies To: Windows Server 2003 R2

So that the organizational partners in your Active Directory Federation Services (ADFS) deployment can collaborate successfully, you must first make sure that your corporate network infrastructure is configured to support ADFS requirements for accounts, name resolution, and certificates. ADFS has the following types of requirements:

• Hardware requirements

• Software requirements

• Browser requirements

• Network requirements

• Account store requirements

• Authentication requirements

The following sections describe these requirements.

Hardware requirements

The following minimum and recommended hardware requirements apply to the federation server, federation server proxy, and Web server computers.

Software requirements

ADFS relies on server functionality that is built into the Windows Server 2003 R2 operating system. The Federation Service, Federation Service Proxy, and ADFS Web Agent components cannot run on other operating systems. The following table identifies the software requirements for each server hosting a specific ADFS component.

Browser requirements

Although any current Web browser with JScript enabled can work as an ADFS client, only Internet Explorer 6, Internet Explorer 5 or 5.5, Mozilla Firefox, and Safari on Apple Macintosh have been tested by Microsoft. For performance reasons, we highly recommend that JScript be enabled. Cookies must be enabled, or at least trusted, for the federation servers and Web applications that are being accessed.

The ADFS product team at Microsoft successfully tested the browser and operating system configurations in the following table.

Cookies

ADFS creates authentication cookies that must be stored on client computers to provide single-sign-on (SSO) functionality. Therefore, the client browser must be configured to accept cookies. Authentication cookies are always Secure Hypertext Transfer Protocol (HTTPS) session cookies that are written for the originating server. If the client browser is not configured to allow these cookies, ADFS cannot function correctly.

The authentication cookie is signed but not encrypted, which is one reason why use of TLS/SSL is mandatory in ADFS.

Network requirements

Configuring the following network services appropriately is critical for a successful deployment of ADFS in your organization.

TCP/IP network connectivity

For ADFS to function, TCP/IP network connectivity must exist between the client; a domain controller; and the computers that host the Federation Service, the Federation Service Proxy (when it is used), and the ADFS Web Agent.

DNS

The primary network service that is critical to the operation of ADFS, other than Active Directory, is Domain Name System (DNS). When DNS is deployed, users can use friendly computer names that are easy to remember to connect to computers and other resources on IP networks.

Windows Server 2003 uses DNS for name resolution instead of the Windows Internet Name Service (WINS) network basic input/output system (NetBIOS) name resolution that was used in Windows NT 4.0-based networks. It is still possible to use WINS for applications that require it. However, Active Directory and ADFS require DNS name resolution.

The process of configuring DNS to support ADFS varies, depending on whether:

• Your organization already has an existing DNS infrastructure. In most scenarios, DNS is already configured throughout your network so that Web browser clients in your corporate network have access to the Internet. Because Internet access and name resolution are requirements of ADFS, this infrastructure is assumed to be in place for your ADFS deployment.

• You intend to add a federated server to your corporate network. For the purpose of authenticating users in the corporate network, internal DNS servers in the corporate network forest must be configured to return the CNAME of the internal server that is running the Federation Service. For more information, see Name resolution requirements for federation servers.

• You intend to add a federated server proxy to your perimeter network. When you want to authenticate user accounts that are located in the corporate network of your account partner organization, the internal DNS servers in the corporate network forest must be configured to return the canonical name (CNAME) of the internal federation server proxy. For information about how to configure DNS to accommodate the addition of federation server proxies, see Name resolution requirements for federation server proxies.

  Name resolution requirements are also necessary for ADFS-enabled Web servers. For more information, see Name resolution requirements for ADFS-enabled Web servers.

• You are setting up DNS for a test lab environment. If you plan to use ADFS in a test lab environment where no single root DNS server is authoritative, it is likely that you will have to set up DNS forwarders so that queries to names between two or more forests will be forwarded appropriately. For general information about how to set up an ADFS test lab environment, see Step-by-Step Guide for Active Directory Federation Services (https://go.microsoft.com/fwlink/?LinkId=49531).

Account store requirements

ADFS requires at least one account store to be used for authenticating users and extracting security claims for those users. ADFS supports two types of account stores: Active Directory and Active Directory Application Mode (ADAM).

Account store requirements depend on whether your organization is acting as the account partner (hosting the federated users) or the resource partner (hosting the federation application). Use the following table to determine the best account store type to use for your partner role in the federation.

Account store type	Can be used by account partners who:	Is required by resource partners who:
Active Directory	Want to allow locally stored identities to access federated applications (both claims-aware applications and Windows NT token–based applications) in a resource partner	Need to grant access permissions for Windows NT token–based applications to federated users in an account partner. Each federated user must be mapped to a resource account or resource group in a local Active Directory domain. Note If federated users need access to only claims-aware applications, Active Directory is not required in the resource partner.
ADAM	Want to allow locally stored identities to access federated applications (both claims-aware applications and Windows NT token–based applications) located in a resource partner	Not required. ADAM cannot be used to map federated users to local resource accounts or resource groups.

ADAM

For ADFS to operate successfully, computers that host the ADAM account store must be running Windows® 2000 Server with Service Pack 4 (SP4) and critical updates, Windows Server 2003 with Service Pack 1 (SP1), or Windows Server 2003 R2.

Active Directory

For ADFS to operate successfully, Active Directory domain controllers in either the account partner organization or the resource partner organization must be running Windows 2000 Server SP4 with critical updates, Windows Server 2003 SP1, or Windows Server 2003 R2.

Schema requirements

ADFS does not require schema changes or functional-level modifications to Active Directory. To ensure that ADAM works with ADFS, install the version of ADAM that comes with Windows Server 2003 R2.

Functional-level requirements

ADFS does not require Active Directory functional-level modifications to operate successfully. However, if you are using Windows NT token–based applications and you want a token to be generated using Kerberos Service-for-User (S4U), the domain functional level must be Windows 2000 native or Windows Server 2003.

Windows NT token–based application requirements

As indicated in the previous table, Windows NT token–based applications require an Active Directory local user store. Incoming ADFS tokens can be mapped into either user accounts or groups, which the application then uses to perform authentication.

Authentication requirements

ADFS integrates naturally with existing Windows authentication, for example, Kerberos authentication, NTLM, smart cards, and X.509 v3 client-side certificates. Federation servers use standard Kerberos authentication to authenticate the user against the domain. Clients can authenticate by using forms-based, smart card, and Windows Integrated authentication, depending on how you configure authentication.

What ADFS can do is require SSL client authentication at an account federation server proxy. You can configure a corporate network-connected account federation server to require SSL client authentication. However, typically you configure the account federation server for Windows integrated authentication to provide a seamless Web single-sign-on (SSO) experience for corporate network users. In this situation, ADFS has no control over what credentials the user employs for Windows desktop logon.

Smart card logon

Although ADFS can enforce the type of credentials that it uses for authentication (passwords, SSL client authentication, or Windows Integrated authentication), it does not directly enforce authentication with smart cards. Therefore, ADFS does not provide a client-side user interface (UI) to obtain smart-card personal identification number (PIN) credentials. This is because Windows-based clients intentionally do not provide user credential details to federation servers or ADFS-protected Web servers.

Smart card authentication

Smart card authentication uses the Kerberos protocol to authenticate to an account federation server. ADFS cannot be extended to add new authentication methods. The certificate in the smart card is not required to chain up to a trusted root on the client computer. Use of a smart card–based certificate with ADFS requires the following conditions:

• The reader and cryptographic service provider (CSP) for the smart card must work on the computer where the browser is located.

• The smart card certificate must chain up to a trusted root on the account federation server and the account federation server proxy.

• The certificate must map to user account in Active Directory by either of the following methods:

  • The certificate subject name corresponds to the Lightweight Directory Access Protocol (LDAP) distinguished name of a user account in Active Directory.

  • The certificate subject altname extension has the user principal name (UPN) of a user account in Active Directory.