Ошибка аутентификации LDAP: как проверить LDAP, Active Directory и другие каталоги

Ошибка аутентификации LDAP не всегда означает неверный пароль. Сбой может возникнуть раньше, на этапе DNS, TCP-подключения, TLS, LDAP bind или поиска записи пользователя. В Active Directory к этой цепочке добавляются доменные DNS-записи, Kerberos, синхронизация времени и формат имени учетной записи.

Проверяйте систему в таком порядке: доступность LDAP-сервера и порта, защищенный канал, bind служебной учетной записи, поиск пользователя по base DN и фильтру, проверка пароля, чтение групп и правила доступа приложения. Переходите к следующему шагу только после успешного результата предыдущего.

До начала диагностики зафиксируйте адрес сервера, порт, режим LDAP, LDAPS или StartTLS, base DN, bind DN, фильтр пользователя, атрибут логина и фрагмент лога без паролей и секретов. Для быстрой сверки команд пригодится шпаргалка по диагностике LDAP-аутентификации.

Ошибка аутентификации LDAP: что проверить в первые 10 минут

Начните с короткой последовательности, которая отделяет сетевую проблему от ошибки учетных данных:

1. Проверьте разрешение имени LDAP-сервера и маршрут с узла, где работает приложение.
2. Проверьте TCP-порт 389 для LDAP или StartTLS и порт 636 для LDAPS.
3. Проверьте TLS handshake, имя сервера в сертификате, цепочку доверия и срок действия сертификата.
4. Выполните bind служебной учетной записью с точным DN и запросом пароля без записи секрета в командной строке.
5. Выполните поиск тестового пользователя по правильному base DN и фильтру.
6. Проверьте пароль пользователя, формат имени и состояние учетной записи.
7. Проверьте группы, вложенное членство и сопоставление ролей в приложении.

Если приложение сразу показывает общую ошибку аутентификации, не меняйте пароль первым действием. Сначала установите этап сбоя по симптому и повторите операцию вне интерфейса приложения.

Как определить этап сбоя по симптому

Сообщение invalidCredentials может относиться к bind служебной учетной записи, а не к паролю пользователя. Приложение часто выполняет несколько операций подряд, но показывает единый текст ошибки.

Минимальный набор проверок перед изменением конфигурации

• Сохраните текущую конфигурацию приложения и значение каждого параметра LDAP.
• Запишите версии приложения, LDAP-сервера, Active Directory или другого каталога, а также образа контейнера, если сервис работает в Docker или Kubernetes.
• Выберите тестовую учетную запись с известным состоянием, сроком действия и членством в группах.
• Определите точный узел, где запускается приложение. Проверка с ноутбука администратора не заменяет проверку из контейнера или с сервера приложения.
• Подготовьте отдельный фрагмент лога с временной меткой и идентификатором запроса. Удалите пароли, токены, cookies и полные ответы каталога.

Меняйте один параметр за раз и записывайте результат. Иначе после исправления будет трудно понять, какая настройка устранила проблему и не появились ли побочные эффекты.

Как проверить LDAP-сервер и соединение

Проверка соединения отвечает на вопрос, может ли клиент установить сетевой канал с нужным сервером. Она не подтверждает bind, права или корректность поиска пользователя.

DNS, имя хоста и доступность контроллера

Выполняйте команды на том же узле, где запущено приложение. Сначала проверьте имя, затем адрес и маршрут:

dig +short ldap.example.org A
dig +short ldap.example.org AAAA
getent hosts ldap.example.org
ip route get 10.20.30.40
ping -c 2 ldap.example.org

ping подходит только как вспомогательная проверка. ICMP может быть запрещен, хотя TCP-порт доступен. Отсутствие ответа на ping не доказывает неисправность LDAP.

Для Active Directory проверьте SRV-записи, по которым клиент находит контроллер домена и KDC:

dig +short SRV _ldap._tcp.dc._msdcs.example.org
dig +short SRV _kerberos._tcp.example.org
nslookup -type=SRV _ldap._tcp.dc._msdcs.example.org

