An authentication problem with Kerberos authentication is shown by an IIS 401 error. In this article, we’ll look into the details of using and diagnosing the 401.x error codes on IIS. Bobcares, as a part of our Server Management Service offers solutions to every IIS query that comes our way.

Overview

1. Understanding IIS 401 Error Codes in Kerberos Authentication
2. The IIS 401.1 Error Code in Kerberos Authentication
3. The IIS 401.2 Error Code in Kerberos Authentication
4. The IIS 401.3 Error Code in Kerberos Authentication
5. The IIS 401.4 Error Code in Kerberos Authentication
6. The IIS 401.5 Error Code in Kerberos Authentication
7. Conclusion

Understanding IIS 401 Error Codes in Kerberos Authentication

The first step in troubleshooting a 401 code that we receive from IIS in the browser is to identify the “type” (i.e., HTTP substatus) of 401 that it is. When paired with the Win32 error code, the HTTP status and substatus codes from the IIS web log files in IIS 6.0 can help debug a lot of 401 issues.

However, web browsers such as Internet Explorer have options like “Show Friendly HTTP Errors” that mask the detailed error response by making it “simple” and “user friendly”. We will need to disable this option in order to see the correct error response. However, because IIS does not even record the 401 substatus, the IIS web log files are worthless for identifying it before IIS 6.0. With the assumption that the 401.x Custom Error pages for that URL’s scope are set up to deliver distinct HTML pages for each kind of error, the only choice is to deduce this information from the HTML response itself.

We can begin limiting the kinds of failures and causes once we have obtained the HTTP substatus code. IIS reports in the following preset categories. Here, we’ll see each in depth along with a few typical reasons and solutions.

The IIS 401.1 Error Code in Kerberos Authentication

The 401.1 Denied by Invalid User Credentials means that IIS was unable to get an NT user token that was needed to process the request. So, 401.1 is returned by IIS if an NT user token is not received at the conclusion of approval. Some of the common reasons behind the error are as follows:

1. The customer provided an incorrect login or password, or none at all. This is because of a user login dialog from the browser or an incorrect auto-login attempt that the browser cached.

2. Unless we use SETSPN or change Integrated Authentication to favor NTLM, we will strangely receive 401.1 on IIS6 if we have a customized Application Pool Identity AND Integrated Authentication is used AND the web server is in a domain.

3. All requests still return 401.1 even after we have enabled Anonymous authentication. If the defined anonymous user credentials—that is, the password that matches—are different from the actual user principle’s credentials in the IIS metabase configuration file, that is a common problem.

Solution

Generally, when the user’s details are rejected during the Kerberos authentication process, the “401.1 Denied by Invalid User Credentials” issue in IIS arises. The following steps can be taken to identify and solve this problem:

1. Verify again that the user is typing the right password as well as username. Also, make sure there are no mistakes or issues with case sensitivity.

2. Make sure the user has access to their account and that it is not locked. Using Active Directory or another authentication service of our choice, we can confirm this.

3. To test Kerberos authentication independently of IIS, use tools such as KerbTray or browser-based tools. This can assist in determining whether there is a problem with the IIS settings or Kerberos itself.

4. Verify that the IIS server’s SPN setup is correct. The SPNs should register with the service account that manages the IIS app pool. So, to manage SPNs, use the setspn command-line tool.

5. Verify that the domain does not contain any duplicate SPNs. Since authentication issues may arise from duplicate SPNs. In order to look for duplicate SPNs, we can use programs like setspn -X.

6. Make sure the domain controller, client, and server all have synced clocks. Due to Kerberos’ sensitivity to time variations, authentication may not succeed if there is a large time skew.

7. Make sure that the delegation setup is correct in Active Directory and IIS if the app calls for it. Also, examine the needs of the app in order to find whether it requires confined or unconstrained delegation.

8. Make sure that IIS has Kerberos authentication enabled as well as set correctly. Verify that the arrangement and listing are proper. Also, enable the authentication method.

9. Verify whether any Group Policy settings have an impact on user rights assignments or Kerberos approval. Sometimes, security policies can also occasionally cause issues.

10. Examine any rules in place regarding account lockouts. Policy limitations on the amount of unsuccessful approval attempts may result in account lockouts.

The IIS 401.2 Error Code in Kerberos Authentication

