VPN وصل می‌شود، اما SQL Server احراز هویت Windows را رد می‌کند

تونل‌ها بالا می‌آیند، سرورها به ping پاسخ می‌دهند و ورود به پایگاه داده هنوز با خطای احراز هویت شکست می‌خورد. این ترکیب روی پیوندهای VPN رایج است و به‌ندرت معنای خرابی شبکه را دارد، زیرا شنونده قابل دسترس و ورود پذیرفته‌شده دو نتیجه متفاوت‌اند. هویتی که دروازه را راضی کرده لزوماً همان هویتی نیست که کلاینت پایگاه داده ارائه می‌کند. فهمیدن اینکه کدام حساب رسیده، تمام کار است.

نشانه: سرور قابل دسترس، ورود رد شده

اتمام زمان به شما می‌گوید بسته هرگز به هیچ شنونده‌ای نرسیده. خطای احراز هویت می‌گوید شنونده پاسخ داده و اعتبارنامه را رد کرده. این دو پیام شما را به تیم‌های متفاوتی می‌فرستند و قاطی کردنشان یک روز را صرف قواعد فایروالی می‌کند که هرگز مشکل نبوده‌اند.

وقتی خطا شکست ورود است، از نگاه کردن به پورت‌ها دست بردارید. پرسش باقی‌مانده این است که کلاینت کدام هویت 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 به‌جای حدس، واقعیت‌های دیدنی می‌شوند. اتصالی که جایی که انتظار Kerberos داشتید NTLM گزارش می‌کند مشکل حل نام یا SPN است، نه مشکل گذرواژه.

شماره خطا بیشتر محدود می‌کند. وضعیت 5 معمولاً یعنی نام ورود اصلاً حل نشده، وضعیت 8 معمولاً یعنی گذرواژه مطابقت نداشته و وضعیت 11 یعنی اعتبارنامه پذیرفته شده اما دسترسی به سرور شکست خورده است. از مدیر وضعیت را بخواهید نه کل پیام را، چون خود پیام عامدانه مبهم است.

وقتی هویت می‌رسد و Kerberos هنوز شکست می‌خورد

اگر سرور هویت موردنظر Windows را می‌بیند و احراز هویت یکپارچه هنوز شکست می‌خورد، خود تبادل مشکل است. Kerberos به نام اصلی سرویس (SPN) ثبت‌شده برای حساب سرویس SQL و کلاینتی نیاز دارد که سرویس را با نامی منطبق با آن درخواست کند. اتصال با نشانی IP نمی‌تواند با SPN مبتنی بر نام مطابقت کند و یک نام مستعار فقط وقتی می‌تواند مطابقت کند که آن هم ثبت شده باشد. اول از همه نامی را که کلاینت تایپ کرده بررسی کنید، چون اتصالی که با نام میزبان کار می‌کند و با IP شکست می‌خورد دقیقاً همین مشکل را توصیف می‌کند.

از مدیر بخواهید هویت ثبت‌شده و حساب سرویس را بازبینی کند نه اینکه با آزمون و خطا SPNهای تکراری بسازد. ثبت‌های تکراری خرابی‌های متناوبی تولید می‌کنند که تشخیصشان از مشکل اصلی سخت‌تر است.

پس از اینکه احراز هویت کار کرد، ورود هنوز به کاربر پایگاه داده و مجوزها نیاز دارد. یک ورود موفق VPN، یک ورود موفق Windows و مجوز خواندن یک جدول مشخص سه نتیجه جداگانه‌اند و هر کدام پیش از بستن تیکت بررسی خودش را می‌خواهد.