Export (0) Print
Expand All

Appendix A: Reviewing AD FS Requirements

Updated: February 5, 2009

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.

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

 

Hardware requirement Minimum requirement Recommended requirement

CPU speed

133 megahertz (MHz)

550 MHz

RAM

128 megabytes (MB)

256 MB

Disk space

10 MB

100 MB

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.

 

Server hosting the Federation Service role service Server hosting the Federation Service Proxy role service Server hosting the AD FS Web Agent role service

Windows Server 2008 Enterprise or Windows Server 2008 Datacenter

Windows Server 2008 Enterprise or Windows Server 2008 Datacenter

Windows Server 2008 Standard, Windows Server 2008 Enterprise, or Windows Server 2008 Datacenter

Internet Information Services (IIS)

IIS

IIS

Microsoft ASP.NET 2.0

Microsoft ASP.NET 2.0

Microsoft ASP.NET 2.0

Microsoft .NET Framework 2.0

Microsoft .NET Framework 2.0

Microsoft .NET Framework 2.0

A default Web site that is configured with Transport Layer Security / Secure Sockets Layer (TLS/SSL)

A default Web site that is configured with TLS/SSL

At least one Web site in IIS must be configured with TLS/SSL so that federated users can access Web-based applications that are hosted on the Web server.

noteNote
The Federation Service and Federation Service Proxy components cannot coexist on the same computer.

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.

 

Browser Windows Server 2008 Windows Server 2003 Windows XP Windows 2000 Windows 98 Macintosh OS X

Internet Explorer 7.0

X

N/A

N/A

N/A

N/A

N/A

Internet Explorer 6.0

N/A

X

X

X

X

N/A

MSN 9.0

X

X

X

X

N/A

N/A

Netscape 8.0

X

X

X

X

X

X

Netscape 7.2

X

X

X

X

X

X

Netscape 4.8 

X

X

X

X

X

N/A

FireFox 1.0.7

X

X

X

X

X

N/A

Safari

X

N/A

N/A

N/A

N/A

X

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.

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

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.

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 (http://go.microsoft.com/fwlink/?LinkId=85685).

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.

noteNote
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.

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.

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.

ImportantImportant
Because AD FS requires the installation of Internet Information Services (IIS), we strongly recommend that you not install any AD FS role services on a domain controller in a production environment for security purposes.

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.

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.

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.

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.

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 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.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft