9

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:

What Chrome does; this is the sort of thing I SHOULD be getting in Safari

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:

What Safari 7 on Mavericks does when I try to connect to my intranet

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?

  • Instead of a keychain issue, it is probably related to cookies. You could try to remove them from the "Privacy" section of the Safari preference pane. – Kent Jan 24 '14 at 2:55
  • Nope. I commented on the answer below; I cleared cache, cookies, everything, and it does the exact same thing. I should be getting an HTTP authentication popup, so I don't think cookies directly pertain to that. – 75th Trombone Jan 24 '14 at 19:50
  • Random thought... did you also check your iCloud keychain (if you are linking your keychain to iCloud, that is)? In Keychain Access, there are separate entries for the login keychain and your iCloud keychain. – ithos67 Jan 25 '14 at 2:23
  • A good thought, but I have iCloud Keychain turned off on this computer, and in any case, a search in Keychain Access searches all available keychains. – 75th Trombone Jan 27 '14 at 22:18
  • 1
    I know it won't help you but I just discovered I have exactly the same problem with Safari 7.0.4 and an intranet SharePoint. I can connect fine with Chrome and Firefox but Safari starts loading, as you described, and then just sits there. Very annoying. – nemesys Jun 3 '14 at 14:46
7

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.

  • Thanks for the info. You should consider copying your official bug report to Open Radar and linking to it here. – 75th Trombone Apr 16 '14 at 1:59
  • 1
    This issue been resolved in OS X 10.11.5 – Claus Jørgensen Aug 25 '16 at 21:48
3

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:

  1. present in Yosemite 10.10.1/Safari 8.0.2
  2. present in El Capitan 10.11.2/Safari 9.0.2
  3. 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

1

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.

  • 1
    "I[n] just a few seconds it will blow away logs" — Really? I don't show it logging anything in Console.app. What log does it write to for you? – 75th Trombone Jan 28 '14 at 18:11
  • We use Solarwinds for our logging. However it hits the System logs on our intranet server. – Daniel Jan 28 '14 at 21:37
1

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.

  • 1
    I don't have anything listed there, and when I try to put in credentials, it says "Incorrect password". – 75th Trombone Jan 27 '14 at 22:14
  • 1
    When you're adding the ticket, you're using msgd\lheidbreder as the username, correct? – flammable Jan 28 '14 at 1:13
  • 1
    Yep, I sure am. – 75th Trombone Jan 28 '14 at 17:57
0

Keychains was a good idea but you didn't quite go far enough.

In Safari if you look under the Safari menu you will see Reset Safari... Select this and a number of caches will be cleared.

Now open Safari > Preferences > Autofill and turn off User names and passwords. Now select Passwords and remove any passwords listed there. Select Privacy and click on Remove All Website Data. Select Extensions and if you have any extensions installed switch extensions to Off.

Now go and try your website. Once you've made the attempt go and have a look at Privacy to see if any cookies have been left and Passwords to see if Safari saved your password.

This might get you closer to a solution. Tell us how it goes after that. If Chrome works I'd love to know exactly what it's doing that works. Could a bit more snooping be required?

Just for giggles try the URL http://username:password@intranet.example.com/ (replacing bits obviously) and see what happens.

  • There were no passwords or cookies for the intranet.companyname.com site, but I cleared them all out anyway, and as expected, I'm getting the exact same behavior. Do note that what I should be getting is the browser's HTTP authentication modal, so if it were going to be anywhere, it'd be in Keychain Access, not in cookies. – 75th Trombone Jan 24 '14 at 19:48
  • 1
    Added a bit more as it came to me. – Tony Williams Jan 26 '14 at 7:53
  • 1
    Nothing useful happens when I try that URL format. – 75th Trombone Jan 28 '14 at 18:16
  • 1
    Try it as https:// as well. – Tony Williams Jan 28 '14 at 20:55
0

I had a similar issue at my office as well. The key was to make sure that my DNS lookup excluded the local (company/intranet) sites from going out to look for a DNS address. That was cause of my system wanting to go out to the proxy and getting the constant log in screen. What was happening is that my request for the url of intranet.company.com was being taken by the proxy server and sent out to the web. The main webserver would see that I was connecting through a company IP and respond looking for credentials that were stripped off by the proxy... I think.

Basically making sure that the intranet site was not being sent to a proxy solved my issue. That plus just making Chrome my default browser...

0

Use the Ticket Viewer.app, /System/Library/CoreServices/Ticket Viewer.app, and add a new ticket.

In the new ticket, use the username and password for the authentication of intranet url.

  • 1
    As indicated above, whenever I try to add a new ticket in that app, it tells me I have a bad username/password combination. I've tried both lheidbreder and msgd\lheidbreder as my username; no luck. – 75th Trombone Feb 28 '14 at 18:42
  • This actually worked for me. I had to add an identity for the domain my intranet was on, so for example 'domainusername@workdomain', using my domain password. – tjeerdhans Mar 4 at 15:53
0
  1. Create a new user on the Mac.
  2. Switch to this new user. You may do this while keeping your current session open.
  3. Launch Safari. This is a virgin Safari.
  4. Try to connect to the site. Normally, you will get the authentication dialog.
0

This may or may not help but I have found that if I connect to an smb share other than myself I lose the Authentication Window in Safari 7.0.3 running OS 10.9.2

Myself as in my active directory login and password. I am bound to an active directory server.

I have not tested this on a non bound machine. I have also tested Chrome and FireFox and these apps have no problem wither way. Aurora does not work either way anymore.

Edit by another user:

This appears to be the cause of the problem. This has now been tested with a non-bound machine running Mavericks and now running Yosemite. After I connect to SMB shares, Safari will no longer present the authentication dialog. In Mavericks, as soon as I disconnect from the SMB shares, the dialog is presented and I can log in to my company's Sharepoint 2013 intranet site. I have no problem on Sharepoint 2007 or other intranet sites.

In Yosemite, it appears that I can connect to a maximum of two SMB shares and Safari will still work. If I am connected to three or more SMB shares, the problem manifests. I am not sure yet if it is the number of shares or if perhaps the different shares have different permissions that might affect the situation. I need to do some more rigorous testing on that front.

You must log in to answer this question.

protected by Community Jun 3 '14 at 15:06

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged .