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

Дивіться ОНОВЛЕННЯ нижче, щоб отримати нову інформацію про фактичні HTTP-запити, що відбуваються під кришкою.

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

У Chrome на Mavericks, коли я заходжу туди, я отримую очікуване невелике спадання HTTP auth:

де я можу ввести своє ім’я користувача та пароль. Я не дуже швидко користуюся Active Directory, але, мабуть, msgdце домен Active Directory, на якому я ввімкнувся, тому я ввожу msgd\lheidbrederі свій пароль, і я можу успішно входити в Chrome.

Ще в жовтні, коли я вперше спробував це в Safari, я отримав деяку дивну поведінку; мов, я бачив річ із паролем, але потім це не спрацювало, коли я ввів свої облікові дані. Я не пам'ятаю точно, що це робило.

Але після цієї першої спроби, і після кожної спроби з того часу, коли я намагаюся перейти intranet.companyname.com, Safari показує порожній екран:

Екран не змінюється, і панель прогресу заповнюється приблизно на 20% і залишається там.

ОНОВЛЕННЯ

Я запустив додаток, щоб перевірити HTTP-запити, і я з’ясував, що це робиться за кадром. Це не просто сидіти там; Сафарі насправді запитує сторінку майже 1000 разів на секунду , і кожного разу вона отримує помилку 401 та помилку HTML із заголовком "Ви не маєте права переглядати цю сторінку".

На одному прикладі запиту із середини спроби завантаження Safari надсилає цей Authorizationзаголовок:

Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA=

І сервер відповідає цим WWW-Authenticateзаголовком:

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

На наступний запит Safari надсилає ідентичний Authorizationзаголовок, а потім сервер відповідає з дещо іншим WWW-Authenticateзаголовком:

Negotiate oYIBIzCCAR+gAwoBAaEMBgorBgEEAYI3AgIKooIBCASCAQROVExNU1NQAAIAAAAOAA4AOAAAAAUCiWLa6vytPOG0owAAAAAAAAAAvgC+AEYAAAAFAs4OAAAAD0EAUgBJAFMAVwBFAEIAAgAOAEEAUgBJAFMAVwBFAEIAAQAMAE4ARQBXAFcARQBCAAQAKgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAADADgATgBFAFcAVwBFAEIALgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAAFACoAYQByAGkAcwB3AGUAYgAuAGEAcgBpAHMAdABvAHQAbABlAC4AbgBlAHQAAAAAAA==

Повторіть ad infinitum.

Я спробував видалити все, що відповідає 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=

І звідти петля піде.

Але якщо аутентифікація переговорів не включена на сервері, буде лише один заголовок WWW-Authenticate:

WWW-Authenticate: NTLM

А відповідь Сафарі буде приблизно такою:

Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=

Це буде добре працювати. По суті, здається, що переговори порушені в Safari, і оскільки сервер спочатку надсилає переговори, вказуючи на його перевагу, Safari спробує це і введе нескінченний цикл, який не дозволяє йому повернутися до NTLM.

Отже, якщо адміністратора сервера можна переконати вимкнути переговори в налаштуваннях аутентифікації, проблема може бути вирішена.

Я можу додати, що Firefox надсилає заголовок "Авторизація: NTLM ..." незалежно від того, надає сервер переговори додатково до NTLM чи ні. Імовірно, переговори не реалізовані у Firefox.

Оновлення

У Safari 7.0.3 (9537.75.14) все ще виникає така ж проблема.

Раніше ми повідомляли про проблему як помилку на bugreport.apple.com, але помилка була закрита як дублікат попередньої помилки - вміст якої ми не можемо побачити, за винятком того, що вона все ще позначена як відкрита.

Оновлення 2

Я можу підтвердити висновок Хауна, що автентифікація працює з Safari 7.0.4 (9537.76.4).

Оновлення 3

Це питання знову в Safari 7.0.5 (9537.77.4)

Оновлення 4

Ця проблема все ще присутня в Safari 7.0.6 (9537.78.2), як зазначають хауни, з встановленими цифами або обсягами 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

У нас те саме питання. Таким чином, чому ми ще не оновили наші Macs до Mavericks. Схоже, намагаються увійти в Інтранет без облікових даних домену (Інтранет \ 'порожній'). Він повинен використовувати домен \ ім'я користувача. Я можу зрозуміти, що це може бути неприємно, але, схоже, аутентифікація відсутня в сафарі.

Я всього через кілька секунд це підірве колоди.

Firefox, здається, працює чудово, хоча.

Це може бути дальнім ударом, але якщо у вас є квиток на Kerberos (від входу в іншу службу), Safari, можливо, намагатиметься ним скористатися.

Відкрийте / Система / Бібліотека / CoreServices / Ticker 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перегляньте, чи залишилося печиво, і 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, проблема виявляється. Я ще не впевнений, чи саме кількість акцій або, можливо, різні акції мають різні дозволи, які можуть вплинути на ситуацію. Мені потрібно провести ще жорсткі випробування на тому фронті.