Safari 7 kann über die HTTP-Authentifizierung keine Verbindung zum Intranet herstellen

9

Im UPDATE unten finden Sie neue Informationen zu den tatsächlichen HTTP-Anforderungen, die unter der Haube ausgeführt werden.

Also habe ich im Oktober einen neuen Job angefangen. Es ist meistens ein Windows-Shop, und sie verwenden IIS und Active Directory für eine Reihe von internen Dingen. Sie haben eine Intranetseite bei intranet.companyname.com.

Wenn ich in Chrome on Mavericks dorthin gehe, erhalte ich das erwartete kleine Dropdown-Menü für die HTTP-Authentifizierung:

Was Chrome macht;  Dies ist die Art von Dingen, die ich in Safari bekommen sollte

Hier kann ich meinen Benutzernamen und mein Passwort eingeben. Ich bin nicht sehr schnell mit Active Directory, aber ich denke, es msgdist die Active Directory-Domäne, in der ich mich befinde. Ich gebe also msgd\lheidbredermein Kennwort ein und kann mich erfolgreich in Chrome anmelden.

Bereits im Oktober, als ich dies zum ersten Mal in Safari versuchte, bekam ich ein seltsames Verhalten. Ich habe das Passwort gesehen, aber dann hat es nicht funktioniert, als ich meine Anmeldeinformationen eingegeben habe. Ich erinnere mich nicht genau, was es getan hat.

Aber nach diesem ersten Versuch und bei jedem Versuch seitdem, wenn ich versuche zu gehen intranet.companyname.com, zeigt Safari einen leeren Bildschirm:

Was Safari 7 auf Mavericks macht, wenn ich versuche, eine Verbindung zu meinem Intranet herzustellen

Der Bildschirm ändert sich nicht und der Fortschrittsbalken füllt sich zu etwa 20% und bleibt dort.


AKTUALISIEREN

Ich habe eine App ausgeführt, um HTTP-Anfragen zu erfassen, und ich habe herausgefunden, was dies hinter den Kulissen tut. Es sitzt nicht nur da; Safari fordert die Seite tatsächlich fast 1000 Mal pro Sekunde an und erhält jedes Mal einen 401-Fehler und eine HTML-Fehlerseite mit dem Titel "Sie sind nicht berechtigt, diese Seite anzuzeigen".

Bei einer Beispielanforderung aus der Mitte eines Ladeversuchs sendet Safari diesen AuthorizationHeader:

Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA=

Und der Server antwortet mit diesem WWW-AuthenticateHeader:

Negotiate oYIBIzCCAR+gAwoBAaEMBgorBgEEAYI3AgIKooIBCASCAQROVExNU1NQAAIAAAAOAA4AOAAAAAUCiWKPhp0o8/Y/9gAAAAAAAAAAvgC+AEYAAAAFAs4OAAAAD0EAUgBJAFMAVwBFAEIAAgAOAEEAUgBJAFMAVwBFAEIAAQAMAE4ARQBXAFcARQBCAAQAKgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAADADgATgBFAFcAVwBFAEIALgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAAFACoAYQByAGkAcwB3AGUAYgAuAGEAcgBpAHMAdABvAHQAbABlAC4AbgBlAHQAAAAAAA==

Bei der nächsten Anforderung sendet Safari einen identischen AuthorizationHeader, und der Server antwortet mit einem geringfügig anderen WWW-AuthenticateHeader:

Negotiate oYIBIzCCAR+gAwoBAaEMBgorBgEEAYI3AgIKooIBCASCAQROVExNU1NQAAIAAAAOAA4AOAAAAAUCiWLa6vytPOG0owAAAAAAAAAAvgC+AEYAAAAFAs4OAAAAD0EAUgBJAFMAVwBFAEIAAgAOAEEAUgBJAFMAVwBFAEIAAQAMAE4ARQBXAFcARQBCAAQAKgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAADADgATgBFAFcAVwBFAEIALgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAAFACoAYQByAGkAcwB3AGUAYgAuAGEAcgBpAHMAdABvAHQAbABlAC4AbgBlAHQAAAAAAA==

Wiederholen Sie ad infinitum.


Ich habe versucht, alles zu löschen, was intranetin Keychain Access übereinstimmt, und meinen gesamten Cache / meine Cookies zu löschen , um zu sehen, ob ich das ursprüngliche seltsame Verhalten wiederherstellen konnte, aber es hat nicht funktioniert.

Habe ich irgendwelche funky Domain-Sachen im Gange? Was kann ich sonst noch versuchen, dies zu diagnostizieren?