The 401.2 Denied by Server Configuration message means that although the web server is set up to need specific authentication protocols for communication, none of them were used by the browser. So, using a client that complies with the server authentication protocol needs or setting up to demand an authentication protocol that the client accepts should be the corrective step. Some of the common reasons behind the error are as follows:

1. Older Netscape/Mozilla browser clients and an IIS web server set up to need Integrated Authentication are frequent causes of this problem. Because these browser clients were not familiar with Integrated Authentication, when IIS requested it and the browsers consistently ignored the responses, IIS would return 401.2, meaning that the browser had not used an authentication protocol that the server had needed. It is not a feature of more recent Mozilla browsers like Firefox.

2. Using Integrated Authentication via the Internet is another potential cause. Since NTLM is a connection-based protocol, the sole evidence of validity is a verified connection between a client and server. This is OK for intranet settings, but in the case of the Internet, a lot of network devices between the client and server can cause unexpected 401.2 because they either cannot support NTLM or handle it improperly (e.g., by not allowing Proxy Server connection pooling or multiplexing).

Solution

The “401.2 Denied by Server Configuration” error in IIS means that, instead of an invalid user credential, the server is set up to restrict access because of its set-up settings. To find and fix this issue in the context of Kerberos, follow these steps:

1. Examine the website or app’s authentication settings in IIS Manager. Make sure that Kerberos verification is set up and activated correctly. If Kerberos is the preferred authentication method, make sure it is prioritized over other methods by checking the order of authentication providers.

2. Examine the authorization policies set up for the program or website. Also, ensure that the person or group trying to utilize the resource has the authorization they need.

3. Verify that the IIS server’s Service Principal Names (SPNs) are set up correctly. The service account that manages the IIS app pool is where the SPNs should be registered. To manage SPNs, use the setspn command-line utility.

4. Verify that the domain does not contain any duplicate SPNs. Authentication issues may arise from duplicate SPNs. So, to look for duplicate SPNs, use programs like setspn -X.

5. Verify whether any Group Policy settings have an impact on user rights assignments or Kerberos authentication. Security policies may occasionally cause issues with authentication.

6. Verify again any additional server designs, such as IP limitations, URL rewrite rules, or SSL settings, that may have an impact on authentication.

7. Make sure that any set URL rewrite rules are not unintentionally impacting authentication. Rewrite rules occasionally have the ability to reroute requests in a way that impedes authentication.

8. Look for any pertinent error messages or warnings in the client and server event logs that can shed more light on the problem.

9. Authentication issues can occasionally be caused by browser-specific problems. To determine if the problem is specific to any one web browser, try using a different one to view the resource.

The IIS 401.3 Error Code in Kerberos Authentication

The 401.3 Denied by Resource ACL error means that although the web server successfully verified and obtained SOME NT user tokens to process the HTTP request, that NT user token does not have the necessary FileSystem ACLs to access the resource that was requested. This is the common “access denied” error that individuals get when file ACLs are missing. To fix this, we will probably need to modify the ACLs.

Since ACLs have nothing to do with any of the other 401.x failures, thus in order to rule out ACL problems, it’s best to adjust resource ACLs to “Everyone: Full Control”. We must be able to identify the precise user who lacks ACLs for the resource, and then simply modify that user’s ACLs on the required resources to fix the problem. Some of the common causes of the error include:

1. Incorrect or absent ACLs for the user on the file. Either alter the ACLs or switch the user to an identity with the proper ACLs on the file.

2. The user concept can come as a surprise since we are not verifying using the mechanism that we believe. In order to run as the user identity we anticipate on the server, modify the verification steps as necessary.

3. We can have conflicting NTFS and UNC Share ACLs if the material is stored on a UNC share.

Solution

The Access Control List (ACL) settings on the resource itself are the reason for the “401.3 Denied by Resource ACL” error in IIS, which indicates that access to the requested resource is prohibited. The following actions can be taken to troubleshoot and fix this problem:

1. Verify that the person or group trying to access the resource has the proper file system permissions set. Examine the security configurations of the files and folders associated with the questioned website or app.

2. Check that the user account selected for anonymous authentication, or the IIS app pool identity, has the necessary permissions to view the content. Check that the files and folders have the proper permissions set for the app pool identity.

3. Make sure the resource is set up correctly in IIS if verification is needed. To make sure users are being verified correctly, check the website’s or app’s authentication settings.

4. Check if any URL rules are set up for the website or app. Make sure that the user or group attempting to access the resource is granted access according to the configured rules.

