NetExtender لاگ اِن کرتا ہے مگر رسائی نہیں: SonicWall مقامی + LDAP
NetExtender جڑتا ہے مگر کوئی جواب نہیں دیتا: SonicWall کی تصدیق، SSL VPN سروس کی رکنیت اور مقامی و LDAP صارفین کے لیے VPN رسائی کی اجازتیں الگ الگ دیکھیں۔
لاگ اِن کامیاب ہوتا ہے، ٹنل قائم ہوتا ہے اور فائر وال کے پیچھے کوئی چیز جواب نہیں دیتی۔ SonicWall SSL VPN پر یہ انداز عام طور پر بتاتا ہے کہ اکاؤنٹ تصدیق سے گزر گیا اور بعد کی دو اجازتوں میں سے ایک پر رک گیا: SSL VPN سروس میں قبولیت، یا کسی وسیلے تک پہنچنے کی اجازت۔ مقامی اور LDAP اکاؤنٹس مخلوط ہوں تو صورتحال بگڑ جاتی ہے، کیونکہ دونوں ذخیرے ان اجازتوں تک مختلف راستوں سے پہنچتے ہیں۔ کلائنٹ کی طرف علامت یکساں ہوتی ہے، اسی لیے تہوں کو سوچے سمجھے طور پر الگ کرنا ہوتا ہے۔
علامت اور اس کے پیچھے تین اجازتیں
صارف نام اور قابلِ رسائی سرور کے درمیان تین آزاد فیصلے ہوتے ہیں۔ تصدیق کا طریقہ طے کرتا ہے کہ اسناد قبول ہوتی ہیں یا نہیں اور کون سا ذخیرہ قبول کرتا ہے۔ SSL VPN سروس کی رکنیت طے کرتی ہے کہ یہ شناخت SSL VPN استعمال کر سکتی ہے یا نہیں۔ VPN رسائی کی فہرست طے کرتی ہے کہ سیشن کن نجی منزلوں تک پہنچ سکتا ہے۔ ایک سے گزرنا اگلی دو کے بارے میں کچھ نہیں کہتا۔
جو صارف تصدیق سے گزرتا ہے مگر SSL VPN سروس کے گروپ میں نہیں، وہ ایسا کنکشن دیکھتا ہے جو قائم ہوتا ہے اور پھر کچھ نہیں لے جاتا، اور فائر وال کا لاگ ناکامی کے بجائے قبول شدہ لاگ اِن دکھاتا ہے۔ یہی وہ صورت ہے جسے جلدی پہچاننا چاہیے، کیونکہ حل گروپ کی رکنیت ہے، پاس ورڈ کی ری سیٹ نہیں۔
جو صارف قبول ہوتا ہے مگر اس کے پاس وسائل نہیں، وہ ایسا سیشن دیکھتا ہے جو جڑتا ہے اور کسی مفید جگہ کی طرف راستہ نہیں بناتا۔ ہیلپ ڈیسک کی نظر میں دونوں ٹوٹی ہوئی ٹنل جیسے لگتے ہیں، اور دونوں کنیکٹیویٹی نہیں بلکہ کنفیگریشن کا مسئلہ ہیں۔
ڈومین کا خانہ ڈائریکٹری نہیں ہے
NetExtender ڈومین مانگتا ہے، اور وہ خانہ Active Directory کی تلاش کی بنیاد نہیں ہے۔ طے شدہ ترتیب میں خانہ اُس SSL VPN صارف ڈومین کے برابر ہونا چاہیے جو فائر وال نے ترتیب دیا ہو، اور اُس کے لیے دستاویزی طے شدہ قدر ہے LocalDomain۔ موازنہ حروفِ تہجی کے بڑے اور چھوٹے ہونے کا حساس ہے، اس لیے مختلف حروف کے ساتھ لکھی گئی قدر اکاؤنٹ درست ہونے پر بھی ناکام ہوتی ہے۔
جب تصدیق کی تقسیم ترتیب دی گئی ہو تو تقسیم کے نام بیرونی تصدیقی سیاق منتخب کرتے ہیں، اور ترتیب شدہ طے شدہ قدر اپنا کردار برقرار رکھتی ہے۔ دونوں ترتیبوں میں کلائنٹ کی طرف کا ڈومین لیبل صارف نام کے حصے کے طور پر LDAP یا RADIUS کو نہیں بھیجا جاتا، اس لیے یہ ڈائریکٹری کی تلاش کی رہنمائی نہیں کر سکتا۔
تینوں رشتے اپنے نوٹس میں الگ رکھیں: کمپنی کا DNS لاحقہ، LDAP تلاش کی بنیاد اور NetExtender کا ڈومین لیبل۔ یہ ایک جیسے لگتے ہیں اور کوئی ایک دوسرے کی جگہ نہیں لیتا۔ اس انسٹالیشن کے لیے آپریٹر کی قدر نقل کریں، کسی اور فرم ویئر ریلیز کے بارے میں فورم کی پوسٹ سے قدر نہیں۔
قبولیت اور وسیلے تک رسائی الگ اجازتیں ہیں
مقامی اکاؤنٹس کو سروس کی قبولیت سے پہلے SSL VPN سروس کے گروپ میں رکنیت درکار ہوتی ہے۔ ڈائریکٹری کے اکاؤنٹس اسی گروپ تک معاون گروپ میپنگ ورک فلو کے ذریعے پہنچتے ہیں، یعنی LDAP گروپ کا تعلق ترتیب دینا ہوتا ہے اور پھر اسے ڈائریکٹری کی طرف سے فرض کرنے کے بجائے مؤثر رکنیت کے طور پر جانچنا ہوتا ہے۔
وسیلے تک رسائی اس کے بعد آتی ہے، صارف یا گروپ پر VPN رسائی کے تحت۔ صرف وہی مخصوص سب نیٹ اور سروسز دیں جن کی کردار کو ضرورت ہو، اور ایک ایپلیکیشن کی ضرورت کی بنا پر پورا LAN دینے کی شارٹ کٹ سے بچیں۔ سیشن کے راستے، رسائی کے قواعد اور منزل کی سروس کی اجازتیں سب اس دائرے سے ہم آہنگ ہونی چاہئیں۔
| Layer | What it decides | Where it is set |
|---|---|---|
| Authentication | Whether the credential is accepted, and by which store | Authentication method and directory configuration |
| Admission | Whether the identity may use the SSL VPN | SSL VPN service group membership |
| Resource | Which destinations the session may reach | VPN Access on the user or group |
کلائنٹ پر راستہ منزل کو قابلِ انتخاب بناتا ہے اور اسے اجازت نہیں دیتا۔ SSL VPN گروپ کی رکنیت بھی اکاؤنٹ کو فائر وال کا منتظم نہیں بناتی، اور اسے عمومی اختیار دینے کے طور پر نہیں سمجھنا چاہیے۔
دو شناختیں، ہر ایک کے چار معائنے
ایک مقامی اکاؤنٹ اور ایک ڈائریکٹری اکاؤنٹ کے ساتھ جانچیں، دونوں کو محدود اختیار دیں اور دونوں کو ٹیسٹ اکاؤنٹ کے طور پر دستاویز کریں۔ ہر ایک کے لیے وہ تصدیقی ذریعہ لکھیں جس نے لاگ اِن قبول کیا، مؤثر گروپس، مختص کردہ وسیلہ رسائی اور ایک مجاز ایپلیکیشن عمل۔ چار معائنے، دو ذخیرے اور ہر امتزاج کے لیے تحریری نتیجہ۔
پھر منفی صورتیں آزمائیں: وہ وسیلہ جس تک اکاؤنٹ نہیں پہنچنا چاہیے، اور وہ اکاؤنٹ جسے فوراً مسترد کرنا چاہیے۔ صرف مثبت راستہ ثابت کرنے والا ڈیزائن عموماً دوسرا دروازہ کھلا چھوڑ دیتا ہے، خاص طور پر جب وہی مختصر صارف نام دونوں ذخیروں میں موجود ہو۔ ڈائریکٹری اکاؤنٹ غیر فعال کریں اور تصدیق کریں کہ مقامی اکاؤنٹ خاموشی سے کام جاری نہیں رکھتا۔
مکرر ناموں کا جائزہ تعیناتی کے حصے کے طور پر لیں، کسی واقعے کے بعد نہیں۔ ایک ہی شخص کا دو ذخیروں میں ہونا بیک وقت سپورٹ کی سہولت اور آڈٹ کا مسئلہ ہے، اور فائر وال خوشی سے اُسے تصدیق کرے گا جسے آپ نے ترتیب دیا۔
بازیابی کا راستہ تنگ رکھیں
مقامی اکاؤنٹس کو مستثنیٰ کرنے کے بجائے ہر اکاؤنٹ طبقے کے لیے MFA پالیسی برقرار رکھیں۔ اگر مقامی اکاؤنٹس ڈائریکٹری کی خرابی کے لیے منظور شدہ بازیابی راستہ فراہم کرتے ہیں تو اس راستے کو نامزد منتظمین تک محدود کریں اور سوچے سمجھے طور پر چلائیں، کیونکہ ہر ملازم کے لیے مقامی ہنگامی اکاؤنٹ کمزور نگرانی والا دوسرا تصدیقی نظام ہے۔
کلائنٹ کا ڈومین، تصدیقی ذریعہ اور مؤثر رسائی ایک ہی ریکارڈ میں لکھیں۔ اگلا منتظم پھر کام کرنے والا مخلوط اکاؤنٹ ڈیزائن دوبارہ بنا سکتا ہے، بجائے اس کے کہ لاگ اِن کامیاب ہونے تک ڈومین کے رشتے آزماتا رہے۔