Share via

Determine Your Security Token Protection Method

  • Article

Applies To: Windows Server 2008

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 AD FS-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 Active Directory Federation Services (AD FS)–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 AD FS-enabled Web server to host your federation application, no additional service account configuration is necessary. This is because the domain service account on AD FS-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 AD FS-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 AD FS-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 AD FS-enabled Web server farm environment

When you farm a federated application across multiple AD FS-enabled Web servers, you configure each AD FS-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 AD FS-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.

Note

To ensure that this service account is not interrupted as a result of domain password change requirements, consider configuring the account so that its password never expires. In the properties of the user account, select the Password never expires check box.

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 from a computer that is joined to the same domain where the service account resides. Setspn is installed by default on Windows Server 2008 computers, and you can run it directly from the command-line.

If you want to use a computer that is running Windows Server 2003 to run this command-line tool, you must first install Windows Server 2003 Support Tools to obtain Setspn.exe. To install 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 Support Tools, open a command-line window, type the following command, and then press ENTER:

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

For example, in the scenario in which all AD FS-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 have to complete this task only once for this account.

3. Configure the Federation Service

After you set the SPN for the new service account, you configure the resource Federation Service to use the same AD FS-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 AD FS-enabled Web server has a computer name of ws.treyresearch.net, type the SPN value of http/ws.treyresearch.net. The format host/ws.treyresearch.net is also acceptable in this field.

4. Configure the service account on the AD FS-enabled Web server

After the Federation Service contains the domain service account value of the AD FS-enabled Web server SPN, configure each AD FS-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 AD FS-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 AD FS-enabled Web server, depending on the type of application that you are deploying in the farm.

Federated application type Configure the following:

Claims-aware application

The IIS application pool identity that is used by the federated application

Windows NT token–based application

The AD FS Web Agent Authentication Service

You can use the following steps to configure each of your AD FS-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 procedure on each of the AD FS-enabled Web servers in the farm when you want to use claims-aware applications with the Kerberos authentication protocol.

Configure the service account on the AD FS enabled Web server for claims-aware applications

  1. Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.

  2. In the console tree, click Application Pools.

  3. In the center pane, right-click the specific AppPool that your federated application is using, and then click Advanced Settings.

  4. In the Advanced Settings dialog box, under Process Model, click Identity, and then click the … button.

  5. In the Application Pool Identity dialog box, click Custom account, and then click the Set button.

  6. In the Set Credentials dialog box, type the service account name and password, and then click OK three times.

  7. Repeat these steps on each AD FS-enabled Web server in the farm.

Windows NT token–based applications

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

  • Grant the service account the TrustedComputingBase (TCB) privilege. For more information about the TCB privilege, see Review the Role of AD FS 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 procedure on each of the AD FS-enabled Web servers in the farm when you want to use Windows NT token–based applications with the Kerberos authentication protocol.

Configure the service account on the AD FS-enabled Web server for Windows NT token–based applications

  1. Open the Services snap-in.

  2. Right-click AD FS 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 AD FS-enabled Web server in the farm.