Determine your security token protection method

Applies To: Windows Server 2003 R2

You can use the Active Directory Federation Services snap-in to modify the way in which a federated application accepts security tokens from a resource federation server. This can be important when you have an application that requires a specific security-token-signing method, such as Public Key Infrastructure (PKI) or the Kerberos authentication protocol.

Security tokens that an ADFS-enabled Web server receives are signed and protected against tampering by resource federation servers using one of the following methods:

• PKI: The PKI method signs security tokens with the resource federation server's token-signing certificate. By default, the security-token-protection method in the Active Directory Federation Services snap-in is PKI.

• Domain service account: The domain service account method relies on the Kerberos authentication protocol to sign tokens using an assigned service principal name (SPN).

Federated applications that use PKI for token-signing have the following advantages over applications that use the domain service account method:

• PKI does not require the additional administrative overhead that is associated with manual configuration of service accounts for farmed federated applications.

• PKI can be used in scenarios in which you want an ADFS-enabled Web server, which hosts a federated claims-aware application, to not be joined to a domain (in a workgroup) or to be joined to a domain that is in a different domain than the domain that contains the resource federation server.

• PKI can be used to sign tokens in environments where Active Directory is not present, whereas the Kerberos protocol (which the domain service account method uses), relies on the Key Distribution Center (KDC) of Active Directory domain controllers to sign tokens.

Federated applications that use domain service account method (with the Kerberos authentication protocol) for token signing have the following advantages over PKI:

• The Kerberos protocol does not have the problem of certificate expiration because the expiration of Kerberos tickets is handled automatically.

• The Kerberos protocol provides better signing performance because it uses symmetric key operations, which are faster than the PKI asymmetric key operations.

For more information about how to configure either of these methods, see Configure the security token protection method for a federated application.

PKI method

The PKI method is the default value in the properties of the application in the Federation Service. This method is applied automatically when you create a new entry for a Windows NT token–based application or a claims-aware application. PKI is the default security-token-protection method because it does not require the additional configuration steps that the domain service account method requires.

When you use PKI as the security-token-protection method, the resource federation server signs only the tokens that are destined for the federated application (using the federation server's PKI-issued token-signing certificate) to protect the application from tampering.

Domain service account method

The domain service account security-token-protection method is an optional value in the properties of the application in the Federation Service. This method is identified by a service principal name (SPN). When a token is transferred using this method, the token contains a binary Kerberos V5 signature for the configured service account. This signature protects the token from tampering.

If you select the domain service account method and you are using a single ADFS-enabled Web server to host your federation application, no additional service account configuration is necessary. This is because the domain service account on ADFS-enabled Web servers defaults to HOST\<computername>. For example, if you select the domain service account method in the properties of the application in the Active Directory Federation Services snap-in and the computer name of your ADFS-enabled Web server is ws.treyresearch.net, you type HOST\ws.treyresearch.net. Typing HOST\ws is also acceptable, but the full DNS name of the computer is preferred.

However, if you will be using the domain service account method for a federated application that is hosted on an ADFS-enabled Web server farm (where two or more servers run the appropriate Web Agent and they are used to load-balance the same federated application), there are additional considerations. The following section describes those considerations.

Using the domain service account method in an ADFS-enabled Web server farm environment

When you farm a federated application across multiple ADFS-enabled Web servers, you configure each ADFS-enabled Web server in the farm so that it points to the same SPN that is configured in the domain service account settings of the resource Federation Service. Complete the following steps to successfully configure your environment for the domain service account security-token-protection method.

1. Create the service account

If the domain service account method is selected in the Federation Service, you must type the SPN for a service account in the properties of the application. Before you can enter the SPN for a service account, you must first create a dedicated service account. The Kerberos protocol needs this service account to function properly and to allow pass-through authentication to the ADFS-enabled Web server. This service account is a dedicated account (that is, it should be used only as a service account) that you create in the Active Directory forest in the resource partner organization.

2. Set the SPN for the new service account

Because the domain service account runs as a domain account, you must configure the SPN for this account in the domain. You configure the SPN with the Setspn command-line tool. Using a computer that is joined to the same domain where the service account resides, install Windows Server 2003 Support Tools to obtain Setspn.exe.

To install the Support Tools, on your Windows Server 2003 CD-ROM, go to the Support\Tools directory, double-click Suptools.msi, and follow the setup instructions. After you install the Support Tools, open a command-line prompt, type the following command, and then press ENTER:

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

For example, in the scenario in which all ADFS-enabled Web servers are clustered under the DNS host name https://ws.treyresearch.net and the service account name that is assigned to the domain service account is adfswsfarm, type the following command:

setspn -a http/ws.treyresearch.net adfswsfarm

You need to complete this task only once for this account.

3. Configure the Federation Service

Now you configure the resource Federation Service to use the same ADFS-enabled Web server SPN that you configured previously, but without specifying the service account name. You can configure this SPN value in the Domain service account box for the application in the Active Directory Federation Services snap-in.

For example, if you select the domain service account method and your ADFS-enabled Web server has a computer name of ws.treyresearch.net, type the SPN value of http/ws.treyresearch.net. Also, the format host/ws.treyresearch.net is also acceptable in this field.

4. Configure the service account on the ADFS-enabled Web server

Now that the Federation Service contains the domain service account value of the ADFS-enabled Web server SPN, configure each ADFS-enabled Web server in the farm to also use the identity of the service account. However, the location where you configure the service account for each ADFS-enabled Web server is different, depending on the type of federated application that you are deploying in the farm. The following table indicates where in the user interface (UI) you specify the service account on each ADFS-enabled Web server, depending on the type of application that you are deploying in the farm.

You can use the following steps to configure each of your ADFS-enabled Web servers—based on the type of federated application—to use the service account that is required for Kerberos token-signing in the domain service account security-token-protection method.

Claims-aware applications

Complete the following steps on each of the ADFS-enabled Web servers in the farm when you want to use claims-aware applications with the Kerberos authentication protocol:

1. Open IIS Manager.

2. In the console tree, double-click Application Pools, right-click the specific AppPool that your federated application is using, and then click Properties.

3. On the Identity tab, click Configurable, and then type the service account name and password.

4. Click OK to exit the property page.

5. Repeat these steps on each ADFS-enabled Web server in the farm.

Windows NT token–based applications

Complete the following prerequisite tasks on each of the ADFS-enabled Web servers in the farm to configure the service account so that it will function correctly with the ADFS Web Agent Authentication Service:

• Grant the service account the TrustedComputingBase (TCB) privilege. For more information about the TCB privilege, see Review the role of ADFS Web Agents.

• Grant the service account the Audit privilege so that you can view all logged security audit events.

• Add the service account to the local IIS_WPG group.

Complete the following steps on each of the ADFS-enabled Web servers in the farm when you want to use Windows NT token–based applications with the Kerberos authentication protocol.

1. Open the Services snap-in.

2. Right-click ADFS Web Agent Authentication Service, and then click Properties.

3. On the Log On tab, click This account, and then type the service account name and password.

4. Click OK to exit the property page.

5. Repeat these steps on each ADFS-enabled Web server in the farm.