Mengapa SQL Server lewat VPN tetap jatuh ke NTLM?

Koneksi Anda berfungsi, login diterima, dan SQL Server memakai NTLM sementara semua orang mengharapkan Kerberos. Hasil itu bukan cacat VPN, karena terowongan hanya menyediakan jalur; skema ditentukan oleh nama yang diminta klien, principal yang terdaftar di direktori, dan tiket yang benar-benar dapat diperoleh klien. Tiga syarat harus terpenuhi sekaligus, dan sesi itu sendiri mengatakan mana yang mengalah. Baca itu sebelum seseorang menyunting nama utama layanan.

Sesi menyebutkan skema yang benar-benar Anda dapatkan

Skema autentikasi milik sebuah koneksi, bukan server atau terowongan, jadi pemeriksaan harus berjalan di dalam sesi yang Anda pedulikan. Jalankan kueri di bawah dari klien, alat, dan akun yang sama yang menghasilkan laporan, dan catat nama target serta transport di samping hasilnya.

SELECT session_id, auth_scheme, net_transport, client_net_address, login_name
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Baris dari jendela SSMS lokal di host basis data menjelaskan koneksi yang sama sekali berbeda, karena itu kueri harus berjalan dari sisi klien. Simpan keluaran dengan cap waktu, karena orang berikutnya yang membacanya akan bertanya kapan itu diambil. Ketika beberapa aplikasi berbagi satu titik akhir, ambil sampel dari masing-masing, karena perbedaan sumber data antara dua aplikasi sering kali adalah keseluruhan cerita.

Syarat pertama: apakah nama cocok dengan SPN?

Kerberos mengautentikasi layanan bernama, jadi klien meminta tiket dari direktori untuk satu principal tertentu. Untuk penyedia TCP, bentuk yang didokumentasikan adalah MSSQLSvc/ diikuti nama host yang sepenuhnya memenuhi syarat dan, untuk instans default, port. Instans bernama mendaftarkan MSSQLSvc/db01.corp.example:SQLPROD, dengan akhiran berupa nama instans alih-alih nomor. Mencapai listener melalui alias, CNAME yang diselesaikan di tempat lain, atau alamat IP telanjang mengubah nama yang diminta, dan permintaan tanpa principal yang cocok tidak punya tiket untuk dikembalikan.

Itulah sebabnya satu aplikasi berfungsi di satu jaringan dan jatuh ke jaringan lain: jawaban DNS, catatan alias, atau entri hosts mengubah nama yang dipakai klien. Bandingkan nama yang diminta dengan yang dipegang direktori sebelum menyentuh pendaftaran.

Syarat kedua: apakah SPN berada di akun yang tepat?

SPN harus menjadi milik akun yang menjalankan layanan SQL, bukan akun klien dan bukan objek komputer secara tidak sengaja. SQL Server dapat mendaftarkan SPN-nya sendiri saat mulai ketika akun layanannya memiliki izin untuk menulisnya, yang praktis dan juga menjelaskan bagaimana duplikat muncul setelah perubahan akun layanan.

Tanyakan direktori untuk nama yang Anda harapkan, lalu daftar apa yang benar-benar dimiliki akun. Objek mana yang memegang entri lebih penting daripada apakah nama itu ada di suatu tempat di hutan. Ketidakcocokan berarti login tidak pernah menjadi masalahnya, dan panduan SPN Microsoft mendokumentasikan format dan kasus ketika administrator domain harus membuat entri.

setspn -Q MSSQLSvc/db01.corp.example:1433
setspn -L CORP\svc-sql01

Menambahkan entri lain bukan eksperimen yang aman. Duplikat atau pendaftaran yang bertentangan dapat merusak klien yang tadinya berfungsi, jadi periksa kepemilikan sebelum perubahan dan periksa lagi sesudahnya.

Syarat ketiga: dapatkah klien memperoleh tiket sama sekali?

SPN yang benar tidak berguna jika klien tidak dapat menjangkau pengendali domain atau tidak memiliki konteks kredensial yang dapat dipakai. Pertukaran membutuhkan KDC dan DNS melalui VPN, dan terowongan yang hanya merutekan port SQL gagal tepat pada langkah ini. Keterjangkauan harus diuji dari mesin dan akun yang sama, bukan dari firewall di depan keduanya.

Periksa cache tiket di mesin dan di bawah akun yang menjalankan aplikasi. Daftar seluruh mesin dari jendela dengan hak tinggi tidak mengatakan apa pun tentang layanan yang berjalan sebagai pengguna lain, dan cache kosong untuk pengguna itu adalah temuan, bukan ketidaknyamanan.

klist
klist -li 0x3e7

Lalu putuskan apa yang boleh dilakukan fallback. Jika kebijakan mewajibkan Kerberos, NTLM harus ditolak secara eksplisit, karena fallback diam-diam mengubah kesalahan konfigurasi menjadi koneksi yang berfungsi tetapi melanggar persyaratan. Jika NTLM tetap dapat diterima untuk sebagian aplikasi, sebutkan aplikasi itu dan berhenti memperlakukan setiap sesi NTLM sebagai insiden.

Mengubah peluncur adalah satu variabel, bukan perbaikan

Menjalankan SSMS dengan kredensial lain dapat menyembuhkan identitas keluar yang tidak diinginkan, yang merupakan kelas masalah nyata. Itu tidak membuktikan apa pun tentang nama target, pendaftaran, atau jalur tiket, dan tidak mengubah apa yang diterima server.

Jaga perbandingan tetap terkendali: titik akhir yang sama, penyedia yang sama, konteks eksekusi yang diketahui, lalu koneksi baru yang skemanya Anda periksa. Konfirmasi login yang diterima dan izin basis datanya secara terpisah, karena akses dan autentikasi gagal karena alasan yang berbeda.

Ketika Kerberos diwajibkan, catat mengapa jalur pertama jatuh, terapkan satu koreksi, dan jalankan kueri lagi dari klien yang sama. Kueri yang berhasil setelah perubahan peluncur adalah bukti akses, dan belum bukti bahwa persyaratan autentikasi terpenuhi.