Windows EAP-TLS پر PIV لاگ اِن ناکام؟ دستخط کا راستہ جانچیں

PIV کارڈ کا سرٹیفکیٹ ہر Windows ڈائیلاگ میں دکھائیں اور VPN لاگ اِن پھر بھی ناکام ہو سکتا ہے، کیونکہ نظر آنا اور قابلِ استعمال ہونا مختلف خصوصیات ہیں۔ سرٹیفکیٹ ایک عوامی شے ہے؛ لاگ اِن کے لیے نجی کلید کی کارروائی درکار ہے جو کارڈ اپنے رسائی قواعد کے مطابق کرتا ہے۔ ان دو حقائق کے درمیان چار مراحل ہیں جو چار مختلف طریقوں سے ناکام ہوتے ہیں: پروفائل کا انتخاب، سرٹیفکیٹ کا انتخاب، مقامی دستخط اور سرور کی طرف توثیق۔ انہیں ترتیب سے طے کرنا ایک عام ہینڈ شیک خرابی کو اگلے حصے کے مالک کے لیے مخصوص سوال میں بدل دیتا ہے۔

پروفائل اور EAP طریقے سے شروع کریں

کنکشن کی خصوصیات کھولیں اور پڑھیں کہ پروفائل درحقیقت کون سا EAP طریقہ استعمال کرتا ہے، پھر پڑھیں کہ طریقہ کس سرٹیفکیٹ کو منتخب کرنے کے لیے ترتیب دیا گیا ہے۔ بہت سی تعیناتیوں میں سرٹیفکیٹ پر مبنی بیرونی طریقہ اور اندرونی طریقہ دونوں ہوتے ہیں، اور کنکشن کی سطح پر ترتیب دیا گیا سرٹیفکیٹ خود بخود وہ نہیں ہوتا جو EAP-TLS کے اندر پیش کیا جاتا ہے۔ اگر پروفائل سرٹیفکیٹ کو جاری کنندہ یا موضوع کے فلٹر کے مطابق چنتا ہے، تو وہ فلٹر متعلقہ اسٹور میں Windows جو دیکھ سکتا ہے اس میں سے چنتا ہے، نہ کہ کارڈ میں اتفاقاً جو موجود ہے اس میں سے۔ کسی سے نہ ملنے والا فلٹر پروفائل کی ترتیب کے مطابق کسی مطالبے یا خاموش ناکامی کی طرف جاتا ہے، اسی لیے کسی بھی تبدیلی سے پہلے منتخب فنگر پرنٹ درج کرنا مفید ہے۔

یہ بھی طے کریں کہ کنکشن لاگ اِن شدہ صارف کے طور پر چلتا ہے یا مشین کے طور پر۔ یہی ایک حقیقت طے کرتی ہے کہ کون سے سرٹیفکیٹ اسٹور دائرے میں ہیں اور کون سا سیکیورٹی سیاق دستخط کرتا ہے۔

تصدیق کریں کہ کون سا سرٹیفکیٹ منتخب ہوا

Windows نے جو فنگر پرنٹ چنا اس کا تقاضے سے موازنہ کریں: کلائنٹ توثیق کے لیے استعمال، قابلِ اعتماد جڑ پر ختم ہونے والی زنجیر، ایسی شناخت جسے توثیق سرور کی پالیسی نقش کرتی ہے، اور وہ مدتِ اعتبار جو کوشش کے حقیقی لمحے کو ڈھانپتی ہے۔ یہ الگ الگ جانچیں ہیں اور آخری والی لوگوں کی توقع سے زیادہ حیرتیں پکڑتی ہے، خاص طور پر رولنگ بنیاد پر جاری کیے گئے سرٹیفکیٹ اور کیش شدہ پروفائل کے ساتھ جو اب بھی کل کے انتخاب کی طرف اشارہ کرتے ہیں۔

صارف اور مشین کا سیاق جانچ کا دوسرا نصف ہے۔ صارف کے ذاتی اسٹور میں سرٹیفکیٹ مشین کے طور پر چلنے والی سروس کو نظر نہیں آتا، اور مشین کا سرٹیفکیٹ صارف موڈ EAP تبادلے کے ذریعے پیش نہیں ہوتا جب تک پروفائل ایسا نہ کہے۔ سرٹیفکیٹ کو غلط اسٹور میں دوبارہ درآمد کرنے سے نظر آنے والا سرٹیفکیٹ اور نظر نہ آنے والی لاگ اِن اسناد بنتی ہیں۔ پروفائل میں اسٹور کا راستہ پڑھیں، وہ نہیں جو اتفاقاً کھلنے والے ڈائیلاگ میں تھا۔

PIN کا اندازہ لگائے بغیر کلید کی کارروائی جانچیں

