کون ڈائل اِن کر سکتا ہے؟ VPN رسائی سے پہلے msNPAllowDialin کا جائزہ

پاس ورڈ درست ہے، اکاؤنٹ VPN گروپ میں ہے، اور پھر بھی رابطہ ایسے پیغام کے ساتھ مسترد ہو رہا ہے جس میں کسی پالیسی کا ذکر نہیں۔ جب یہ Windows ریموٹ رسائی سرور پر ہوتا ہے تو سب سے پہلے میں NPS قاعدہ نہیں دیکھتا، بلکہ Active Directory کی ایک خصوصیت دیکھتا ہوں جو کوئی نہیں کھولتا: msNPAllowDialin، یعنی Dial-in ٹیب کے پیچھے کی قدر۔ اس کی تین حالتیں ہیں، اور تیسری خاموشی سے فیصلہ کسی اور جگہ سونپ دیتی ہے۔ بیشتر اوقات کسی نے اسے دانستہ تبدیل نہیں کیا: اکاؤنٹ کسی سانچے سے نقل کیا گیا تھا، یا ایسی اسکرپٹ نے بنایا تھا جس نے برسوں پہلے واضح انکار لکھا اور پھر کبھی جائزہ نہیں لیا گیا۔

انکار پالیسی پڑھنے سے پہلے بھی ہو سکتا ہے

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

اُلٹی صورت بھی اتنی ہی الجھن والی ہے۔ جس اکاؤنٹ پر کبھی جھنڈا مقرر نہیں ہوا وہ کامیابی سے جڑ سکتا ہے کیونکہ پالیسی نے اجازت دی تھی، اور پھر وہی اکاؤنٹ جڑنا بند کر دیتا ہے جب کوئی غیر متعلق وجہ سے NPS قاعدہ میں تبدیلی کرتا ہے۔ ان دونوں واقعات میں سے کوئی بھی باہر سے ڈائل اِن اجازت کی تبدیلی جیسا نہیں لگتا۔

تین حالتیں، اور تیسری نظر نہیں آتی

TRUE ڈائل اِن کی اجازت دیتا ہے، FALSE اسے مسترد کرتا ہے، اور NULL قدر کا مطلب ہے کہ اکاؤنٹ اپنا جواب ریموٹ رسائی پالیسی یا NPS اجازت سے ورثے میں لیتا ہے۔ GUI اس تیسری حالت کو "Control access through NPS Network Policy" کے طور پر دکھاتا ہے، اور یہ فیصلے کی بجائے بغیر نشان زدہ چیک باکس جیسا پڑھا جاتا ہے۔

اسی لیے کنسول سے اجازت یافتہ صارفین گننے سے تقریباً کچھ معلوم نہیں ہوتا۔ ورثے میں ملا اکاؤنٹ اکاؤنٹ کو چھوئے بغیر آج اجازت یافتہ اور کل مسترد ہو سکتا ہے، اور FALSE اکاؤنٹ ایسے سرور پر بھی جڑ سکتا ہے جس کی پالیسی صارف کی ڈائل اِن خصوصیات کو نظر انداز کرنے پر مقرر ہے۔ خصوصیت اور پالیسی ساتھ پڑھیں، ورنہ آپ آدھے فیصلے کا جائزہ لے رہے ہیں۔

ورثے میں ملے اکاؤنٹس کھوئے بغیر جھنڈیاں برآمد کریں

برآمد ڈومین کنٹرولر سے، یا Active Directory ماڈیول والے ورک سٹیشن سے چلائیں، اور خلاصہ دوبارہ لکھنے کی بجائے خام فائل بطور ثبوت رکھیں:

Get-ADUser -Filter * -Properties msNPAllowDialin, LastLogonDate |
  Select-Object SamAccountName, Enabled, msNPAllowDialin, LastLogonDate |
  Sort-Object SamAccountName |
  Export-Csv -NoTypeInformation .\dialin.csv

ایک ہی LDAP فلٹر تبدیلی کے ریکارڈ میں چپکانا آسان ہے۔ یہ صرف واضح اجازتیں واپس کرتا ہے:

dsquery * -Filter "(&(objectCategory=person)(objectClass=user)(msNPAllowDialin=TRUE))" -Attr sAMAccountName

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

جھنڈے کو گروپ رسائی اور اکاؤنٹ کی صحت سے الگ کریں

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

آپ جن چیزوں پر عمل کرتے ہیں وہی امتزاج ہیں۔ غیر فعال اکاؤنٹ TRUE کے ساتھ محض شور ہے۔ فعال اکاؤنٹ TRUE کے ساتھ ایک سال لاگ اِن نہ ہوا ہو تو وہ ہٹانے کا امیدوار ہے۔ لیکن VPN گروپ میں ورثے والا اکاؤنٹ جس کی کوئی وضاحت نہ کر سکے وہی اصل اہم دریافت ہے، کیونکہ کوئی ایک ترتیب یہ درج نہیں کرتی کہ وہ کیوں دیا گیا۔

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

ایک اکاؤنٹ تبدیل کریں اور ثابت کریں کہ تبدیلی پہنچ گئی

رسائی ہٹانے کے لیے خصوصیت کو FALSE پر مقرر کریں، اسے صاف کرنے کی بجائے۔ صاف کرنا اکاؤنٹ کو پالیسی وراثت میں واپس لاتا ہے، جو اگلی بار جڑنے پر اسے دوبارہ اجازت دے سکتا ہے، اور تبدیلی اصلاح جیسی لگتی ہے جبکہ درحقیقت یہ مختلف فیصلہ ہے:

dsmod user "CN=Jane Doe,OU=Staff,DC=corp,DC=example" -allowDialin no
Set-ADUser -Identity jdoe -Clear msNPAllowDialin

دوسری سطر وراثت کی ری سیٹ ہے، جان بوجھ کر الگ رکھی گئی تاکہ کوئی دونوں کارروائیوں کو نہ ملائے۔ پھر دوسرے سیشن سے تصدیق کریں، خصوصیت دوبارہ پڑھیں، اور کنسول کی تازہ کاری پر بھروسہ کرنے کی بجائے انکار کے لیے NPS اکاؤنٹنگ واقعات دیکھیں۔

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

جائزے سے بچنے والا نتیجہ مختصر ہے: کون جڑ سکتا ہے، کس طریقہ کار سے، کب جائزہ لیا گیا، کس نے۔ ڈائل اِن جھنڈا پہلے دو جواب دیتا ہے؛ باقی صرف پالیسی کے جائزے سے ملتا ہے۔