Appendix A: Reviewing AD FS Requirements

Applies To: Windows Server 2008

So that the organizational partners in your Active Directory Federation Services (AD FS) deployment can collaborate successfully, you must first make sure that your corporate network infrastructure is configured to support AD FS requirements for accounts, name resolution, and certificates. AD FS 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

AD FS relies on server functionality that is built into the Windows Server 2008 operating system. The following table identifies the software requirements for each server hosting a specific AD FS role service.

Browser requirements

Although any current Web browser with JScript enabled can work as an AD FS 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 AD FS product team at Microsoft successfully tested the browser and operating system configurations in the following table.

Cookies

AD FS 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, AD FS cannot function correctly.

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

Network requirements

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

TCP/IP network connectivity

For AD FS 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 AD FS Web Agent.

DNS

The primary network service that is critical to the operation of AD FS, other than Active Directory Domain Services (AD DS), 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 2008 uses DNS for name resolution instead of the Windows Internet Name Service (WINS) 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, AD DS and AD FS require DNS name resolution.

The process of configuring DNS to support AD FS 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 AD FS, this infrastructure is assumed to be in place for your AD FS 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 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 AD FS-enabled Web servers. For more information, see Name Resolution Requirements for AD FS-Enabled Web Servers.

• You are setting up DNS for a test lab environment. If you plan to use AD FS 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 AD FS test lab environment, see Step-by-Step Guide for AD FS in Windows Server 2008 (https://go.microsoft.com/fwlink/?LinkId=85685).

Account store requirements

AD FS requires at least one account store to be used for authenticating users and extracting security 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).

Account store requirements depend on whether your organization is acting as the account partner (hosting the federated users) or the resource partner (hosting the federated 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 …
AD DS	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, AD DS is not required in the resource partner.
AD LDS	Want to allow locally stored identities to access federated applications (both claims-aware applications and Windows NT token–based applications) in a resource partner	Not required. AD LDS cannot be used to map federated users to local resource accounts or resource groups.

AD LDS

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

AD DS

For AD FS to operate successfully, 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, Windows Server 2003 R2, or Windows Server 2008.

Schema requirements

AD FS does not require schema changes or functional-level modifications to AD DS. To ensure that AD LDS works with AD FS, install the version of AD LDS that comes with Windows Server 2008.

Functional-level requirements

AD FS does not require AD DS 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, Windows Server 2003, or Windows Server 2008.

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 AD FS tokens can be mapped into either user accounts or groups, which the application then uses to perform authentication.

Authentication requirements

AD FS 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 AD FS 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, AD FS has no control over what credentials the user employs for Windows desktop logon.

Smart card logon

Although AD FS 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, AD FS 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 AD FS-protected Web servers.

Smart card authentication

Smart card authentication uses the Kerberos protocol to authenticate to an account federation server. AD FS 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 AD FS 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 AD DS 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 AD DS.

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