Чому один запит через проксі вимагає пароль, а для інших Kerberos працює
Знайдіть правило політики, яке призначає одному запиту неочікувану область автентифікації проксі, навіть коли інші запити успішно використовують Kerberos.
Кілька запитів успішно використовують Kerberos через корпоративний проксі. Один запит спричиняє запит пароля. Перш ніж замінювати keytab, перевірте, яку політику автентифікації вибрав саме цей запит.
Шлюз може вибирати область і підтримувані схеми через політику. Дві транзакції, що надходять на той самий проксі з того самого браузера, не зобов'язані отримувати однакові вимоги автентифікації.
Розгляньте цей гіпотетичний слід:
| Транзакція | Перше відповідне правило | Доступна автентифікація |
|---|---|---|
| Основний документ | Кероване правило перегляду | Negotiate |
| Скрипт з іншого хоста | Раніший виняток призначення | Basic або NTLM |
Перший успішний обмін показує, що один вибраний шлях працює. Він не показує, що друга транзакція потрапила на цей шлях. Облікові дані можуть бути дійсними, а правило, яке вибирає механізм автентифікації, — хибним.
Перевірте вибране правило та його порядок
Зіставте призначення та час запиту, що отримав виклик, зі слідом політики шлюзу. Визначте область, вибір схем і режим автентифікації, які створює перше застосовне правило. Порівняйте ці значення з успішним запитом того самого клієнта.
Політика на основі ідентичності, пов'язаної з IP, також може поводитися інакше, ніж політика, що вимагає автентифікації на з'єднанні. Не вважайте, що відсутність нового рукостискання означає вибір тієї самої області.
Якщо ресурс потрапив у непередбачений виняток, виправте це правило або його межі та перегляньте отриманий слід. Розширення дозволених методів автентифікації всюди може приховати невідповідність, але змінює поведінку доступу для незв'язаного трафіку.
Якщо вибрано потрібну область, а очікуваний обмін не вдається, переходьте до доказів облікового запису й Kerberos. Саме тоді стають важливими квиток, назва служби або діагностика бекенду.