VPN terhubung, tetapi SQL Server menolak autentikasi Windows

Tunnel menyala, server menjawab ping, dan login basis data tetap gagal dengan kesalahan autentikasi. Kombinasi itu umum pada tautan VPN dan jarang berarti jaringan rusak, karena pendengar yang terjangkau dan login yang diterima adalah dua hasil berbeda. Identitas yang memuaskan gateway belum tentu identitas yang ditawarkan klien basis data. Menentukan akun mana yang datang adalah keseluruhan tugasnya.

Gejalanya: server terjangkau, login ditolak

Batas waktu memberi tahu Anda bahwa paket tidak pernah mencapai pendengar. Kesalahan autentikasi memberi tahu bahwa pendengar menjawab dan menolak kredensial. Kedua pesan itu mengirim Anda ke tim berbeda, dan mencampurnya menghabiskan satu hari pada aturan firewall yang tidak pernah menjadi masalah.

Saat kesalahannya adalah login gagal, berhentilah melihat port. Pertanyaan yang tersisa adalah identitas Windows mana yang diajukan klien, apakah server menerima identitas itu, dan apakah identitas itu terselesaikan menjadi pengguna basis data yang punya izin.

Dua identitas, satu tunnel

Akun VPN diautentikasi di gateway dan pada sebagian besar penerapan berhenti di situ. Klien basis data secara terpisah mengajukan token Windows, yang diambil dari proses yang menjalankannya, atau login SQL jika string koneksi memintanya. Pengguna VPN lokal gateway tidak punya hubungan dengan domain yang menghosting SQL Server, dan tunnel tidak membuat hubungan itu.

Menghubungkan mesin pribadi ke VPN juga tidak memasukkannya ke domain. Mengganti nama akun lokal dan menyamakan kata sandinya dengan pengguna domain bukan prosedur pendaftaran, dan itu menghasilkan token yang tidak akan diterima pengendali domain sebagai pengguna tersebut.

Beberapa klien akses jarak jauh bawaan Windows dapat memakai ulang kredensial VPN untuk sumber daya jaringan bila profilnya dikonfigurasi demikian. Perilaku itu milik klien dan profil tertentu, bukan milik koneksi VPN secara umum, jadi verifikasikan untuk klien yang dipakai alih-alih mengasumsikannya.

Baca mode yang diminta klien

String koneksi menentukan jalur autentikasi yang diambil klien. Keamanan terintegrasi memakai token Windows; pasangan pengguna dan kata sandi memilih login SQL. Keduanya mode terpisah dalam konfigurasi server, dan hanya satu yang dapat diaktifkan untuk satu upaya koneksi tertentu.

Server=tcp:sql.lab.example,1433;Database=ops;Integrated Security=SSPI;Encrypt=True;TrustServerCertificate=False;

Beralih ke login SQL karena login Windows gagal adalah akal-akalan yang menyembunyikan pertanyaan identitas, dan biasanya tetap memerlukan pembuatan login dan kata sandi baru. Jika penerapan menuntut autentikasi Windows, pertahankan mode itu dan perbaiki jalur identitasnya. Login SQL juga butuh izin sendiri, jadi akal-akalan itu membeli akun kedua untuk dirawat.

Pastikan juga aplikasi mana yang terhubung. Layanan yang berjalan sebagai akun sistem, tugas terjadwal, dan jendela kueri interaktif dapat mengajukan tiga token berbeda pada mesin yang sama, dan hanya yang terakhir cocok dengan apa yang dilihat pengguna saat menjalankan whoami.

Tanyakan kepada server apa yang sebenarnya dilihatnya

Server dapat memberi tahu login mana yang diselesaikannya dan bagaimana koneksi diautentikasi. Jalankan kueri di dalam sesi yang sedang diselidiki, karena koneksi berhasil milik administrator secara terpisah tidak membuktikan apa pun tentang klien yang gagal.

SELECT ORIGINAL_LOGIN() AS original_login,
       SUSER_SNAME() AS current_context;
SELECT auth_scheme, net_transport
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Baris pertama membedakan login yang membuka sesi dari konteks keamanan yang berlaku sekarang, dan keduanya berbeda di bawah penyamaran. Baris kedua menyebut skema autentikasi, sehingga KERBEROS, NTLM, dan SQL menjadi fakta yang terlihat alih-alih dugaan. Koneksi yang melaporkan NTLM di tempat Anda mengharapkan Kerberos adalah masalah resolusi nama atau SPN, bukan masalah kata sandi.

Nomor kesalahan mempersempitnya lebih jauh. Status 5 biasanya berarti nama login tidak terselesaikan sama sekali, status 8 biasanya berarti kata sandi tidak cocok, dan status 11 berarti kredensial diterima tetapi akses ke server gagal. Mintalah status kepada administrator, bukan seluruh pesan, karena pesannya sendiri sengaja kabur.

Ketika identitas datang dan Kerberos tetap gagal

Jika server melihat identitas Windows yang dimaksud dan autentikasi terintegrasi tetap gagal, pertukaran itu sendiri yang bermasalah. Kerberos memerlukan nama utama layanan yang terdaftar untuk akun layanan SQL dan klien yang meminta layanan dengan nama yang cocok dengannya. Menghubungkan lewat alamat IP tidak dapat cocok dengan SPN berbasis nama, dan alias hanya dapat cocok jika alias itu juga terdaftar. Periksa lebih dulu nama yang diketik klien, karena koneksi yang berhasil lewat nama host dan gagal lewat IP menggambarkan persis masalah ini.

Mintalah administrator meninjau identitas terdaftar dan akun layanan alih-alih membuat SPN duplikat dengan coba-coba. Pendaftaran duplikat menghasilkan kegagalan berselang yang lebih sulit didiagnosis daripada masalah aslinya.

Setelah autentikasi berhasil, login masih memerlukan pengguna basis data dan izin. Login VPN yang berhasil, login Windows yang berhasil, dan izin membaca tabel tertentu adalah tiga hasil terpisah, dan masing-masing layak diperiksa sendiri sebelum tiket ditutup.