ADFS 2.0 error: 401 The requested resource requires user authentication

Article
02/19/2024

This article discusses an issue where you're prompted for credentials and event 111 is logged when you authenticate an account in Active Directory Federation Services (AD FS) 2.0.

Applies to: Windows Server 2012 R2
Original KB number: 3044976

Summary

Most Active Directory Federated Services (AD FS) 2.0 problems belong to one of the following main categories. This article contains step-by-step instructions to troubleshoot authentication problems.

Symptoms

When you try to authenticate an account in Active Directory Federation Services (AD FS) 2.0, the following errors occur:

The AD FS server returns the following error message:

Not Authorized-HTTP error 401. The requested resource requires user authentication.
On a form-based login screen, the server returns the following error message:

The user name or password is incorrect.
You're continually prompted for credentials.
Event 111 is logged in the AD FS Admin log, as follows:

Log Name: AD FS 2.0/Admin
Event ID: 111
Level: Error
Keywords: AD FS
Description:
The Federation Service encountered an error while processing the WS-Trust request.
Request type: http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue
Exception details:
Microsoft.IdentityModel.SecurityTokenService.FailedAuthenticationException: MSIS3019: Authentication failed. ---> System.IdentityModel.Tokens.SecurityTokenValidationException: ID4063: LogonUser failed for the 'user1' user. Ensure that the user has a valid Windows account. ---> System.ComponentModel.Win32Exception: Logon failure: unknown user name or bad password

Resolution

To resolve this problem, follow these steps, in the order given. These steps will help you determine the cause of the problem.

Step 1: Assign the correct AD FS Federation service name record

Make sure that the DNS has a HOST (A) record for the AD FS Federation service name, and avoid using a CNAME record. For more information, see Internet Explorer behaviors with Kerberos Authentication.

Step 2: Check Federation Service name registration

Locate the Federation Service Name, and check whether the name is registered under the AD FS service account. To do this, follow these steps:

Locate the HOST/<Federation Service Name> name:
1. Open AD FS 2.0 Manager.
2. Right-click ADFS 2.0, and then select Edit Federation Service Properties.
3. On the General tab, locate the Federation Service name field to see the name.
Check whether HOST/<Federation Service Name> name is registered under the AD FS service account:
1. Open the Management snap-in. To do this, click Start, click All Programs, click Administrative Tools, and then click Services.
2. Double-click AD FS (2.0) Windows Service.
3. On the Log On tab, note the service account that's displayed in the This account field.
4. Click Start, click All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.
5. Run the following command:
```
SETSPN -L domain\<ADFS Service Account>
```

If the Federation Service name doesn't already exist, run the following command to add the service principal name (SPN) to the AD FS account:

SetSPN -a host/<Federation service name> <username of service account>

Screenshot for the result of the setspn command, which is to add the service principal name.

Step 3: Check for duplicate SPNs

Verify that there are no duplicate SPNs for the AD FS account name. To do this, follow these steps:

Click Start, click All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.
Run the following command to make sure that there are no duplicate SPNs for the AD FS account name:
```
SETSPN -X -F
```

Step 4: Check whether the browser uses Windows Integrated Authentication

Make sure that the Internet Explorer browser that you're using is configured to use Windows Integrated Authentication. To do this, start Internet Explorer, click Settings, click Internet Options, click Advanced, and then click Enable IntegratedWindows Authentication.

Step 5: Check the authentication type

Make sure that the default authentication type on the AD FS server is configured correctly. To do this, follow these steps:

In Windows Explorer, navigate to C:\inetpub\adfs\ls (this assumes that inetpub is located on drive C).
Locate Web.config, and then open the file in Notepad.
In the file, locate (Ctrl+F) <localAuthenticationTypes>.
Under <localAuthenticationTypes>, locate the four lines that represent the local authentication types.
Select and delete your preferred local authentication type (the whole line). Then, paste the line at the top of the list (under <localAuthenticationTypes>).
Save and close the Web.config file.

