Safari 7 не может подключиться к интрасети с использованием HTTP-аутентификации

Посмотрите ОБНОВЛЕНИЕ ниже для новой информации о фактических запросах HTTP, происходящих под капотом.

Поэтому я начал новую работу еще в октябре. В основном это магазин Windows, и они используют IIS и Active Directory для множества внутренних вещей. У них есть интранет-сайт по адресу intranet.companyname.com.

В Chrome на Mavericks, когда я иду туда, я получаю ожидаемое небольшое выпадающее меню HTTP-аутентификации:

где я могу ввести свое имя пользователя и пароль. Я не очень быстр в работе с Active Directory, но, думаю, msgdэто домен Active Directory, на котором я работаю, поэтому я ввожу msgd\lheidbrederсвой пароль и могу успешно войти в Chrome.

Еще в октябре, когда я впервые попробовал это в Safari, у меня было странное поведение; Например, я видел пароль, но потом он не работал, когда я вводил свои учетные данные. Я не помню точно, что он сделал.

Но после этой первой попытки и при каждой попытке с тех пор, когда я пытаюсь перейти intranet.companyname.com, Safari показывает пустой экран:

Экран не меняется, а индикатор выполнения заполняется примерно на 20% и остается там.

ОБНОВИТЬ

Я запустил приложение для отслеживания HTTP-запросов и выяснил, что это делает за кулисами. Это не просто сидеть там; Safari запрашивает страницу почти 1000 раз в секунду и каждый раз получает ошибку 401 и страницу ошибки HTML с заголовком «Вы не авторизованы для просмотра этой страницы».

В одном примере запроса от середины попытки загрузки Safari отправляет этот Authorizationзаголовок:

Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA=

И сервер отвечает этим WWW-Authenticateзаголовком:

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

При следующем запросе Safari отправляет идентичный Authorizationзаголовок, а затем сервер отвечает очень немного другим WWW-Authenticateзаголовком:

Negotiate oYIBIzCCAR+gAwoBAaEMBgorBgEEAYI3AgIKooIBCASCAQROVExNU1NQAAIAAAAOAA4AOAAAAAUCiWLa6vytPOG0owAAAAAAAAAAvgC+AEYAAAAFAs4OAAAAD0EAUgBJAFMAVwBFAEIAAgAOAEEAUgBJAFMAVwBFAEIAAQAMAE4ARQBXAFcARQBCAAQAKgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAADADgATgBFAFcAVwBFAEIALgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAAFACoAYQByAGkAcwB3AGUAYgAuAGEAcgBpAHMAdABvAHQAbABlAC4AbgBlAHQAAAAAAA==

Повторите до бесконечности.

Я попытался удалить все, что соответствует intranetв Keychain Access и очистить весь кэш / куки, чтобы посмотреть, смогу ли я восстановить оригинальное странное поведение, но это не сработало.

У меня есть какие-то интересные вещи в домене? Что еще я могу попытаться диагностировать это?

Я могу подтвердить, что вижу ту же проблему с Safari 7.0.2 (9537.74.9) со всеми установленными обновлениями Mac OS X Mavericks. (Тысячи пакетов запросов в секунду с тем же типом контента, как описано выше.)

Однако, хотя это может или не может помочь оригинальному постеру, я обнаружил, что эта проблема возникает, только если на сервере Windows включена встроенная проверка подлинности Windows (также известная как проверка подлинности NTLM) и согласованная проверка подлинности.

Затем сервер отправляет эти два заголовка:

WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM

Safari ответит:

Authorization: Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA=

И оттуда, цикл будет идти.

Но если на сервере не включена Negotiate Authentication, будет только один заголовок WWW-Authenticate:

WWW-Authenticate: NTLM

И ответ Safari будет примерно таким:

Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=

Это будет работать просто отлично. По сути, кажется, что Negotiate не работает в Safari, и, так как сервер сначала отправляет Negotiate, указывая предпочтение для него, Safari попытается выполнить его и войдет в бесконечный цикл, который не позволяет ему вернуться к NTLM.

Таким образом, если администратора сервера можно убедить отключить согласование в настройках аутентификации, проблема может быть решена.

Я мог бы добавить, что Firefox отправляет заголовок «Authorization: NTLM ...» независимо от того, предоставляет ли сервер Negotiate в дополнение к NTLM или нет. Предположительно, Negotiate не реализован в Firefox.

Обновить

Safari 7.0.3 (9537.75.14) по-прежнему демонстрирует ту же проблему.

Ранее мы сообщали о проблеме как об ошибке на bugreport.apple.com, но эта ошибка была закрыта как дубликат предыдущей ошибки, содержимое которой мы не видим, за исключением того, что она все еще помечена как открытая.

Обновление 2

Я могу подтвердить вывод hauns о том, что аутентификация работает с Safari 7.0.4 (9537.76.4).

Обновление 3

Эта проблема вернулась в Safari 7.0.5 (9537.77.4)

Обновление 4

Эта проблема все еще присутствует в Safari 7.0.6 (9537.78.2), как отмечает hauns, с подключенными томами cifs или smb.