75. Posaune
quelle
Anstelle eines Schlüsselbundproblems hängt es wahrscheinlich mit Cookies zusammen. Sie können versuchen, sie aus dem Abschnitt "Datenschutz" des Safari-Einstellungsbereichs zu entfernen.
Kent
Nee. Ich habe die Antwort unten kommentiert. Ich habe den Cache, die Cookies und alles geleert, und es macht genau das Gleiche. Ich sollte ein HTTP-Authentifizierungs-Popup erhalten, daher denke ich nicht, dass Cookies direkt damit zusammenhängen.
75. Posaune
Zufälliger Gedanke ... haben Sie auch Ihren iCloud-Schlüsselbund überprüft (wenn Sie Ihren Schlüsselbund mit iCloud verknüpfen)? In Keychain Access gibt es separate Einträge für den Login- Schlüsselbund und Ihren iCloud- Schlüsselbund.
ithos67
Ein guter Gedanke, aber ich habe iCloud Keychain auf diesem Computer deaktiviert, und auf jeden Fall durchsucht eine Suche in Keychain Access alle verfügbaren Schlüsselanhänger.
75. Posaune
1
Ich weiß, dass es Ihnen nicht helfen wird, aber ich habe gerade festgestellt, dass ich genau das gleiche Problem mit Safari 7.0.4 und einem SharePoint-Intranet habe. Ich kann mich gut mit Chrome und Firefox verbinden, aber Safari wird wie beschrieben geladen und sitzt dann einfach da. Sehr nervig.
Nemesys

Antworten:

7

Ich kann bestätigen, dass ich das identische Problem mit Safari 7.0.2 (9537.74.9) sehe, wenn alle aktuellen Mac OS X Mavericks-Updates installiert sind. (Tausende von Anforderungspaketen pro Sekunde mit dem gleichen Inhalt wie oben beschrieben.)

Obwohl dies dem Originalposter möglicherweise hilft oder nicht, habe ich festgestellt, dass dieses Problem nur auftritt, wenn auf dem Windows-Server die integrierte Windows-Authentifizierung (auch als NTLM-Authentifizierung bezeichnet) und die Authentifizierung aushandeln aktiviert sind.

Der Server sendet dann diese beiden Header:

WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM

Safari wird antworten:

Authorization: Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA=

Und von dort geht die Schleife los.

Wenn die Negotiate-Authentifizierung auf dem Server nicht aktiviert ist, gibt es nur einen WWW-Authenticate-Header:

WWW-Authenticate: NTLM

Und Safaris Antwort wird ungefähr so ​​lauten:

Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=

Dies wird gut funktionieren. Im Wesentlichen scheint Negotiate in Safari fehlerhaft zu sein. Da der Server Negotiate zuerst sendet und eine Präferenz dafür angibt, wird Safari es versuchen und in eine Endlosschleife eintreten, die verhindert, dass es auf NTLM zurückfällt.

Wenn der Serveradministrator dazu gebracht werden kann, Negotiate in den Authentifizierungseinstellungen zu deaktivieren, ist das Problem möglicherweise behoben.

Ich könnte hinzufügen, dass Firefox den Header "Authorization: NTLM ..." sendet, unabhängig davon, ob der Server zusätzlich zu NTLM Negotiate bereitstellt oder nicht. Vermutlich ist Negotiate in Firefox nicht implementiert.


Aktualisieren

Safari 7.0.3 (9537.75.14) weist immer noch das gleiche Problem auf.

Wir haben das Problem zuvor als Fehler unter bugreport.apple.com gemeldet, aber der Fehler wurde als Duplikat eines vorherigen Fehlers geschlossen, dessen Inhalt wir nicht sehen können, außer dass er immer noch als offen markiert ist.

Update 2

Ich kann hauns 'Feststellung bestätigen, dass die Authentifizierung mit Safari 7.0.4 (9537.76.4) funktioniert.

Update 3

Dieses Problem ist wieder in Safari 7.0.5 (9537.77.4) enthalten.

Update 4

Dieses Problem tritt weiterhin in Safari 7.0.6 (9537.78.2) auf, wie von hauns festgestellt, mit gemounteten cifs oder smb-Volumes.

Otto G.
quelle
Danke für die Information. Sie sollten in Betracht ziehen, Ihren offiziellen Fehlerbericht auf Open Radar zu kopieren und hier darauf zu verlinken.
75. Posaune
1
Dieses Problem wurde in OS X 10.11.5
Claus Jørgensen
3

