When to create a federation server farm
Applies To: Windows Server 2003 R2
Consider installing additional federation servers when you have a larger Active Directory Federation Services (ADFS) 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.
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 ADFSAppPool 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. Unique token-signing certificates can be acquired 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 endpoint Uniform Resource Locator (URL) and Federation Service Uniform Resource Identifier (URI) fields, in the trust policy properties, to identify precisely which ADFS 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 because 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 automatically added 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 it to the trust policy). In this scenario, you do not have to manually add a verification certificate file to the trust policy. |
||
Add Common View State Element to the web.config file |
Add the For more information about this element, see How to Configure MachineKey in ASP.NET 2.0 (https://go.microsoft.com/fwlink/?LinkId=79067). |
.gif "note")
NoteEnable 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:
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.
On each federation server in the farm, configure the ADFSAppPool to run as the service account. In IIS Manager, navigate to the properties of ADFSAppPool (under the Application Pools folder), click the Identity tab, click Configurable, and type the new service account name and password. Repeat this task for each account federation server in the farm.
Because the application pool identity for ADFSAppPool 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. To obtain Setspn.exe, install the Windows Server 2003 Support Tools on a computer that is joined to the same domain where the user/service account resides. To install Support Tools, use your Windows Server 2003 CD. Navigate to the Support\Tools directory, double-click Suptools.msi, and follow the setup instructions. After you install the Support Tools, open a command prompt, and then type the following command:
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 ADFSAppPool is named adfsaccountfarm, type the command as follows:
setspn -a http:/fs.adatum.com adfsaccountfarm
It is necessary to complete this task only once for this account.
After the ADFSAppPool 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 ADFSAppPool can read the trust policy.