Safari 7.0.5 по-прежнему имеет проблему: аутентификация не работает, если искатель совместно использует сетевые ресурсы через SMB: (или CIFS :). как только все подключенные сетевые тома отключены, Safari возобновляет правильную аутентификацию.

Регресс:

1. присутствует в Yosemite 10.10.1 / Safari 8.0.2
2. присутствует в El Capitan 10.11.2 / Safari 9.0.2
3. присутствует в Safari 10.0.1

Соответствующая ошибка Apple 22990203 по-прежнему активна. Ни одному смертному не разрешено его видеть (cf.bugreporter.apple.com)

Смотрите также: https://discussions.apple.com/message/27727310#27727310

У нас та же проблема. Вот почему мы еще не обновили наши Mac до Mavericks. Похоже, что он пытается войти в интрасеть без учетных данных домена («пустая» интрасеть). Следует использовать домен \ имя пользователя. Я могу понять, что это может расстраивать, но кажется, что аутентификация отсутствует в сафари.

У меня всего несколько секунд он сдувает бревна.

Firefox, похоже, отлично работает.

Это может быть далеко, но если у вас есть билет Kerberos (от входа в другой сервис), Safari может попытаться использовать это.

Откройте / System / Library / CoreServices / Ticket Viewer.app, чтобы увидеть, есть ли у вас билеты Kerberos. Если это так, щелкните билет, удалите личность и повторите попытку.

В качестве альтернативы, если ничего не указано в списке, попробуйте использовать «Добавить идентификатор» и посмотреть, работает ли это с Safari.

Я не думаю, что Firefox и Chrome не используют Kerberos, поэтому они будут запрашивать учетные данные отдельно.

Брелки были хорошей идеей, но вы не достаточно далеко зашли.

В Safari, если вы заглянете в Safariменю, вы увидите « Reset Safari...Выбрать это», и несколько кешей будут очищены.

Теперь откройте Safari> Preferences> Autofillи выключить User names and passwords. Теперь выберите Passwordsи удалите все пароли, перечисленные там. Выберите Privacyи нажмите Remove All Website Data. Выберите Extensionsи, если у вас установлены какие-либо расширения, переключите расширения на Off.

Теперь иди и попробуй свой сайт. После того, как вы сделали попытку, посмотрите Privacy, не осталось ли файлов cookie, и Passwordsпосмотрите, сохранил ли Safari ваш пароль.

Это может приблизить вас к решению. Расскажите нам, как это происходит после этого. Если Chrome работает, я бы хотел точно знать, что он делает, что работает. Может ли потребоваться немного больше слежки?

Просто для смеха попробуйте URL http://username:password@intranet.example.com/(очевидно, заменив биты) и посмотрите, что произойдет.

У меня была похожая проблема в моем офисе. Ключ был в том, чтобы убедиться, что мой DNS-поиск исключил локальные (компания / интранет) сайты для поиска DNS-адреса. Это было причиной того, что моя система захотела выйти на прокси и получить экран постоянного входа в систему. Происходило то, что мой запрос на URL-адрес intranet.company.com был получен прокси-сервером и отправлен в Интернет. Основной веб-сервер видел, что я подключался через IP-адрес компании, и отвечал в поисках учетных данных, которые были удалены прокси-сервером ... Я думаю.

По сути, решение моей проблемы решило, что сайт интрасети не был отправлен прокси. Это плюс просто сделать Chrome моим браузером по умолчанию ...

Используйте Viewer.app билетов , /System/Library/CoreServices/Ticket Viewer.appи добавить новый билет.

В новом тикете используйте имя пользователя и пароль для аутентификации в интрасети.

1. Создайте нового пользователя на Mac.
2. Переключиться на этого нового пользователя. Вы можете сделать это, оставив текущий сеанс открытым.
3. Запустите Safari. Это девственное сафари.
4. Попробуйте подключиться к сайту. Обычно вы получите диалог аутентификации.

Это может помочь, а может и не помочь, но я обнаружил, что, если я подключаюсь к общему ресурсу smb, я теряю окно аутентификации в Safari 7.0.3 под управлением ОС 10.9.2

Сам как в моей активной директории логин и пароль. Я связан с активным сервером каталогов.

Я не проверял это на не связанной машине. Я также протестировал Chrome и FireFox, и у этих приложений нет проблем с ними. Аврора больше не работает в любом случае.

Редактировать другим пользователем:

Похоже, это является причиной проблемы. Теперь это было протестировано на машине без ограничений, на которой запущены Mavericks и Yosemite. После подключения к общим ресурсам SMB Safari больше не будет отображать диалоговое окно аутентификации. В Mavericks, как только я отключаюсь от общих ресурсов SMB, появляется диалоговое окно, и я могу войти на интранет-сайт моей компании Sharepoint 2013. У меня нет проблем на Sharepoint 2007 или других интранет-сайтах.

В Yosemite кажется, что я могу подключиться максимум к двум общим ресурсам SMB, и Safari все равно будет работать. Если я подключен к трем или более SMB-ресурсам, проблема проявляется. Я еще не уверен, если это количество акций или, возможно, разные акции имеют разные разрешения, которые могут повлиять на ситуацию. Мне нужно провести более тщательное тестирование на этом фронте.