Клиент домена должен использовать корпоративный DNS. Публичный резолвер может вернуть адреса веб-сервисов, но не знает внутренние SRV-записи Active Directory. Подключение к контроллеру по случайному IP ухудшает обнаружение сервиса и может нарушить Kerberos.

Проверка LDAP-портов 389 и 636

Проверьте оба порта отдельно, если конфигурация допускает разные режимы:

nc -vz -w 3 ldap.example.org 389
nc -vz -w 3 ldap.example.org 636

• succeeded или open означает, что TCP-соединение установлено.
• connection refused обычно указывает на закрытую службу, неправильный порт или активный отказ firewall.
• timeout указывает на фильтрацию трафика, проблему маршрутизации, неверный адрес или недоступный контроллер.

Открытый порт не подтверждает корректность TLS, bind и поиска. После успешного nc продолжайте проверку протоколом LDAP.

LDAP и LDAPS: какой режим фактически используется

LDAP на порту 389 начинает работу без шифрования. На этом же порту клиент может выполнить StartTLS и затем продолжить обмен внутри защищенного канала. LDAPS использует отдельное TLS-соединение на порту 636 с самого начала.

Замена порта без смены схемы подключения часто создает новый сбой. Например, указание ldaps:// на порту 389 не превращает обычный LDAP в StartTLS. Проверьте фактический handshake:

openssl s_client -connect ldap.example.org:636 -servername ldap.example.org -showcerts -verify_return_error </dev/null

Для StartTLS выполните LDAP-запрос с явным параметром -ZZ:

ldapsearch -x -H ldap://ldap.example.org:389 -ZZ -D 'uid=svc-app,ou=service,dc=example,dc=org' -W -b 'dc=example,dc=org' -s base '(objectClass=*)' dn

Параметр -W запрашивает пароль интерактивно. Это безопаснее, чем передавать секрет через -w, где пароль может попасть в историю shell или список процессов.

LDAP bind ошибка: проверка DN, пароля и прав

Bind устанавливает контекст доступа к каталогу. Клиент может использовать анонимный bind, simple bind с DN и паролем или bind отдельной служебной учетной записью. Если bind не прошел, поиск пользователя и проверка групп не дадут достоверного результата.

Проверка полного bind DN

Полный Distinguished Name описывает путь к объекту в каталоге. Для OpenLDAP пример может выглядеть так:

uid=svc-app,ou=service,dc=example,dc=org

В Active Directory DN обычно содержит CN и OU:

CN=svc-app,OU=Service Accounts,DC=example,DC=org

Проверьте каждую часть DN, включая вложенные OU и написание атрибутов. Короткое имя svc-app не всегда заменяет полный bind DN. В Active Directory simple bind может принимать UPN, например svc-app@example.org, но это зависит от клиента и политики каталога.

Повторите bind отдельно от приложения:

ldapwhoami -x -H ldaps://ldap.example.org:636 -D 'uid=svc-app,ou=service,dc=example,dc=org' -W

Успешный ответ подтверждает соединение, TLS и проверку служебной учетной записи. Он не подтверждает правильность base DN, фильтра пользователя или групп.

Пароль и ограничения политики каталога

Проверьте пароль тестовой служебной учетной записи напрямую. Убедитесь, что в нем нет случайного пробела в начале или конце, а оболочка не изменила специальные символы. Не вставляйте пароль в команду, тикет или конфигурацию, которую читают другие пользователи.

В Active Directory проверьте состояние учетной записи: блокировку, отключение, истекший пароль, запрет интерактивного или сетевого входа и требования доменной политики. Для OpenLDAP проверьте атрибуты блокировки, срок действия пароля и правила ACL, если их использует конкретная схема.

Код invalidCredentials может появиться из-за неверного bind DN, UPN, домена или запрещенного способа аутентификации. Пароль пользователя проверяйте после успешного bind служебной записи и успешного поиска самого пользователя.

Права доступа LDAP пользователя

Разделите права по операциям:

• bind, вход в каталог под учетной записью;
• поиск объектов в нужной ветке;
• чтение атрибутов пользователей;
• чтение групп и атрибутов членства;
• изменение или создание объектов, если приложение действительно выполняет такие операции.

Для обычной аутентификации служебной записи обычно достаточно чтения нужных OU и атрибутов. Проверьте ACL на каждом уровне дерева: запрет на родительской OU может перекрыть разрешение на дочернем объекте.

Успешный bind с последующим insufficientAccessRights означает, что пароль служебной записи принят, но каталог запретил следующую операцию. Проверьте, не запрашивает ли приложение атрибут, закрытый политикой, и не пытается ли оно выполнять запись вместо чтения. В конфигурациях OpenSearch ошибки в DN, TLS и фильтрах часто смешиваются, поэтому для них полезен отдельный разбор LDAP-параметров и диагностическая таблица.

Поиск пользователя: base DN, фильтр и атрибут логина

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

Как выбрать правильный base DN

Base DN задает корень поиска. Если тестовый пользователь имеет DN uid=ivan,ou=people,dc=example,dc=org, base DN ou=admins,dc=example,dc=org его не охватит.

Проверьте поиск с явным base DN:

ldapsearch -x -H ldap://ldap.example.org:389 -D 'uid=svc-app,ou=service,dc=example,dc=org' -W -b 'ou=people,dc=example,dc=org' -s sub '(uid=test.user)' dn uid mail

Ошибка No such object часто означает, что сам base DN не существует или недоступен. Пустой результат при успешном ответе LDAP чаще связан с фильтром, областью поиска или атрибутом.

В Active Directory base DN часто совпадает с доменным корнем, например DC=example,DC=org. Поиск во вложенных OU зависит от области sub и прав служебной учетной записи.

LDAP-фильтр и атрибут имени пользователя

Атрибут логина должен соответствовать схеме конкретного каталога. В OpenLDAP часто используют uid или mail. В Active Directory применяют sAMAccountName или userPrincipalName.

Пример фильтра для OpenLDAP:

(&(objectClass=person)(uid=test.user))

Пример фильтра для Active Directory:

(&(objectCategory=person)(objectClass=user)(sAMAccountName=test.user))

Проверьте скобки, подстановочную переменную и экранирование специальных символов LDAP-фильтра. Символы *, (, ), обратная косая черта и нулевой байт требуют корректной обработки. Пользовательский ввод нельзя вставлять в фильтр без экранирования.

Условие активности учетной записи добавляйте только после базового теста. Сначала убедитесь, что фильтр находит тестового пользователя без дополнительных условий, затем добавляйте проверки отключенной учетной записи, срока действия или требований конкретной схемы.

Дублирующиеся записи и неоднозначный результат

Корректный запрос для логина должен возвращать ровно одну запись. Если поиск по mail или короткому имени вернул несколько объектов в разных OU, приложение может выбрать первый результат, завершить вход ошибкой или связать пароль с неверным DN.

Проверьте число результатов и полные DN:

ldapsearch -x -H ldap://ldap.example.org:389 -D 'uid=svc-app,ou=service,dc=example,dc=org' -W -b 'dc=example,dc=org' -s sub '(&(objectClass=person)(mail=test.user@example.org))' dn uid mail

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

Проверка групп и сопоставления ролей

Аутентификация подтверждает учетные данные. Авторизация решает, разрешен ли пользователю вход в конкретное приложение и какие действия ему доступны.

Проверьте:

• DN групп, которые приложение считает разрешенными;
• атрибут членства, например memberOf или member;
• вложенные группы и глубину их обработки;
• регулярные выражения и регистр в правилах маппинга;
• соответствие имени группы и роли приложения.

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

Ошибка входа через Active Directory: DNS, Kerberos и формат имени

Active Directory использует LDAP для работы с каталогом, но доменная аутентификация и SSO могут обращаться к Kerberos. Успешный LDAP bind не доказывает, что Kerberos получает билеты и что приложение правильно находит сервис.

Проверка домена и SRV-записей Active Directory

