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

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:

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:

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?

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.

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

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.

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.

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:password@intranet.example.com/(ersetzen Sie Bits offensichtlich) und sehen Sie, was passiert.

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 ...

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.

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.

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.