რატომ ეცემა SQL Server VPN-ის გავლით მაინც NTLM-ზე?

თქვენი კავშირი მუშაობს, შესვლა მიიღება და SQL Server იყენებს NTLM-ს, მაშინ როცა ყველა Kerberos-ს ელოდა. ეს შედეგი VPN-ის დეფექტი არ არის, რადგან გვირაბი მხოლოდ გზას იძლევა; სქემა განსაზღვრა კლიენტის მოთხოვნილმა სახელმა, დირექტორიაში რეგისტრირებულმა ძირითადმა სუბიექტმა და იმ ბილეთმა, რომლის მიღებაც კლიენტმა რეალურად შეძლო. სამი პირობა ერთდროულად უნდა სრულდებოდეს და თავად სესია ამბობს, რომელი დათმო. წაიკითხეთ ეს, სანამ ვინმე სერვისის ძირითად სახელს შეცვლის.

სესია ასახელებს სქემას, რომელიც რეალურად მიიღეთ

ავთენტიფიკაციის სქემა კავშირს ეკუთვნის და არა სერვერს ან გვირაბს, ამიტომ შემოწმება თქვენთვის საინტერესო სესიის შიგნით უნდა გაშვდეს. შეასრულეთ ქვემოთ მოცემული მოთხოვნა იმავე კლიენტიდან, ხელსაწყოდან და ანგარიშიდან, რომლებმაც შექმნეს ანგარიში, და ჩაწერეთ სამიზნის სახელი და ტრანსპორტი შედეგის გვერდით.

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

მონაცემთა ბაზის ჰოსტზე ლოკალური SSMS ფანჯრიდან მიღებული სტრიქონი სრულიად სხვა კავშირს აღწერს, ამიტომ მოთხოვნა კლიენტის მხრიდან უნდა გაშვდეს. შეინახეთ გამოსავალი დროის ნიშნით, რადგან შემდეგი მკითხველი იკითხავს, როდის იქნა აღებული. როცა რამდენიმე აპლიკაცია ერთ საბოლოო წერტილს იზიარებს, თითოეულიდან აიღეთ ნიმუში, რადგან ორ აპლიკაციას შორის მონაცემთა წყაროს სხვაობა ხშირად მთელი ისტორიაა.

პირველი პირობა: ემთხვევა სახელი SPN-ს?

Kerberos ავთენტიფიცირებს დასახელებულ სერვისს, ამიტომ კლიენტი დირექტორიას ერთი კონკრეტული ძირითადი სუბიექტისთვის ბილეთს სთხოვს. TCP პროვაიდერისთვის დოკუმენტირებული ფორმაა MSSQLSvc/, რასაც მოჰყვება სრულად კვალიფიციური ჰოსტის სახელი და ნაგულისხმევი ინსტანციისთვის პორტი. დასახელებული ინსტანცია არეგისტრირებს MSSQLSvc/db01.corp.example:SQLPROD, სადაც სუფიქსი რიცხვის ნაცვლად ინსტანციის სახელია. მსმენელამდე ალიასით, სხვაგან გადაწყვეტადი CNAME-ით ან შიშველი IP მისამართით მისვლა მოთხოვნილ სახელს ცვლის და შესაბამისი ძირითადი სუბიექტის გარეშე მოთხოვნას დასაბრუნებელი ბილეთი არ აქვს.

ამიტომ ერთი აპლიკაცია ერთ ქსელში მუშაობს და მეორეში უკან იხევს: DNS პასუხმა, ალიასის ჩანაწერმა ან hosts-ის ჩანაწერმა შეცვალა სახელი, რომელსაც კლიენტი იყენებდა. შეადარეთ მოთხოვნილი სახელი იმას, რაც დირექტორიას აქვს, სანამ რეგისტრაციას შეეხებით.

მეორე პირობა: SPN სწორ ანგარიშზეა?

SPN უნდა ეკუთვნოდეს იმ ანგარიშს, რომელიც SQL სერვისს ამუშავებს, და არა კლიენტის ანგარიშს და არც შემთხვევით კომპიუტერის ობიექტს. SQL Server-ს შეუძლია საკუთარი SPN-ების რეგისტრაცია გაშვებისას, როცა მის სერვისის ანგარიშს მათი ჩაწერის ნებართვა აქვს, რაც მოხერხებულია და ასევე ხსნის, როგორ ჩნდება დუბლიკატი სერვისის ანგარიშის შეცვლის შემდეგ.