Проверьте записи служб домена:

dig +short SRV _ldap._tcp.dc._msdcs.example.org
dig +short SRV _kerberos._tcp.example.org
dig +short SRV _kerberos._udp.example.org

В ответе должны присутствовать контроллеры домена с приоритетом и портом. Сверьте FQDN контроллера с именем, которое указано в конфигурации. Если приложение обращается к имени, отсутствующему в DNS или сертификате, LDAP и TLS могут вести себя по-разному.

Клиент должен получать DNS-ответы от корпоративных серверов. Проверьте содержимое /etc/resolv.conf, настройки NetworkManager или DNS внутри пода Kubernetes. Случайная подмена DNS часто ломает обнаружение контроллера при внешне исправном IP-соединении.

Kerberos, время и SPN

Kerberos зависит от времени, realm, KDC и имени сервиса. Проверьте состояние часов:

timedatectl status
kinit user@EXAMPLE.ORG
klist

kinit должен получить билет без ошибки KDC или realm. klist покажет срок действия билета и его область. Расхождение времени сверх допустимого значения политики приводит к отказу в предварительной или взаимной аутентификации.

SPN связывает имя сетевого сервиса с учетной записью, которая его обслуживает. Если приложение обращается к сервису по имени, отличающемуся от зарегистрированного SPN, билет может не выдаваться или не приниматься. Для проверки на стороне администратора Active Directory можно использовать команду:

setspn -Q HTTP/app.example.org

Замените префикс сервиса на фактический, например HTTP, HOST или другой тип, который использует приложение.

UPN, доменный логин и sAMAccountName

Одна учетная запись может встречаться в нескольких форматах:

• user@example.org, UPN;
• EXAMPLE\user, доменное имя в формате NetBIOS;
• user, значение sAMAccountName.

Клиент может ожидать один формат для bind и другой атрибут для поиска. Проверьте документацию конкретного приложения и сопоставьте вводимый логин с реальными атрибутами записи. UPN из одного домена не заменяет UPN из другого домена или леса.

LDAP или Kerberos: что именно проверяет приложение

Определите механизм по конфигурации, логам и сетевым обращениям. Для LDAP ищите bind на 389 или 636 и операции поиска. Для Kerberos ищите обращения к KDC, получение билета, realm и SPN.

Не пытайтесь исправлять ошибку Kerberos изменением base DN. Сначала подтвердите, какой механизм вызывает приложение, и проверяйте только относящиеся к нему параметры.

Сертификаты и TLS при подключении к LDAP

TLS-сбой происходит до проверки пароля. Поэтому изменение bind DN не поможет, пока клиент не доверяет сертификату или не может завершить handshake.

Проверка сертификата LDAPS

Проверьте соединение с тем же именем, которое указано в приложении:

openssl s_client -connect ldap.example.org:636 -servername ldap.example.org -showcerts -verify_return_error </dev/null

Проверьте в выводе:

• имя ldap.example.org в SAN сертификата;
• срок действия сертификата;
• полную цепочку до доверенного корневого CA;
• совместимую версию TLS и набор шифров;
• отсутствие ошибки hostname mismatch.

Подключение по IP может пройти на уровне TCP и завершиться ошибкой TLS, если IP отсутствует в SAN. Указанное в конфигурации имя должно разрешаться в нужный адрес и совпадать с именем сертификата.

StartTLS на порту 389

StartTLS требует отдельной команды внутри LDAP-сессии. Клиент должен выполнить ее до bind, если сервер запрещает простой незашифрованный вход.

ldapsearch -x -H ldap://ldap.example.org:389 -ZZ -D 'uid=svc-app,ou=service,dc=example,dc=org' -W -b 'dc=example,dc=org' -s base '(objectClass=*)' dn

Если обычный запрос на 389 проходит, а вариант с -ZZ завершается ошибкой, проверяйте сертификат, доверенный CA, разрешенные версии TLS и требования сервера к StartTLS. Если StartTLS успешен, но bind отклонен, переходите к проверке DN и пароля.

