Export (0) Print
Expand All

Troubleshooting User-Reported Symptoms for AD FS 2.0

Updated: March 21, 2011

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

For most users who are using single sign-on (SSO) that is enabled by AD FS 2.0, the first symptoms that will be reported or observed can vary depending on your deployment.

  • Passive federation

    This type of identity federation involves a Web browser client (also referred to as a "passive client") that implements and uses the WS-Federation or Security Assertion Markup Language (SAML) protocols.

  • Active federation

    This type of identity federation involves a Web service application (also referred to as an "active client") that is built to run on a phone or a computer that uses the WS-Trust protocol.

The following flowchart demonstrates the process flow to follow when you are troubleshooting a passive federation issue.

Troubleshoot AD FS 2.0 FedPassive flowchart

 

Description of symptom Possible cause Suggested resolution

My sign-out does not work; I see an error page.

For SAML-P sign-out to work, the following conditions need to be true:

  • All messages for sign-out must be signed. This is sometimes a nondefault setting for third-party SAML-P implementations.

  • If you want to have sign-out be operational, you may have to configure a name identifier rule in AD FS 2.0 policy.

The following are possible resolutions:

  • Verify that other SAML-P implementations involved are enabled for SAML sign out.

  • If necessary, configure a name identifier rule in AD FS 2.0 policy.

My sign-out does not work in my Web browser. When I try to sign out it does not happen.

To enable sign-out, AD FS 2.0 can use IFRAME elements within a Web page that rely on browser clients sending third-party cookies. Third-party cookies are defined as any cookies that are not in the same domain as the domain hosting the outermost frame.

Because third-party cookies can be used to invade privacy for users by allowing one website to act on the behalf of another website, some Web browsers such as Apple Safari 4 and Internet Explorer 8 restrict and block third party cookies by default.

The following are possible resolutions for this issue:

  • Allow the issue for browser applications that do not allow for discrete authorization of third-party cookies where appropriate. For example, Apple Safari only allows for the default "always reject" setting to be modified to an "always accept" setting for third-party cookies. This setting is potentially too broad and not recommended as it might risk browser security against malicious third party cookies.

  • For browser applications that allow for more discrete security settings, such as Internet Explorer 8, you can either enable protected mode for your intranet zone or disable protected mode for your Internet zone to permit sign out operations to function as expected.

I am seeing a "connection failure" error in Internet Explorer.

AD FS 2.0 sometimes can generate SAML-P requests longer than the maximum supported length for Internet Information Services (IIS) of 2048 characters. If this occurs, it typically happens for SAML-P during logout activity and a "connection failure" error might be returned by IIS. Also, if AD FS 2.0 is configured to send the EncryptedNameId in a signed request the query string is almost certainly longer than 2048 characters.

The following is a possible workaround to resolve this issue:

  • For any claims provider trusts or relying party trusts that are configured to use an encrypted name identifier, use POST instead of Redirect in the SAML logout endpoints configuration. This should help prevent query string overflow when using Internet Explorer.

    To update SAML logout endpoints, select the claims provider trust or relying party trust party in the AD FS 2.0 snap-in. Then right-click and select Properties. In the trust properties, click the Endpoints tab. For any logout endpoints that have a value of POST for the Bindings column, update them to use Redirect instead.

 

Description of symptom Possible cause Suggested resolution

My sign-in provider is not showing up on the sign-in home page

If a claims provider does not appear on the home realm discovery page for a Fedpassive website, its possible the claims provider is not properly configured. In the federation scenario, the fedpassive URL for the claims provider might need to be not be properly configured

To update the URL for the Fedpassive endpoint, do the following in the AD FS 2.0 snap-in:

  1. In the console, tree, navigate to Trust Relationships\Claims Provider Trust node.

  2. In the details pane, double-click the claims provider trust that you want to verify its URL configuration.

  3. Click the Endpoints tab.

  4. Double-click the endpoint from the list of WS-Federation Passive Endpoints.

  5. Verify the URL is correct in the endpoint properties.

I am seeing errors (HTTP 503 Service Unavailable Errors) that indicate sign-in service is not available and I also see Event ID 364 (Encountered error during federation passive request) in the Windows Event Log at my federation server.

The AD FS 2.0 application pool might be stopped, possibly because of an AD FS 2.0 service account password change. You might need to update the password for the AD FS 2.0 application pool in IIS or reset the password for both AD FS 2.0 service account and its application pool.

