Mengapakah SQL Server melalui VPN masih jatuh ke NTLM?

Sambungan anda berfungsi, log masuk diterima, dan SQL Server menggunakan NTLM sedangkan semua orang menjangka Kerberos. Hasil itu bukan kecacatan VPN, kerana terowong hanya menyediakan laluan; skema ditentukan oleh nama yang diminta klien, prinsipal yang didaftarkan dalam direktori dan tiket yang benar-benar dapat diperoleh klien. Tiga syarat mesti dipenuhi serentak, dan sesi itu sendiri memberitahu yang mana mengalah. Baca itu sebelum sesiapa menyunting nama prinsipal perkhidmatan.

Sesi menamakan skema yang benar-benar anda peroleh

Skema pengesahan milik sambungan dan bukan pelayan atau terowong, jadi pemeriksaan mesti dijalankan di dalam sesi yang anda pedulikan. Jalankan pertanyaan di bawah daripada klien, alat dan akaun yang sama yang menghasilkan laporan, dan catat nama sasaran serta pengangkutan di sebelah hasil.

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

Baris daripada tetingkap SSMS tempatan pada hos pangkalan data menerangkan sambungan yang sama sekali berbeza, sebab itu pertanyaan mesti dijalankan dari sisi klien. Simpan output dengan cap masa, kerana orang seterusnya yang membacanya akan bertanya bila ia diambil. Apabila beberapa aplikasi berkongsi satu titik akhir, ambil sampel daripada setiap satu, kerana perbezaan sumber data antara dua aplikasi selalunya keseluruhan cerita.

Syarat pertama: adakah nama sepadan dengan SPN?

Kerberos mengesahkan perkhidmatan bernama, jadi klien meminta tiket daripada direktori untuk satu prinsipal tertentu. Bagi penyedia TCP, bentuk yang didokumenkan ialah MSSQLSvc/ diikuti nama hos yang layak sepenuhnya dan, untuk instans lalai, port. Instans bernama mendaftarkan MSSQLSvc/db01.corp.example:SQLPROD, dengan akhiran ialah nama instans dan bukannya nombor. Mencapai pendengar melalui alias, CNAME yang diselesaikan di tempat lain atau alamat IP kosong mengubah nama yang diminta, dan permintaan tanpa prinsipal yang sepadan tiada tiket untuk dipulangkan.

Itulah sebabnya satu aplikasi berfungsi pada satu rangkaian dan jatuh ke rangkaian lain: jawapan DNS, rekod alias atau entri hosts mengubah nama yang digunakan klien. Bandingkan nama yang diminta dengan apa yang dipegang direktori sebelum menyentuh pendaftaran.

Syarat kedua: adakah SPN pada akaun yang betul?

SPN mesti milik akaun yang menjalankan perkhidmatan SQL, bukan akaun klien dan bukan objek komputer secara tidak sengaja. SQL Server boleh mendaftarkan SPNnya sendiri semasa permulaan apabila akaun perkhidmatannya mempunyai kebenaran untuk menulisnya, yang memudahkan dan juga menjelaskan bagaimana pendua muncul selepas perubahan akaun perkhidmatan.

Tanya direktori untuk nama yang anda jangkakan, kemudian senaraikan apa yang sebenarnya dimiliki akaun. Objek mana yang memegang entri lebih penting daripada sama ada nama itu wujud di suatu tempat dalam hutan. Ketidakpadanan bermaksud log masuk tidak pernah menjadi masalahnya, dan panduan SPN Microsoft mendokumenkan format dan kes apabila pentadbir domain mesti mencipta entri.

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

Menambah entri lain bukan eksperimen yang selamat. Pendua atau pendaftaran bercanggah boleh merosakkan klien yang berfungsi, jadi periksa pemilikan sebelum perubahan dan periksa semula selepasnya.

Syarat ketiga: bolehkah klien memperoleh tiket langsung?

SPN yang betul tidak berguna jika klien tidak dapat mencapai pengawal domain atau tiada konteks kelayakan yang boleh digunakan. Pertukaran memerlukan KDC dan DNS melalui VPN, dan terowong yang hanya menyalurkan port SQL gagal tepat pada langkah ini. Kebolehcapaian mesti diuji dari mesin dan akaun yang sama, bukan dari tembok api di hadapan mereka.

Periksa cache tiket pada mesin dan di bawah akaun yang menjalankan aplikasi. Senarai seluruh mesin daripada tetingkap tinggi tidak memberitahu apa-apa tentang perkhidmatan yang berjalan sebagai pengguna lain, dan cache kosong untuk pengguna itu ialah penemuan dan bukan kesulitan.

klist
klist -li 0x3e7

Kemudian tentukan apa yang boleh dilakukan oleh sandaran. Jika dasar memerlukan Kerberos, NTLM mesti ditolak secara eksplisit, kerana sandaran senyap menukar ralat konfigurasi menjadi sambungan berfungsi yang melanggar keperluan. Jika NTLM kekal boleh diterima untuk sesetengah aplikasi, namakan aplikasi itu dan berhenti menganggap setiap sesi NTLM sebagai insiden.

Menukar pelancar ialah satu pemboleh ubah, bukan pembaikan

Memulakan SSMS di bawah kelayakan lain boleh menyembuhkan identiti keluar yang tidak diingini, yang merupakan kelas masalah sebenar. Ia tidak membuktikan apa-apa tentang nama sasaran, pendaftaran atau laluan tiket, dan tidak mengubah apa yang diterima pelayan.

Kekalkan perbandingan terkawal: titik akhir sama, penyedia sama, konteks pelaksanaan yang diketahui, kemudian sambungan baharu yang skemanya anda periksa. Sahkan log masuk yang diterima dan kebenaran pangkalan datanya secara berasingan, kerana akses dan pengesahan gagal atas sebab yang berbeza.

Apabila Kerberos diwajibkan, catat mengapa laluan pertama jatuh, gunakan satu pembetulan dan jalankan semula pertanyaan daripada klien yang sama. Pertanyaan berjaya selepas perubahan pelancar ialah bukti akses, dan ia belum lagi bukti bahawa keperluan pengesahan telah dipenuhi.