1. Установите операцию, источник и учётную запись Bind
Сначала сохраните полный исходный ответ и клиентский журнал за узкий UTC-интервал. Зафиксируйте сервер/DC, домен, версию библиотеки, адрес подключения и тот же идентификатор соединения. Выясните, отказал служебный Bind приложения или вход конечного пользователя: это могут быть разные учётные записи и этапы. LDAP BindResponse и Windows Security 4625 имеют собственные схемы. Номер 49 относится к LDAP, а не к порту, событию или HTTP. Сохраняйте код и исходное сообщение: перевод или сокращение строки может скрыть важные детали.
2. Отделите 49 от расширенной ошибки и debug-хвоста
RFC 4511 называет 49 invalidCredentials; диагноз по одной цифре шире, чем «пользователь существует, неверен пароль». Сервер может заменить код, чтобы не раскрывать сведения, а diagnosticMessage вообще оставить пустым. MS-ADTS отдельно описывает восемь начальных hex-знаков errorMessage. Всё после них служит отладке и может отсутствовать. Поэтому data 52e, DSID и суффикс версии сохраняют как исходный текст конкретного источника. Парсер не должен требовать этих токенов, переносить их на OpenLDAP или выводить первопричину без дополнительных свидетельств.
3. Прочитайте примеры и локальную выборку
В первом учебном объекте resultCode равен 49, а строка содержит отдельные префикс 80090308 и debug data 52e. Это авторская проекция декодированного сообщения для объяснения, а не стандартный JSON каталога. Сохраните два объекта как отдельные строки ldap-bind-demo.jsonl; перед собственным экспортом согласуйте его ключи со схемой клиента. Код читает только этот файл, отбирает BindResponse 49 и печатает найденные части. Второй объект тоже проходит отбор, но выдаёт null для обеих диагностических частей. Null не превращается в успешный вход или «неверный пароль».
4. Условно сопоставьте hex со словарём Win32
Если происхождение конкретного диагностического data подтверждено как Win32, переводите его с основанием 16: 52e даёт 1326, а 775 — 1909. Таблица ниже — официальный словарь WinError.h, а не нормативная схема поля data и не обещание возврата всех кодов конкретным DC. Она задаёт направление ручной проверки. Не превращайте 52e в утверждение о правильном имени: ERROR_LOGON_FAILURE охватывает имя или пароль. Не переносите эти значения в NTSTATUS Status/SubStatus 4625; совпадение слов не делает пространства кодов одинаковыми.
| Hex Win32 | Десятичный | Имя | Значение для проверки |
|---|---|---|---|
| 0x525 | 1317 | ERROR_NO_SUCH_USER | Указанная учётная запись не существует. |
| 0x52e | 1326 | ERROR_LOGON_FAILURE | Неверное имя пользователя или пароль; не доказательство существующего имени. |
| 0x530 | 1328 | ERROR_INVALID_LOGON_HOURS | Вход ограничен по времени. |
| 0x531 | 1329 | ERROR_INVALID_WORKSTATION | Вход на данный компьютер не разрешён. |
| 0x532 | 1330 | ERROR_PASSWORD_EXPIRED | Истёк срок действия пароля. |
| 0x533 | 1331 | ERROR_ACCOUNT_DISABLED | Учётная запись отключена. |
| 0x701 | 1793 | ERROR_ACCOUNT_EXPIRED | Истёк срок действия учётной записи. |
| 0x773 | 1907 | ERROR_PASSWORD_MUST_CHANGE | Перед входом требуется изменить пароль. |
| 0x775 | 1909 | ERROR_ACCOUNT_LOCKED_OUT | Учётная запись заблокирована. |
5. Проверьте имя, состояние и фактический механизм
Попросите владельца каталога сверить объект и форму имени на момент попытки, назначение учётной записи Bind, применимую политику и состояние учётной записи. MS-ADTS различает разрешение DN/UPN и других форм; для отсутствующего или неоднозначного сопоставления допускает invalidCredentials/ERROR_INVALID_PARAMETER. Не ставьте знак равенства между формами имени для AD DS и AD LDS. Simple и SASL также различаются: GSSAPI использует Kerberos, а GSS-SPNEGO может применять Kerberos или NTLM. Один LDAP 49 не доказывает наличие отдельной ошибки Kerberos 4771.
6. Проверьте цепочку до очередной попытки
Не проверяйте гипотезу серией новых bind: повторения могут участвовать в действующем пороге блокировки, в том числе когда старые сведения использует служба. Сначала найдите источник повторений, временное окно и существующие подтверждения состояния. При data 775, если его интерпретация подтверждена, запросите 4740 и историю той же учётной записи. Сопоставляйте сервер, область/SID при доступности, время и реальный механизм; один messageID глобальной связью не является. Разблокировка, сброс пароля и изменение политики — отдельные административные действия, эта инструкция их не выполняет.
7. Разделите TLS, аутентификацию и доступ к данным
Сохраните фактический защитный режим и сообщения TLS/клиентской библиотеки. Ошибка до получения LDAP BindResponse не становится LDAP 49 по догадке. Simple bind требует защиты TLS; не отключайте проверку сертификата, signing или channel binding ради проверки учётных данных. Наличие TCP 636 само по себе не доказывает успешную проверку TLS. Успешный Bind не гарантирует полномочия на дальнейший Search; 49 и insufficientAccessRights 50 нельзя подменять друг другом. Следующим свидетельством будет результат нужной операции приложения в согласованной сессии.
8. Если диагностических данных или события нет
Разделите отсутствие BindResponse, обрезанный клиентский текст, пустой diagnosticMessage и отсутствие записи в доступном журнале. Проверьте исходную копию, ротацию, роль источника и права чтения; не включайте дополнительное журналирование в рамках этого маршрута. Для Microsoft-поля data без подтверждённого контекста запишите «debug-семантика не установлена». Итог должен содержать факт отказа конкретной операции, проверенные гипотезы и недостающие свидетельства. Наличие LDAP 49 не устанавливает злоумышленника, успешность других входов или блокировку всей учётной записи.