وہ LDAP پاس ورڈ کی خرابی شاید صارف کے پاس ورڈ کی نہ ہو
bind کی ناکامی سروس اکاؤنٹ یا تلاش کے دائرے سے آ سکتی ہے، صارف سے نہیں۔ کسی کا پاس ورڈ دوبارہ ترتیب دینے سے پہلے bind کو الگ کریں۔
جب لاگ صرف یہ کہے کہ bind مسترد ہوا تو صارف کا پاس ورڈ دوبارہ ترتیب دینا پہلا غلط قدم ہے۔ ڈائریکٹری پلگ ان کے ساتھ ایک ہی لاگ ان میں ایک سے زیادہ bind ہوتے ہیں، اور مسترد ہونا اس سروس اکاؤنٹ کا ہو سکتا ہے جو تلاش کرتا ہے۔ اس صورت میں صارف کی اسناد دوبارہ ترتیب دینے سے کچھ نہیں بدلتا۔ یہ اس شخص کو بھی باہر کر دیتا ہے جو کبھی مسئلہ نہیں تھا۔
ایک لاگ ان، کئی bind
مخصوص ڈائریکٹری اکاؤنٹ والی کنفیگریشن عام طور پر ترتیب سے چار مراحل کرتی ہے، اور ان میں سے کوئی بھی لاگ ان ختم کر سکتا ہے۔
connect to the directory and establish the configured TLS protection
bind as the configured service account
search for the user entry using the search base and filter
open a second connection and bind as that user, then evaluate groupsپلگ ان اپنا صارف کی توثیق کا کنکشن اسی مددگار کے ذریعے بناتا ہے جو پہلا کنکشن سنبھالتا ہے، اس لیے وہ مددگار کنیکٹ کرتے وقت، TLS گفتگو کے دوران یا سروس اکاؤنٹ کے طور پر bind کرتے وقت ناکام ہو سکتا ہے۔ پاس ورڈ کے بارے میں اعلیٰ سطح کا پیغام بعد میں بنتا ہے، اور اس میں یہ نہیں آتا کہ کون سی شناخت شامل تھی۔ اسی لیے صرف خرابی کا متن نہیں بتا سکتا کہ صارف مسترد ہوا یا سروس اکاؤنٹ۔
پیغام سے پہلے کی سطریں پڑھیں، اور ناکامی کا وقت نوٹ کریں۔ آغاز میں، کسی بھی صارف کے آنے سے پہلے مسترد ہونا کنفیگر شدہ اکاؤنٹ یا آخری نقطے کی طرف اشارہ کرتا ہے۔ کامیاب تلاش کے بعد صرف ایک شخص کے لیے ظاہر ہونے والا انکار اس شخص کے اندراج یا اکاؤنٹ کی حالت کی طرف اشارہ کرتا ہے۔
خرابی کو شناخت سے جوڑیں
عملی اصول یہ ہے کہ تین چیزیں ایک ساتھ درج کریں: کب ناکام ہوا، کون سا عمل چل رہا تھا اور کون سی شناخت پیش کی گئی۔ اس تین گانے کے بغیر، صرف آخری جملہ رکھنے والے لاگ میں دو بہت مختلف خرابیاں ایک جیسی دکھتی ہیں۔
| What the log shows | Identity likely refused | First thing to check |
|---|---|---|
| Failure at start-up, no user yet | Service account | DN, password, expiry, lockout |
| Search returns nothing | None, the search scope is wrong | Search base and filter |
| Failure only for one user | That user's entry | Entry state, bind DN, group rules |
اگر کنفیگر شدہ اکاؤنٹ ناکام ہو، تو کسی بھی صارف ریکارڈ کو چھونے سے پہلے اس اکاؤنٹ اور کنکشن کا معائنہ کریں۔ اگر کامیاب تلاش کے بعد صارف کا bind ناکام ہو، تو تلاش نے جو اندراج واپس کیا اس کا جائزہ لیں، نہ کہ اس کا جس کی آپ توقع کر رہے تھے۔ دونوں راستے صرف ایک پیغام میں شریک ہیں۔ لکھیں کہ آپ نے کسے خارج کیا، کیونکہ اگلا شخص بالکل یہی پوچھے گا۔
امتیازی نام معلومات ہے، اندازہ نہیں
نام کا کوئی جزو غیر مانوس لگنے کی وجہ سے بدلنا چلتی ہوئی کنفیگریشن توڑنے کا عام طریقہ ہے۔ Active Directory میں صارف اشیاء کی طے شدہ جگہ Users نامی کنٹینر ہے، اور کنٹینر مشابہ نام والی تنظیمی اکائی جیسی وہی قسم کی شے نہیں ہے۔
ڈائریکٹری منتظم سے اکاؤنٹ کا اصل امتیازی نام پوچھیں، یا اسے خود شے سے پڑھیں۔ نیچے دیے گئے دونوں اپنی اپنی ڈائریکٹری میں درست ہو سکتے ہیں، اسی لیے کسی کو بھی یاد سے ٹائپ نہیں کرنا چاہیے۔
CN=VPN Bind,CN=Users,DC=corp,DC=example
CN=VPN Bind,OU=Service Accounts,DC=corp,DC=exampleمنتقل کرنا یا نام بدلنا اس قدر کو بدلتا ہے جبکہ اکاؤنٹ اور پاس ورڈ درست رہتے ہیں، اس لیے پچھلی سہ ماہی میں چلنے والی کنفیگریشن اس بار ناکام ہو سکتی ہے، بغیر کسی کے اسناد کو چھونے کے۔ کسی بھی تنظیم نو کے بعد کنفیگر شدہ سٹرنگ کا ڈائریکٹری کی موجودہ خصوصیت سے موازنہ کریں۔ خاموش منتقلی کے بعد بھی کریں، صرف رپورٹ شدہ رکاوٹ کے بعد نہیں۔
تلاش کی بنیاد سروس اکاؤنٹ نہیں ہے
bind کی شناخت اور تلاش کی بنیاد مختلف سوالوں کے جواب دیتے ہیں: پلگ ان کس کے طور پر تصدیق کرتا ہے اور لوگوں کو کہاں تلاش کرتا ہے۔ کامیاب bind کے بعد کوئی مماثل صارف نہ ہونا دائرے، فلٹر یا پڑھنے کی اجازت کا مسئلہ ہے، اور اکاؤنٹ کا امتیازی نام صارفین کی بنیاد سے بدلنے سے اس میں کچھ نہیں بدلتا۔
تصدیق کریں کہ سروس نے آپ کی ترمیم شدہ کنفیگریشن لوڈ کی ہے اور اس کا آخری نقطہ، TLS اعتماد اور توثیق کا طریقہ کسی چلنے والے انتظامی امتحان سے میل کھاتا ہے۔ کسی دوسرے اکاؤنٹ کے ساتھ یا کسی دوسرے ڈومین کنٹرولر کے خلاف دستی تلاش مساوی تجربہ نہیں ہے۔
محفوظ راز کی جانچ کریں، اور جانچیں کہ اکاؤنٹ فعال، میعاد ختم یا مقفل ہے، پاس ورڈ کہیں چھاپے بغیر۔ میعاد ختم ہونا چھوٹ جانا آسان ہے کیونکہ اکاؤنٹ اس دن تک چلتا رہتا ہے جب وہ چلنا بند کر دیتا ہے۔ غیر متعلقہ سروس سے ورثے میں ملنے والا تالا بھی اتنا ہی خاموش ہوتا ہے۔ ان دونوں حالتوں میں سے کوئی بھی ایسا پیغام پیدا نہیں کرتی جو سروس اکاؤنٹ کا نام لے۔
گروپ کے قواعد آخر میں آتے ہیں
اجازت bind کامیاب ہونے کے بعد چلتی ہے، اس لیے گروپ کی جانچ bind کی ناکامی کا سبب نہیں ہو سکتی، اور گروپ کی شرط ہٹانا اسے ٹھیک نہیں کر سکتا۔ اگر لاگ ان اب گروپ مرحلے تک پہنچتا ہے، تو باقی مسئلہ رکنیت ہے، اسناد نہیں۔
خرابی کے غائب ہونے کے لیے سروس اکاؤنٹ کو وسیع ڈائریکٹری حقوق دینا پوری تعیناتی کی رسائی پالیسی بدل دیتا ہے۔ اسے اپنے جائزے والا سلامتی فیصلہ سمجھیں، نہ کہ ایسے پیغام کا حل جو آپ نے ابھی کسی شناخت سے منسوب نہیں کیا۔