For more information about the Local Authentication Type, see the following TechNet topic:

AD FS 2.0: How to Change the Local Authentication Type

Step 6: Check authentication settings

Make sure that the AD FS virtual directories are configured correctly for authentication in Internet Information Services (IIS).

In the Default Web Site/adfs node, open the Authentication setting, and then make sure the Anonymous Authentication is enabled.
In the Default Web Site/adfs/ls node, open the Authentication setting, and then make sure that both Anonymous and Windows Authentication are enabled.

Step 7: Check proxy trust settings

If you have an AD FS proxy server configured, check whether proxy trust is renewed during the connection intervals between the AD FS and AD FS Proxy servers.

The Proxy server automatically renews trust with AD FS Federation Service. If this process fails, event 394 is logged in Event Viewer and you receive the following error message:

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

To resolve this problem, try to run the AD FS proxy configuration wizard again. As the wizard runs, make sure that valid domain user name and passwords are used. These credentials aren't stored on the AD FS Proxy server. When entering credentials for the proxy trust configuration wizard, you have two choices.

Use domain credentials that have local administrative rights on the AD FS servers.
Use the AD FS service account credentials

Step 8: Check IIS extended protection settings

Certain browsers can't authenticate if extended protection (that is, Windows Authentication) is enabled in IIS as shown in Step 5. Try to disable Windows Authentication to determine whether this resolves the problem.

You would also see Extended protection not allowing Windows Authentication when SSL proxy is being done by tools like Fiddler or some intelligent load balancers.

For example: You may see repeated authentication prompts if you have Fiddler Web Debugger running on the client.

To disable extended protection for authentication, follow the appropriate method, depending on the client type.

For passive clients

Use this method for the "Default Web Site/adfs/ls" virtual applications on all servers in the AD FS federation server farm. To do this, follow these steps:

Open IIS Manager, and then locate the level that you want to manage.

For more information about how to open IIS Manager, see Open IIS Manager (IIS 7).
In Features View, double-click Authentication.
On the Authentication page, select Windows Authentication.
In the Actions pane, click Advanced Settings.
When the Advanced Settings dialog box appears, click Off on the Extended Protection menu.

For active clients

Use this method for the primary AD FS server:

Start Windows PowerShell.
To load the Windows PowerShell for AD FS snap-in, run the following command:
```
Add-PsSnapIn Microsoft.Adfs.Powershell
```
To disable extended protection for authentication, run the following command:
```
Set-ADFSProperties -ExtendedProtectionTokenCheck "None"
```

Step 9: Check the secure channel status between ADFS server and DCs

Make sure that the secure channel between AD FS and the DCs is good. To do this, run the following command:

Nltest /dsgetdc:domainname

If the response is anything other than "success," you must troubleshoot the netlogon secure channel. To do this, make sure that the following conditions are true:

The domain controller (DC) is reachable
DC names can be resolved
Passwords on the computer and its account on the Active Directory site are in sync.

Step 10: Check for bottlenecks

Check whether you're experiencing authentication-related bottlenecks per the MaxconcurrentAPI setting on the AD FS server or on the DCs. For more information about how to check this setting, see the following Knowledge Base article:

How to do performance tuning for NTLM authentication by using the MaxConcurrentApi setting

Step 11: Check whether the ADFS proxy server is experiencing congestion

Check whether the ADFS proxy server is throttling connections because it has received many requests or delayed response from the AD FS server. For more information, see the following TechNet topic:

AD FS 2.x: Troubleshooting Proxy Server Event ID 230 (Congestion Avoidance Algorithm)

In this scenario, you may note intermittent login failures on ADFS.

Step 12: Check proxy trust settings

If you have an ADFS proxy server configured, check whether proxy trust is renewed during the connection intervals between the AD FS and AD FS Proxy servers.