انتخاب طے ہونے کے بعد سوال یہ ہے کہ کارڈ دستخط کرے گا یا نہیں۔ Windows کو نجی کلید تک پہنچنے کے لیے معاون کارڈ فراہم کنندہ یا منی ڈرائیور درکار ہے، اور ڈیوائس کارروائی پر اپنے PIN اور موجودگی کے قواعد لاگو کرتا ہے۔ ہر دستخط کے لیے لمس کا تقاضا کرنے والا کارڈ سیشن کے لیے توثیق کیش کرنے والے کارڈ سے مختلف برتاؤ کرتا ہے، اور دونوں جائز ترتیبات ہیں جو بدلتی ہیں کہ مطالبہ کب ظاہر ہوتا ہے۔ یہی فرق اس لاگ اِن کی وضاحت کرتا ہے جو نئے اندراج پر کامیاب ہوتا ہے اور نیند سے واپسی کے بعد ناکام ہو جاتا ہے، بغیر کسی سرٹیفکیٹ کے غلط ہونے کے۔

certutil.exe -scinfo
certutil.exe -store -user My
Get-WinEvent -LogName Application -MaxEvents 40 | Where-Object ProviderName -like '*Ras*'

پہلا کمانڈ کارڈ کی فہرست بناتا ہے اور ریڈر و فراہم کنندہ کی حالت بتاتا ہے، جو Microsoft کی سمارٹ کارڈ ڈی بگ رہنمائی میں درج ہے۔ دوسرا بتاتا ہے کہ صارف کا سیاق درحقیقت کیا دیکھ سکتا ہے۔ کوئی بھی کامیاب توثیق ثابت نہیں کرتا؛ دونوں یہ تنگ کرتے ہیں کہ کہاں رکا۔

PIN کا اندازہ نہ لگائیں۔ کارڈز دوبارہ کوششوں کی حدیں نافذ کرتے ہیں، اور چند امید پرست کوششیں اجازت کے مسئلے کو ایسی مسدود اسناد میں بدل دیتی ہیں جن کے لیے انتظامی بحالی درکار ہوتی ہے۔ اگر مقامی دستخط ناکام ہوں تو مختلف صورتیں آزمانے کے بجائے فراہم کنندہ کی حالت اور کارڈ کی حالت درج کریں۔ وہی پروفائل، وہی سرٹیفکیٹ اور معلوم درست ریڈر راستے کے ساتھ کوشش ایک بار دہرائیں، پھر دونوں ریکارڈ کا موازنہ کریں؛ ایک وقت میں کئی متغیر بدلنا نتیجے کے بجائے ایک کہانی پیدا کرتا ہے۔

ہینڈ شیک کے دونوں پہلو پڑھیں

مکمل شدہ دستخط ابھی داخلہ نہیں۔ توثیق سرور کو زنجیر قبول کرنی چاہیے، منسوخی جانچنی چاہیے، اپنے موجودہ قواعد کے مطابق شناخت نقش کرنی چاہیے اور درخواست کی اجازت دینی چاہیے؛ کلائنٹ کو بدلے میں سرور کا سرٹیفکیٹ ویسے ہی تصدیق کرنا چاہیے جیسے پروفائل کا تقاضا ہے۔ سرور کی پیدا کردہ TLS انتباہ کلائنٹ کے لاگ میں مقامی طور پر پیدا ہونے والے جیسی نظر آتی ہے، اسی لیے جاری کرنے والا پہلو انتباہ کے متن سے زیادہ اہم ہے۔

Windows کے واقعات اور سرور کی طرف کے واقعات ہم آہنگ ٹائم اسٹیمپ کے ساتھ جمع کریں، پھر پہچانیں کہ پہلی ناکامی کس پہلو نے پیدا کی۔ RFC 5216 EAP-TLS میں ملکیت کے ثبوت کا مرحلہ بیان کرتا ہے، اور عام ہینڈ شیک انتباہ خود سے کوئی مقامی کلیدی سبب نہیں بتاتا۔ ٹائم اسٹیمپ کا موازنہ ہی دو لاگز کو ایک ترتیب بناتا ہے۔

رپورٹ میں حدود سیدھی رکھیں

رپورٹ کو چار مراحل کے طور پر لکھیں، ہر ایک کے لیے ایک فیصلہ: کون سا پروفائل اور سیاق چلا، Windows نے کون سا سرٹیفکیٹ چنا، کارڈ نے دستخط کیے یا نہیں، اور سرور نے کیا فیصلہ کیا۔ یہ ڈھانچہ اگلے قدم کو واضح کرتا ہے اور اس عام مرمت کو روکتا ہے جس میں کسی نامعلوم مرحلے سے گزرنے کے لیے توثیق بند کر دی جاتی ہے۔

عارضی موازنے کے طور پر سافٹ ویئر سرٹیفکیٹ ایک جائز انتظامی امتحان ہے، مگر یہ اسناد اور ضمانت کا ماڈل بدل دیتا ہے، اس لیے یہ خاموش پیداواری حل کے بجائے منظور شدہ تبدیلی میں آتا ہے۔ یہی نظم PIN کی کوششوں اور ناکام مرحلے کے معلوم ہونے سے پہلے اسناد دوبارہ جاری کرنے پر لاگو ہوتا ہے۔ یکساں طور پر ناکام ہونے والا متبادل کارڈ اس بات کا مہنگا ثبوت ہے کہ مسئلہ کبھی کارڈ پر نہیں تھا۔