چرا SQL Server از طریق VPN باز هم به NTLM بازمی‌گردد؟
Kerberos به نام سرویس درست، یک SPN روی حساب درست و بلیتی نیاز دارد که کلاینت بتواند بگیرد. پیش از تغییر هر چیزی auth_scheme را بخوانید.
اتصال شما کار می‌کند، ورود پذیرفته می‌شود و SQL Server از NTLM استفاده می‌کند در حالی که همه انتظار Kerberos داشتند. این نتیجه نقص VPN نیست، زیرا تونل تنها یک مسیر فراهم می‌کند؛ طرح‌واره را نامی تعیین کرد که کلاینت درخواست کرد، principal ثبت‌شده در دایرکتوری و بلیتی که کلاینت واقعاً توانست به دست آورد. سه شرط باید هم‌زمان برقرار باشند و خود نشست می‌گوید کدام‌یک عقب نشست. این را پیش از آنکه کسی نام اصلی سرویس را ویرایش کند بخوانید.
نشست نام طرح‌واره‌ای را می‌گوید که واقعاً گرفتید
طرح‌واره احراز هویت به یک اتصال تعلق دارد نه به سرور یا تونل، بنابراین بررسی باید درون نشستی اجرا شود که برای شما مهم است. پرس‌وجوی زیر را از همان کلاینت، ابزار و حسابی اجرا کنید که گزارش را تولید کردند و نام هدف و انتقال را کنار نتیجه یادداشت کنید.
SELECT session_id, auth_scheme, net_transport, client_net_address, login_name
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;سطری از یک پنجره محلی SSMS روی میزبان پایگاه داده اتصال کاملاً دیگری را توصیف می‌کند و به همین دلیل پرس‌وجو باید از سمت کلاینت اجرا شود. خروجی را با مهر زمان ذخیره کنید، زیرا نفر بعدی که آن را می‌خواند می‌پرسد چه زمانی گرفته شده است. وقتی چند برنامه یک نقطه پایانی را به اشتراک می‌گذارند، از هرکدام نمونه بگیرید، زیرا تفاوت منبع داده میان دو برنامه اغلب تمام ماجراست.
شرط اول: آیا نام با SPN مطابقت دارد؟
Kerberos یک سرویس نام‌دار را احراز هویت می‌کند، بنابراین کلاینت از دایرکتوری بلیتی برای یک principal مشخص می‌خواهد. برای ارائه‌دهنده TCP شکل مستند MSSQLSvc/ است که پس از آن نام میزبان کاملاً واجد شرایط و برای نمونه پیش‌فرض پورت می‌آید. نمونه نام‌دار MSSQLSvc/db01.corp.example:SQLPROD را ثبت می‌کند که در آن پسوند به‌جای شماره، نام نمونه است. دسترسی به شنونده از طریق یک نام مستعار، یک CNAME که جای دیگری حل می‌شود یا یک نشانی IP خالی نام درخواستی را تغییر می‌دهد و درخواستی که principal مطابق ندارد بلیتی برای بازگرداندن ندارد.
به همین دلیل یک برنامه در یک شبکه کار می‌کند و در شبکه دیگر عقب می‌نشیند: پاسخ DNS، یک رکورد نام مستعار یا یک ورودی hosts نامی را که کلاینت استفاده می‌کرد تغییر داد. پیش از دست زدن به ثبت، نام درخواستی را با آنچه دایرکتوری دارد مقایسه کنید.
شرط دوم: آیا SPN روی حساب درست است؟
SPN باید به حسابی تعلق داشته باشد که سرویس SQL را اجرا می‌کند، نه به حساب کلاینت و نه به‌طور تصادفی به یک شیء رایانه. SQL Server می‌تواند هنگام راه‌اندازی SPNهای خودش را ثبت کند اگر حساب سرویسش اجازه نوشتن آن‌ها را داشته باشد، که راحت است و همچنین توضیح می‌دهد چگونه پس از تغییر حساب سرویس یک نسخه تکراری پدیدار می‌شود.
دایرکتوری را برای نامی که انتظار دارید بپرسید، سپس فهرست کنید که حساب واقعاً چه چیزی دارد. اینکه کدام شیء ورودی را نگه می‌دارد مهم‌تر از آن است که نام جایی در جنگل وجود داشته باشد. عدم تطابق یعنی ورود هرگز مشکل نبوده است و راهنمای SPN مایکروسافت قالب‌ها و مواردی را مستند می‌کند که مدیر دامنه باید ورودی را ایجاد کند.
setspn -Q MSSQLSvc/db01.corp.example:1433
setspn -L CORP\svc-sql01افزودن یک ورودی دیگر آزمایش ایمنی نیست. یک نسخه تکراری یا ثبت متناقض می‌تواند کلاینت‌هایی را که کار می‌کردند بشکند، بنابراین مالکیت را پیش از تغییر بررسی کنید و پس از آن دوباره بازبینی کنید.
شرط سوم: آیا کلاینت اصلاً می‌تواند بلیت بگیرد؟
یک SPN درست بی‌فایده است اگر کلاینت نتواند به کنترل‌کننده دامنه برسد یا زمینه اعتبار قابل استفاده‌ای نداشته باشد. تبادل به KDC و DNS از طریق VPN نیاز دارد و تونلی که فقط پورت SQL را مسیریابی می‌کند دقیقاً در همین گام شکست می‌خورد. دسترس‌پذیری باید از همان ماشین و همان حساب آزمایش شود، نه از دیوار آتشی که جلوی آن‌هاست.
حافظه نهان بلیت را روی ماشین و زیر حسابی که برنامه را اجرا می‌کند بررسی کنید. فهرستی در سطح کل ماشین از یک پنجره ارتقایافته هیچ چیزی درباره سرویسی که به‌عنوان کاربر دیگری اجرا می‌شود نمی‌گوید و حافظه نهان خالی برای آن کاربر یک یافته است نه یک ناراحتی.
klist
klist -li 0x3e7سپس تصمیم بگیرید که عقب‌نشینی چه کاری می‌تواند بکند. اگر سیاست Kerberos را الزامی می‌کند، NTLM باید صریحاً رد شود، زیرا عقب‌نشینی خاموش یک خطای پیکربندی را به اتصال کارآمدی تبدیل می‌کند که الزام را نقض می‌کند. اگر NTLM برای برخی برنامه‌ها قابل قبول می‌ماند، آن‌ها را نام ببرید و دیگر هر نشست NTLM را حادثه ندانید.
تغییر راه‌انداز یک متغیر است، نه راه‌حل
اجرای SSMS با اعتبار دیگر می‌تواند هویت خروجی ناخواسته را درمان کند که یک کلاس واقعی از مشکل است. این هیچ چیزی درباره نام هدف، ثبت یا مسیر بلیت اثبات نمی‌کند و آنچه سرور پذیرفته است را تغییر نمی‌دهد.
مقایسه را کنترل‌شده نگه دارید: همان نقطه پایانی، همان ارائه‌دهنده، زمینه اجرای شناخته‌شده، سپس اتصال تازه‌ای که طرح‌واره‌اش را بررسی می‌کنید. ورود پذیرفته‌شده و مجوزهای پایگاه داده‌اش را جداگانه تأیید کنید، زیرا دسترسی و احراز هویت به دلایل متفاوتی شکست می‌خورند.
وقتی Kerberos الزامی است، ثبت کنید چرا مسیر اول عقب نشست، یک اصلاح اعمال کنید و پرس‌وجو را دوباره از همان کلاینت اجرا کنید. پرس‌وجوی موفق پس از تغییر راه‌انداز شاهدی بر دسترسی است و هنوز شاهدی بر برآورده شدن الزام احراز هویت نیست.