Сброс пароля пользователя — неверный первый шаг, когда журнал лишь сообщает, что 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 showsIdentity likely refusedFirst thing to check
Failure at start-up, no user yetService accountDN, password, expiry, lockout
Search returns nothingNone, the search scope is wrongSearch base and filter
Failure only for one userThat user's entryEntry 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, и удаление требования группы не может это исправить. Если вход теперь доходит до этапа группы, оставшаяся проблема — членство, а не учётные данные.

Выдача служебной учётной записи широких прав каталога, чтобы ошибка исчезла, меняет политику доступа всего развёртывания. Относитесь к этому как к решению по безопасности с собственным обзором, а не как к исправлению сообщения, которое вы ещё не привязали к учётной записи.

Похожие статьи