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;

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