Доверие к центру сертификации на клиенте

Проверяйте хранилище CA на сервере, в контейнере или в Kubernetes-поде, где работает приложение. Сертификат, доверенный хостовой системе, может отсутствовать внутри образа.

После добавления корневого CA обновите системное хранилище средствами конкретного дистрибутива, например update-ca-certificates или update-ca-trust. Некоторые приложения используют собственное хранилище Java, Python или встроенной библиотеки LDAP. Перезапустите процесс, если он читает сертификаты только при старте.

Не отключайте проверку сертификата в рабочей среде как постоянное решение. Такое изменение скрывает проблему доверия и позволяет принять подмененный сервер.

Как читать логи и коды ошибок LDAP

Сопоставляйте запись приложения с журналом LDAP-сервера или контроллера домена по времени, имени узла и идентификатору запроса. Локальный текст ошибки часто короче причины, которую сервер записал в свой журнал.

invalidCredentials

Код invalidCredentials, часто обозначаемый LDAP result code 49 в Active Directory, требует проверки нескольких вариантов:

• неверный пароль пользователя или служебной записи;
• неверный полный DN, UPN или домен;
• блокировка, отключение или истечение срока действия учетной записи;
• неподдерживаемый формат имени;
• попытка использовать Kerberos через LDAP-конфигурацию или наоборот.

Сверьте время отказа с журналом контроллера домена. Не передавайте в тикет диагностические данные, которые содержат пароль или полное содержимое LDAP-ответа.

Can't contact LDAP server и timeout

Эти сообщения указывают на отсутствие успешного обмена с сервером, а не на неверный пароль. Проверьте DNS, маршрут, firewall, TCP-порт и доступность конкретного контроллера. При LDAPS добавьте проверку TLS handshake и цепочки сертификатов.

Повторите команду с узла приложения. Результат с рабочей станции администратора может отличаться из-за другого DNS, маршрута, прокси или сетевой политики.

No such object и пустой результат поиска

No such object, LDAP result code 32, обычно связан с несуществующим base DN или недоступной веткой. Пустой результат при коде успеха указывает на несовпадение фильтра, атрибута или области поиска.

Повторите запрос через ldapsearch, выведите полный DN тестового объекта и сравните его с base DN. Затем замените фильтр на простой поиск по одному атрибуту и постепенно верните дополнительные условия.

insufficientAccessRights и отказ в чтении

insufficientAccessRights, LDAP result code 50, означает отказ в операции. Bind при этом может быть успешным. Проверьте ACL на OU, разрешение чтения атрибутов пользователей и групп, ограничения анонимных запросов и права на родительские объекты.

Убедитесь, что приложение выполняет чтение. Некоторые интеграции пытаются записать служебный атрибут, создать объект или обновить пароль, хотя учетной записи разрешен только поиск.

TLS и Kerberos-сообщения в логах

На Linux полезны журналы systemd:

journalctl -u имя-сервиса --since '10 minutes ago'

docker logs --since 10m имя-контейнера

kubectl logs -n namespace deploy/app --since=10m

Время, идентификатор запроса, имя контроллера и код LDAP сохраняйте. Пароли, токены, cookies и открытые данные simple bind маскируйте. Для общей диагностики ошибок входа полезен базовый алгоритм проверки учетных данных, времени, SSO и журналов.

Пошаговый сценарий исправления и контрольная проверка

Исправляйте проблему по одной гипотезе. После каждого изменения повторяйте один и тот же тест, чтобы увидеть фактический эффект.

Матрица проверки до и после исправления

Тестируйте минимум две учетные записи: разрешенную и заведомо не имеющую нужной группы. Пользователь из другой OU показывает, не ограничен ли поиск одной веткой случайно. Проверка только одной учетной записью скрывает ошибки фильтра и маппинга.

Безопасная настройка служебной учетной записи

