Home » Posts tagged 'ADFS'

Tag Archives: ADFS

Advertisements

Federation Server Farm Using WID and Proxies

This deployment topology for Active Directory Federation Services (AD FS) 2.0 is identical to the federation server farm with Windows Internal Database (WID) topology, but it adds federation server proxies to the perimeter network to support external users. The federation server proxies redirect client authentication requests that come from outside your corporate network to the federation server farm.

This section describes various considerations about the intended audience, benefits, and limitations that are associated with this deployment topology.

  • Organizations with 100 or fewer configured trust relationships that need to provide both their internal users and external users (who are logged on to computers that are physically located outside the corporate network) with single sign-on (SSO) access to federated applications or services
  • Organizations that need to provide both their internal users and external users with SSO access to Microsoft Office 365
  • Smaller organizations that have external users and require redundant, scalable services

To deploy this topology, in addition to adding two federation server proxies, you must make sure that your perimeter network can also provide access to a Domain Name System (DNS) server and to a second Network Load Balancing (NLB) host. The second NLB host must be configured with an NLB cluster that uses an Internet-accessible cluster IP address, and it must use the same cluster DNS name setting as the previous NLB cluster that you configured on the corporate network (fs.fabrikam.com). The federation server proxies should also be configured with Internet-accessible IP addresses.

The following illustration shows the existing federation server farm with WID topology that was described previously and how the fictional Fabrikam, Inc., company provides access to a perimeter DNS server, adds a second NLB host with the same cluster DNS name (fs.fabrikam.com), and adds two federation server proxies (fsp1 and fsp2) to the perimeter network.

Federation Server Farm with WID & Proxies Topology

For more information about how to configure your networking environment for use with federation servers or federation server proxies, see either Name Resolution Requirements for Federation Servers or Name Resolution Requirements for Federation Server Proxies.

Source: https://technet.microsoft.com/en-us/library/gg982488(v=ws.10).aspx

Advertisements

Best Practices for Secure Planning and Deployment of AD FS 2.0

This topic provides best-practice information to help you plan and evaluate security when you design your Active Directory Federation Services (AD FS) 2.0 deployment. This topic is a starting point for reviewing and assessing considerations that affect the overall security of your use of AD FS 2.0. The information in this topic is meant to compliment and extend your existing security planning and other design best practices.

