5

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: enter image description here

Response: enter image description here

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?

enter image description here enter image description here enter image description here enter image description here

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?

Clinton Pierce
  • 186
  • 2
  • 10
  • If you download and use Account Lockout Status from microsoft what does it say on that specific account? http://www.microsoft.com/en-us/download/details.aspx?id=15201 – artifex Apr 08 '15 at 17:55
  • Could you post an equivalent entry from the security log for a successful logon for comparison? – dbr Apr 09 '15 at 23:06
  • @Clinton Pierce..Hello, Have you had any luck with this. This is the same problem we have been having. Like you said, I am at the end of google-fu. Please suggest – user575219 Jan 29 '16 at 03:42

1 Answers1

3

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.

hmqcnoesy
  • 161
  • 1
  • 6
  • Be aware that this changes the value of System.Security.Claims.ClaimsPrincipal.Current.Identity to be the worker process instead of the end user. See https://stackoverflow.com/questions/34643894/is-it-possible-to-use-authenticateduseroverride-in-iis-and-still-get-the-windows – kevinpo Dec 08 '20 at 15:47