Niyə VPN üzərindən SQL Server yenə də NTLM-ə keçir?

Bağlantınız işləyir, giriş qəbul olunur və hamı Kerberos gözləyərkən SQL Server NTLM istifadə edir. Bu nəticə VPN qüsuru deyil, çünki tunel yalnız yol verir; sxemi müştərinin istədiyi ad, kataloqda qeydiyyatdan keçmiş əsas və müştərinin həqiqətən əldə edə bildiyi bilet müəyyən edib. Üç şərt eyni vaxtda ödənməlidir və sessiya özü hansının güzəştə getdiyini deyir. Hər hansı biri xidmət əsas adını redaktə etməzdən əvvəl bunu oxuyun.

Sessiya həqiqətən aldığınız sxemin adını çəkir

Doğrulama sxemi serverə və ya tunelə deyil, bağlantıya aiddir, ona görə yoxlama sizi maraqlandıran sessiyanın içində aparılmalıdır. Aşağıdakı sorğunu hesabatı yaradan eyni müştəri, alət və hesabdan icra edin və hədəf adı ilə nəqliyyatı nəticənin yanında qeyd edin.

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

Verilənlər bazası hostundakı yerli SSMS pəncərəsindən gələn sətir tamamilə başqa bağlantını təsvir edir, ona görə sorğu müştəri tərəfindən aparılmalıdır. Çıxışı zaman damğası ilə saxlayın, çünki onu oxuyacaq növbəti şəxs nə vaxt götürüldüyünü soruşacaq. Bir neçə tətbiq bir son nöqtəni paylaşdıqda hər birindən nümunə götürün, çünki iki tətbiq arasında məlumat mənbəyi fərqi çox vaxt bütün hekayədir.

Birinci şərt: ad SPN-ə uyğundurmu?

Kerberos adlı xidməti doğrulayır, buna görə müştəri kataloqdan bir konkret əsas üçün bilet istəyir. TCP provayderi üçün sənədləşdirilmiş forma MSSQLSvc/ və ardınca tam kvalifikasiyalı host adı, standart nüsxə üçün isə portdur. Adlı nüsxə MSSQLSvc/db01.corp.example:SQLPROD qeydiyyatdan keçirir, burada şəkilçi rəqəm əvəzinə nüsxə adıdır. Dinləyiciyə ləqəb, başqa yerdə həll olunan CNAME və ya təmiz IP ünvanı ilə çatmaq tələb olunan adı dəyişir və uyğun əsası olmayan sorğunun qaytaracaq bileti olmur.

Buna görə bir tətbiq bir şəbəkədə işləyir, digərində isə geri çəkilir: DNS cavabı, ləqəb qeydi və ya hosts yazısı müştərinin istifadə etdiyi adı dəyişib. Qeydiyyata toxunmazdan əvvəl tələb olunan adı kataloqda saxlananla müqayisə edin.

İkinci şərt: SPN düzgün hesabdadır?

SPN SQL xidmətini işlədən hesaba aid olmalıdır, müştərinin hesabına və ya təsadüfən kompüter obyektinə deyil. SQL Server xidmət hesabı onları yazmaq icazəsinə malik olduqda öz SPN-lərini başlanğıcda qeydiyyatdan keçirə bilər; bu rahatdır və həm də xidmət hesabı dəyişdikdən sonra dublikatın necə yarandığını göstərir.

Gözlədiyiniz adı kataloqdan soruşun, sonra hesabın həqiqətən nəyə sahib olduğunu sadalayın. Hansı obyektin yazını saxlaması adın meşədə haradasa mövcud olmasından daha vacibdir. Uyğunsuzluq girişin heç vaxt problem olmadığını bildirir və Microsoft-un SPN bələdçisi formatları və domen administratorunun yazını yaratmalı olduğu halları sənədləşdirir.

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

Başqa yazı əlavə etmək təhlükəsiz təcrübə deyil. Dublikat və ya ziddiyyətli qeydiyyat işləyən müştəriləri poza bilər, ona görə dəyişiklikdən əvvəl sahibliyi yoxlayın və sonra yenidən yoxlayın.

Üçüncü şərt: müştəri ümumiyyətlə bilet ala bilirmi?

Düzgün SPN, müştəri domen nəzarətçisinə çata bilmirə və ya istifadə edilə bilən etimad konteksti yoxdursa faydasızdır. Mübadilə VPN vasitəsilə KDC və DNS tələb edir və yalnız SQL portunu yönləndirən tunel məhz bu addımda uğursuz olur. Əlçatımlılıq onların qarşısındakı firewall-dan deyil, eyni maşın və eyni hesabdan yoxlanmalıdır.

Bilet keşini maşında və tətbiqi işlədən hesabın altında yoxlayın. Yüksək imtiyazlı pəncərədən alınan maşın üzrə siyahı başqa istifadəçi kimi işləyən xidmət barədə heç nə demir və həmin istifadəçi üçün boş keş narahatlıq deyil, tapıntıdır.

klist
klist -li 0x3e7

Sonra geri çəkilmənin nə edə biləcəyinə qərar verin. Siyasət Kerberos tələb edirsə, NTLM açıq şəkildə rədd edilməlidir, çünki səssiz geri çəkilmə konfiqurasiya səhvini tələbi pozan işlək bağlantıya çevirir. NTLM bəzi tətbiqlər üçün məqbul qalırsa, onları adlandırın və hər NTLM sessiyasını insident kimi qəbul etməyi dayandırın.

Başladıcını dəyişmək bir dəyişəndir, düzəliş deyil

SSMS-i başqa etimadla başlatmaq qeyri-ixtiyari gedən kimliyi aradan qaldıra bilər ki, bu real problem sinfidir. Bu, hədəf adı, qeydiyyat və ya bilet yolu barədə heç nə sübut etmir və serverin nəyi qəbul etdiyini dəyişmir.

Müqayisəni nəzarət altında saxlayın: eyni son nöqtə, eyni provayder, məlum icra konteksti, sonra sxemini yoxladığınız təzə bağlantı. Qəbul edilmiş girişi və onun verilənlər bazası icazələrini ayrıca təsdiqləyin, çünki giriş və doğrulama fərqli səbəblərdən uğursuz olur.

Kerberos tələb olunduqda birinci yolun niyə geri çəkildiyini qeyd edin, bir düzəliş tətbiq edin və sorğunu eyni müştəridən yenidən icra edin. Başladıcı dəyişikliyindən sonra uğurlu sorğu girişin sübutudur və hələ doğrulama tələbinin yerinə yetirildiyinin sübutu deyil.