Ця помилка пароля 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, а видалення вимоги групи не може це виправити. Якщо вхід тепер доходить до етапу групи, залишкова проблема — членство, а не облікові дані.
Надання службовому обліковому запису широких прав каталогу, щоб помилка зникла, змінює політику доступу всього розгортання. Ставтеся до цього як до рішення з безпеки з власним оглядом, а не як до виправлення повідомлення, яке ви ще не прив'язали до облікового запису.