Safari 7.0.5 hat immer noch das Problem: Die Authentifizierung bricht zusammen, wenn der Finder Netzwerkressourcen über SMB: (oder CIFS :) gemeinsam nutzt. Sobald alle verbundenen Netzwerkvolumes nicht mehr bereitgestellt sind, setzt Safari die ordnungsgemäße Authentifizierung fort.

Regression:

  1. vorhanden in Yosemite 10.10.1 / Safari 8.0.2
  2. vorhanden in El Capitan 10.11.2 / Safari 9.0.2
  3. in Safari 10.0.1 vorhanden

Der entsprechende Apple-Fehler 22990203 ist noch aktiv. Kein Sterblicher darf es sehen (vgl. Bugreporter.apple.com)

Siehe auch: https://discussions.apple.com/message/27727310#27727310

hauns
quelle
1

Wir haben das gleiche Problem. Deshalb haben wir unsere Macs noch nicht auf Mavericks aktualisiert. Es scheint zu versuchen, sich ohne Domänenanmeldeinformationen im Intranet anzumelden (Intranet \ 'leer'). Es sollte die Domäne \ Benutzername verwenden. Ich kann verstehen, dass dies frustrierend sein kann, aber es scheint, dass die Authentifizierung in Safari fehlt.

Ich nur ein paar Sekunden wird es Protokolle wegblasen.

Firefox scheint jedoch großartig zu funktionieren.

Daniel
quelle
1
"Ich [n] nur ein paar Sekunden wird es Protokolle wegblasen" - Wirklich? Ich zeige nicht, dass irgendetwas in Console.app protokolliert wird. In welches Protokoll schreibt es für Sie?
75. Posaune
Wir verwenden Solarwinds für unsere Protokollierung. Es trifft jedoch die Systemprotokolle auf unserem Intranetserver.
Daniel
1

Dies mag ein langer Weg sein, aber wenn Sie ein Kerberos-Ticket haben (von der Anmeldung bei einem anderen Dienst), versucht Safari möglicherweise, dieses zu verwenden.

Öffnen Sie / System / Library / CoreServices / Ticket Viewer.app, um festzustellen, ob Sie Kerberos-Tickets haben. Wenn ja, klicken Sie auf das Ticket, Identität entfernen und versuchen Sie es erneut.

Wenn nichts aufgelistet ist, versuchen Sie alternativ, Identität hinzufügen, und prüfen Sie, ob dies mit Safari funktioniert.

Firefox und Chrome verwenden Kerberos nicht, glaube ich nicht. Deshalb werden Sie separat nach Anmeldeinformationen gefragt.

brennbar
quelle
1
Ich habe dort nichts aufgelistet und wenn ich versuche, Anmeldeinformationen einzugeben, wird "Falsches Passwort" angezeigt.
75. Posaune
1
Wenn Sie das Ticket hinzufügen, verwenden Sie msgd \ lheidbreder als Benutzernamen, richtig?
brennbar
1
Ja, das bin ich sicher.
75. Posaune
0

Schlüsselanhänger waren eine gute Idee, aber Sie sind nicht weit genug gegangen.

Wenn Sie in Safari unter dem SafariMenü nachsehen , wird Folgendes Reset Safari...angezeigt: Wählen Sie diese Option aus, und eine Reihe von Caches werden gelöscht.

Nun öffnen Safari> Preferences> Autofillund ausschalten User names and passwords. Wählen Sie nun Passwordsalle dort aufgeführten Passwörter aus und entfernen Sie sie. Wählen Sie Privacyund klicken Sie auf Remove All Website Data. Wählen Sie Extensionsund wenn Sie Erweiterungen installiert haben, wechseln Sie zu Off.

Probieren Sie jetzt Ihre Website aus. Sobald Sie den Versuch unternommen haben, überprüfen Sie Privacy, ob noch Cookies vorhanden sind und Passwordsob Safari Ihr Passwort gespeichert hat.

Dies könnte Sie einer Lösung näher bringen. Sagen Sie uns, wie es danach geht. Wenn Chrome funktioniert, würde ich gerne genau wissen, was es funktioniert. Könnte ein bisschen mehr Schnüffeln erforderlich sein?

Nur zum Kichern versuchen Sie die URL http://username:[email protected]/(ersetzen Sie Bits offensichtlich) und sehen Sie, was passiert.

