File / URL authorization failed for the SECOND request

Question

I have an issue similar to these:

URL authorization failed for the request

IIS File authorization failed for the request

I am running several similar web sites on IIS 7. I am testing with Firefox, so that I can act as users other than me.

I have been doing all my work on site 1. I can log in as network users administrator and sys\bob.

I am now working on sites 2 and 3. I can log in as administrator just fine. The problem is: When I log in as dom\bob, the initial log in is properly authenticated. On all subsequent requests, dom\bob is rejected for either a file or a URL authentication failure.

The Application event log entries are materially similar to those quoted in the linked issues, except that the custom event details section is empty.

I have checked the web sites in IIS Manager and found no differences so far. I have confirmed that the web.config files are identical, except for site-specific information such as the connection string. I have verified that the folder permissions are correct as far as I have looked.

Specifically on permissions:

The <authentication> mode is Windows on all web sites.

The <authorization> node in particular is identical between web sites.

The local domain is the same MS Windows Server 2008 virtual machine in all cases -- one server image hosting multiple web sites. So in theory, user authorizations should be identical across all web sites.

--Edit 1-- Just my luck. I had this authorization issue pop up on web site 1, on a JavaScript file that has run just fine before, during a sprint review. There was the twist that in this case, the user was able to go through quite a few pages before the authorization failed.

I'll post my logs as soon as I can.

--Edit 2-- I did make one environment change shortly before this issue started: I updated jQuery and Bootstrap.

Here's my diffs in packages.config:

Before

  <package id="AspNet.ScriptManager.bootstrap" version="3.3.5" targetFramework="net45" />
  <package id="AspNet.ScriptManager.jQuery" version="2.1.4" targetFramework="net45" />
  <package id="bootstrap" version="3.3.5" targetFramework="net45" />
  <package id="jQuery" version="2.1.4" targetFramework="net45" />

After

  <package id="AspNet.ScriptManager.bootstrap" version="3.3.6" targetFramework="net45" />
  <package id="AspNet.ScriptManager.jQuery" version="2.2.3" targetFramework="net45" />
  <package id="bootstrap" version="3.3.6" targetFramework="net45" />
  <package id="jQuery" version="2.2.3" targetFramework="net45" />

And here are two typical entries in the Application event log, appropriately sanitized.

1:

Event code: 4008 
Event message: File authorization failed for the request. 
Event time: 6/2/2016 2:31:29 PM 
Event time (UTC): 6/2/2016 6:31:29 PM 
Event ID: e4a0fd65d9e34686967f14429d21ab97 
Event sequence: 14 
Event occurrence: 1 
Event detail code: 0 

Application information: 
    Application domain: /LM/W3SVC/21/ROOT-1-131093658656731243 
    Trust level: Full 
    Application Virtual Path: / 
    Application Path: C:\Users\Administrator\Documents\Visual Studio 2013\Projects\HAWK_WebForms\HAWK.Web.LogansRun\ 
    Machine name: BAH01 

Process information: 
    Process ID: 5288 
    Process name: iisexpress.exe 
    Account name: HAWK\administrator 

Request information: 
    Request URL: http://localhost:53104/Scripts/jquery-2.2.3.js 
    Request path: /Scripts/jquery-2.2.3.js 
    User host address: ::1 
    User: HAT\john.smith
    Is authenticated: True 
    Authentication Type: NTLM 
    Thread account name: HAWK\administrator 

Custom event details: 

2:

Event code: 4008 
Event message: File authorization failed for the request. 
Event time: 6/2/2016 2:28:51 PM 
Event time (UTC): 6/2/2016 6:28:51 PM 
Event ID: a43d7292a8894df193600e829e74c696 
Event sequence: 14 
Event occurrence: 1 
Event detail code: 0 

Application information: 
    Application domain: /LM/W3SVC/14/ROOT-1-131093657141125131 
    Trust level: Full 
    Application Virtual Path: / 
    Application Path: C:\Users\Administrator\Documents\Visual Studio 2013\Projects\HAWK_WebForms\HAWK.Web.LogansRun\ 
    Machine name: BAH01 

Process information: 
    Process ID: 5248 
    Process name: iisexpress.exe 
    Account name: HAWK\administrator 

Request information: 
    Request URL: http://localhost:53752/Scripts/Pages/Admin/SelfRatingWizard.js 
    Request path: /Scripts/Pages/Admin/SelfRatingWizard.js 
    User host address: ::1 
    User: HAWK\james.jones
    Is authenticated: True 
    Authentication Type: NTLM 
    Thread account name: HAWK\administrator 

Custom event details: 

--Edit 3--

I tried adding the registry key from this answer: https://stackoverflow.com/a/13015279/2615836

It didn't change anything. I also double checked the order of the authentication providers. NTLM is already ahead of Negotiate for all the sites.

--another update-- I rolled back Bootstrap and jQuery. To my astonishment, the file authorization still fails! Again, jQuery.js is one spot -- just about every file raises this complaint. It's as if the authorization token gets "forgotten".

--update to Edit 1-- The JavaScript file that was raising issues in web site 1 did not have permissions for Network Service like all the other JavaScript files did. Once I fixed that, web site 1 was resolved. Alas, this fix did not resolve web site 2.

Answer 1

This behavior may occur (in different browsers) when several factors are actual at the same time:

• The WindowsAuthentication is enabled. The AnonymousAuthentication is disabled;
• The server is accessed by the IP address (not by the alias);
• A first ajax request is completed;
• 1 minute timeout is lapsed.

Check the ajax request hangs when referring to server by IP address and WindowsAuthentication is enabled in IE11 thread regarding this.

Check if this issue is applicable in your case. If so, try using any other value from the above list to (temporarily) overcome this problem.

Answer 2

I eventually found that the directory for Project1 gave read permissions to the domain group Users, and none of the other projects did. Once I granted Users the Read permission on Project2's base directory, the authentication issue was resolved.

So it was an OS-level user permissions issue.