7

I have a development copy of an ASP.NET intranet site checked out and running on my local machine. We're using digest authentication to allow users to log in using their active directory accounts.

On my development copy only, Digest sometimes will repeatedly prompt for login information usually ~9 times per page request. After repeatedly logging in (or it also works to cancel out of 8 out of the 9 prompts), I can use the site as normal.

I cannot pinpoint what is triggering the issue. Sometimes this problem triggers upon the next page request, sometimes after I edited/saved/refreshed a page, and sometimes it doesn't happen at all.

Each prompt triggers several logon (Event ID 4624 & 4672) security events in the Events Viewer. Shortly after each burst of logon events, I'll see a burst of logoff events (Event ID 4634)

A co-worker who has a nearly an identical setup (Windows 7, IIS 7) is not experiencing the issue. Our production copy (that is running on a different server) also does not experience the issue. We've tried to compare our settings in IIS, not really finding any differences.

I'm using chrome but I've experienced the issue in other browsers.

David Budiac
  • 515
  • 1
  • 6
  • 11

3 Answers3

2

The question is 11 years old, but still not solved.

The actual problem is wrong MD5-sess implementation in Chrome and Firefox. The only correct implementation can be found in (already abandoned) IE.

According to RFC 2617 (and RFC 7616) the first part of hash code (H(A1)) for MD5-sess must be calculated with the server nonce and the first client cnonce. The H(A1) should not be changed until new server nonce is received, even if client uses another cnonce.

According to Chrome and Firefox source code, browsers ignore this requirement and always recalculate H(A1) with new cnonce. As the result, the first request with the first cnonce is valid and accepted by IIS, but the second and following requests with the same nonce and different cnonce have invalid response hash and rejected by IIS. This force browsers to request the username and password again for every element located on URL with Digest Authorization.

The more info is here.

Karlson2k
  • 21
  • 2
1

If this app is for internal use only I would recommend using integrated auth rather then digest. For apps without built in web-form auth like yours, 99% are integrated (AD auth pass through) or basic auth over SSL.

Also, Digest doesn't always work with AD and depends on settings in AD and in each user. Google things like "digest auth active directory" or "digest reversible encryption" so see the issues people have with it.

Other things to look at are NTFS permissions on files/folders, and if anonymous is enabled (it shouldn't be).

Bret Fisher
  • 3,963
  • 2
  • 20
  • 25
0

Do you have a (caching/non-caching) web proxy between your machine and the server ? I saw the same problem with Sharepoint authentication, the solution we took was to get rid of the ISA Firewall/Proxy through a rule allowing clients to bypass it for the Sharepoint site. That solved the problem but we didn't investigate the root cause.

Shadok
  • 623
  • 5
  • 10