VPN უკავშირდება, მაგრამ SQL Server Windows-ის ავთენტიფიკაციას უარყოფს

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

სიმპტომი: ხელმისაწვდომი სერვერი, უარყოფილი შესვლა

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

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

ორი იდენტობა, ერთი გვირაბი

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

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

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

წაიკითხეთ რეჟიმი, რომელიც კლიენტმა მოითხოვა

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

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

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

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

ჰკითხეთ სერვერს, რა დაინახა სინამდვილეში

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

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;

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

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

როცა იდენტობა ჩამოდის და Kerberos მაინც იშლება

თუ სერვერი ხედავს განზრახულ Windows-ის იდენტობას და ინტეგრირებული ავთენტიფიკაცია მაინც იშლება, პრობლემა თავად გაცვლაა. Kerberos-ს სჭირდება SQL-ის სერვისის ანგარიშისთვის რეგისტრირებული სერვისის ძირითადი სახელი (SPN) და კლიენტი, რომელიც სერვისს სთხოვს მასთან შესაბამისი სახელით. IP-მისამართით დაკავშირება ვერ დაემთხვევა სახელზე დაფუძნებულ SPN-ს, ხოლო ფსევდონიმი მხოლოდ მაშინ დაემთხვევა, თუ ისიც რეგისტრირებულია. ყველაფერზე ადრე შეამოწმეთ ის სახელი, რომელიც კლიენტმა აკრიფა, რადგან კავშირი, რომელიც ჰოსტის სახელით მუშაობს და IP-ით იშლება, ზუსტად ამ პრობლემას აღწერს.

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

მას შემდეგ, რაც ავთენტიფიკაცია მუშაობს, შესვლას მაინც სჭირდება მონაცემთა ბაზის მომხმარებელი და ნებართვები. წარმატებული VPN-შესვლა, წარმატებული Windows-შესვლა და კონკრეტული ცხრილის წაკითხვის ნებართვა სამი ცალკე შედეგია, და თითოეული იმსახურებს საკუთარ შემოწმებას სანამ ბილეთი დაიხურება.