5. If the resource is a .NET app, check the web.config file for any specific settings related to the verification. Make sure that the settings are correct and do not override the IIS settings.

6. If SSL is being used and there are SSL certificate-related issues, ensure that the SSL certificate is valid and properly configured in IIS.

7. Check the event logs on the server for any relevant error messages or warnings that can provide more details about the issue.

8. To find out if the problem is unique to a certain person or group, try accessing the resource using various user credentials.

9. Make sure that any IP restrictions that are in place aren’t unintentionally preventing access to the resource.

10. Make sure that any proxy servers or gateways that exist between the client and the server are not blocking access or interfering with the request.

The IIS 401.4 Error Code in Kerberos Authentication

The error 401.4 Denied by Custom ISAPI Filter suggests that the request was handled by an ISAPI Filter, which returned a structured 401 response. IIS has no control over the purely arbitrary reasons the ISAPI Filter is issuing such 401 answers.

Solution

A custom ISAPI filter is preventing access to the resource, as shown by the “401.4 Denied by Custom ISAPI Filter” error in IIS. It means that the request is being intercepted by a custom filter that has been used on the IIS server, preventing access to the resource. This is how to troubleshoot and fix the problem:

1. Identify the specific custom ISAPI filter that is preventing access. Examine the settings of any installed ISAPI filters to see whether any are set up to block access in specific circumstances.

2. After determining which ISAPI filter is the problem, check its configuration settings. Verify whether any particular conditions or rules are set up that might be blocking access to the resource.

3. Consider temporarily removing the ISAPI filter or changing its configuration to provide access to the resource if it is not necessary or if it is causing unintentional access limitations.

4. Look through the server’s event logs for any pertinent warnings or error messages pertaining to the ISAPI filter. Perhaps the logs will shed further light on the reasons behind the access denial.

5. Test resource access once more after temporarily disabling or deleting the ISAPI filter from the IIS settings. This will help us in finding if the access denial is due to the filter.

6. Verify any additional IIS configuration options that might be influencing how the ISAPI filter behaves. Verify that every configuration complies with the resource’s intended access permissions.

7. If the ISAPI filter is in place for security-related reasons, be sure that actual users aren’t unintentionally denied access by closely examining the access controls.

Our Tech team can assist you in identifying WHICH ISAPI Filter is giving this result and provide further support for it.

The IIS 401.5 Error Code in Kerberos Authentication

The error 401.5 Denied by Custom ISAPI/CGI Web Application suggests that a structured 401 response of some kind was returned by an ISAPI Extension or CGI Web App. The CGI/ISAPI returns these 401 responses for entirely arbitrary and IIS-uncontrollable causes.

Solution

This error in IIS signifies that a custom ISAPI or CGI web app is preventing access to the resource. This shows that the request is being intercepted and access to the resource is being blocked by a custom app that is installed on the IIS server. This is how to troubleshoot and fix the problem:

1. Identify the specific custom ISAPI/CGI web app that is preventing access. Examine the settings of any setup programs to see whether any are set up to prevent access in specific situations.

2. Examine the custom app’s setup settings after we’ve determined which one is causing the problem. Also, verify whether any particular conditions or rules are set up that might be blocking access to the resource.

3. Consider temporarily stopping the custom app or changing its setup to permit the use of the resource if it is causing unintentional usage limitations due to its setup.

4. Check for any available updates or patches if the app is a third-party component. These may address compatibility problems or known concerns with access denial.

5. Look through the server’s event logs for any pertinent warnings or error messages pertaining to the custom app. Perhaps the logs will shed further light on the reasons behind the access denial.

6. Test resource access once more after temporarily disabling or removing the custom app from the IIS setup. This will assist in ascertaining whether the app is, in fact, the root of the denied access.

7. Verify any additional IIS configuration options that might be influencing how the custom app behaves. Verify that every configuration complies with the resource’s intended access permissions.

8. If the custom program is installed for security-related concerns, be sure that valid users are not unintentionally denied access by closely examining the access controls.

[Looking for a solution to another query? We are just a click away.]

Conclusion

To conclude, The IIS request processing errors 401.1 through 401.3 permits a number of logical interpretations and assumptions. Due to the potential for non-obvious behavior from CGI EXE and bespoke ISAPI DLLs, the 401.4 and 401.5 problems are the most unpredictable to identify. As a result, many of the reasonable notions regarding these 401.x are false.