Как сохранить учетные данные прокси-сервера в macOS, чтобы они использовались системными службами?

Я использую macOS Sierra 10.12.6 за корпоративным прокси-сервером NTLM. Мой браузер и другие приложения используют системные настройки прокси, в которых я сохранил свое имя пользователя и пароль для аутентификации с помощью прокси. Это работает нормально.

Существует постоянная проблема с системными службами, которые пытаются получить доступ к информации в Интернете и не видят доступа к учетным данным прокси-сервера в моей учетной записи пользователя. Я вижу следующее всплывающее окно каждые пару минут, и что бы я ни делал (обновлял свои учетные данные в Системных настройках или нажимал «Не сейчас»), всплывающее окно продолжает появляться снова и снова:

Требуется прокси-аутентификация

Текст во всплывающем окне гласит:

Требуется прокси-аутентификация

Введите пароль для HTTP-прокси http://xxx.xxx.xxx.xxx:yyyy в Системных настройках.

Что я могу сделать, чтобы это всплывающее окно не появлялось?

Вещи, которые я пробовал до сих пор:

  • Обновлены мои учетные данные в Системных настройках ( Сеть > Дополнительно > Прокси )
  • Скопировал записи учетных данных из моей цепочки для ключей входа в цепочку для ключей системы , так как я прочитал рекомендацию по этому поводу в сообщении в блоге или вопросе на форуме.

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

Обновление 1:

Как только я ввожу свои учетные данные, нажав кнопку « Системные настройки» в приведенном выше диалоговом окне (которую я могу активировать, например, открыв Safari и начав вводить URL-адрес в поле местоположения), в цепочке ключей входа создаются две записи, обе с идентичными содержание:

@ xxx.xxx.xxx.xxx (имя пользователя) Интернет Пароль Сегодня, 09:10 -- логин

Обе записи выглядят одинаково, с одинаковым именем и атрибутами. Оба показывают, что приложение, запросившее это AuthBrokerAgent:

Контроль доступа к связке ключей

Обновление 2:

Я также пробовал это предложение: https://discussions.apple.com/message/23848961#message23848961 , скопировав записи аутентификации из цепочки для ключей входа в системную цепочку для ключей, а затем перезагрузив компьютер, но это не помогло. На самом деле, ужасное окно «Требуется аутентификация прокси» снова появилось при вводе этого...

Обновление 3:

Я использовал Wireshark, чтобы посмотреть на трафик между моей машиной и нашим прокси:

  • Прокси возвращает с 407 Proxy Authentication Requiredи Proxy-Authenticate: NTLM, что соответствует моим ожиданиям, так как наш прокси использует NTLM.
  • Некоторые примеры, которые я видел в трафике (например, iCloud), затем возвращают NTLMSSP_NEGOTIATEответ.
  • Прокси возвращается с NTLMSSP_CHALLENGEзапросом
  • Служба отвечает NTLMSSP_AUTHмоим именем пользователя, которое должно быть откуда-то получено.
  • Наконец, прокси отвечает200 Connection established

Для меня это показывает, что в целом прокси-аутентификация работает нормально, если система может откуда-то получить имя пользователя и прокси. Остается вопрос, как/где хранить логин/пароль, чтобы все системные службы могли его найти. Некоторые системные службы (я полагаю) не имеют средств для поиска учетных данных прокси-сервера, где я их сейчас храню.