The following core best practices are common to all AD FS 2.0 installations where you want to improve or extend the security of your design or deployment:

  • Use the Security Configuration Wizard to apply AD FS-specific security best practices to federation servers and federation server proxy computers 

    The Security Configuration Wizard (SCW) is a tool that comes preinstalled on all Windows Server 2008 and Windows Server 2008 R2 computers. You can use it to apply security best practices that can help reduce the attack surface for a server, based on the server roles that you are installing.

    When you install AD FS 2.0, the setup program creates role extension files that you can use with the SCW to create a security policy that will apply to the specific AD FS 2.0 server role (either federation server or federation server proxy) that you choose during setup.

    Each role extension file that is installed represents the type of role and subrole for which each computer is configured. The following role extension files are installed in the %systemroot%\Active Directory Federation Services 2.0\Scw directory: 

    • Farm.xml
    • SQLFarm.xml
    • StandAlone.xml
    • Proxy.xml (This file is present only if you configured the computer in the federation server proxy role.)

    To apply the AD FS 2.0 role extensions in the SCW, complete the following steps in order:

    1. Install AD FS 2.0 and choose the appropriate server role for that computer. For more information, see Install the AD FS 2.0 Software in the AD FS 2.0 Deployment Guide.
    2. Register the appropriate role extension file using the Scwcmd command-line tool. See the following table for details about using this tool in the role for which your computer is configured.
    3. Verify that the command has completed successfully by examining the SCWRegister_log.xml file, which is located in the %systemroot%\security\Msscw\Logs directory.

    You must perform all these steps on each federation server or federation server proxy computer to which you want to apply AD FS 2.0–based SCW security policies. 

    The following table explains how to register the appropriate SCW role extension, based on the AD FS 2.0 server role that you chose on the computer where you installed AD FS 2.0.

     

    AD FS 2.0 server role AD FS configuration database used Type the following command at a command prompt:

    Stand-alone federation server

    Windows Internal Database

    scwcmd register /kbname:ADFS2Standalone /kbfile:"%programfiles%\Active Directory Federation Services 2.0\scw\StandAlone.xml"

    Farm-joined federation server

    Windows Internal Database

    scwcmd register /kbname:ADFS2Standalone /kbfile:"%programfiles%\Active Directory Federation Services 2.0\scw\Farm.xml"

    Farm-joined federation server

    SQL Server

    scwcmd register /kbname:ADFS2Standalone /kbfile:"%programfiles%\Active Directory Federation Services 2.0\scw\SQLFarm.xml"

    Federation server proxy

    N/A

    scwcmd register /kbname:ADFS2Standalone /kbfile:"%programfiles%\Active Directory Federation Services 2.0\scw\Proxy.xml"

    For more information about the databases that you can use with AD FS 2.0, see The Role of the AD FS Configuration Database.

  • Use token replay detection in situations in which security is a very important concern, for example, when kiosks are used. 
    Token replay detection is a feature of AD FS 2.0 that ensures that any attempt to replay a token request that is made to the Federation Service is detected and the request is discarded. Token replay detection is enabled by default. It works for both the WS-Federation passive profile and the Security Assertion Markup Language (SAML) WebSSO profile by ensuring that the same token is never used more than once.

    When the Federation Service starts, it begins to build a cache of any token requests that it fulfills. Over time, as subsequent token requests are added to the cache, the ability to detect any attempts to replay a token request multiple times increases for the Federation Service. If you disable token replay detection and later choose to enable it again, remember that the Federation Service will still accept tokens for a period of time that may have been used previously, until the replay cache has been allowed enough time to rebuild its contents. For more information, see The Role of the AD FS Configuration Database.

  • Use token encryption, especially if you are using supporting SAML artifact resolution. 

    Encryption of tokens is strongly advised to increase security and protection against potential man-in-the-middle (MITM) attacks that might be tried against your AD FS 2.0 deployment. Using use encryption might have a slight impact on throughout but in general, it should not be usually noticed and in many deployments the benefits for greater security exceed any cost in terms of server performance.

    To enable token encryption, first set add an encryption certificate for your relying party trusts. You can configure an encryption certificate either when creating a relying party trust or later. To add an encryption certificate later to an existing relying party trust, you can set a certificate for use on the Encryption tab within trust properties while using the AD FS 2.0 snap-in. To specify a certificate for an existing trust using the AD FS 2.0 cmdlets for Windows PowerShell, use the EncryptionCertificate parameter of either the Set-ClaimsProviderTrust or Set-RelyingPartyTrust cmdlets. To set a certificate for the Federation Service to use when decrypting tokens, use the Set-ADFSCertificate cmdlet and specify "Token-Encryption" for the CertificateType parameter. Enabling and disabling encryption for specific relying party trust can be done by using the EncryptClaims parameter of the Set-RelyingPartyTrust cmdlet.

  • Utilize extended protection for authentication 

    To help secure your deployments, you can set and use the extended protection for authentication feature with AD FS 2.0. This setting specifies the level of extended protection for authentication supported by a federation server. 

    Extended protection for authentication helps protect against man-in-the-middle (MITM) attacks, in which an attacker intercepts client credentials and forwards them to a server. Protection against such attacks is made possible through a Channel Binding Token (CBT) which can be either required, allowed, or not required by the server when it establishes communications with clients. 

    To enable the extended protection feature, use the ExtendedProtectionTokenCheck parameter on the Set-ADFSProperties cmdlet. Possible values for this setting and the level of security that the values provide are described in the following table.

     

    Parameter Value Security level Protection setting

    Require

    Server is fully hardened.

    Extended protection is enforced and always required.

    Allow

    Server is partially hardened.

    Extended protection is enforced where systems involved have been patched to support it.

    None

    Server is vulnerable.

    Extended protection is not enforced.

  • If you are using logging and tracing, ensure the privacy of any sensitive information. 

    AD FS 2.0 does not, by default, expose or track personally identifiable information (PII) directly as part of the Federation Service or normal operations. When event logging and debug trace logging are enabled in AD FS 2.0, however, depending on the claims policy that you configure some claims types and their associated values might contain PII that might be logged in the AD FS 2.0 event or tracing logs. 

    Therefore, enforcing access control on the AD FS 2.0 configuration and its log files is strongly advised. If you do not want this kind of information to be visible, you should disable loggin, or filter out any PII or sensitive data in your logs before you share them with others.

    The following tips can help you prevent the content of a log file from being exposed unintentionally:

    • Ensure that the AD FS 2.0 event log and trace log files are protected by access control lists (ACL) that limit access to only those trusted administrators who require access to them.
    • Do not copy or archive log files using file extensions or paths that can be easily served using a Web request. For example, the .xml file name extension is not a safe choice. You can check the Internet Information Services (IIS) administration guide to see a list of extensions that can be served.
    • If you revise the path to the log file, be sure to specify an absolute path for the log file location, which should be outside of the Web host virtual root (vroot) public directory to prevent it from being accessed by an external party using a Web browser.

