IIS 8.5 Windows Authentication failing for some users

I have an application that was installed requiring Windows Authentication under Windows 2012, IIS 8.5. When certain users use the application, they're receiving a 401 error after the challenge/response. Others can use the site without problems. The users all happen to be in the same AD Group, but that may be a coincidence.

Here's the request and responses that are processed (the web site is internal to us, http://lcf -- this is an A-Record, not a CNAME):

Request:

Response:

In the security log, this is typical of what's showing up:

An account failed to log on.

Subject:
    Security ID:        NULL SID
    Account Name:       -
    Account Domain:     -
    Logon ID:       0x0

Logon Type:         3

Account For Which Logon Failed:
    Security ID:        NULL SID
    Account Name:       test1
    Account Domain:     CORP

Failure Information:
    Failure Reason:     Account locked out.
    Status:         0xC0000234
    Sub Status:     0x0

Process Information:
    Caller Process ID:  0x0
    Caller Process Name:    -

Network Information:
    Workstation Name:   1N14SW1-PC
    Source Network Address: -
    Source Port:        -

Detailed Authentication Information:
    Logon Process:      NtLmSsp 
    Authentication Package: NTLM
    Transited Services: -
    Package Name (NTLM only):   -
    Key Length:     0

The given account ("test1") is not locked out from Active Directory for login failures, etc.. I think Lockout here must be from IIS.

In the IIS log, this is a relevant entry:

2015-04-06 13:41:27 10.0.150.6 GET /Loss - 80 CORP\test1 10.0.20.28 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.1;+WOW64;+Trident/6.0;+SLCC2;+.NET+CLR+2.0.50727;+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729;+Media+Center+PC+6.0;+.NET4.0C;+.NET4.0E;+InfoPath.3;+EIE10;ENUSWOL) - 401 0 0 15

For the site:

• Only Windows Authentication is Enabled, all others are Disabled.
• Windows Auth, Extended Protection is Off and Kernel-mode Authentication is enabled.
• The providers are Negotiate and NTLM. (The headers above bear that out.)
• Authorization rules are set to Allow All Users

I have tried multiple browsers as well. In fact, switching users on the same machine produces different results. (User A on Machine A is fine, User B on Machine A is not.) The machines are on the same intranet.

Edit: I added a top-level "test.html" file to keep things simple. I turned on failure logging and this is my result. Can anyone read these runes?

EDIT

• Lockoutstatus.exe shows "Not Locked" on all 12 DC's for this domain.

• A successful login:

  An account was successfully logged on.
  
  Subject:
      Security ID:        NULL SID
      Account Name:       -
      Account Domain:     -
      Logon ID:       0x0
  
  Logon Type:         3
  
  Impersonation Level:        Impersonation
  
  New Logon:
      Security ID:        CORP\xxxx1
      Account Name:       xxxx1
      Account Domain:     CORP
      Logon ID:       0x12E1355
      Logon GUID:     {00000000-0000-0000-0000-000000000000}
  
  Process Information:
      Process ID:     0x0
      Process Name:       -
  
  Network Information:
      Workstation Name:   1N14SW1-PC
      Source Network Address: -
      Source Port:        -
  
  Detailed Authentication Information:
      Logon Process:      NtLmSsp 
      Authentication Package: NTLM
      Transited Services: -
      Package Name (NTLM only):   NTLM V2
      Key Length:     0
  

I'm kind of at the end of my Google-fu and rope. Any suggestions?

The fact that the locked out users are all in the same AD group is probably not a coincidence. Those users may not have NTFS permissions to access the application folder. To avoid this problem, I've done the following which should ensure that the application pool identity account is used for all file access, and there is never any impersonation funny business.

Open IIS Manager. Select the application under Sites. Double-click the "Configuration Editor" icon. In the "Section" dropdown, find system.webServer/serverRuntime. Set it to UseWorkerProcessUser.

The same thing can be accomplished using appcmd.exe or .config files.

It's a bit surprising that this isn't the default behavior. Apparently when using Windows authentication and the default setting (UseAuthenticatedUser), some file access is performed using the permissions of the user browsing the site, and some file access is performed using the permissions of the application pool identity. Personally, I always want to use only the app pool identity's permissions, so I have to remember to adjust the settings described above.