OpenVPN میں LDAP تصدیق کام کرتی ہے مگر گروہ کی جانچ ناکام ہوتی ہے: کہاں دیکھیں

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

مسترد ہونے کو اجازت کا جواب سمجھیں

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

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

فیصلہ کریں کہ رکنیت فلٹر میں رہتی ہے یا گروہ بلاک میں

دو معاون شکلیں ہیں، اور انہیں ملانا ہی وہ راستہ ہے جس سے چلتی ترتیب چلنا بند کر دیتی ہے۔ پہلی رکنیت کو صارف آبجیکٹ پر صفت مانگ کر صارف کی تلاش میں دھکیلتی ہے؛ دوسری صارف کی تلاش کو ویسا ہی رہنے دیتی ہے اور پلگ ان کو بعد میں گروہ کا آبجیکٹ تلاش کرنے دیتی ہے۔ ہر تعیناتی کے لیے ایک چنیں اور لکھیں کہ کون سی چنی۔

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(&(sAMAccountName=%u)(memberOf=CN=VPN Access,OU=Groups,DC=example,DC=org))"
    RequireGroup false
</Authorization>

اس شکل میں فلٹر ہر چیز کا فیصلہ کرتا ہے، اس لیے RequireGroup کو false ہونا چاہیے، ورنہ پلگ ان ایسے گروہ آبجیکٹ کی تلاش میں جاتا ہے جس کا فلٹر نے کبھی ذکر نہیں کیا۔ فلٹر میں موجود صفت صارف آبجیکٹ پر ہونی چاہیے اور بھری ہونی چاہیے، جو گروہوں کے اندر اندر ہونے پر یقینی نہیں۔

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

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(sAMAccountName=%u)"
    RequireGroup true
    Group        "CN=VPN Access,OU=Groups,DC=example,DC=org"
</Authorization>

پوشیدہ جگہ مشترک ہے: سادہ رکنیت کا موازنہ اندر اندر کے گروہوں کو پھیلاتا نہیں، اس لیے جس اکاؤنٹ تک رسائی والدین گروہ کے ذریعے آتی ہے وہ ناکام ہوتا ہے جبکہ کنسول اب بھی رکنیت دکھاتا ہے۔ Active Directory گروہ پر member ظاہر کرتی ہے، دیگر اسکیمیں uniqueMember استعمال کرتی ہیں، اور غلط صفت کی طرف اشارہ کرنے پر خرابی کے بجائے خالی نتیجہ آتا ہے۔

ایسا آخری نقطہ چنیں جو گروہ کا آبجیکٹ رکھتا ہو

URL طے کرتا ہے کہ پلگ ان کس ڈائریکٹری سے پوچھتا ہے، اور 389 پورٹ پر ڈومین کنٹرولر صرف اپنے نام کے سیاق کا جواب دیتا ہے۔ 3268 پورٹ پر عالمی کیٹلاگ پورے جنگل کا جواب دیتی ہے، صرف پڑھنے کے لیے اور جزوی صفات کے مجموعے کے ساتھ۔ جب اکاؤنٹ ایک ڈومین میں ہوں اور VPN گروہ دوسرے میں، تو ایک ڈومین کا استفسار صارف کو ڈھونڈ کر بھی رکنیت سے محروم رہ سکتا ہے۔ یہی وہ صورت ہے جس میں URL کو کیٹلاگ پورٹ پر منتقل کرنا مسترد ہونا حل کرتا ہے، اور یہی وہ صورت بھی ہے جس میں لوگ حد سے زیادہ عمومی بناتے ہیں۔

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

اکاؤنٹ کی حالت اور تلاش کا دائرہ ان کے اپنے خانے میں رکھیں

غیر فعال کرنے کا جھنڈا فلٹر میں آتا ہے، گروہ کی جانچ میں نہیں۔ Active Directory میں یہ userAccountControl کا دوسرا بٹ ہے، اور اس شرط کے بغیر درست پاس ورڈ والا غیر فعال اکاؤنٹ تصدیق کرتا ہے اور پھر گروہ کے مرحلے پر ناکام ہوتا ہے، جو اجازت کی خرابی جیسا لگتا ہے۔ تلاش کا دائرہ بنیادی DN میں آتا ہے، کیونکہ ڈومین کی جڑ سے شروع کرنا سست ہے اور اس تنظیمی اکائی سے باہر کی اشیاء سے میل کھا سکتا ہے جسے آپ ڈھانپنا چاہتے تھے۔

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

تین اکاؤنٹس سے نتیجہ ثابت کریں

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

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

ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=alice)" memberOf
ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=bob)" userAccountControl

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