First, investigate the following:

  • In IIS Manager, check to see if the AD FS 2.0 application pool is stopped.

  • Check whether the AD FS 2.0 service account user password has been changed or updated.

If the AD FS 2.0 service account password has been changed and the AD FS 2.0 application pool is stopped, try one of the following:

  • Update the password for the AD FS 2.0 application pool in IIS.

  • Reset the password for both the AD FS 2.0 service account and the AD FS 2.0 application pool.

 

Description of symptom Possible causes Suggested resolution

When I try signing in I receive an error in the browser that tells me I failed authentication.

The following are possible causes for this error:

  • The user's browser is configured to block cookies.

  • The relying party trust used to enable authentication is not configured properly.

  • The user belongs to too many Active Directory groups.

The following are possible resolutions for authentication errors:

  • Verify that cookies are enabled on the user's browser. Review specific instructions for the user's browser application. For example, for more information on enabling cookies for Internet Explorer, see Block or allow cookies (http://go.microsoft.com/fwlink/?LinkId=200603).

  • Review relying party trust settings using either the AD FS 2.0 snap-in or in Windows PowerShell, you can use the Get-ADFSRelyingPartyTrust cmdlet to view current settings. For more information see Get-ADFSRelyingPartyTrust (http://go.microsoft.com/fwlink/?LinkId=179439)

  • If the user receives a bad request error or an error that explains the size of the request headers is too long, the problem might be that the user belongs to a large number of Active Directory groups. To correct this issue, the size of the request headers field in IIS can be increased as well as the size of the bytes sent using MaxFieldLength and MaxRequestBytes from their defaults of 16kb to a higher value such as 32kb. For more information on how to make this configuration change in IIS, see Http.sys registry settings for IIS (http://go.microsoft.com/fwlink/?LinkId=179439)

 

Description of symptom Possible cause Suggested resolution

When I try signing in, it fails and the message I receive from AD FS 2.0 says I am not authorized.

You are not authorized to use the site.

If you need access, contact your site's administrator for more information on how to become authorized for access to the site.

 

Description of symptom Possible cause Suggested resolution

The error I am seeing is too general for me to understand the problem.

There was a problem accessing the site. More information might be available in the AD FS 2.0 event logs.

For more information about how to resolve this issue, see the additional details that are provided with this event and other events that are related to this error.

For more information about how to determine what other events are related to this event in the AD FS 2.0 event log, see the section "Correlating events and traces using Activity ID and Caller ID" in the blog post Diagnostics in AD FS 2.0(http://go.microsoft.com/fwlink/?LinkID=188910).

The following flowchart demonstrates the process flow to follow when troubleshooting an active federation issue.

Troubleshoot AD FS 2.0 active scenario flowchart

 

Description of symptom Possible cause Suggested resolution

I am having trouble communicating with the site that I use to sign-in from my client application.

The following are possible causes for this error:

  • The endpoint used for service is down.

  • The client failed to connect. This might be caused by network connectivity problems on the client such as DNS or HTTP proxy settings that are not up to date.

  • There might be a problem with the federation server proxy. It might not be able to connect to the federation server.

The following are possible resolutions to the problem:

 

Description of symptom Possible cause Suggested resolution

My client application failed to authenticate with AD FS 2.0.

The client provided the wrong credentials.

Verify the credentials are correct.

 

Description of symptom Possible cause Suggested resolution

When I try signing in, it fails and the message I receive from AD FS 2.0 says I am not authorized.

You are not authorized to use the site or a more specific authorization problem occurred in because of your deployment.

If you need access, contact your site's administrator for more information on how to become authorized for access to the site.

There might be more information available in AD FS 2.0 event logs if you are using identity delegation or a federation server proxy within your deployment to facilitate the authorization process.

For more information about how to determine what other events are related to this event in the AD FS 2.0 event log, see the section "Correlating events and traces using Activity ID and Caller ID" in the blog post Diagnostics in AD FS 2.0(http://go.microsoft.com/fwlink/?LinkID=188910).

 

Description of symptom Possible cause Suggested resolution

The error I am seeing is too general for me to understand the problem.

There was a problem accessing the site. More information might be available in the AD FS 2.0 event logs.

For more information about how to resolve this issue, see the additional details that are provided with this event and other events that are related to this error.

For more information about how to determine what other events are related to this event in the AD FS 2.0 event log, see the section "Correlating events and traces using Activity ID and Caller ID" in the blog post Diagnostics in AD FS 2.0(http://go.microsoft.com/fwlink/?LinkID=188910).

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft