Safari 7 can't connect to intranet using HTTP authentication
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?
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:
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
Safari will reply:
Authorization: Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA=
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:
WWW-Authenticate: NTLM
And Safari's reply will be something like:
Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=
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.
Safari 7.0.5 still has the issue: authentication breaks down if finder shares network resources via SMB: (or CIFS:). once all connected network volumes are unmounted, Safari resumes proper authentication.
Regression:
- present in Yosemite 10.10.1/Safari 8.0.2
- present in El Capitan 10.11.2/Safari 9.0.2
- present in Safari 10.0.1
The corresponding Apple bug 22990203 is still active. No mortal is allowed to see it (cf.bugreporter.apple.com)
See also: https://discussions.apple.com/message/27727310#27727310
We are having the same issue. Thus why we haven't upgraded our Macs to Mavericks yet. It appears to try to log into the Intranet without domain credentials(Intranet\'blank'). It should be using the domain\username. I can understand this can be frustrating but it seems that authentication is missing in safari.
I just a few seconds it will blow away logs.
Firefox seems to work great though.
This might be a long shot, but if you have a Kerberos ticket (from signing into another service), Safari might be trying to use that.
Open /System/Library/CoreServices/Ticket Viewer.app to see if you have any Kerberos tickets. If so, click on the ticket, Remove Identity, and try again.
Alternatively, if nothing is listed, try using Add Identity and seeing if that works with Safari.
Firefox and Chrome don't utilize Kerberos, I don't think, which is why they'll prompt you separately for credentials.