Mengapa Satu Permintaan Proxy Meminta Kata Sandi Sementara Kerberos Berhasil untuk Permintaan Lain
Temukan aturan kebijakan yang memberikan realm autentikasi proxy tak terduga kepada satu permintaan, meskipun permintaan lain menggunakan Kerberos dengan sukses.
Beberapa permintaan menggunakan Kerberos dengan sukses melalui proxy perusahaan. Satu permintaan memunculkan perintah kata sandi. Sebelum mengganti keytab, periksa kebijakan autentikasi mana yang dipilih permintaan tersebut.
Gateway dapat memilih realm dan skema yang didukung melalui kebijakan. Dua transaksi yang mencapai proxy yang sama dari peramban yang sama belum tentu menerima persyaratan autentikasi yang sama.
Perhatikan jejak hipotetis ini:
| Transaksi | Kebijakan pertama yang cocok | Autentikasi yang tersedia |
|---|---|---|
| Dokumen utama | Aturan penjelajahan terkelola | Negotiate |
| Skrip dari host lain | Pengecualian tujuan sebelumnya | Basic atau NTLM |
Pertukaran sukses pertama menunjukkan bahwa satu jalur terpilih berfungsi. Itu tidak menunjukkan bahwa transaksi kedua mencapai jalur tersebut. Kredensial bisa valid sementara aturan yang memilih mekanisme autentikasinya salah.
Periksa aturan yang dipilih dan urutannya
Korelasikan tujuan dan waktu permintaan yang ditantang dengan jejak kebijakan gateway. Identifikasi realm, pilihan skema, dan mode autentikasi yang dihasilkan aturan pertama yang berlaku. Bandingkan nilai tersebut dengan permintaan yang berhasil dari klien yang sama.
Kebijakan berbasis identitas yang terkait IP juga dapat berperilaku berbeda dari kebijakan yang mensyaratkan autentikasi pada koneksi. Jangan berasumsi bahwa tidak adanya handshake baru berarti realm yang sama telah dipilih.
Jika sumber daya masuk ke pengecualian yang tidak diinginkan, perbaiki aturan itu atau cakupannya dan tinjau jejak yang dihasilkan. Memperluas metode autentikasi yang diizinkan di mana-mana dapat menyembunyikan ketidaksesuaian tetapi mengubah perilaku akses untuk lalu lintas yang tidak terkait.
Jika realm yang dimaksud dipilih dan pertukaran yang diharapkan gagal, lanjutkan ke bukti akun dan Kerberos. Saat itulah tiket, nama layanan, atau diagnostik backend menjadi relevan.