Как хранить учетные данные прокси в 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 , скопировав записи аутентификации из цепочки для ключей входа в системную цепочку для ключей, а затем перезагрузившись, но это не помогло. На самом деле, страшное окно «Proxy Authentication Required» снова появилось при наборе этого ...

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

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

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

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

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

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

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

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

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

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

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

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

• Клиент отправляет имя пользователя на сервер (в виде открытого текста).
• Сервер генерирует 16-байтовое случайное число, называемое запросом или одноразовым номером, и отправляет его клиенту.
• Клиент шифрует эту задачу с помощью хэша пароля пользователя и возвращает результат на сервер. Это называется ответом.

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

  • Имя пользователя
  • Задача отправлена ​​клиенту
  • Ответ получен от клиента

• DC проверяет зашифрованный запрос и ответ. Если аутентифицировано, доступ предоставляется.

Третий шаг выше требует от клиента хэширования случайного числа, полученного с сервера. По сути, это означает, что на вашем MacOS-клиенте нечего хранить.

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

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

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

^{(Акцент мой)}

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

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

путем изменения настроек приложения

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

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

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