VPN qoşulur, amma SQL Server Windows autentifikasiyasını rədd edir

Tunellər qalxır, serverlər ping-ə cavab verir, amma verilənlər bazasına giriş yenə autentifikasiya xətası ilə uğursuz olur. Bu birləşmə VPN bağlantılarında tez-tez olur və nadir hallarda şəbəkənin xarab olduğunu bildirir, çünki əlçatan dinləyici ilə qəbul edilmiş giriş fərqli nəticələrdir. Şlüzü razı salan kimlik mütləq verilənlər bazası müştərisinin təqdim etdiyi kimlik deyil. Hansı hesabın gəldiyini müəyyən etmək bütün işdir.

Simptom: əlçatan server, rədd edilən giriş

Taym-aut paketin heç bir dinləyiciyə çatmadığını deyir. Autentifikasiya xətası isə dinləyicinin cavab verdiyini və etimad məlumatını rədd etdiyini deyir. Bu iki mesaj sizi fərqli komandalara göndərir və onları qarışdırmaq heç vaxt problem olmayan firewall qaydalarına bir gün sərf edir.

Xəta giriş uğursuzluğu olduqda portlara baxmağı dayandırın. Qalan sual budur: müştəri hansı Windows kimliyini təqdim etdi, server bu kimliyi qəbul etdimi və o, icazəsi olan verilənlər bazası istifadəçisinə çevrildimi.

İki kimlik, bir tunel

VPN hesabı şlüzdə autentifikasiyadan keçir və əksər quraşdırmalarda orada bitir. Verilənlər bazası müştərisi ayrıca olaraq onu işə salan prosesdən götürülmüş Windows tokenini, ya da əlaqə sətri tələb edirsə SQL girişini təqdim edir. Şlüzün yerli VPN istifadəçisinin SQL Server-in yerləşdiyi domenlə heç bir əlaqəsi yoxdur və tunel belə bir əlaqə yaratmır.

Şəxsi maşını VPN-ə qoşmaq onu domenə də qatmır. Yerli hesabın adını dəyişmək və parolunu domen istifadəçisininkinə uyğunlaşdırmaq qeydiyyat proseduru deyil və domen nəzarətçisinin həmin istifadəçi kimi qəbul etməyəcəyi token yaradır.

Bəzi yerli Windows uzaqdan giriş müştəriləri profili belə konfiqurasiya edildikdə VPN etimad məlumatını şəbəkə resursları üçün təkrar istifadə edə bilir. Bu davranış konkret müştəriyə və profilə aiddir, ümumiyyətlə VPN bağlantılarına deyil, ona görə də bunu fərz etmək əvəzinə istifadədəki müştəri üçün yoxlayın.

Müştərinin tələb etdiyi rejimi oxuyun

Əlaqə sətri müştərinin hansı autentifikasiya yolunu tutacağını müəyyən edir. İnteqrasiya edilmiş təhlükəsizlik Windows tokenindən istifadə edir; istifadəçi və parol cütü SQL girişini seçir. Bunlar server konfiqurasiyasında ayrı rejimlərdir və verilmiş əlaqə cəhdi üçün yalnız biri aktiv ola bilər.

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

Windows girişi uğursuz olduğu üçün SQL girişinə keçmək kimlik sualını gizlədən bir müvəqqəti həlldir və adətən yenə yeni giriş və parol yaratmağı tələb edir. Quraşdırma Windows autentifikasiyası tələb edirsə, rejimi saxlayın və kimlik yolunu düzəldin. SQL girişinin də öz icazələri lazımdır, yəni həll ikinci bir hesabı saxlamaq yükü gətirir.

Həmçinin hansı tətbiqin qoşulduğunu təsdiqləyin. Sistem hesabı ilə işləyən xidmət, planlaşdırılmış tapşırıq və interaktiv sorğu pəncərəsi eyni maşında üç fərqli token təqdim edə bilər və yalnız sonuncusu istifadəçinin whoami işlədəndə gördüyü ilə üst-üstə düşür.

Serverdən həqiqətən nə gördüyünü soruşun

Server hansı girişi həll etdiyini və bağlantının necə autentifikasiya olunduğunu deyə bilər. Sorğunu araşdırılan sessiyanın içində işlədin, çünki administratorun ayrıca uğurlu bağlantısı uğursuz müştəri haqqında heç nə sübut etmir.

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;

Birinci sətir sessiyanı açan girişi hazırda qüvvədə olan təhlükəsizlik kontekstindən ayırır; bunlar kimliyə bürünmə zamanı fərqlənir. İkincisi autentifikasiya sxemini adlandırır, beləliklə KERBEROS, NTLM və SQL təxmin deyil, görünən faktlara çevrilir. Kerberos gözlədiyiniz yerdə NTLM bildirən bağlantı parol problemi deyil, ad həlli və ya SPN problemidir.

Xəta nömrəsi bunu daha da daraldır. Vəziyyət 5 adətən giriş adının ümumiyyətlə həll olunmadığını, vəziyyət 8 adətən parolun uyğun gəlmədiyini, vəziyyət 11 isə etimad məlumatının qəbul edildiyini, lakin serverə girişin uğursuz olduğunu bildirir. Administratordan bütün mesajı deyil, vəziyyəti soruşun, çünki mesajın özü qəsdən qeyri-müəyyəndir.

Kimlik gəlib Kerberos yenə uğursuz olduqda

Server nəzərdə tutulan Windows kimliyini görürsə və inteqrasiya edilmiş autentifikasiya yenə uğursuz olursa, problem mübadilənin özündədir. Kerberos SQL xidmət hesabı üçün qeydiyyatdan keçmiş xidmət əsas adını və xidməti ona uyğun adla tələb edən müştəri tələb edir. IP ünvanı ilə qoşulma ad əsaslı SPN-ə uyğun gələ bilməz, ləqəb isə yalnız qeydiyyatdan keçibsə uyğun gələ bilər. Əvvəlcə müştərinin yazdığı adı yoxlayın, çünki host adı ilə işləyib IP ilə uğursuz olan bağlantı məhz bu problemi təsvir edir.

Administratordan sınaq-yanılma yolu ilə dublikat SPN yaratmaq əvəzinə qeydiyyatdan keçmiş kimliyi və xidmət hesabını nəzərdən keçirməsini xahiş edin. Dublikat qeydiyyatlar orijinal problemdən daha çətin diaqnoz qoyulan fasiləli uğursuzluqlar yaradır.

Autentifikasiya işlədikdən sonra girişin hələ verilənlər bazası istifadəçisi və icazələri lazımdır. Uğurlu VPN girişi, uğurlu Windows girişi və müəyyən cədvəli oxumaq icazəsi üç ayrı nəticədir və hər biri bileti bağlamazdan əvvəl öz yoxlamasına layiqdir.