VPN bersambung, tetapi SQL Server menolak pengesahan Windows

Terowong naik, pelayan menjawab ping, dan log masuk pangkalan data masih gagal dengan ralat pengesahan. Gabungan itu biasa pada pautan VPN dan jarang bermaksud rangkaian rosak, kerana pendengar yang boleh dicapai dan log masuk yang diterima ialah dua hasil berbeza. Identiti yang memuaskan gerbang belum tentu identiti yang ditawarkan klien pangkalan data. Menentukan akaun mana yang tiba ialah keseluruhan tugas.

Gejalanya: pelayan boleh dicapai, log masuk ditolak

Tamat masa memberitahu anda bahawa paket tidak pernah sampai kepada pendengar. Ralat pengesahan memberitahu bahawa pendengar menjawab dan menolak kelayakan. Kedua-dua mesej itu menghantar anda kepada pasukan berbeza, dan mencampurkannya membazirkan sehari pada peraturan tembok api yang tidak pernah menjadi masalah.

Apabila ralat itu ialah log masuk gagal, berhenti melihat port. Soalan yang tinggal ialah identiti Windows mana yang dikemukakan oleh klien, sama ada pelayan menerima identiti itu, dan sama ada ia diselesaikan kepada pengguna pangkalan data yang mempunyai kebenaran.

Dua identiti, satu terowong

Akaun VPN mengesahkan diri di gerbang dan dalam kebanyakan penggunaan berakhir di situ. Klien pangkalan data mengemukakan token Windows secara berasingan, yang diambil daripada proses yang menjalankannya, atau log masuk SQL jika rentetan sambungan memintanya. Pengguna VPN setempat di gerbang tidak mempunyai hubungan dengan domain yang mengehos SQL Server, dan terowong tidak mencipta hubungan itu.

Menyambung mesin peribadi ke VPN juga tidak memasukkannya ke dalam domain. Menamakan semula akaun setempat dan memadankan kata lalunya dengan pengguna domain bukan prosedur pendaftaran, dan ia menghasilkan token yang tidak akan diterima oleh pengawal domain sebagai pengguna itu.

Sesetengah klien akses jauh asli Windows boleh menggunakan semula kelayakan VPN untuk sumber rangkaian apabila profil mereka dikonfigurasikan sedemikian. Tingkah laku itu milik klien dan profil tertentu, bukan sambungan VPN secara umum, jadi sahkan untuk klien yang digunakan dan bukannya menganggapnya.

Baca mod yang diminta oleh klien

Rentetan sambungan menentukan laluan pengesahan yang diambil oleh klien. Keselamatan bersepadu menggunakan token Windows; pasangan pengguna dan kata laluan memilih log masuk SQL. Ini ialah mod berasingan dalam konfigurasi pelayan, dan hanya satu daripadanya boleh didayakan untuk percubaan sambungan tertentu.

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

Bertukar kepada log masuk SQL kerana log masuk Windows gagal ialah penyelesaian sementara yang menyembunyikan persoalan identiti, dan biasanya tetap memerlukan log masuk dan kata laluan baharu dicipta. Jika penggunaan memerlukan pengesahan Windows, kekalkan mod itu dan betulkan laluan identiti. Log masuk SQL juga memerlukan kebenarannya sendiri, jadi penyelesaian sementara itu membeli akaun kedua untuk diselenggara.

Sahkan juga aplikasi mana yang bersambung. Perkhidmatan yang berjalan sebagai akaun sistem, tugas berjadual dan tetingkap pertanyaan interaktif boleh mengemukakan tiga token berbeza pada mesin yang sama, dan hanya yang terakhir sepadan dengan apa yang dilihat pengguna apabila menjalankan whoami.

Tanyakan kepada pelayan apa yang sebenarnya dilihatnya

Pelayan boleh memberitahu anda log masuk mana yang diselesaikannya dan bagaimana sambungan itu disahkan. Jalankan pertanyaan di dalam sesi yang sedang disiasat, kerana sambungan berjaya yang berasingan oleh pentadbir tidak membuktikan apa-apa 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 membezakan log masuk yang membuka sesi daripada konteks keselamatan yang berkuat kuasa sekarang, dan keduanya berbeza di bawah penyamaran. Baris kedua menamakan skema pengesahan, jadi KERBEROS, NTLM dan SQL menjadi fakta yang kelihatan dan bukan andaian. Sambungan yang melaporkan NTLM di tempat anda menjangka Kerberos ialah masalah penyelesaian nama atau SPN, bukan masalah kata laluan.

Nombor ralat menyempitkannya lebih lanjut. Keadaan 5 biasanya bermaksud nama log masuk tidak diselesaikan langsung, keadaan 8 biasanya bermaksud kata laluan tidak sepadan, dan keadaan 11 bermaksud kelayakan diterima tetapi akses ke pelayan gagal. Mintalah keadaan daripada pentadbir dan bukannya keseluruhan mesej, kerana mesej itu sendiri sengaja kabur.

Apabila identiti tiba dan Kerberos masih gagal

Jika pelayan melihat identiti Windows yang dimaksudkan dan pengesahan bersepadu masih gagal, pertukaran itu sendiri adalah masalahnya. Kerberos memerlukan nama prinsipal perkhidmatan yang didaftarkan untuk akaun perkhidmatan SQL dan klien yang meminta perkhidmatan dengan nama yang sepadan dengannya. Menyambung melalui alamat IP tidak boleh sepadan dengan SPN berasaskan nama, dan alias hanya boleh sepadan jika ia juga didaftarkan. Semak nama yang ditaip oleh klien dahulu, kerana sambungan yang berfungsi melalui nama hos dan gagal melalui IP menggambarkan masalah ini dengan tepat.

Mintalah pentadbir menyemak identiti berdaftar dan akaun perkhidmatan dan bukannya mencipta SPN pendua melalui cuba-cuba. Pendaftaran pendua menghasilkan kegagalan berselang-seli yang lebih sukar didiagnosis daripada masalah asalnya.

Selepas pengesahan berfungsi, log masuk masih memerlukan pengguna pangkalan data dan kebenaran. Log masuk VPN yang berjaya, log masuk Windows yang berjaya dan kebenaran membaca jadual tertentu ialah tiga hasil berasingan, dan setiap satu wajar semakan tersendiri sebelum tiket ditutup.