Windows Authentication Intermittently Prompts for Credentials

I thought that only applied to Forms authentication. Is that not the case? I don't have <forms> defined at all in Web.config.

You are right, that only applies to Forms Authentication.  Is this running on more than one server (e.g. load balancing)?

      -dZ.

I found this article, see if it applies to your problem:
    http://support.microsoft.com/kb/871179

"If you set the SPN by using only the FQDN of the server that is running IIS, you will be prompted for your user credentials after 30 minutes. The 30-minute time-out occurs because of the way that Internet Explorer caches Domain Name System (DNS) information. After 30 minutes, Internet Explorer reverts to the NetBIOS name. Therefore, you must make sure that you also register the SPN by using the NetBIOS name of the server that is running IIS to avoid being prompted for your user credentials."

    -dZ.

Never heard of this .. but Dropzone's link looks promising ...

If that does not solve ur problem can you please tell whether this prompting occurs when the user is browsing the same web pages that earlier did not prompt and when doing the same function? do you have any code which access other machines within the network i.e hop though multiple machines? Is impersonation set to true?

Rejo

Impersonation is not set.

The web server is standalone, not part of a farm. It is a virtual server running on VMWare if that makes a difference (can't imagine it would).

I had found DropZone's link via Google already, but it seems to be talking about web services running as a domain user. In my case, it's running as Network Service which that article indicates should not be affected by the problem the article is written to address.

Again, the intent is for the user to never have to log in to access the web app. As I understand it, this should be entirely feasible.

I should have mentioned that the user can cancel the login dialog, close the browser and reopen it and access the page again without logging in.

This tells me that there is some sort of issue with a cookie or a session expiring. It could conceivably be browser related, network related or .NET config related.

Or something else entirely. I'm at a loss.

When the browser prompts the user for credentials it is because the server responded with a 401 status code after the original credentials were sent.  The browser then assumes that the last credentials failed and prompts the user.

Now, what is causing the web server to respond with a 401 status code is the mystery.  The article mentions the application pool (not IIS or the service itself) running as a domain user.  Can you confirm that this is not the case?  Have you tried registering the SPN with the NetBIOS name just to be sure?

Also, have you tried using the "Authentication and Access Control Diagnostics" tool referenced in that article?
     http://www.microsoft.com/downloads/details.aspx?FamilyId=E90FE777-4A21-4066-BD22-B931F7572E9A&displaylang=en

I grabbed ieHTTPHeaders and I see that every connection to the web app, even the ones that do not cause an auth prompt, have an initial response of 401 Unauthorized followed immediately by a response of 200 OK

HTTP/1.1 401 Unauthorized
Date: Fri, 23 Jan 2009 15:37:52 GMT
Server: Microsoft-IIS/6.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 1683
 
HTTP/1.1 200 OK
Date: Fri, 23 Jan 2009 15:37:52 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
WWW-Authenticate: Negotiate oYGgMIGdoAMKAQChCwYJKoZIgvcSAQICooGIBIGFYIGCBgkqhkiG9xIBAgICAG9zMHGgAwIBBaEDAgEPomUwY6ADAgEXolwEWs36ACByBIhs6S9zMGKW6bdwXONN2XRpVgEgUYU3iDF9768dAB9nmFbIJRRIzL5NOSgiiq1TS/ek2ERkCdIRvRJSlZke5X/Rs45FSucLtqE3gDK/5yMg3CZCmg==
X-AspNet-Version: 2.0.50727
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 495
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:

I've downloaded the tool and I'll see what I can find with it.

Yes, that's how the HTTP Authentication works:  The server responds with 401, and the browser re-sends the request with the appropriate credentials.  Ocassionaly, in your case, the server will respond with a 401 after the browser sent the credentials, which causes the browser to assumed the credentials were rejected.  It will then prompt the user for new credentials.

Since this seems to be a transient error with IE (for whatever mysterious reason, which we can't yet determine), if you close the browser and try again, it'll work.

Let us know if you are able to determine any problems with the diagnostics tool.

      -dZ.

FYI: I'm looking at the Property sheet for the Application Pool. On the Identity tab, "Predefined" is selected and Network Service is shown in the drop-down next to it.

I'm a bit wary of futzing with the SPN as that's pretty far outside my area of expertise and I don't want to hose the webserver.

Would it make any difference that this webapp is runing on port 8080?

Ok, the Application Pool is fine, and I agree with you on the SPN.  I am also not very familiar with it, so won't recommend changing it unless you know what you are doing.

As for the listening port, it shouldn't make a difference.

     -dZ.

It may take some time to reproduce the issue. In the meantime, here's the Kerberos diagnostics output (domain name censored)

 SPNs for CN=POL-WEB2,OU=Servers,OU=Public Safety,DC=internal,DC=<domain>,DC=org: 
  SMTPSVC/POL-WEB2 
  SMTPSVC/pol-web2.internal.<domain>.org 
  HOST/POL-WEB2 
  HOST/pol-web2.internal.<domain>.org 
 ServiceName = krbtgt INTERNAL.<DOMAIN>.ORG  
 TargetName = krbtgt <DOMAIN>  
 ClientName = JCFord  
 DomainName = INTERNAL.<DOMAIN>.ORG 
 TargetDomainName = INTERNAL.<DOMAIN>.ORG 
 AltTargetDomainName = INTERNAL.<DOMAIN>.ORG 
 Diagnostics complete 
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:

Well, fiddlesticks. The Authentication and Access Control Diagnostics tool will not accept my URL when I add the port number. It says http://pol-ntweb2:8080 is an invalid URL.

I followed the instructions in the article to edit the timeouts on a local machine and was able to reproduce the error much more quickly. I am beginning to suspect that it is indeed the NTLM/NetBIOS issue as described in the article.

Now the dreaded part: Trying to get the network nazis to listen to me and help chase this down.

Stewed on this problem over the weekend. Possible epiphany. The Microsoft whitepaper describes the problem as being a result of IE ditching server information after 30 minutes and reverting to the NetBIOS name.

I recall now that the NetBIOS name of our server is different from the domain name users use to access the web app. When our network group virtualized the server, they created it as POL-WEB2. The users' shortcuts point to POL-NTWEB2 which was redirected via NAT. So what may be happening is that IE is dropping the POL-NTWEB2 server information and reverting to the POL-WEB2 NetBIOS name, to which the user is not already authenticated.

Testing is under way.

Well not quite exactly. The article from MS was addressing the similar symptoms but an entirely different cause. It's written to resolve issues stemming from user accounts.

• The IIS 6.0 Web site is part of an IIS application pool. 
• The application pool is running under a local account or under a domain user account. 
• The Web site is configured to use Integrated Windows authentication only. 

You are right, it was addressing similar symptoms from different causes.  But ultimately the symptoms were manifested because of IE's behaviour, which is where it relates to your problem.

In any case, I'm glad you are close to solving it.  I don't really think I deserve the points--at least not yet--since we still don't know if you will be able to solve the original problem completely.  Although I'm fairly confident in this solution, we still could be barking off the wrong tree.  Perhaps closing the question was a bit premature.

Indeed, I'd like to know how it plays out.

    Cheers!
    -dZ.

I haven't been prompted again since switching to use the NetBIOS name on my PC so my confidence is quite high. The only challenge ahead is getting the network group to play ball and make a change.

Premature to close it? Eh. Maybe. I felt the cause was identified as well as at least one possible workaround (don't use NAT). I wanted to award the points for your persistent followup. It's appreciated.

I'll add more comments once I talk to the network guys.

Just to follow up, the problem seems to have truly been solved. The network group renamed the server so that the domain name matched the NetBIOS name, which seemed to be the path of least resistance as they didn't want to try fooling with the SPN fix.