10

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?

Improve this question
6
  • 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, 2014 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, 2014 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, 2014 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, 2014 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, 2014 at 14:46

9 Answers 9

Reset to default
8

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.

Improve this answer
2
  • Thanks for the info. You should consider copying your official bug report to Open Radar and linking to it here.
    – 75th Trombone
    Apr 16, 2014 at 1:59
  • 1
    This issue been resolved in OS X 10.11.5
    – Claus Jørgensen
    Aug 25, 2016 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

Improve this answer
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.

Improve this answer
2
  • 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, 2014 at 18:11
  • We use Solarwinds for our logging. However it hits the System logs on our intranet server.
    – Daniel
    Jan 28, 2014 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.

Improve this answer
3
  • 1
    I don't have anything listed there, and when I try to put in credentials, it says "Incorrect password".
    – 75th Trombone
    Jan 27, 2014 at 22:14
  • 1
    When you're adding the ticket, you're using msgd\lheidbreder as the username, correct?
    – flammable
    Jan 28, 2014 at 1:13
  • 1
    Yep, I sure am.
    – 75th Trombone
    Jan 28, 2014 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:[email protected]/ (replacing bits obviously) and see what happens.

Improve this answer
4
  • 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, 2014 at 19:48
  • 1
    Added a bit more as it came to me.
    – Tony Williams
    Jan 26, 2014 at 7:53
  • 1
    Nothing useful happens when I try that URL format.
    – 75th Trombone
    Jan 28, 2014 at 18:16
  • 1
    Try it as https:// as well.
    – Tony Williams
    Jan 28, 2014 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...

Improve this answer
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.

Improve this answer
2
  • 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, 2014 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, 2019 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.
Improve this answer
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.

Improve this answer

You must log in to answer this question.

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