Связанный вопрос: apple.stackexchange.com/questions/117556/…
Какой прокси вы используете? Я помню (из другой прошлой жизни), что прокси-сервер, который мы использовали, имел возможность запрещать сохранение паролей, тем самым вынуждая пользователя аутентифицироваться каждый раз. Это может быть так.
Вы когда-нибудь решали эту проблему, потому что я иногда сталкиваюсь с той же проблемой и подключаюсь к решению Citrix VPN. Как только появляется всплывающее окно, оно повторяется снова и снова, и в конце концов моя учетная запись AD будет заблокирована. Мне еще предстоит найти решение, которое решает эту проблему. Поскольку я использую MacBook Pro, а большая часть ИТ-отдела работает на базе Windows, мне не удалось получить какую-либо полезную информацию от ИТ-отдела. Как только я подключаюсь к VPN, я работаю над приложениями Oracle, работающими на серверах Solaris SPARC. Я очень надеюсь, что вы найдете способ решить эту проблему. Стэн
Извините, пока не нашел решения для этого. В итоге я перемещаю окно, которое запрашивает учетные данные прокси-сервера, в сторону экрана, не нажимая ни одной из кнопок - это, по крайней мере, делает его тихим...
В моем случае также появляются два почти одинаковых элемента в цепочке ключей входа, но есть одно небольшое отличие - один из них для протокола HTTP, а второй для HTTPS.

Ответы (3)

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

На странице Microsoft « Обработка аутентификации » в разделе « О HTTP-аутентификации »:

Существует два основных типа схем аутентификации:

  • Базовая схема аутентификации, при которой имя пользователя и пароль отправляются на сервер в открытом виде.
  • Схемы «вызов-ответ», которые допускают формат «вызов-ответ».

Схемы запрос-ответ обеспечивают более безопасную аутентификацию. Если запрос требует аутентификации с использованием схемы запрос-ответ, клиенту возвращается соответствующий код состояния и заголовки Authenticate. Затем клиент должен повторно отправить запрос с согласованием. Сервер вернет соответствующий код состояния с вызовом, а затем клиенту потребуется повторно отправить запрос с правильным ответом, чтобы получить запрошенную услугу.

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

Процесс аутентификации NTLM

Это гораздо больше, чем просто хранение учетных данных. Клиент должен сгенерировать ответ на основе сгенерированного запроса от сервера. Ниже приведено очень сокращенное описание процесса аутентификации с точки зрения клиент/сервер в соответствии с документацией Microsoft.

  • Клиент отправляет имя пользователя на сервер (в открытом виде).

  • Сервер генерирует 16-байтовое случайное число, называемое вызовом или одноразовым номером, и отправляет его клиенту.

  • Клиент шифрует этот вызов хэшем пароля пользователя и возвращает результат на сервер. Это называется реакцией.

  • Сервер отправляет контроллеру домена следующие три элемента:

    • Имя пользователя
    • Вызов отправлен клиенту
    • Получен ответ от клиента

  • Контроллер домена проверяет зашифрованные запрос и ответ. В случае аутентификации доступ предоставляется.

Третий шаг выше требует , чтобы клиент хешировал случайное число, полученное от сервера. Это по своей сути означает, что на вашем клиенте macOS нечего хранить.

Как минимум, вы должны быть присоединены к домену Active Directory. Это означает, что вам необходимо включить и правильно настроить поддержку Kerberos для вашей конкретной организации.

В документе «Обработка аутентификации», на который я ссылался выше, есть ключевая фраза:

Если требуется аутентификация, при вызове HttpOpenRequest следует использовать флаг INTERNET_FLAG_KEEP_CONNECTION. Флаг INTERNET_FLAG_KEEP_CONNECTION требуется для NTLM и других типов аутентификации, чтобы поддерживать соединение во время завершения процесса аутентификации. Если соединение не поддерживается, процесс аутентификации необходимо перезапустить с помощью прокси или сервера.

(выделено мной)

Судя по представленным симптомам, вашей организации требуется аутентификация на прокси-сервере; ваше имя пользователя/пароль действительны, но он продолжает (повторно) запрашивать аутентификацию. Вероятно, это связано с тем, что вы теряете состояние подключения и вынуждены делать это снова и снова. Что еще больше подчеркивает суть....

Чтобы решить эту проблему, вам нужно будет связаться с вашим сетевым администратором, чтобы помочь вам с проблемами аутентификации.

