See the UPDATE below for new information about the actual HTTP requests going on under the hood.
So I started a new job back in October. It's mostly a Windows shop, and they use IIS and Active Directory for a bunch of internal stuff. They have an intranet site at intranet.companyname.com.
In Chrome on Mavericks, when I go there, I get the expected little HTTP auth dropdown:
where I can type my username and password. I'm not very swift with Active Directory, but I guess msgd is the Active Directory domain I'm on, so I type msgd\lheidbreder and my password, and I can log in successfully in Chrome.
Way back in October, the first time I tried this in Safari, I got some weird behavior; like, I saw the password thing, but then it didn't work when I put in my credentials. I don't remember exactly what it did.
But after that first attempt, and on every attempt since then, when I try to go to intranet.companyname.com, Safari shows a blank screen:
The screen doesn't change, and the progress bar fills up about 20% and stays there.
UPDATE
I ran an app to snoop HTTP requests, and I found out what this was doing behind the scenes. It's not just sitting there; Safari is actually requesting the page almost 1000 times per second, and each time, it gets a 401 error and an HTML error page with the title "You are not authorized to view this page".
On one example request from the middle of a load attempt, Safari sends this Authorization header:
Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA=
And the server responds with this WWW-Authenticate header:
Negotiate oYIBIzCCAR+gAwoBAaEMBgorBgEEAYI3AgIKooIBCASCAQROVExNU1NQAAIAAAAOAA4AOAAAAAUCiWKPhp0o8/Y/9gAAAAAAAAAAvgC+AEYAAAAFAs4OAAAAD0EAUgBJAFMAVwBFAEIAAgAOAEEAUgBJAFMAVwBFAEIAAQAMAE4ARQBXAFcARQBCAAQAKgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAADADgATgBFAFcAVwBFAEIALgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAAFACoAYQByAGkAcwB3AGUAYgAuAGEAcgBpAHMAdABvAHQAbABlAC4AbgBlAHQAAAAAAA==
On the next request, Safari sends an identical Authorization header, and then the server responds with a very slightly different WWW-Authenticate header:
Negotiate oYIBIzCCAR+gAwoBAaEMBgorBgEEAYI3AgIKooIBCASCAQROVExNU1NQAAIAAAAOAA4AOAAAAAUCiWLa6vytPOG0owAAAAAAAAAAvgC+AEYAAAAFAs4OAAAAD0EAUgBJAFMAVwBFAEIAAgAOAEEAUgBJAFMAVwBFAEIAAQAMAE4ARQBXAFcARQBCAAQAKgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAADADgATgBFAFcAVwBFAEIALgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAAFACoAYQByAGkAcwB3AGUAYgAuAGEAcgBpAHMAdABvAHQAbABlAC4AbgBlAHQAAAAAAA==
Repeat ad infinitum.
I've tried deleting everything that matches intranet in Keychain Access and clearing my entire cache/cookies, to see if I could restore the original weird behavior, but it didn't work.
Do I have some kind of funky domain stuff going on? What else can I try to diagnose this?
Best Answer
I can confirm that I see the identical problem with Safari 7.0.2 (9537.74.9), with all current Mac OS X Mavericks updates installed. (Thousands of request packets per second with the same kind of content as described above.)
However, while this may or may not help the original poster, I have found that this problem only occurs if the Windows server has Integrated Windows Authentication (also known as NTLM Authentication) and Negotiate Authentication enabled.
The server then sends these two headers:
Safari will reply:
And from there, the loop will get going.
But if Negotiate Authentication is not enabled on the server, there will be only one WWW-Authenticate header:
And Safari's reply will be something like:
This will work just fine. Essentially, it seems that Negotiate is broken in Safari, and since the server sends Negotiate first, indicating a preference for it, Safari will try it and enter an infinite loop that prevents it from falling back to NTLM.
So, if the server administrator can be persuaded to turn off Negotiate in the authentication settings, the problem may be solved.
I might add that Firefox sends the "Authorization: NTLM ..." header regardless of whether the server provides Negotiate in addition to NTLM or not. Presumably, Negotiate is not implemented in Firefox.
Update
Safari 7.0.3 (9537.75.14) still exhibits the same problem.
We previously reported the issue as a bug at bugreport.apple.com, but the bug was closed as a duplicate of a previous bug—the contents of which we cannot see, except that it is still marked as open.
Update 2
I can confirm hauns's finding that the authentication works with Safari 7.0.4 (9537.76.4).
Update 3
This issue is back in Safari 7.0.5 (9537.77.4)
Update 4
This issue is still present in Safari 7.0.6 (9537.78.2), as noted by hauns, with cifs or smb volumes mounted.