Проблема

Zabbix 7.4 (Ubuntu, nginx + php-fpm 8.3) не мог аутентифицировать пользователей через LDAP в домене corp.holding.ru с контроллером на Windows Server 2025. Тест выдавал generic-ошибку:

Incorrect user name or password

При этом ldapsearch с хоста Zabbix показывал реальную причину:

ldap_bind: Strong(er) authentication required (8)
additional info: 00002028: The server requires binds to turn on integrity checking

Корневая причина

Windows Server 2025 по умолчанию принудительно требует LDAP signing — через новую политику «Domain controller: LDAP server signing requirements Enforcement». Её коварство в трёх вещах:

1. В состоянии Not Configured она действует как Require Signing — то есть требование активно, хотя нигде явно не задано и в gpresult не видно.
2. Она имеет приоритет над старой политикой «LDAP server signing requirements» и её реестровым значением — поэтому LDAPServerIntegrity = 1 (None) игнорировался, что и сбивало с толку.
3. Simple bind по нешифрованному ldap:// (который использует Zabbix и любой типовой Linux LDAP-клиент) под это требование не попадает — DC его отклоняет.

Диагностика

Шаг 1 — Исключить конфигурацию Zabbix

Проверили настройки LDAP в Administration → Authentication:

• Default authentication переключён с Internal на LDAP
• JIT provisioning включён
• Маппинг групп настроен
• Bind-учётка указана корректно

Проблема воспроизводилась и при тесте соединения — ещё до попытки входа пользователя.

Шаг 2 — Локализовать проблему через ldapsearch

ldapsearch -x -H ldap://dc01.corp.holding.ru \
  -D "CN=zabbix-bind,OU=Service Accounts,DC=corp,DC=holding,DC=ru" \
  -w 'BindPassword' \
  -b "DC=corp,DC=holding,DC=ru" \
  "(sAMAccountName=testuser)"

Ошибка ldap_bind: Strong(er) authentication required (8) / 00002028 однозначно указывала на DC: сервер отклонял simple bind без подписи.

Шаг 3 — Проверить GPO через gpresult

gpresult /H C:\gpresult.html /SCOPE COMPUTER
# Открыть gpresult.html и найти "LDAP server signing"

Ни одна GPO не содержала явной настройки — подтверждено, что работает дефолт WS2025.

Шаг 4 — Попытка перейти на LDAPS

Попытка переключить Zabbix на ldaps://dc01.corp.holding.ru (порт 636 / 3268) упёрлась в то, что сертификат DC подписан SHA1 (центр сертификации HOLDING-CA на устаревшем хеше). OpenSSL 3 на Ubuntu отклонял цепочку:

ldap_start_tls: Connect error (-11)
additional info: error:0A000086:SSL routines::certificate verify failed
# В openssl s_client:
verify error:num=68:CA signature digest algorithm too weak

Решение

Способ 1 — Отключить Enforcement через GPO (рекомендуется)

В Default Domain Controllers Policy (GPMC → Forest → Domains → corp.holding.ru → Domain Controllers) добавить параметр:

• Путь: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options
• Политика: Domain controller: LDAP server signing requirements Enforcement
• Значение: Disabled

Параметр виден в редакторе GPO только при редактировании с контроллера на WS2025. С более старых систем он может отсутствовать в списке.

После сохранения политики GPO запишет в GptTmpl.inf:

LDAPServerEnforceIntegrity=0

Способ 2 — Принудительно через реестр (если GPO не применяется)

Security-расширение групповых политик может не сразу перенести значение из GPO в реестр. В этом случае — создаём параметр вручную и перезапускаем NTDS:

New-ItemProperty `
  -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" `
  -Name LDAPServerEnforceIntegrity `
  -PropertyType DWord `
  -Value 0 `
  -Force

Restart-Service NTDS -Force

Значение реестра совпадает с тем, что задано в GPO, — при последующих применениях политики оно сохранится.

Проверка результата

ldapsearch -x -H ldap://dc01.corp.holding.ru \
  -D "CN=zabbix-bind,OU=Service Accounts,DC=corp,DC=holding,DC=ru" \
  -w 'BindPassword' \
  -b "DC=corp,DC=holding,DC=ru" \
  "(sAMAccountName=testuser)" cn mail

После перезапуска NTDS simple bind прошёл успешно. LDAP-аутентификация в Zabbix заработала: маппинг группы Zabbix-admin → роль Super admin через memberOf отработал корректно.

Временный характер решения — технический долг

Текущее состояние: пароли пользователей Zabbix (в том числе Domain Admins) передаются до DC открытым текстом, и весь домен снова принимает нешифрованные бинды. Это приемлемо только как временная мера.

План возврата к безопасной схеме

1. Перевести HOLDING-CA на SHA256

certutil -setreg ca\csp\CNGHashAlgorithm SHA256
net stop CertSvc && net start CertSvc

2. Перевыпустить сертификат контроллера домена

# На DC01:
certutil -pulse

После этого DC запросит новый сертификат с SHA256-подписью. Проверить:

Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Subject -match "dc01" } | Select-Object Subject, Thumbprint, NotAfter

3. Переключить Zabbix на LDAPS

В Administration → Authentication → LDAP:

• Host: ldaps://dc01.corp.holding.ru
• Port: 3268 (Global Catalog) или 636
• Убедиться, что корневой сертификат HOLDING-CA установлен на хосте Zabbix:

cp HOLDING-CA.crt /usr/local/share/ca-certificates/
update-ca-certificates
# Проверить цепочку:
openssl s_client -connect dc01.corp.holding.ru:636 -CApath /etc/ssl/certs

4. Вернуть Enforcement в GPO

После успешного теста LDAPS — вернуть политику «LDAP server signing requirements Enforcement» в значение Required или удалить явную настройку (вернув дефолт WS2025).

Затронутые приложения при миграции DC на WS2025

Те же грабли с LDAPServerEnforceIntegrity ждут любое приложение с simple bind при обновлении контроллера домена на Windows Server 2025:

• Nextcloud — LDAP-модуль использует simple bind по умолчанию
• Exim / Dovecot — LDAP-аутентификация пользователей почты
• GitLab, Roundcube, phpLDAPadmin
• Любые скрипты с ldap_bind() или ldapsearch -x

Диагноз в каждом случае одинаков: ldapsearch с хоста приложения → ошибка 8 / 00002028 → причина в новом Enforcement-дефолте WS2025. Решение — одно из двух описанных выше.

Итог