Safari 7 nie może połączyć się z intranetem przy użyciu uwierzytelniania HTTP

Zobacz UPDATE poniżej, aby uzyskać nowe informacje na temat rzeczywistych żądań HTTP realizowanych pod maską.

Więc zacząłem nową pracę w październiku. Jest to głównie sklep z systemem Windows i używają IIS i Active Directory do wielu wewnętrznych czynności. Mają witrynę intranetową pod adresem intranet.companyname.com.

W Chrome na Mavericks, kiedy tam wchodzę, pojawia się oczekiwane małe menu uwierzytelniania HTTP:

gdzie mogę wpisać swoją nazwę użytkownika i hasło. Nie jestem bardzo szybki z Active Directory, ale myślę, że msgdjest to domena Active Directory, w której jestem, więc piszę msgd\lheidbrederi moje hasło i mogę się pomyślnie zalogować w Chrome.

W październiku, kiedy po raz pierwszy spróbowałem tego w Safari, dostałem dziwne zachowanie; na przykład widziałem hasło, ale potem nie zadziałało, kiedy podałem swoje dane uwierzytelniające. Nie pamiętam dokładnie, co to zrobiło.

Ale po pierwszej próbie i przy każdej kolejnej próbie przejścia do intranet.companyname.comSafari pokazuje pusty ekran:

Ekran się nie zmienia, a pasek postępu zapełnia się o około 20% i pozostaje tam.

AKTUALIZACJA

Uruchomiłem aplikację, aby snoopować żądania HTTP i dowiedziałem się, co robił za kulisami. Nie tylko tam siedzi; Safari faktycznie żąda strony prawie 1000 razy na sekundę i za każdym razem pojawia się błąd 401 oraz strona błędu HTML z tytułem „Nie masz uprawnień do przeglądania tej strony”.

Na jedno przykładowe żądanie z połowy próby załadowania Safari wysyła ten Authorizationnagłówek:

Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA=

A serwer odpowiada tym WWW-Authenticatenagłówkiem:

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

Na następne żądanie Safari wysyła identyczny Authorizationnagłówek, a następnie serwer odpowiada bardzo nieznacznie innym WWW-Authenticatenagłówkiem:

Negotiate oYIBIzCCAR+gAwoBAaEMBgorBgEEAYI3AgIKooIBCASCAQROVExNU1NQAAIAAAAOAA4AOAAAAAUCiWLa6vytPOG0owAAAAAAAAAAvgC+AEYAAAAFAs4OAAAAD0EAUgBJAFMAVwBFAEIAAgAOAEEAUgBJAFMAVwBFAEIAAQAMAE4ARQBXAFcARQBCAAQAKgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAADADgATgBFAFcAVwBFAEIALgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAAFACoAYQByAGkAcwB3AGUAYgAuAGEAcgBpAHMAdABvAHQAbABlAC4AbgBlAHQAAAAAAA==

Powtórz ad infinitum.

Próbowałem usunąć wszystko, co pasuje intranetdo pęku kluczy i wyczyścić całą pamięć podręczną / pliki cookie, aby sprawdzić, czy mogę przywrócić oryginalne dziwne zachowanie, ale to nie zadziałało.

Czy mam coś funky w domenie? Co jeszcze mogę spróbować zdiagnozować?

Mogę potwierdzić, że widzę identyczny problem z Safari 7.0.2 (9537.74.9), z zainstalowanymi wszystkimi aktualnymi aktualizacjami Mac OS X Mavericks. (Tysiące pakietów żądań na sekundę z tego samego rodzaju treścią, jak opisano powyżej.)

Jednak chociaż może to pomóc oryginalnemu plakatowi, ale nie musi, stwierdziłem, że ten problem występuje tylko wtedy, gdy serwer Windows ma zintegrowane uwierzytelnianie systemu Windows (znane również jako uwierzytelnianie NTLM) i włączone uwierzytelnianie negocjacyjne.

Serwer następnie wysyła te dwa nagłówki:

WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM

Safari odpowie:

Authorization: Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA=

Stamtąd pętla zacznie działać.

Ale jeśli uwierzytelnianie negocjacyjne nie jest włączone na serwerze, będzie tylko jeden nagłówek uwierzytelniania WWW:

WWW-Authenticate: NTLM

A odpowiedź Safari będzie taka:

Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=

To zadziała dobrze. Zasadniczo wydaje się, że Negocjacja jest zepsuta w Safari, a ponieważ serwer najpierw wysyła Negocjację, wskazując preferencję, Safari spróbuje go i wejdzie w nieskończoną pętlę, która nie pozwoli mu wrócić do NTLM.

Jeśli więc można przekonać administratora serwera do wyłączenia Negocjuj w ustawieniach uwierzytelniania, problem może zostać rozwiązany.

Mogę dodać, że Firefox wysyła nagłówek „Autoryzacja: NTLM ...” bez względu na to, czy serwer oprócz negocjacji NTLM udostępnia Negocjacje. Przypuszczalnie Negotiate nie jest zaimplementowany w Firefoksie.

Aktualizacja

Safari 7.0.3 (9537.75.14) wciąż ma ten sam problem.

Wcześniej zgłaszaliśmy problem jako błąd na bugreport.apple.com, ale błąd został zamknięty jako duplikat poprzedniego błędu - którego zawartości nie widzimy, z wyjątkiem tego, że nadal jest oznaczony jako otwarty.

Aktualizacja 2

Mogę potwierdzić ustalenie Haunsa, że ​​uwierzytelnianie działa w przeglądarce Safari 7.0.4 (9537.76.4).

Aktualizacja 3

Ten problem powraca w przeglądarce Safari 7.0.5 (9537.77.4)

Aktualizacja 4

Ten problem jest nadal obecny w przeglądarce Safari 7.0.6 (9537.78.2), jak zauważają hauns, z zamontowanymi woluminami cifs lub smb.

W Safari 7.0.5 nadal występuje problem: uwierzytelnianie ulega awarii, jeśli wyszukiwarka współdzieli zasoby sieciowe za pośrednictwem SMB: (lub CIFS :). po odłączeniu wszystkich podłączonych woluminów sieciowych Safari wznawia prawidłowe uwierzytelnianie.

Regresja:

1. obecny w Yosemite 10.10.1 / Safari 8.0.2
2. obecny w El Capitan 10.11.2 / Safari 9.0.2
3. obecny w Safari 10.0.1

Odpowiedni błąd Apple 22990203 jest nadal aktywny. Żaden śmiertelnik nie może go zobaczyć (por. Bugreporter.apple.com)

Zobacz także: https://discussions.apple.com/message/27727310#27727310

Mamy ten sam problem. Dlatego nie zaktualizowaliśmy jeszcze naszych komputerów Mac do Mavericks. Wygląda na to, że próbuje zalogować się do intranetu bez poświadczeń domeny (intranet \ „blank”). Powinien używać domeny \ nazwa użytkownika. Rozumiem, że może to być frustrujące, ale wydaje się, że w safari brakuje uwierzytelnienia.

Zaledwie kilka sekund wysadzi kłody.

Firefox wydaje się jednak działać świetnie.

To może być długa szansa, ale jeśli masz bilet Kerberos (od zalogowania się do innej usługi), Safari może próbować go użyć.

Otwórz / System / Library / CoreServices / Ticket Viewer.app, aby sprawdzić, czy masz bilety Kerberos. Jeśli tak, kliknij bilet, Usuń tożsamość i spróbuj ponownie.

Alternatywnie, jeśli nic nie ma na liście, spróbuj użyć opcji Dodaj tożsamość i sprawdź, czy to działa z Safari.

Firefox i Chrome nie używają Kerberos, nie sądzę, dlatego właśnie pytają cię osobno o poświadczenia.

Breloki to dobry pomysł, ale nie posunąłeś się wystarczająco daleko.

