VPN کے ذریعے SQL Server اب بھی 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 لازم ہو تو درج کریں کہ پہلا راستہ کیوں پیچھے ہٹا، ایک اصلاح لگائیں اور اسی کلائنٹ سے استفسار دوبارہ چلائیں۔ لانچر بدلنے کے بعد کامیاب استفسار رسائی کا ثبوت ہے، اور یہ ابھی ثبوت نہیں کہ تصدیق کی شرط پوری ہوئی۔