Share via

ADFS troubleshooting

  • Article

Applies To: Windows Server 2003 R2

Setup issues

You receive an Internet Explorer error page with the message “This page cannot be displayed” “Cannot find server or DNS Error.”

There are a few things that can cause this problem:

  • Verify that Windows Firewall is turned off.

  • Verify that all the Federation Services and application Web servers have a server authentication certificate issued to the default Web site.

  • If there is an external account partner Federation Service Proxy involved, verify that the correct Federation Service host name was used during installation.

  • If you are using a Windows NT token-based application, verify that the Federation Service Uniform Resource Locator (URL) on the ADFS Web Agent tab of Web Sites Properties is configured correctly.

When you try to connect to the application, you get an Internet Explorer error page with the message “This page cannot be found” “HTTP Error 404 – File or directory not found.”

This issue might be caused by the following configuration problems:

  • Verify that the Web application is properly configured in Internet Information Services (IIS).

  • Verify that the Web application URL is properly named in the Active Directory Federation Services Snap-in.

  • Verify that Microsoft ASP.NET is installed on the application Web server and in the Federation Service.

  • If you are connecting to a Windows NT token–based application that uses ASP and you receive the 404 error after supplying your credentials, in the IIS Manager console tree, click the local computer, click Web Service Extensions, and then verify that Active Server Pages is set to Allowed.

After setting up a Windows NT token–based application, you attempt to connect to it but you are not prompted to choose a host realm and login credentials.

Verify that the virtual directory of the Windows NT token–based application is set up to use the Ifsext.dll Internet Server Application Programming Interface (ISAPI) extension.

Where are the ADFSSetup.log, ADFSOCM.log, and ADFSMSI.log files located?

They are located in %SYSTEMROOT%\.

Enable logging

Registry settings to enable logging on the account federation server

The account federation server uses an authentication package for mapping client certificates. To enable logging for the account federation server authentication package, perform the following tasks in order:

  1. If it is not already installed, install the Federation Service component of Active Directory Federation Services (ADFS).

  2. Set the following registry key: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\WebSso\Parameters]

    "DebugLevel"=dword:ffffffff

Registry settings to enable logging on the Web server for the:

ADFS Web Agent Authentication Package

The ADFS Web Agent authentication package is used by Windows NT token-based applications for generating tokens when Service-for-User (S4U) is not available.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\WebSso\Parameters]

"DebugLevel"=dword:ffffffff

ADFS Web Agent ISAPI Extension

The ADFS Web Agent ISAPI Extension handles the protocols that are used by ADFS to authenticate requests.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ADFS\WebServerAgent]

"DebugPrintLevel"=dword:ffffffff

ADFS Web Agent Authentication Service

The ADFS Web Agent Authentication Service validates incoming tokens and cookies.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IFSSVC\Parameters]

"DebugPrintLevel"=dword:ffffffff

Where are these logs located?

They are located in %SYSTEMDRIVE%\ADFS\logs.

Configuration issues

The following section covers some of the known issues with ADFS configuration.

Condition: server error

Error: The token request for application with URL https://... cannot be fulfilled because the URL does not identify any known trusting application

Solution: This error is returned by the resource Federation Service when the application URL does not identify any known application. Make sure that the application has been added to the trust policy for the Federation Service. For more information about how to do this, see Complete the Add Applications Wizard.

For a claims-aware application, verify that the return URL is typed correctly in the application’s web.config file and that it matches the application URL that is specified in the trust policy of the Federation Service.

For a Windows NT token-based application, verify that the return URL is typed correctly on the ADFS Web Agent tab of IIS and that it matches the application URL in the trust policy of the Federation Service.

Condition: validation error

Error: Validation of viewstate MAC failed. If this application is hosted by a Web farm or cluster, ensure that <machineKey> configuration specifies the same validationKey and validation algorithm.

AutoGenerate cannot be used in a cluster. An unhandled exception occurred during the execution of the current Web request. Review the stack trace for more information about the error and where it originated in the code.

Or

Error: An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Solution: Using a text editor, add the following setting to the Web.config file on the computer hosting either the Federation Service, Federation Service Proxy, or ADFS Web Agent that will be farmed:

<system.web>

<machineKey>

<machineKey validationKey="specify key for the appropriate algorithm"

decryptionKey="specify key"

validation="SHA1|MD5|3DES"/>

Or

Solution: Add the following element in the <system.web> section of the Web.config file on the computers hosting the Federation Service, Federation Service Proxy, or ADFS Web Agent that are set up in the farm:

<pages enableViewStateMac="false"/>

Behavior: The Federation Service tries to authenticate the user each time, and no sign-on occurs. The event logs on the federation server show that the user has been authenticated successfully. However, the user never sees the login succeed.

