Bir proksi sorğusu parol tələb edirsə, digərləri üçün Kerberos işləyir
Digər sorğular Kerberosdan uğurla istifadə etsə də, bir sorğuya gözlənilməz proksi autentifikasiya sahəsi təyin edən siyasət qaydasını tapın.
Bir neçə sorğu şirkət proksisindən Kerberos ilə uğurla keçir. Bir sorğu isə parol sorğusu yaradır. Keytab dəyişməzdən əvvəl həmin sorğunun hansı autentifikasiya siyasətini seçdiyini yoxlayın.
Şlüz siyasət vasitəsilə sahə və dəstəklənən sxemləri seçə bilər. Eyni brauzerdən eyni proksiyə çatan iki əməliyyatın eyni autentifikasiya tələbləri alması vacib deyil.
Bu hipotetik izi nəzərdən keçirin:
| Əməliyyat | İlk uyğun siyasət | Mövcud autentifikasiya |
|---|---|---|
| Əsas sənəd | İdarə olunan gəzinti qaydası | Negotiate |
| Başqa hostdan skript | Daha əvvəlki təyinat istisnası | Basic və ya NTLM |
İlk uğurlu mübadilə bir seçilmiş yolun işlədiyini göstərir. İkinci əməliyyatın həmin yola çatdığını göstərmir. Etibarnamə etibarlı ola bilər, amma onun autentifikasiya mexanizmini seçən qayda səhvdir.
Seçilmiş qaydayı və onun sırasını yoxlayın
Meydan oxunan sorğunun təyinatını və vaxtını şlüzün siyasət izi ilə əlaqələndirin. İlk tətbiq olunan qaydanın yaratdığı sahəni, sxem seçimlərini və autentifikasiya rejimini müəyyən edin. Bu dəyərləri eyni müştəridən gələn uğurlu sorğu ilə müqayisə edin.
IP ilə əlaqəli şəxsiyyətə əsaslanan siyasət də bağlantı üzərində autentifikasiya tələb edən siyasətdən fərqli davrana bilər. Yeni əl sıxışmasının olmamasının eyni sahənin seçildiyi anlamına gəldiyini güman etməyin.
Resurs təsadüfi bir istisnaya düşübsə, həmin qaydayı və ya onun əhatəsini düzəldin və yaranan izi nəzərdən keçirin. İcazə verilən autentifikasiya üsullarını hər yerdə genişləndirmək uyğunsuzluğu gizlədə bilər, amma əlaqəsiz trafikin giriş davranışını dəyişir.
Nəzərdə tutulan sahə seçilib və gözlənilən mübadilə uğursuz olarsa, hesab və Kerberos sübutlarına keçin. Biletin, xidmət adının və ya backend diaqnostikasının əhəmiyyətli olduğu yer budur.