• Создайте отдельную запись для приложения с правами только на чтение нужных объектов.
• Храните секрет в защищенной конфигурации или секрет-хранилище, а не в командной строке.
• Исключите пароль из логов, переменных диагностики и сообщений об ошибках.
• Задайте процедуру ротации пароля и проверьте, как приложение подхватывает новый секрет.
• В Kubernetes ограничьте чтение Secret нужным ServiceAccount и перезапустите поды после ротации, если приложение не перечитывает секрет динамически.

Для изолированного тестового стенда можно выделить отдельный облачный сервер или VDS, например через Timeweb Cloud. В рабочем окружении тестовый каталог и служебные учетные данные должны иметь отдельные права и сетевые ограничения.

Когда подключать серверные журналы и сетевой анализ

Подключайте журналы сервера, если клиент видит только общий отказ. Для OpenLDAP проверьте журнал slapd, для Active Directory, события контроллера домена, для Kerberos, журнал KDC. Если между приложением и каталогом стоит прокси или балансировщик, проверьте его журнал отказов и таймаутов.

При необходимости используйте трассировку LDAP-клиента или ограниченный сетевой захват:

sudo tcpdump -ni any host 10.20.30.40 and port 636

Не собирайте и не передавайте захват трафика с открытым simple bind. На порту 389 без TLS пароль может передаваться в форме, пригодной для раскрытия. Остановите захват после получения нужного фрагмента и удалите файл по правилам безопасности.

Если сбой появился после смены схемы входа в конкретном продукте, сверяйте его встроенные требования с отдельным сценарием миграции. Например, при переходе Zabbix на LDAP полезен практический план с аварийной учетной записью и контрольными тестами.

Особенности OpenLDAP, FreeIPA и других каталогов

Универсальная цепочка диагностики сохраняется для LDAP-совместимых каталогов, но названия атрибутов, структура DN, ACL и связь с Kerberos зависят от продукта. Не переносите фильтр Active Directory в OpenLDAP без проверки схемы.

OpenLDAP

Проверьте:

• suffix и фактический base DN;
• полный bind DN служебной записи;
• ACL на suffix, OU, пользователей и группы;
• схему и наличие классов person, inetOrgPerson или других классов, которые использует каталог;
• атрибуты uid, ou, mail и posixGroup;
• фильтры поиска и область base, one или sub.

В OpenLDAP группа может хранить список участников через memberUid, member или схему, заданную администратором. Настройка, рассчитанная на memberOf Active Directory, может вернуть пустой результат даже при корректном пароле.

FreeIPA и Kerberos-каталоги

FreeIPA объединяет каталог, Kerberos, DNS, сертификаты и политики доступа. Проверяйте каждый слой отдельно:

1. DNS разрешает имя сервера и возвращает записи доменных служб.
2. Системное время синхронизировано с KDC.
3. Kerberos получает билет для нужного realm.
4. LDAP bind и поиск пользователя проходят с нужным сертификатом или DN.
5. Группы и правила доступа возвращают ожидаемый результат.

Ошибка Kerberos не доказывает неисправность LDAP. И наоборот, успешный LDAP-запрос не подтверждает работу SSO. Сохраняйте для каждой проверки отдельную команду и результат.

Что остается общим для любого каталога

Для OpenLDAP, Active Directory, FreeIPA и других каталогов используйте одну модель:

1. соединение с нужным узлом;
2. защищенный канал и проверка сертификата;
3. bind служебной учетной записью;
4. поиск пользователя по base DN и фильтру;
5. проверка пароля или Kerberos-билета;
6. чтение групп;
7. сопоставление групп с правами приложения.

Названия атрибутов, коды ошибок и требования TLS сверяйте с документацией конкретного каталога и версии приложения. Для интеграции NAS с LDAP отдельные параметры маппинга пользователей, групп и ACL разобраны в руководстве по LDAP-аутентификации в TrueNAS SCALE.

Рабочая диагностика заканчивается после контрольного входа разрешенного пользователя, предсказуемого отказа пользователя без группы и проверки логов без утечки секретов. Если bind, поиск, пароль или группы проверены отдельно, причина ошибки аутентификации обычно локализуется без хаотичной смены параметров.