The following security best practices are specific to the use of Microsoft SQL Server® or Windows Internal Database (WID) when these database technologies are used to manage data in AD FS 2.0 design and deployment.

noteNote
These recommendations are meant to extend, but not replace, SQL Server product security guidance. For more information about planning a secure SQL Server installation, see Security Considerations for a Secure SQL Installation (http://go.microsoft.com/fwlink/?LinkID=139831).

  • Always deploy SQL Server behind a firewall in a physically secure network environment. 

    A SQL Server installation should never be exposed directly to the Internet. Only computers that are inside your datacenter should be able to reach your SQL server installation that supports AD FS 2.0. For more information, see Security Best Practices Checklist(http://go.microsoft.com/fwlink/?LinkID=189229). 

  • Run SQL Server under a service account instead of using the built-in default system service accounts. 

    By default, SQL Server is often installed and configured to use one of the supported built-in system accounts, such as the LocalSystem or NetworkService accounts. To enhance the security of your SQL Server installation for AD FS 2.0, wherever possible use a separate service account for accessing your SQL Server service and enable Kerberos authentication by registering the security principal name (SPN) of this account in your Active Directory deployment. This enables mutual authentication between client and server. Without SPN registration of a separate service account, SQL Server will use NTLM for Windows-based authentication, where only the client is authenticated.

  • Minimize the surface area of SQL Server. 

    Enable only those SQL Server endpoints that are necessary. By default, SQL Server provides a single built-in TCP endpoint that cannot be removed. For AD FS 2.0, you should enable this TCP endpoint for Kerberos authentication. To review the current TCP endpoints to see if additional user-defined TCP ports are added to a SQL installation, you can use the "SELECT * FROM sys.tcp_endpoints" query statement in a Transact-SQL (T-SQL) session. For more information about SQL Server endpoint configuration, see How To: Configure the Database Engine to Listen on Multiple TCP Ports (http://go.microsoft.com/fwlink/?LinkID=189231). 

  • Avoid using SQL-based authentication. 

    To avoid having to transfer passwords as clear text over your network or storing passwords in configuration settings, use Windows authentication only with your SQL Server installation. SQL Server authentication is a legacy authentication mode. Storing Structured Query Language (SQL) login credentials (SQL user names and passwords) when you are using SQL Server authentication is not recommended. For more information, see Authentication Modes (http://go.microsoft.com/fwlink/?LinkID=189232).

  • Evaluate the need for additional channel security in your SQL installation carefully. 

    Even with Kerberos authentication in effect, the SQL Server Security Support Provider Interface (SSPI) does not provide channel-level security. However, for installations in which servers are securely located on a firewall-protected network, encrypting SQL communications may not be necessary.

    Although encryption is a valuable tool to help ensure security, it should not be considered for all data or connections. When you are deciding whether to implement encryption, consider how users will access data. If users access data over a public network, data encryption might be required to increase security. However, if all access of SQL data by AD FS 2.0 involves a secure intranet configuration, encryption might not be required. Any use of encryption should also include a maintenance strategy for passwords, keys, and certificates.

    If there is a concern that any SQL data might be seen or tampered with over your network, use Internet Protocol security (IPsec) or Secure Sockets Layer (SSL) to help secure your SQL connections. However, this might have a negative effect on SQL Server performance, which might affect or limit AD FS 2.0 performance in some situations. For example, AD FS 2.0 performance in token issuance might degrade when attribute lookups from a SQL-based attribute store are critical for token issuance. You can better eliminate a SQL tampering threat by having a strong perimeter security configuration. For example, a better solution for securing your SQL Server installation is to ensure that it remains inaccessible for Internet users and computers and that it remains accessible only by users or computers within your datacenter environment.

    For more information, see Encrypting Connections to SQL Server (http://go.microsoft.com/fwlink/?LinkID=189234) or SQL Server Encryption (http://go.microsoft.com/fwlink/?LinkID=189233).

  • Configure securely designed access by using stored procedures to perform all SQL-based lookups by AD FS 2.0 of SQL-stored data. 

    To provide better service and data isolation, you can create stored procedures for all attribute store lookup commands. You can create a database role to which you then grant permission to run the stored procedures. Assign the service identity of the AD FS 2.0 Windows service to this database role. The AD FS 2.0 Windows service should not be able to run any other SQL statement, other than the appropriate stored procedures that are used for attribute lookup. Locking down access to the SQL Server database in this way reduces the risk of an elevation-of-privilege attack.

Source: https://technet.microsoft.com/en-us/library/ff630160(v=ws.10).aspx

Name Resolution Requirements for Federation Server Proxies

When client computers on the Internet attempt to access an application that is secured by Active Directory Federation Services (AD FS) 2.0, they must first authenticate to the federation server. In most cases, the federation server is usually not directly accessible from the Internet. Therefore, Internet client computers must be redirected to the federation server proxy instead. You can accomplish successful redirection by adding the appropriate Domain Name System (DNS) records to your DNS zone or zones that face the Internet.

The method that you use to redirect Internet clients to the federation server proxy depends on how you configure the DNS zone in your perimeter network or how you configure a DNS zone that you control on the Internet. Federation server proxies are intended for use in a perimeter network. They redirect Internet client requests to federation servers successfully only when DNS has been configured properly in all the Internet-facing zones that you control. Therefore, the configuration of your Internet-facing zones—whether you have a DNS zone serving only the perimeter network or a DNS zone serving both the perimeter network and Internet clients—is important.

This topic describes the steps that you can take to configure name resolution when you place a federation server proxy in your perimeter network. To determine which steps to follow, first determine which of the following DNS scenarios most closely matches the DNS infrastructure in the perimeter network of your organization. Then, follow the steps for that scenario.

In this scenario, your organization has one or two DNS zones in the perimeter network, and your organization does not control any DNS zones on the Internet. Successful name resolution for a federation server proxy in the DNS zone that serves only the perimeter network scenario depends on the following conditions:

  • The federation server proxy must have a setting in the hosts file to resolve the fully qualified domain name (FQDN) of the federation server endpoint URL to an IP address of a federation server or a federation server cluster.
  • DNS in the perimeter network of the account partner must be configured so that the FQDN of the federation server endpoint URL resolves to the IP address of the federation server proxy.

The following illustration and corresponding steps show how each of these conditions is achieved for a given example. In this illustration, Microsoft Network Load Balancing (NLB) technology provides a single, cluster FQDN and a single, cluster IP address for an existing federation server farm.

DNS configuration for servers

For more information about configuring a cluster IP address or a cluster FQDN using NLB, see Specifying the Cluster Parameters (http://go.microsoft.com/fwlink/?LinkId=75282).

Because DNS in the perimeter network is configured to resolve all requests for fs.fabrikam.com to the account federation server proxy, the account partner federation server proxy has an entry in its local hosts file to resolve fs.fabrikam.com to the IP address of the actual account federation server (or cluster DNS name for the federation server farm) that is connected to the corporate network. This makes it possible for the account federation server proxy to resolve the host name fs.fabrikam.com to the account federation server rather than to itself—as would occur if it attempted to look up fs.fabrikam.com using perimeter DNS—so that the federation server proxy can communicate with the federation server.

Because there is only a single AD FS 2.0 host name that client computers are directed to—whether they are on an intranet or on the Internet—client computers on the Internet that use the perimeter DNS server must resolve the FQDN for the account federation server (fs.fabrikam.com) to the IP address of the account federation server proxy on the perimeter network. So that it can forward clients on to the account federation server proxy when they attempt to resolve fs.fabrikam.com, perimeter DNS contains a limited corp.fabrikam.com DNS zone with a single host (A) resource record for fs (fs.fabrikam.com) and the IP address of the account federation server proxy on the perimeter network.

For more information about how to modify the hosts file of the federation server proxy and configure DNS in the perimeter network, see Configure Name Resolution for a Federation Server Proxy in a DNS Zone That Serves Only the Perimeter Network.

In this scenario, your organization controls the DNS zone in the perimeter network and at least one DNS zone on the Internet. Successful name resolution for a federation server proxy in this scenario depends on the following conditions:

  • DNS in the Internet zone of the account partner must be configured so that the FQDN of the federation server host name resolves to the IP address of the federation server proxy in the perimeter network.
  • DNS in the perimeter network of the account partner must be configured so that the FQDN of the federation server host name resolves to the IP address of the federation server in the corporate network.

The following illustration and corresponding steps show how each of these conditions is achieved for a given example.

DNS zone settings for proxies

For this scenario, because it is assumed that you will configure the Internet DNS zone that you control to resolve requests that are made for a specific endpoint URL (that is, fs.fabrikam.com) to the federation server proxy in the perimeter network, you must also configure the zone in the perimeter DNS to forward these requests to the federation server in the corporate network.

So that clients can be forwarded to the account federation server when they attempt to resolve fs.fabrikam.com, perimeter DNS is configured with a single host (A) resource record for fs (fs.fabrikam.com) and the IP address of the account federation server on the corporate network. This makes it possible for the account federation server proxy to resolve the host name fs.fabrikam.com to the account federation server rather than to itself—as would occur if it attempted to look up fs.fabrikam.com using Internet DNS—so that the federation server proxy can communicate with the federation server.

For name resolution to be successful in this scenario, all requests from client computers on the Internet to fs.fabrikam.com must be resolved by the Internet DNS zone that you control. Consequently, you must configure your Internet DNS zone to forward client requests for fs.fabrikam.com to the IP address of the account federation server proxy in the perimeter network.

For more information about how to modify the perimeter network and Internet DNS zones, see Configure Name Resolution for a Federation Server Proxy in a DNS Zone That Serves Both the Perimeter Network and Internet Clients.

Source: https://technet.microsoft.com/en-us/library/dd807055(v=ws.10).aspx

Provide Your Active Directory Users Access to the Applications and Services of Other Organizations

This Active Directory Federation Services (AD FS) 2.0 deployment goal builds on the goal in Provide Your Active Directory Users Access to Your Claims-Aware Applications and Services.

When you are an administrator in the account partner organization and you have a deployment goal to provide federated access for employees to hosted resources in another organization:

  • Employees who are logged on to an Active Directory domain in the corporate network can use single-sign-on (SSO) functionality to access multiple Web-based applications or services, which are secured by AD FS 2.0, when the applications or services are in a different organization. For more information, see Federated Web SSO Design. 

    For example, Fabrikam may want corporate network employees to have federated access to Web services that are hosted in Contoso.

  • Remote employees who are logged on to an Active Directory domain can obtain AD FS 2.0 tokens from the federation server in your organization to gain federated access to AD FS 2.0–secured Web-based applications or services that are hosted in another organization.

    For example, Fabrikam may want its remote employees to have federated access to AD FS 2.0–secured services that are hosted in Contoso, without requiring the Fabrikam employees to be on the Fabrikam corporate network.

In addition to the foundational components that are described in Provide Your Active Directory Users Access to Your Claims-Aware Applications and Services and that are shaded in the following illustration, the following components are required for this deployment goal:

  • Account partner federation server proxy: Employees that access the federated service or application from the Internet can use this AD FS 2.0 component to perform authentication. By default, this component performs forms authentication, but it can also perform basic authentication. You can also configure this component to perform Secure Sockets Layer (SSL) client authentication if employees at your organization have certificates to present. For more information, see Where to Place a Federation Server Proxy.
  • Perimeter DNS: This implementation of Domain Name System (DNS) provides the host names for the perimeter network. For more information about how to configure perimeter DNS for a federation server proxy, see Name Resolution Requirements for Federation Server Proxies.
  • Remote employee: The remote employee accesses a Web-based application (through a supported Web browser) or a Web-based service (through an application), using valid credentials from the corporate network, while the employee is offsite using the Internet. The employee’s client computer in the remote location communicates directly with the federation server proxy to generate a token and authenticate to the application or service.

After reviewing the information in the linked topics, you can begin deploying this goal by following the steps in Checklist: Implementing a Federated Web SSO Design.

The following illustration shows each of the required components for this AD FS 2.0 deployment goal.

Internal Account Store (intranet and Internet)

Source: https://technet.microsoft.com/en-us/library/dd807123(v=ws.10).aspx

Federated Web SSO Design

The Federated Web Single-Sign-On (SSO) design in Active Directory Federation Services (AD FS) 2.0 involves secure communication that spans multiple firewalls, perimeter networks, and name-resolution servers—in addition to the entire Internet routing infrastructure.

Typically, this design is used when two organizations agree to create a federation trust relationship to allow users in one organization (the account partner organization) to access Web-based applications or services, which are secured by AD FS 2.0, in the other organization (the resource partner organization).

In other words, a federation trust relationship is the embodiment of a business-level agreement or partnership between two organizations. As shown in the following illustration, you can establish a federation trust relationship between two businesses, which results in an end-to-end federation scenario.

Federated Web SSO Design

The one-way arrow in the illustration signifies the direction of the federation trust, which—like the direction of Windows trusts—always points to the account side of the forest. This means that authentication flows from the account partner organization to the resource partner organization.

In this Federated Web SSO design, two federation servers (one in Fabrikam and the other in Contoso) route authentication requests from user accounts in Fabrikam to Web-based applications or services in Contoso.

noteNote
For additional security, you can use federation server proxies to relay requests to federation servers that are not directly accessible from the Internet.

In this example, Fabrikam is the identity, or account, provider. The Fabrikam portion of the Federated Web SSO design uses the following AD FS 2.0 deployment goal:

Contoso is the resource provider. The Contoso portion of the Federated Web SSO design achieves the following AD FS 2.0 deployment goals:

For a list of detailed tasks that you can use to plan and deploy the Federated Web SSO design, see Checklist: Implementing a Federated Web SSO Design.

Source: https://technet.microsoft.com/en-us/library/dd807050(v=ws.10).aspx

Troubleshooting federation server farm problems with AD FS 2.0

The following table provides troubleshooting guidance for specific error event messages or other issues that you may encounter if you are having problems in a federation server farm deployment.

Before you begin the troubleshooting process, we recommend that you first try to configure Active Directory Federation Services (AD FS) 2.0 for troubleshooting and check for known common issues that might prevent normal functioning for the Federation Service. For detailed instructions for configuring and performing related system checks, see Configuring Computers for Troubleshooting AD FS 2.0 and Things to Check Before Troubleshooting AD FS 2.0.

 

Event or symptom Possible cause Resolution

Event ID 344 
There was an error doing synchronization. Synchronization of data from the primary federation server to a secondary federation server did not occur.

Generally, this event results from any failure that occurs during the synchronization. The following are more specific possible causes of this event:

  • If the error occurred while data was being read on the primary federation server, the primary federation server is unavailable or the service account identity on the secondary federation server computer does not match the service account identity of the primary federation server.
  • If a SQL write operation failed to write to the configuration database on the local federation server, the cause might be that the SQL Server or Windows Internal Database (WID) service was stopped.

Refer to the additional data in the event to determine the actual cause. Also, when this event occurs for any type of synchronization failure, look for a corresponding error (Event ID 346) on the synchronization partner server.

Make sure that the primary federation server is available, and that the service account identity of this computer matches the service account identity of the primary federation server.

Event ID 345 
There was a communication error during AD FS configuration database synchronization. Synchronization of data from the primary federation server to a secondary federation server did not occur.

Communication failed between the primary federation server and other secondary federation servers in the same farm.

Troubleshoot network connectivity between servers in the federation server farm. For more information, see Verify network connectivity.

Event ID 346 
There was an error during the retrieval of configuration data for the secondary federation server.

The SQL Server or WID service is not available.

Troubleshoot network connectivity between servers in the federation server farm, and verify that the SQL Server or WID service is available. For more information, see Verify network connectivityand Verify that the Federation Service can connect to the AD FS configuration database.

Event ID 351 
There was an error getting synchronization properties.

The SQL Server or WID service is not available.

Troubleshoot network connectivity between servers in the federation server farm, and verify that the SQL Server or WID service is available. For more information, see Verify network connectivityand Verify that the Federation Service can connect to the AD FS configuration database.

Event ID 382 
AD FS 2.0 detected that the Federation Service has more than %1 %2 trusts configured.

The farm deployment is trying to synchronize using a WID database, and it has more than 100 claim trust provider trusts or more than 100 relying party trusts.

Move to SQL Server for improved database synchronization performance when you need to support more than 100 claim trust provider trusts or more than 100 relying party trusts.

For more information about how to do this, see AD FS 2.0 operations documentation on theTechNet Wiki site (http://go.microsoft.com/fwlink/?LinkId=181189).

Source: https://technet.microsoft.com/en-us/library/adfs2-troubleshooting-federation-server-farm-problems(v=ws.10).aspx

Troubleshooting federation server proxy problems with AD FS 2.0

Before you begin the troubleshooting process, we recommend that you first try to configure Active Directory Federation Services (AD FS) 2.0 for troubleshooting and check for known common issues that might prevent normal functioning of the Federation Service. For detailed instructions for configuring and performing related system checks, see Configuring Computers for Troubleshooting AD FS 2.0 and Things to Check Before Troubleshooting AD FS 2.0.

The following table provides troubleshooting guidance for specific error event messages or other issues that you may encounter if you are having problems with establishing trusts with AD FS 2.0.

 

Event or symptom Possible cause Resolution

Event ID 275 
The federation server proxy could not establish a trust relationship for the Secure Sockets Layer (SSL) secure channel with the Federation Service.

The SSL certificate for the Federation Service is invalid or is not trusted by the federation server proxy.

Ensure that the SSL certificate for the Federation Service has a valid chain to a trusted certification authority (CA) store. Also, verify that the certificate is present in a trusted store on the federation server proxy computer.

Event ID 276 
The federation server proxy could not authenticate to the Federation Service.

The federation server proxy is not trusted by the Federation Service.

Ensure that the federation server proxy is trusted by the Federation Service. To do this, log on to the federation server proxy computer and establish a trust between the proxy and the Federation Service by using the AD FS 2.0 Proxy Configuration Wizard.

Event ID 393 
The federation server proxy could not establish a trust with the Federation Service.

The following are possible causes for this event:

  • The credentials that are used to establish a trust between the federation server proxy and the Federation Service are not valid, or the Federation Service cannot be reached.
  • The federation server proxy trust was revoked.
  • The federation server proxy has been inactive for a long period of time (such as 30 days or more).

The following are possible resolutions for this event:

  • Ensure that the credentials that are being used to establish a trust between the federation server proxy and the Federation Service are valid, and that the Federation Service can be reached.
  • Run the AD FS 2.0 Proxy Configuration Wizard again to renew trust with the Federation Service.

Event ID 394 
The federation server proxy could not renew its trust with the Federation Service.

The federation server proxy is not trusted by the Federation Service. Either the trust does not exist, or it was revoked.

Ensure that the federation server proxy is trusted by the Federation Service. If the trust does not exist or has been revoked, renew trust by running the AD FS 2.0 Proxy Configuration Wizard again.

The following table provides troubleshooting guidance for specific error event messages or other issues that you may encounter if you are having problems with starting a federation server proxy in your AD FS 2.0 deployment.

 

Event or symptom Possible cause Resolution

Event ID 199 
The federation server proxy could not be started.

The following are possible causes for this event:

  • No SSL certificate is configured in HTTPS bindings in Internet Information Services (IIS).
  • The HTTP listener cannot listen on proxy endpoints. This indicates that URL access control lists (ACLs) are not configured for the identity of the Federation Service.

The following are possible resolutions for this event:

  • Using IIS Manager, verify that a valid SSL certificate is configured for HTTPS bindings.
  • Use the netsh http show urlacl command or the netsh http add urlacl command to verify or update the URL ACLs respectively. 
  • If needed, run the AD FS 2.0 Proxy Configuration Wizard to restore the federation server proxy configuration. 

Event ID 215 
The Federation Service did not return any WS-Trust endpoints to be published by the federation server proxy.

No WS-Trust endpoints are either configured or enabled for the Federation Service.

Using the AD FS 2.0 snap-in, open to the Endpoints node and verify that WS-Trust endpoints are proxy enabled. To enable an endpoint, on the Action menu, click Enable on proxy.

If you are using AD FS 2.0 cmdlets for Windows PowerShell, use the Set-ADFSEndpoint cmdlet with the Proxy=True parameter to enable a specific endpoint. For example, to enable the WS-Trust 1.3 endpoint for proxy use, use the following command at the Windows PowerShell prompt:

Set-ADFSEndpoint -TargetAddress /adfs/services/trust/13/Windows -Proxy $true

Event ID 224 

The federation server proxy configuration could not be loaded correctly from the configuration file.

The federation server proxy configuration could not be loaded correctly at service startup from the configuration file.

A configuration element that is specified in the additional data provided in the event is misconfigured. Correct the specified error in the federation server proxy configuration database.

Event ID 274 

The federation server proxy encountered an error while it was trying to listen on one of the proxy endpoints.

The federation server proxy encountered an error while it was trying to listen on one of the proxy endpoints. The federation server proxy cannot start until it can listen on all required proxy endpoints.

Ensure that the permissions on the URLs of the proxy endpoints allow the federation server proxy security account (the default is Network Service) to listen on them.

The proxy endpoints that are referenced in this event are actually the base addresses that the federation server proxy is listening on. These include the following endpoints:

http://hostname/adfs/services/
https://hostname/adfs/services/
https://hostname/FederationMetadata/2007-06/
https://hostname/adfs/fs/FederationServerService.asmx

The following table provides troubleshooting guidance for specific error event messages or other issues that you may encounter if you are having problems replicating configuration data to a federation server proxy from a federation server in your AD FS 2.0 deployment.

 

Event or symptom Possible cause Resolution

Event ID 248 

The federation server proxy was not able to retrieve the list of endpoints from the Federation Service.

Network connectivity is a possible cause of this event. Also, you should review any error message that is returned with this event to further determine the actual cause as needed.

Make sure that the Federation Service is running. Troubleshoot network connectivity. For more information, see Verify network connectivity. If the trust between the federation server proxy and the Federation Service is lost, run the AD FS 2.0 Proxy Configuration Wizard again.

The following table provides troubleshooting guidance for specific error event messages or other issues that you may encounter if you are having connection failures between a federation server proxy and its configured federation server in your AD FS 2.0 deployment.

 

Event or symptom Possible cause Resolution

Event ID 218 

The federation server proxy received an error code while making a request to the Federation Service.

This could mean that the AD FS 2.0 Windows Service is not started on the federation server computer.

Verify that the AD FS 2.0 Windows service is running on the remote federation server computer, and that the remote federation server is reachable. For more information, see Verify that AD FS is installed and running and Verify network connectivity.

Event ID 222 

The federation server proxy was unable to complete a request to the Federation Service.

The federation server proxy timed out while it was trying to reach the federation server. This might mean that the Federation Service is currently unavailable.

Verify that the AD FS 2.0 Windows service is running on the remote federation server computer, and that the remote federation server is reachable. For more information, see Verify that AD FS is installed and running and Verify network connectivity.

Source: https://technet.microsoft.com/en-us/library/adfs2-troubleshooting-federation-server-proxy-problems(v=ws.10).aspx