ჰკითხეთ დირექტორიას მოსალოდნელი სახელის შესახებ, შემდეგ ჩამოთვალეთ, რასაც ანგარიში რეალურად ფლობს. რომელი ობიექტი ინახავს ჩანაწერს, უფრო მნიშვნელოვანია, ვიდრე ის, არსებობს თუ არა სახელი სადმე ტყეში. შეუსაბამობა ნიშნავს, რომ შესვლა არასოდეს ყოფილა პრობლემა, და Microsoft-ის SPN-ის სახელმძღვანელო აღწერს ფორმატებსა და იმ შემთხვევებს, როცა დომენის ადმინისტრატორმა ჩანაწერი უნდა შექმნას.

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

კიდევ ერთი ჩანაწერის დამატება უსაფრთხო ექსპერიმენტი არ არის. დუბლიკატმა ან კონფლიქტურმა რეგისტრაციამ შეიძლება გატეხოს მომუშავე კლიენტები, ამიტომ შეცვლამდე შეამოწმეთ საკუთრება და შემდეგ კვლავ გადაამოწმეთ.

მესამე პირობა: შეუძლია კლიენტს საერთოდ ბილეთის მიღება?

სწორი SPN უსარგებლოა, თუ კლიენტი ვერ აღწევს დომენის კონტროლერს ან არ აქვს გამოსაყენებელი რწმუნებათა კონტექსტი. გაცვლას VPN-ის გავლით სჭირდება KDC და DNS, და მხოლოდ SQL პორტის მარშრუტიზაცია გვირაბი ზუსტად ამ საფეხურზე ფარდება. ხელმისაწვდომობა უნდა შემოწმდეს იმავე მანქანიდან და იმავე ანგარიშიდან, და არა მათ წინ მდებარე ფაილვოლიდან.

შეამოწმეთ ბილეთების ქეში მანქანაზე და აპლიკაციის გამშვები ანგარიშის ქვეშ. მანქანის მასშტაბის სია ამაღლებული ფანჯრიდან არაფერს ამბობს სხვა მომხმარებლის სახელით მომუშავე სერვისზე, და ამ მომხმარებლისთვის ცარიელი ქეში აღმოჩენაა და არა უხერხულობა.

klist
klist -li 0x3e7

შემდეგ გადაწყვიტეთ, რა შეიძლება გააკეთოს უკან დახევამ. თუ პოლიტიკა Kerberos-ს მოითხოვს, NTLM ცალსახად უნდა იყოს უარყოფილი, რადგან ჩუმი უკან დახევა კონფიგურაციის შეცდომას აქცევს მოთხოვნის დამრღვევ სამუშაო კავშირად. თუ NTLM ზოგიერთი აპლიკაციისთვის მისაღები რჩება, დაასახელეთ ისინი და შეწყვიტეთ ყოველი NTLM სესიის ინციდენტად მიჩნევა.

გამშვების შეცვლა ერთი ცვლადია და არა გამოსწორება

SSMS-ის სხვა რწმუნებით გაშვებამ შეიძლება განკურნოს განზრახ არასასურველი გამავალი იდენტობა, რაც პრობლემის რეალური კლასია. ეს არაფერს ამტკიცებს სამიზნე სახელზე, რეგისტრაციაზე ან ბილეთის გზაზე და არ ცვლის იმას, რაც სერვერმა მიიღო.

შეინარჩუნეთ შედარება კონტროლირებული: იგივე საბოლოო წერტილი, იგივე პროვაიდერი, ცნობილი შესრულების კონტექსტი, შემდეგ ახალი კავშირი, რომლის სქემასაც ამოწმებთ. ცალ-ცალკე დაადასტურეთ მიღებული შესვლა და მისი მონაცემთა ბაზის ნებართვები, რადგან წვდომა და ავთენტიფიკაცია სხვადასხვა მიზეზით ფარდება.

როცა Kerberos სავალდებულოა, ჩაწერეთ, რატომ დათმო პირველმა გზამ, გამოიყენეთ ერთი შესწორება და ხელახლა გაუშვით მოთხოვნა იმავე კლიენტიდან. წარმატებული მოთხოვნა გამშვების შეცვლის შემდეგ წვდომის მტკიცებულებაა და ჯერ არ არის მტკიცებულება იმისა, რომ ავთენტიფიკაციის მოთხოვნა შესრულდა.