Как узнать, какая схема аутентификации используется? Есть ли HTTP-заголовок, на который я мог бы посмотреть, когда приложение взаимодействует с прокси-сервером? Могу ли я сделать это в сетевой консоли Chrome или мне нужно использовать что-то вроде Wireshark?
Скорее всего, вам нужно будет использовать Wireshark. Имейте в виду, это также может быть зашифрованный трафик.
Я добавил к вопросу некоторую информацию из того, что я видел в Wireshark.
Спасибо за добавление дополнительной информации о NTLM к вашему ответу. Я понимаю NTLM, и, судя по выходным данным Wireshark, он работает — задача/ответ, которые вы описываете, выполняются, например, для служб Dropbox или iCloud. Я до сих пор не уверен, какая служба выводит повторяющиеся диалоги учетных данных прокси-сервера. Ваш ответ содержит много информации, но пока мне не очень помогает.
Connection Established!= Access Granted. Люди, которые могут подтвердить , что это работает, являются вашими системными/сетевыми администраторами в вашем ИТ-отделе.

Примечание. Установите переключатель, чтобы разрешить всем приложениям использовать прокси.

путем аутентификации приложения цепочки для ключей изменить настройку

У меня это работает какое-то время (несколько минут), а затем этот параметр автоматически переключается обратно на «Подтвердить, прежде чем разрешить доступ», и приложения снова начинают показывать всплывающие окна. У меня есть подозрение, что элемент удаляется и создается заново с некоторыми параметрами по умолчанию. Не уверен, какое приложение делает это и почему.

Запустите следующую команду из Console.app:

networksetup -setwebproxy "Your Interface Name" "web proxy hostname or IP" 
8080 on username password

Вас спросят о доступе к связке ключей. Согласитесь добавить запись в связку ключей и у вас будет доступ без пароля все время, пока ваша связка ключей открыта.

Я пробовал это, но это не решает проблему. Команда устанавливает конфигурацию прокси для моего пользователя и сохраняет аутентификацию в loginцепочке ключей моего пользователя. Сразу после того, как я это сделал, диалоговое окно аутентификации прокси-сервера, показанное выше, снова появилось. Предлагаемое вами исправление не решает проблему для меня.
потому что ваша цепочка ключей для входа заблокирована или у вас есть двойные записи
Брелок для входа в систему разблокирован, я перепроверил это. Однако точка зрения о двойных записях может быть справедливой. Я удалил все записи для аутентификации прокси, которые я нашел в цепочках ключей входа и системы, но как только я ввожу свой пароль один раз в диалоговом окне в моем исходном сообщении, я получаю две записи в цепочке ключей входа, обе с точно те же данные. Если я удалю один, он вернется, когда я снова ввожу свои учетные данные.
У вас установлен wireshark? Не могли бы вы сбросить все переговоры между вашим osx и прокси-сервером и записи цепочки для ключей (безопасность find-generic-password -g -s your_proxy_definition)? У меня есть сильное ощущение, что аутентификация прокси-сервера происходит по https, а не по http. Вы пытались определить URL-адрес прокси-сервера как https?
Пробовал securityуказанную вами команду - ничего не находит. Это произойдет, если я изменю find-generic-passwordкоманду на find-internet-password, поскольку в связке ключей запись указана как «Интернет-пароль».
URL-адрес прокси настроен как xxx.xxx.xxx.xxx , так он работает, например, из командной строки. Я попытаюсь захватить что-нибудь с помощью Wireshark.
Я добавил к вопросу некоторую информацию из того, что я видел в Wireshark.
Похоже, это была аналогичная ошибка в 10.10.
Похоже, это была похожая ошибка в 10.10 support.apple.com/kb/DL1785?locale=en_US . Итак, вы пробовали использовать настройки прокси-сервера Firefox, поведение другое? (можно использовать общесистемный прокси и вручную ввести там настройки прокси
Пробовал Firefox, без изменений...
Оба варианта, общесистемный прокси в Firefox и внутренние настройки Firefox для http-прокси?
Да, оба - ни один не работал.
Как сохранить учетные данные прокси-сервера в macOS, чтобы они использовались системными службами?
СпросиСетьПолитика конфиденциальности1y, 1v