Tony Williams
quelle
Es gab keine Passwörter oder Cookies für die intranet.companyname.comSite, aber ich habe sie trotzdem alle gelöscht, und wie erwartet bekomme ich genau das gleiche Verhalten. Zu beachten ist, dass , was ich soll bekomme der Browser-HTTP - Authentifizierung ist modal, also wenn es überall sein würde, es in Schlüsselbund, nicht in Cookies sein würde.
75. Posaune
1
Fügte ein bisschen mehr hinzu, als es zu mir kam.
Tony Williams
1
Wenn ich dieses URL-Format versuche, passiert nichts Nützliches.
75. Posaune
1
Probieren Sie es https://auch aus.
Tony Williams
0

Ich hatte auch ein ähnliches Problem in meinem Büro. Der Schlüssel bestand darin, sicherzustellen, dass meine DNS-Suche die lokalen (Unternehmens- / Intranet-) Websites von der Suche nach einer DNS-Adresse ausschloss. Das war der Grund dafür, dass mein System zum Proxy gehen und den konstanten Anmeldebildschirm erhalten wollte. Was geschah, war, dass meine Anfrage nach der URL von intranet.company.com vom Proxyserver entgegengenommen und an das Web gesendet wurde. Der Hauptwebserver würde sehen, dass ich eine Verbindung über eine Firmen-IP herstellte und nach Anmeldeinformationen suchte, die vom Proxy entfernt wurden ... Ich denke.

Grundsätzlich konnte ich mein Problem beheben, indem ich sicherstellte, dass die Intranetsite nicht an einen Proxy gesendet wurde. Das plus macht Chrome zu meinem Standardbrowser ...

Bradford Benn
quelle
0

Verwenden Sie das Ticket Viewer.app , /System/Library/CoreServices/Ticket Viewer.appund fügen Sie ein neues Ticket.

Verwenden Sie im neuen Ticket den Benutzernamen und das Kennwort für die Authentifizierung der Intranet-URL.

serbanc
quelle
1
Wie oben angegeben, wird mir bei jedem Versuch, ein neues Ticket in dieser App hinzuzufügen, mitgeteilt, dass ich eine falsche Kombination aus Benutzername und Passwort habe. Ich habe beide lheidbrederund msgd\lheidbrederals meinen Benutzernamen versucht ; kein Glück.
75. Posaune
Das hat bei mir tatsächlich funktioniert. Ich musste eine Identität für die Domain hinzufügen, in der sich mein Intranet befand, also zum Beispiel 'domainusername @ workdomain' mit meinem Domain-Passwort.
Tjeerdhans
0
  1. Erstellen Sie einen neuen Benutzer auf dem Mac.
  2. Wechseln Sie zu diesem neuen Benutzer. Sie können dies tun, während Sie Ihre aktuelle Sitzung offen halten.
  3. Starten Sie Safari. Dies ist eine jungfräuliche Safari.
  4. Versuchen Sie, eine Verbindung zur Site herzustellen. Normalerweise erhalten Sie den Authentifizierungsdialog.
Nicolas Barbulesco
quelle
0

Dies kann hilfreich sein oder auch nicht, aber ich habe festgestellt, dass ich das Authentifizierungsfenster in Safari 7.0.3 unter OS 10.9.2 verliere, wenn ich eine Verbindung zu einer anderen SMB-Freigabe als mir selbst herstelle

Ich selbst wie in meinem Active Directory Login und Passwort. Ich bin an einen Active Directory-Server gebunden.

Ich habe dies nicht auf einem nicht gebundenen Computer getestet. Ich habe auch Chrome und FireFox getestet und diese Apps haben kein Problem damit. Aurora funktioniert so oder so nicht mehr.

Von einem anderen Benutzer bearbeiten:

Dies scheint die Ursache des Problems zu sein. Dies wurde jetzt mit einem nicht gebundenen Computer getestet, auf dem Mavericks und Yosemite ausgeführt werden. Nachdem ich eine Verbindung zu SMB-Freigaben hergestellt habe, wird in Safari der Authentifizierungsdialog nicht mehr angezeigt. In Mavericks wird der Dialog angezeigt, sobald ich mich von den SMB-Freigaben trenne, und ich kann mich bei der Sharepoint 2013-Intranetsite meines Unternehmens anmelden. Ich habe kein Problem mit Sharepoint 2007 oder anderen Intranetseiten.

In Yosemite kann ich anscheinend eine Verbindung zu maximal zwei SMB-Freigaben herstellen, und Safari funktioniert weiterhin. Wenn ich mit drei oder mehr SMB-Freigaben verbunden bin, tritt das Problem auf. Ich bin mir noch nicht sicher, ob es die Anzahl der Aktien ist oder ob die verschiedenen Aktien unterschiedliche Berechtigungen haben, die die Situation beeinflussen könnten. Ich muss an dieser Front einige strengere Tests durchführen.

Christopher Lee
quelle