VPN پر گروپ پالیسی غائب ہے؟ سرنگ سے پہلے دائرہ کار جانچیں

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

سرنگ سے نہیں، ترتیب سے شروع کریں

ایک متوقع GPO اور اُس میں ایک ٹھوس ترتیب لکھیں، پھر فیصلہ کریں کہ وہ ترتیب صارف ترتیب میں ہے یا کمپیوٹر ترتیب میں۔ یہ فرض کرتا ہے کہ منظور شدہ VPN پر ڈومین سے منسلک مجاز Windows کلائنٹ موجود ہے، نہ کہ کوئی غیر منظم یا صرف کلاؤڈ ڈیوائس جسے ڈومین ممبر بنایا جا رہا ہے۔ دائرہ کار کا جواب طے کرتا ہے کہ نتیجہ کون پڑھ سکتا ہے اور کیا اجازت بڑھانا ضروری ہے، اس لیے کچھ بھی چلانے سے پہلے یہ طے کریں۔

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

رپورٹ اُس اکاؤنٹ سے پڑھیں جس کی یہ ترتیب ہے

متاثرہ صارف کے اپنے سیشن میں whoami /user اور پھر gpresult /scope user /r چلائیں۔ جس اکاؤنٹ نے VPN کی تصدیق کی وہ خودبخود وہ Windows اکاؤنٹ نہیں جس کی پالیسی آپ پڑھ رہے ہیں، اور منتظم اکاؤنٹ سے کی گئی جانچ کسی دوسرے سوال کا جواب دیتی ہے۔ بنیادی حالت نئے فائل نام کے ساتھ محفوظ کریں، مثلاً %TEMP%\vpn-policy-user-before.html۔ gpresult کا حوالہ دائرہ کار اور آؤٹ پٹ کے سوئچ بیان کرتا ہے، اور یہ جاننا اچھا ہے کہ رپورٹ بنانے سے کچھ بھی ریفریش نہیں ہوتا۔

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

دریافت رسائی نہیں: پہلے SRV ریکارڈز، پھر SMB

منظور شدہ VPN منسلک ہونے پر تصدیق کریں کہ کلائنٹ ڈومین کنٹرولرز کو مطلوبہ DNS راستے سے حل کرتا ہے؛ لوڈ ہونے والی عوامی ویب سائٹ کنٹرولر کی دریافت کے بارے میں کچھ نہیں کہتی۔ مثال کے ڈومین corp.example کے لیے nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example اُس سوال کا جواب دیتا ہے جو واقعی آپ کے پاس ہے۔ واپس ملنے والا سروس ریکارڈ صرف دریافت کا ثبوت ہے، کیونکہ منتخب کنٹرولر کے پتے تک اب بھی مطلوبہ تصدیق اور اجازت شدہ ڈائریکٹری سروسز کے ساتھ پہنچنا ضروری ہے۔ پالیسی کا مواد پھر SYSVOL سے آتا ہے، جو اُسی مخصوص کنٹرولر کے خلاف SMB پڑھائی ہے اور ICMP ٹیسٹ نہیں۔

کمزور ثبوت کو ثبوت سمجھ لینا آسان ہے۔ کنٹرولر کی ICMP پاسخ، پالیسی ٹیمپلیٹ کی مسترد شدہ پڑھائی کے ساتھ، ایسی رپورٹ بناتی ہے جو کسی ایسی وجہ سے خالی دکھتی ہے جو ابھی کسی نے جوڑی نہیں۔

تعیناتی کی AD سروس اجازتیں، واپسی راستے اور وقت کی ہم آہنگی مربوط رکھیں، اُنہیں وسیع فائر وال کھولنے یا عوامی DNS سرور سے بدلنے کے بجائے۔ کنٹرولرز کے درمیان مختلف پالیسی ڈیٹا ڈائریکٹری کے مالک کے لیے نقل کا سوال ہے۔

ایک ریفریش، دو رپورٹیں، ایک موازنہ

راستہ ثابت ہونے کے بعد متعلقہ ریفریش gpupdate /target:user سے طلب کریں اور فرض کرنے کے بجائے نتیجہ پڑھیں۔ طے شدہ ریفریش بدلی ہوئی پالیسی لاگو کرتا ہے جبکہ /force دوبارہ لاگو کرنے کی درخواست کرتا ہے؛ دونوں میں سے کوئی DNS، فائل اجازتیں یا فلٹرنگ درست نہیں کرتا۔ کچھ ایکسٹینشن صرف بعد کے سائن اِن یا کسی اور پیش منظر واقعے پر مکمل ہوتے ہیں، اس لیے ایک بار چلانا فیصلہ نہیں ہے۔ دور دراز صارف کے سیشن میں لاگ آف یا ری اسٹارٹ سوئچ معمول کی تشخیص کے طور پر شامل کرنا اُس کا کھلا رکھا ہوا سب کچھ پھینک دیتا ہے۔

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

ناکامی کو ایک ہی سرگرمی سے باندھیں

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

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

HTML رپورٹیں نجی رکھیں، کیونکہ وہ اندرونی نام، گروپ رکنیت اور سیکیورٹی ترتیب ظاہر کرتی ہیں۔ ترتیب کی تصدیق کے بعد شامل کی گئی عارضی اجازتیں وہیں رکھنے کے بجائے ہٹا دیں۔