Зашто један захтев кроз прокси тражи лозинку док Kerberos ради за остале
Пронађите правило политике које једном захтеву додељује неочекивану proxy домену за аутентификацију, чак и када други захтеви успешно користе Kerberos.
Неколико захтева успешно користи Kerberos кроз корпоративни прокси. Један захтев изазива упит за лозинку. Пре замене keytab-а проверите коју је политику аутентификације одабрао тај захтев.
Приступник може да одабере домену и подржане шеме кроз политику. Две трансакције које долазе на исти прокси из истог прегледача не морају да добију исте захтеве за аутентификацију.
Размотрите овај хипотетички траг:
| Трансакција | Прво одговарајуће правило | Доступна аутентификација |
|---|---|---|
| Главни документ | Управљано правило прегледања | Negotiate |
| Скрипта са другог хоста | Ранији изузетак одредишта | Basic или NTLM |
Прва успешна размена показује да један одабрани пут ради. Не показује да је друга трансакција стигла до тог пута. Акредитив може бити ваљан, а правило које одабира његов механизам аутентификације погрешно.
Прегледајте одабрано правило и његов редослед
Повежите одредиште и време изазваног захтева са трагом политике приступника. Утврдите домену, изборе шеме и начин аутентификације које производи прво примењиво правило. Упоредите те вредности са успешним захтевом истог клијента.
Политика заснована на идентитету повезаном са IP-ом такође се може понашати другачије од оне која захтева аутентификацију на вези. Не претпостављајте да одсуство новог руковања значи да је одабрана иста домена.
Ако је ресурс завршио у ненамерном изузетку, исправите то правило или његов обим и прегледајте добијени траг. Проширење дозвољених метода аутентификације свуда може прикрити неусклађеност, али мења понашање приступа за неповезани саобраћај.
Ако је одабрана жељена домена, а очекивана размена не успе, пређите на доказе о налогу и Kerberos-у. Тада постају релевантни улазница, назив услуге или дијагностика позадинског система.