Compartilhar via

Configuring Advanced Options for AD FS 2.0

  • Artigo

Updated: May 17, 2012

Applies To: Active Directory Federation Services (AD FS) 2.0

This topic provides advanced Active Directory Federation Services (AD FS) 2.0 configuration and deployment options that can be helpful when you need to plan for single sign-on access to Microsoft Office 365 or other cloud services.

For more information about how to configure single sign-on access to Office 365 using AD FS 2.0, see Prepare for single sign-on on the Office 365 content portal.

Disable the Extended Protection for Authentication feature in AD FS 2.0

Certain client browser software, such as Firefox, Chrome, and Safari, do not support the Extended Protection for Authentication capabilities that can be used across the Windows platform to protect against man-in-the-middle attacks. To prevent this type of attack from occurring over secure AD FS communications, AD FS 2.0 enforces (by default) that all communications use a channel binding token (CBT) to mitigate against this threat.

However, if it is important that browser clients that do not support Extended Protection for Authentication must be used in your organization, you will have to adjust a feature setting in AD FS 2.0 that will disable the CBT from being used over communications, which, in turn, may leave client credentials vulnerable to man-in-the-middle attacks.

If this is the case, you can disable the Extended Protection for Authentication feature by using the Windows PowerShell cmdlet Set-ADFSProperties in the following procedure.

To disable the Extended Protection for Authentication feature in AD FS 2.0

  1. On a federation server, login using the Administrator account, open the Windows PowerShell command prompt, and then type the following command:

    Set-ADFSProperties –ExtendedProtectionTokenCheck None

  2. Repeat this step on each federation server in the farm.

Using the Federation Server Farm with SQL Server deployment topology

For most AD FS 2.0 deployments, Microsoft recommends the Federation Server Farm with WID and Proxies deployment topology as the default choice. In this topology, AD FS 2.0 uses the Windows Internal Database (WID) as the AD FS 2.0 configuration database for all federation servers that are joined to that farm. This WID farm replicates and maintains the Federation Service data in the configuration database across each server in the farm.

The Federation Server Farm with SQL Server deployment topology uses Microsoft SQL Server for the configuration database store, and all federation servers in the farm read and write to a common SQL Server database instance. This deployment topology is typically reserved for more advanced AD FS 2.0 deployments that require one or more of the following criteria:

  • Geographic load-balancing

  • High availability

  • Additional performance enhancements, including the ability to scale out using more than five federation servers (WID is limited to five federation servers per farm)

  • The need to use SAML token replay detection to protect the integrity of authentication requests by making sure that the same token is never used more than once

    The need to use SAML artifact resolution to direct browser clients with an artifact to a SAML artifact endpoint URL for resolution

For more information about SAML token replay detection and SAML artifact resolutions, see The Role of the AD FS Configuration Database.

For more detailed information about the benefits of using this topology, see Federation Server Farm Using SQL Server and Proxies.

Change the AD FS 2.0 service account password

There are several steps required to efficiently change the password for the AD FS 2.0 service account across all of the federation servers in a federation server farm. Depending on the type of AD FS configuration database you are using for your organizations federation server farm, click the most applicable link below to display the steps necessary for you to change the AD FS 2.0 service account password.

Customize the federation server proxy sign-in page for two-factor authentication

For more information about how to customize the federation server proxy sign-in page using two-factor authentication, see AD FS 2.0 Step-by-Step Guide: Integration with RSA SecurID in the Extranet

Use a third-party proxy instead of a federation server proxy

For more information about what the configuration requirements are for third-party proxies to work with AD FS 2.0 federation servers, see Using a Third-Party Proxy as a Replacement to an AD FS 2.0 Federation Server Proxy.

Limit Access to Office 365 Services Based on a Client’s location

For more information about how AD FS 2.0 can be used to enforce client access policies that restrict access to Office 365 services, see Limiting Access to Office 365 Services Based on the Location of the Client.

Support for Identity Provider Initiated RelayState

For more information about how AD FS 2.0 servers running Update Rollup 2 for AD FS 2.0 can support RelayState, see Supporting Identity Provider Initiated RelayState.

See Also

Other Resources

AD FS 2.0 Content Map
Plan for and deploy AD FS 2.0 for use with single sign-on to Office 365
Description of Update Rollup 2 for Active Directory Federation Services (AD FS) 2.0