Solution: To resolve this issue, correct the cookie path that is specified in the trust policy.

The cookie path must match a prefix of the request Uniform Resource Identifier (URI). It is important to note that some browsers treat "/path" or "/path1/samp" as a prefix match of "/path1/sample" while others do not allow matches that consume only parts of the individual words. These strict implementations accept only a subset of those matches that are allowed by the first implementation, for example, "/path1" or "/path1/sample".

Condition: A Windows NT token–based application cannot create a Windows access token for the user using the security token from the resource Federation Service as a result of one of the following conditions:

  • The only identity claim is the common name claim.

  • Services-for-User (S4U) fails because there is no resource account corresponding to the user principal name (UPN).

Behavior: The Web application returns an anonymous user token.

Condition: The UPN name for forms authentication with the user@domain NetBIOS name can be different from the UPN for integrated authentication and Transport Layer Security / Secure Sockets Layer (TLS/SSL) client authentication.

Behavior: In the case of integrated and TLS/SSL client authentication, the UPN is always the explicit UPN that is configured in Active Directory for the user object. However, for forms authentication, the UPN can be whatever the user enters in the user name field. Therefore, the UPN can be in the form:

username@netbiosname of domain or username@domaindnsname

Condition: The Web server application should not be configured with any URLs that are not Secure Hypertext Transfer Protocol (HTTPS).

Behavior: If the application contains links that are not HTTPS, the browser will not send the browser authentication cookies for those URLs. Single sign-on (SSO) is not possible because the ADFS cookies are secure cookies. In cases where the Web server is hosting only Windows NT token–based applications, the Web server will redirect to the HTTPS URL. Therefore, this behavior may not be noticed in most cases.

Condition: If the Federation Service or Web server is running on a domain controller, APPIDENTITY should be provided with the Write permission to the Temporary ASP.NET files directory.

(%windir%\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET files)

APPIDENTITY refers to the identity of the application pool with which the Federation Service or Federation Service Proxy is configured to run.

Condition: The Federation Service log file gets filled, and the Federation Service starts to fail all requests.

Solution: Increase the log size of the Federation Service log to something large, such as 16 megabytes (MB).

Condition: A forest trust is created between an extranet forest and an intranet forest, and a user has successfully authenticated as an intranet domain user to the extranet forest. However, the user cannot authenticate as a user from a domain that is a child domain of the intranet forest.

Cause: The Federation Service maintains a cache of forest trust information that is refreshed every eight hours.

Solution: Recycle the Federation Service application pool. This ensures that no authentication requests are dropped.

Duplicate group or custom claim names

As a best practice, do not create duplicate group or custom claims using case-insensitive names. For example, do not create an organization group claim using the names “Smith” and “smith”. If similar claim names are typed but they have case-sensitive differences, ADFS will treat those claims differently.

Active Directory node in the ADFS snap-in:

Extracting multiple Active Directory users to a single organizational group claim displays ‘*’ under the account store data field in the details pane.

Solution: This is by design. To verify the list of added Active Directory users, open the properties dialog box for the organizational group claim.

Account Partners node in the ADFS snap-in:

Object picker under the Groups tab in the UPN claim mapping dialog box returns a selected user’s UPN as NULL in the UPN edit field.

Solution: This is expected behavior. If the selected user is not assigned with a UPN explicitly, the object picker returns NULL, and the UPN field shows a blank value. Type the UPN manually in the field.

Applications node in the ADFS snap-in:

A common name claim for a Windows NT token-based application cannot be enabled in the Add Applications Wizard.

Solution: The user cannot enable a common name identity claim for a Windows NT token–based application in the Add Applications Wizard. This can be fixed in the properties dialog box for the common name identity claim in the Added Applications details pane.

ADAM issues

After user accounts are created in Active Directory Application Mode (ADAM) and the trust policy is configured with information about the ADAM store, the Federation Service is not able to validate users in the ADAM store.

Solution: Use caution while creating user accounts using the ADAM ADSI Edit snap-in. Always create a user account with a password. If you create a user account without a password, use ADSI Edit to reset the password for the user account. Most importantly, check the value of the msDS-UserAccountDisabled property of the user account. This property should not have the value True. The value should be either False or Not set. If the value of msDS-UserAccountDisabled property is True, it means that the user account is disabled and the Federation Service cannot validate credentials for this ADAM user account.

You have enabled an ADAM account store, but the Federation Service is not able to retrieve any claims.

If the Federation Service is running as Local System, you must add the machine account of the computer hosting the Federation Service to the Readers group in the ADAM store.

If the Federation Service is running as Network Service, you must add the domain account to the Readers group in the ADAM store.