Несколько запросов успешно используют Kerberos через корпоративный прокси. Один запрос вызывает запрос пароля. Прежде чем заменять keytab, проверьте, какую политику аутентификации выбрал именно этот запрос.

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

Рассмотрите этот гипотетический след:

ТранзакцияПервое подходящее правилоДоступная аутентификация
Основной документУправляемое правило просмотраNegotiate
Скрипт с другого хостаБолее раннее исключение назначенияBasic или NTLM

Первый успешный обмен показывает, что один выбранный путь работает. Он не показывает, что вторая транзакция попала на этот путь. Учётные данные могут быть действительными, а правило, выбирающее механизм аутентификации, — ошибочным.

Проверьте выбранное правило и его порядок

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

Политика на основе идентичности, связанной с IP, тоже может вести себя иначе, чем политика, требующая аутентификации на соединении. Не считайте, что отсутствие нового рукопожатия означает выбор той же области.

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

Если выбрана нужная область, а ожидаемый обмен не удаётся, переходите к свидетельствам учётной записи и Kerberos. Именно тогда становятся важны билет, имя службы или диагностика бэкенда.

Похожие статьи