Няколко заявки успешно използват Kerberos през корпоративното прокси. Една заявка предизвиква подкана за парола. Преди да смените keytab, проверете коя политика за удостоверяване е избрала точно тази заявка.

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

Разгледайте тази хипотетична следа:

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

Първият успешен обмен показва, че един избран път работи. Той не показва, че втората транзакция е достигнала този път. Удостоверение може да е валидно, докато правилото, което избира механизма му за удостоверяване, е грешно.

Прегледайте избраното правило и неговия ред

Свържете дестинацията и времето на оспорената заявка със следата от политиката на шлюза. Определете домейна, изборите на схеми и режима на удостоверяване, които създава първото приложимо правило. Сравнете тези стойности с успешна заявка от същия клиент.

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

Ако ресурсът е попаднал в нежелано изключение, коригирайте това правило или обхвата му и прегледайте получената следа. Разширяването на разрешените методи за удостоверяване навсякъде може да скрие несъответствието, но променя поведението на достъп за несвързан трафик.

Ако желаният домейн е избран и очакваният обмен се провали, продължете към доказателствата за акаунта и Kerberos. Тогава билетът, името на услугата или диагностиката на бекенда стават важни.

Подобни статии