این خطای گذرواژه 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 باشد و حذف الزام گروه نمیتواند آن را ترمیم کند. اگر ورود اکنون به مرحله گروه میرسد، مشکل باقیمانده عضویت است، نه اعتبارنامه.
دادن حقوق گسترده دایرکتوری به حساب سرویس برای ناپدید شدن خطا سیاست دسترسی کل استقرار را تغییر میدهد. با آن بهعنوان یک تصمیم امنیتی با بازبینی مستقل خودش رفتار کنید، نه بهعنوان راهحلی برای پیامی که هنوز به هویتی نسبت ندادهاید.