Dlaczego jedno żądanie przez proxy prosi o hasło, gdy Kerberos działa dla innych
Znajdź regułę zasad, która przypisuje jednemu żądaniu nieoczekiwaną domenę uwierzytelniania proxy, nawet gdy inne żądania pomyślnie używają Kerberosa.
Kilka żądań pomyślnie używa Kerberosa przez proxy firmowe. Jedno żądanie wywołuje monit o hasło. Przed wymianą keytab sprawdź, które zasady uwierzytelniania wybrało właśnie to żądanie.
Brama może wybrać domenę i obsługiwane schematy za pomocą zasad. Dwie transakcje trafiające do tego samego proxy z tej samej przeglądarki nie muszą otrzymywać tych samych wymagań uwierzytelniania.
Rozważ ten hipotetyczny ślad:
| Transakcja | Pierwsza pasująca zasada | Dostępne uwierzytelnianie |
|---|---|---|
| Dokument główny | Zarządzana reguła przeglądania | Negotiate |
| Skrypt z innego hosta | Wcześniejszy wyjątek miejsca docelowego | Basic lub NTLM |
Pierwsza udana wymiana pokazuje, że jedna wybrana ścieżka działa. Nie pokazuje, że druga transakcja dotarła do tej ścieżki. Poświadczenie może być ważne, podczas gdy reguła wybierająca jego mechanizm uwierzytelniania jest błędna.
Zbadaj wybraną regułę i jej kolejność
Powiąż miejsce docelowe i czas zakwestionowanego żądania ze śladem zasad bramy. Zidentyfikuj domenę, wybory schematów i tryb uwierzytelniania tworzone przez pierwszą pasującą regułę. Porównaj te wartości z udanym żądaniem tego samego klienta.
Zasada oparta na tożsamości powiązanej z adresem IP może zachowywać się inaczej niż zasada wymagająca uwierzytelniania na połączeniu. Nie zakładaj, że brak nowego uzgadniania oznacza wybór tej samej domeny.
Jeśli zasób wpadł w niezamierzony wyjątek, popraw tę regułę lub jej zakres i przejrzyj wynikowy ślad. Rozszerzanie dozwolonych metod uwierzytelniania wszędzie może ukryć niezgodność, ale zmienia zachowanie dostępu dla niepowiązanego ruchu.
Jeśli wybrano zamierzoną domenę, a oczekiwana wymiana kończy się niepowodzeniem, przejdź do dowodów dotyczących konta i Kerberosa. Wtedy znaczenie zyskują bilet, nazwa usługi lub diagnostyka zaplecza.