Zašto jedan zahtev kroz proxy traži lozinku dok Kerberos radi za ostale
Pronađite pravilo politike koje jednom zahtevu dodeljuje neočekivanu proxy autentifikacionu domenu, čak i kada drugi zahtevi uspešno koriste Kerberos.
Nekoliko zahteva uspešno koristi Kerberos kroz korporativni proxy. Jedan zahtev izaziva upit za lozinku. Pre zamene keytaba proverite koju je politiku autentifikacije odabrao taj zahtev.
Pristupnik može odabrati domenu i podržane šeme kroz politiku. Dve transakcije koje dolaze na isti proxy iz istog pregledača ne moraju dobiti iste zahteve za autentifikaciju.
Razmotrite ovaj hipotetički trag:
| Transakcija | Prvo odgovarajuće pravilo | Dostupna autentifikacija |
|---|---|---|
| Glavni dokument | Upravljano pravilo pregledanja | Negotiate |
| Skripta sa drugog hosta | Raniji izuzetak odredišta | Basic ili NTLM |
Prva uspešna razmena pokazuje da jedan odabrani put radi. Ne pokazuje da je druga transakcija stigla do tog puta. Akreditiv može biti valjan, a pravilo koje odabire njegov mehanizam autentifikacije pogrešno.
Pregledajte odabrano pravilo i njegov redosled
Povežite odredište i vreme izazvanog zahteva sa tragom politike pristupnika. Utvrdite domenu, izbore šeme i način autentifikacije koje proizvodi prvo primenjivo pravilo. Uporedite te vrednosti sa uspešnim zahtevom istog klijenta.
Politika zasnovana na identitetu povezanom sa IP-om takođe se može ponašati drukčije od one koja zahteva autentifikaciju na vezi. Ne pretpostavljajte da odsustvo novog rukovanja znači da je odabrana ista domena.
Ako je resurs završio u nenamernom izuzetku, ispravite to pravilo ili njegov obim i pregledajte dobijeni trag. Proširenje dozvoljenih metoda autentifikacije svuda može prikriti neusklađenost, ali menja ponašanje pristupa za nepovezani saobraćaj.
Ako je odabrana željena domena, a očekivana razmena ne uspe, pređite na dokaze o nalogu i Kerberosu. Tada postaju relevantni ulaznica, naziv usluge ili dijagnostika pozadinskog sistema.