IIS Web App Using Windows Authentication Nevertheless Generates Login Prompts

Question

So, my problem is that I have a web application, which should be using Windows authentication, but is nevertheless prompting the user for a password upon first use of the day.

Details: This is an internal-only app, only used by people on the same intranet as the application.

The server is Windows Web Server 2008R2, the version of IIS is 7.5.7600.16385.

The browser I'm using for testing is IE 11.09600.18124. It recognizes the site as Local intranet | Protected Mode: Off. The User Authentication, Logon option chosen for this zone is "Automatic logon with current name and password". Enable Integrated Windows Authentication is on.

The application is ASP.NET v4, running on an ASP.NET v4.0 application pool, classic pipeline, and NetworkService for the identity.

Authentication for the app is Anonymous disabled, ASP.NET impersonation enabled, Forms disabled, Windows Authentication enabled.

Providers are NTLM first, Negotiate second. Extended Protection is Accept, Kernel-mode authentication is enabled.

Authenticated Users, NETWORK SERVICE, aspnet_wp account, and Domain Users all have permission to view the site, along with the usual suspects.

The URL I'm using for the site is not the FQDN. It's http://machinename/DUmmyNameOfApp etc.

There is no "deny" rule under the .NET Authorization Rules.

I have tried disabling the loopback check per article 896861 at MS support, which didn't help, and does not appear to apply to my issue anyway.

I have tried switching the first provider to Negotiate:Kerberos, which didn't help.

I have tried switching app pool identity to the App Pool ID, which did not help.

I have added Network Service, the app pool identity, to IIS_IUSRS.

I have read question 5402381 here, which has not helped.

The IIS log for a typical incident reads:

#Software: Microsoft Internet Information Services 7.5
#Version: 1.0
#Date: 2016-01-12 19:23:31
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken
2016-01-12 19:23:31 10.1.1.60 GET /DummyNameOfApp/Default.aspx - 80 - 10.1.28.54 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.1;+WOW64;+Trident/7.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;+.NET+CLR+1.1.4322) 401 1 2148074254 78
2016-01-12 19:23:34 10.1.1.60 GET /DummyNameOfApp/Default.aspx - 80 DUMMYDOMAIN\jwoodward 10.1.28.54 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.1;+WOW64;

+Trident/7.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;+.NET+CLR+1.1.4322) 401 5 0 

249
2016-01-12 19:23:43 10.1.1.60 GET /DummyNameOfApp/Default.aspx - 80 DUMMYDOMAIN\jwoodward 10.1.28.54 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.1;+WOW64;

+Trident/7.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;+.NET+CLR+1.1.4322) 200 0 0 

7004
2016-01-12 19:23:43 10.1.1.60 GET /DummyNameOfApp/null sEcho=1&iColumns=10&sColumns=&iDisplayStart=0&iDisplayLength=-

1&mDataProp_0=0&mDataProp_1=1&mDataProp_2=2&mDataProp_3=3&mDataProp_4=4&mDataProp_5=5&mDataProp_6=6&mDataProp_7=7&mDataProp_8=8&mDataProp_9=9&_=1452626623940 80 

DUMMYDOMAIN\jwoodward 10.1.28.54 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.1;+WOW64;+Trident/7.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;+.NET+CLR+1.1.4322) 404 17 50 0

EDIT: The authentication tag in the web.config is <authentication mode="Windows" />. There is no authorization tag.

Answer 1

Starting with Windows 7, an additional security feature called Extended Protection for Authentication is enabled by default. My suspicion is that this is causing the issue you're observing. You've already set "Extended Protection" to "Accept" for this web app on the server. If you confirm that the client has it set, and then update the server to use "Require" for Extended Protection, the prompt should go away.

See http://blogs.technet.com/b/srd/archive/2009/12/08/extended-protection-for-authentication.aspx for additional details on how to set up EPA on both the client and the server.