W Safari, jeśli spojrzysz pod Safarimenu, zobaczysz Reset Safari...Wybierz to, a kilka pamięci podręcznych zostanie wyczyszczonych.

Teraz otwarte Safari> Preferences> Autofilli wyłącz User names and passwords. Teraz wybierz Passwordsi usuń wymienione tam hasła. Wybierz Privacyi kliknij Remove All Website Data. Wybierz Extensionsi jeśli masz jakieś rozszerzenia, przełącz rozszerzenia na Off.

Teraz idź i wypróbuj swoją stronę internetową. Po podjęciu próby Privacyzobacz, czy nie pozostały jakieś pliki cookie i Passwordsczy Safari zapisało twoje hasło.

Może to przybliżyć Cię do rozwiązania. Powiedz nam, jak to będzie potem. Jeśli Chrome działa, chciałbym wiedzieć dokładnie, co robi, że działa. Czy może być wymagane nieco więcej węszenia?

Tylko na chichot wypróbuj adres URL http://username:password@intranet.example.com/(oczywiście zastępując bity) i zobacz, co się stanie.

Miałem podobny problem również w moim biurze. Kluczem było upewnienie się, że moje wyszukiwanie DNS wykluczyło lokalne witryny (firmy / intranetu) z szukania adresu DNS. To było spowodowane tym, że mój system chciał przejść do serwera proxy i uzyskać stały ekran logowania. Działało się tak, że moja prośba o adres intranet.company.com została pobrana przez serwer proxy i wysłana do sieci. Główny serwer zobaczyłby, że łączyłem się przez firmowy adres IP i odpowiedział, szukając poświadczeń, które zostały usunięte przez proxy ... Myślę, że.

Zasadniczo upewnienie się, że strona intranetowa nie była wysyłana do serwera proxy, rozwiązało mój problem. To plus, czyniąc Chrome moją domyślną przeglądarką ...

Użyj Viewer.app biletów , /System/Library/CoreServices/Ticket Viewer.appi dodać nowy bilet.

W nowym bilecie użyj nazwy użytkownika i hasła do uwierzytelnienia adresu intranetowego.

1. Utwórz nowego użytkownika na komputerze Mac.
2. Przełącz się na tego nowego użytkownika. Możesz to zrobić, utrzymując bieżącą sesję otwartą.
3. Uruchom Safari. To jest dziewicze safari.
4. Spróbuj połączyć się z witryną. Zwykle pojawi się okno dialogowe uwierzytelniania.

To może, ale nie musi pomóc, ale okazało się, że jeśli połączę się z udziałem kogoś innego niż ja, stracę okno uwierzytelniania w przeglądarce Safari 7.0.3 z systemem OS 10.9.2

Siebie jak w moim active directory login i hasło. Jestem związany z serwerem Active Directory.

Nie testowałem tego na maszynie niezwiązanej. Przetestowałem również Chrome i FireFox i te aplikacje nie mają problemu z uschnięciem. Aurora już nie działa.

Edytuj przez innego użytkownika:

To wydaje się być przyczyną problemu. Zostało to przetestowane na niezwiązanej maszynie z systemem Mavericks, a teraz z systemem Yosemite. Po połączeniu się z udziałami SMB Safari nie będzie już wyświetlać okna dialogowego uwierzytelniania. W Mavericks, gdy tylko odłączę się od udziałów SMB, pojawia się okno dialogowe i mogę zalogować się na stronie intranetowej Sharepoint 2013 mojej firmy. Nie mam problemu z Sharepoint 2007 ani innymi stronami intranetowymi.

W Yosemite wydaje się, że mogę połączyć się z maksymalnie dwoma udziałami SMB, a Safari nadal będzie działać. Jeśli jestem podłączony do co najmniej trzech udziałów SMB, problem pojawia się. Nie jestem jeszcze pewien, czy jest to liczba akcji, czy może różne akcje mają różne uprawnienia, które mogą mieć wpływ na sytuację. Muszę przeprowadzić bardziej rygorystyczne testy na tym froncie.