Share via

When to Create a Federation Server Farm

  • Article

Applies To: Windows Server 2008

Consider installing additional federation servers when you have a larger Active Directory Federation Services (AD FS) deployment and you want to provide fault tolerance, load balancing, or scalability to your organization's Federation Service. The act of creating two or more federation servers in the same network, configuring each of them to use the same trust policy file, and adding the public key of each server's token-signing certificates (verification certificates) to the trust policy creates a federation server farm.

Before federation servers can be grouped as a farm, they must first be clustered so that requests arriving at a single fully qualified domain name (FQDN) are routed to the various federation servers in the server farm. You can create the server cluster by deploying Network Load Balancing (NLB) inside the corporate network. This guide assumes that NLB has been configured appropriately to cluster each of the federation servers in the farm.

For more information about how to configure a cluster FQDN using Microsoft NLB technology, see Specifying the Cluster Parameters (https://go.microsoft.com/fwlink/?LinkID=74651).

Best practices for deploying a federation server farm

The following best practices are recommended for deploying a federation server in a production environment:

  • If you will be deploying multiple federation servers at the same time or you know that you will be adding more servers to the farm over time, consider creating a server image of an existing federation server in the farm and then installing from that image when you need to create additional federation servers quickly.

Note

If you do decide to use the server image method for deploying additional federation servers, you do not need to complete the tasks in Checklist: Installing a Federation Server every time that you want to add a new server to the farm.

  • Use NLB or some other form of clustering to allocate a single IP address for many federation server computers.

  • Reserve a static IP address for each federation server in the farm and, depending on your Domain Name System (DNS) configuration, insert an exclusion for each IP address in Dynamic Host Configuration Protocol (DHCP). Microsoft NLB technology requires that each server that participates in the NLB cluster be assigned a static IP address.

  • Avoid editing the trust policy from multiple federation servers at the same time.

Configuring federation servers for a farm

The following table describes the tasks that must be completed so that each federation server can participate in a farmed environment.

Task Description

Store the trust policy file on a protected network shared folder

A federation server farm consists of two or more federation servers that share the same trust policy information and token-signing certificates. If you currently have one federation server and you will be adding additional federation servers, you will have to move the location of the trustpolicy.xml file to a protected network shared folder so that it can be accessed by all new federation servers that participate in the farm.

Note
For farmed scenarios, it is important that the trust policy file be shared on a computer that does not also participate as a federation server in that farm. Microsoft NLB does not allow any of the computers that participate in a farm to communicate with one another.

After the trustpolicy.xml file has been placed in a shared folder, you protect that share with the appropriate permissions. This means that for each new federation server to successfully share a trust policy file, you must provide at least Read-only access permissions to each of the machine accounts on every federation server in the farm. The administrator of the Federation Service will be able to modify the trust policy file even though the machine accounts have Read-only permissions.

Note

Ensure that the identity of the AD FS AppPool on every federation server that participates in the farm has Read access to the shared trust policy file.

Obtain and share certificates

A single server authentication certificate can be obtained from a public certification authority (CA)—for example, VeriSign—and then configured so that all federation servers share the same private key portion of the certificate. For more information about how to share the same certificate, see Checklist: Configuring Certificates for a Federation Server.

You can obtain unique token-signing certificates for each federation server, or you can obtain one certificate and share it among all other federation servers in the farm. For more information, see Certificate Requirements for Federation Servers.

Point to the trust policy file location

The new federation server must point to the same trust policy file that is used by other federation servers in the farm so that the new server can participate in the farm. The federation server uses the values that are specified in the Federation Service endpointUniform Resource Locator (URL) and Federation Service Uniform Resource Identifier (URI) fields, in the trust policy properties, to identify precisely which AD FS instance, or Federation Service, it belongs to.

Note

After you point the new federation server to the existing trust policy file location successfully (which is typically done at setup time), you do not have to alter the existing URL and URI values that are specified in the properties of the trust policy. This information is shared, and it applies to every federation server in the farm.

Add the verification certificate to the trust policy

The public key of the token-signing certificate that is assigned to the new federation server must be added to the trust policy. The public key of the token-signing certificate is also referred to as the verification certificate.

This certificate is added automatically to the trust policy when you select an existing trust policy during the installation of the Federation Service or when you select a different token-signing certificate using the Active Directory Federation Services snap-in. (Click Yes when you are prompted to add the certificate to the trust policy.)

In this scenario, you do not have to manually add a verification certificate file to the trust policy.

Add the Common View State Element to the web.config file

Add the <pages enableViewStateMac="true"/> element under the <system.web> section of the web.config file on each of the federation servers that participate in the farm. You must configure this element in the web.config file to post form data and to prevent view state validation failures.

For more information about this element, see How to Configure MachineKey in ASP.NET 2.0 (https://go.microsoft.com/fwlink/?LinkId=79067).

Enable Windows Integrated authentication in the account partner

You must complete the following tasks in the account partner organization when you want to allow clients on the corporate network to authenticate to any of the federation servers in the farm using Windows Integrated authentication:

  1. Create a dedicated user/service account in the Active Directory forest that is located in the account partner organization. This account is necessary for the Kerberos authentication protocol to work in a farm scenario and to allow pass-through authentication on each of the federation servers. Use this account only for the purposes of the federation server farm. To ensure that this service account's function is not interrupted as a result of domain password change requirements, configure the account (in the properties of the user account) so that the password never expires. (Select the Password never expires check box.)

Note

Using the Network Service account for this dedicated account will result in random failures when access is attempted through Windows Integrated authentication as a result of Kerberos tickets not validating from one server to another.

  1. On each federation server in the farm, configure the AD FS AppPool to run as the service account:

    1. In IIS Manager, click AD FS AppPool (under Application Pools in the console tree).

    2. In the Actions pane, click Advanced Settings, click Identity, and then click the … button.

    3. In the Set Credentials dialog box, click Custom account, click Set, and then type the new service account name and password.

    4. Repeat this task for each account federation server in the farm.

  2. Because the application pool identity for AD FS AppPool is running as a domain user/service account, you must configure the Service Principal Name (SPN) for that account in the domain using the Setspn.exe command-line tool. Setspn.exe is installed by default on computers running Windows Server 2008. Run the following command on a computer that is joined to the same domain where the user/service account resides.

    setspn -a <http/<farmclusterdnsname> <serviceaccountname>

    For example, in a scenario in which all federation servers are clustered under the DNS host name https://fs.adatum.com and the service account name that is assigned to the AD FS AppPool is named adfsaccountfarm, type the command as follows, and then press ENTER:

    setspn -a http:/fs.adatum.com adfsaccountfarm

    It is necessary to complete this task only once for this account.

  3. After the AD FS AppPool identity is changed to the service account, set the access control lists (ACLs) on the trust policy file to allow Read access to this new account so that AD FS AppPool can read the trust policy.