Proč jeden požadavek přes proxy žádá heslo, zatímco Kerberos funguje pro ostatní
Najděte pravidlo zásad, které jednomu požadavku přiřadí neočekávanou oblast ověřování proxy, i když ostatní požadavky Kerberos úspěšně používají.
Několik požadavků úspěšně používá Kerberos přes firemní proxy. Jeden požadavek vyvolá výzvu k zadání hesla. Než vyměníte keytab, zjistěte, kterou zásadu ověřování si tento konkrétní požadavek vybral.
Brána může zásadou zvolit oblast a podporované schémy. Dvě transakce přicházející na stejnou proxy ze stejného prohlížeče nemusí dostat stejné požadavky na ověření.
Zvažte tento hypotetický záznam:
| Transakce | První odpovídající pravidlo | Dostupné ověření |
|---|---|---|
| Hlavní dokument | Spravované pravidlo prohlížení | Negotiate |
| Skript z jiného hostitele | Dřívější výjimka cíle | Basic nebo NTLM |
První úspěšná výměna ukazuje, že jedna zvolená cesta funguje. Neukazuje, že druhá transakce touto cestou prošla. Přihlašovací údaj může být platný, zatímco pravidlo volící jeho ověřovací mechanismus je špatné.
Prozkoumejte zvolené pravidlo a jeho pořadí
Spojte cíl a čas napadeného požadavku se záznamem zásad brány. Určete oblast, volby schémat a režim ověřování, které vytváří první použitelné pravidlo. Porovnejte tyto hodnoty s úspěšným požadavkem stejného klienta.
Zásada založená na identitě spojené s IP se také může chovat jinak než zásada vyžadující ověření na spojení. Nepředpokládejte, že nepřítomnost nového handshake znamená volbu stejné oblasti.
Pokud zdroj spadl do nezamýšlené výjimky, opravte toto pravidlo nebo jeho rozsah a zkontrolujte výsledný záznam. Rozšíření povolených metod ověřování všude může nesoulad skrýt, ale mění chování přístupu pro nesouvisející provoz.
Pokud je zvolena zamýšlená oblast a očekávaná výměna selže, přejděte k důkazům o účtu a Kerberosu. Tehdy se stanou relevantními tiket, název služby nebo diagnostika backendu.