VPN سرٹیفکیٹ LDAP حصے کی حفاظت نہیں کرتا

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

یہی عدم مساوات ایسے لاگ اِن کے پیچھے طریقہ کار ہے جو خفیہ دکھتا ہے اور پھر بھی bind پاس ورڈ کھلے طور پر بھیجتا ہے۔

دو کنکشن، اعتماد کے دو فیصلے

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

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

StartTLS اور LDAPS، سوچ سمجھ کر منتخب

StartTLS سادہ LDAP کے طور پر کھلتا ہے اور وہیں ترقی پاتا ہے، عام طور پر پورٹ 389 پر۔ LDAPS کنکشن کے ساتھ ہی TLS شروع کرتا ہے، عام طور پر 636 پر۔ دونوں جائز ہیں اور اڈاپٹر کو وہی کرنا چاہیے جو ڈائریکٹری پیش کرتی ہے۔ StartTLS کا تقاضا کرنا اسے آزمانے اور ترقی ناکام ہونے پر جاری رکھنے سے مختلف ہے، اور اسی فرق میں bind پاس ورڈ باہر نکل سکتا ہے۔ سخت موڈ ترتیب دیں اور پاس ورڈ bind کے لیے غیر محفوظ متبادل راستے کی اجازت نہ دیں۔

ldapsearch -H ldap://dc1.corp.example -ZZ -x -D "CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example" -W -b "DC=corp,DC=example" "(sAMAccountName=example-user)" dn

-ZZ اختیار ہی پوری بات ہے: استفسار ترقی کے بغیر خاموشی سے آگے بڑھنے کے بجائے ناکام ہو جاتا ہے۔ اس سطر کے نام اور اکاؤنٹس مثالیں ہیں۔ OpenLDAP TLS دستاویزات اس کے پیچھے کی ٹرسٹ ترتیبات کا احاطہ کرتی ہیں۔

LDAP کلائنٹ کون سا ٹرسٹ اسٹور پڑھتا ہے؟

OpenLDAP کلائنٹ لائبریری اپنی ٹرسٹ ترتیب پڑھتی ہے، چاہے سسٹم فائل سے ہو یا پلگ اِن مخصوص ترتیب سے۔ VPN کی CA ہدایت VPN ساتھیوں پر لاگو ہوتی ہے اور یہ ثبوت نہیں کہ LDAP لائبریری وہی فائل پڑھتی ہے۔ وہ ڈائریکٹری ہوسٹ نام استعمال کریں جسے سرٹیفکیٹ واقعی ڈھکتا ہے، نیز وہ جاری کنندہ سلسلہ جس پر لائبریری بھروسا کرتی ہے۔ Active Directory میں ڈسپلے نام سے اندازہ لگانے کے بجائے درست سرور توثیق کے استعمال کے ساتھ ڈائریکٹری سروس سرٹیفکیٹ تعینات کریں۔

ہر فیصل کنارہ منزل کو وہی شناخت پالیسی پوری کرنی چاہیے۔ جس ماحول میں بنیادی تصدیق شدہ ہو اور ثانوی نہ ہو، وہ فیصل کنارے کے بغیر ماحول سے بدتر ہے، کیونکہ کمزور راستہ صرف خلل کے دوران ہی معلوم ہوتا ہے۔

bind اکاؤنٹ الگ مسئلہ ہی رہتا ہے

ٹرانسپورٹ کی حفاظت bind اکاؤنٹ کی اجازت کو کما نہیں کرتی۔ ڈائریکٹری میں تلاش کا دائرہ، گروہی اجازت اور سروس اکاؤنٹ کے مراعات الگ فیصلے ہیں، اور TLS فعال ہونے کے بعد بھی وسیع bind اکاؤنٹ وسیع ہی رہتا ہے۔ انضمام کو درکار سب سے تنگ سروس اکاؤنٹ اور تلاش کی بنیاد استعمال کریں، اور اینڈ پوائنٹ، TLS موڈ، اعتماد کا مالک اور تجدید کا عمل VPN ترتیب کے ساتھ درج کریں۔

جب سرٹیفکیٹ میں عدم مطابقت ظاہر ہو تو درست سرٹیفکیٹ یا سلسلہ تعینات کریں۔ تصدیق بند کرنا نظر آنے والی عدم مطابقت کو نظر نہ آنے والی بنا دیتا ہے اور دوسرے اعتماد کے تعلق کو بغیر جانچے چھوڑ دیتا ہے۔

دو کنکشن، دو مالک، دو تجدید کی تاریخیں۔ دستاویزات میں انہیں الگ رکھنا ہی لاگ اِن کو ایماندار رکھتا ہے۔