LDAPS работает — это ещё ничего не значит: как найти клиентов, которые сломаются после включения LDAP channel binding

Чтобы узнать, кто сломается после включения LDAP channel binding, нужны события 3074 и 3075 со всех контроллеров домена. Они пишутся только в режиме When Supported или Always и при диагностике «16 LDAP Interface Events» не ниже 2 — поэтому пустой журнал обычно означает выключенный аудит. Ниже — настройка, скрипты сбора, разбор гостиничного домена и план перехода.

Почему в журнале Directory Service нет событий 3074 и 3075

Мне пишут примерно так: «Мы месяц смотрели журнал на контроллере домена, событий про channel binding нет. Включаем Always?» Я задаю три вопроса: какое сейчас значение LdapEnforceChannelBinding, какой уровень у диагностического параметра «16 LDAP Interface Events» и сколько контроллеров вы смотрели. Чаще всего ответ — «ноль, не трогали, один». Это первое, что я проверяю, когда нас зовут на аудит Active Directory перед ужесточением политик.

Механика неинтуитивная. По KB4520412 события аудита 3074 и 3075 контроллер пишет, только когда политика channel binding стоит в When Supported (значение 1) или Always (2). В режиме Never — а это умолчание для контроллеров Windows Server 2019 и 2022 — журнал будет пустым при любом количестве несовместимых клиентов. Вы смотрите, там пусто, и делаете обратный вывод: «проблемных клиентов нет». На деле пусто, потому что никто не проверял.

Второй слой — диагностика. Оба события требуют минимального уровня 2 у параметра «16 LDAP Interface Events» в ветке HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics, а по умолчанию там ноль. И ставить его нужно на каждом контроллере: клиенты выбирают DC сами — по SRV-записям, по сайту или по жёстко прописанному адресу. Классика — МФУ и NAS, у которых в веб-интерфейсе вбит адрес одного конкретного контроллера, обычно самого старого. Именно он покажет всю картину, и именно на него никто не смотрит.

Третий момент вспоминают уже после аварии: успешное TLS-соединение и успешный bind по порту 636 ничего не говорят о поддержке CBT. Channel binding token — это не шифрование, а привязка контекста аутентификации к конкретной TLS-сессии. Клиент может поднять LDAPS, пройти аутентификацию и ничего не знать о channel binding. Вопрос «а он подключается по LDAPS?» — не тот вопрос.

• LdapEnforceChannelBinding = 0 (Never) — событий 3074/3075 не будет физически.
• «16 LDAP Interface Events» = 0 (умолчание) — события с IP клиента не пишутся.
• Смотрели один DC из двух-трёх — увидели часть картины или ничего.
• Проверяли «работает ли LDAPS» — это другой вопрос, к CBT отношения не имеющий.

Что означают события 3074, 3075, 3039 и 2889

Путаница здесь реальная. В статье Microsoft Learn про LDAP signing есть таблица событий channel binding с номерами 3039–3041, а кампания ужесточения в KB4520412 опирается на аудиторские 3074 и 3075. Администраторы читают одну страницу, ищут указанные там номера, не находят и решают, что всё чисто. Для предварительного аудита нужны именно 3074 и 3075. Причём описания событий в таблице Learn местами расходятся с тем, что реально пишет контроллер, поэтому я ориентируюсь на KB и на текст события в своём журнале.

Событие 3074 по KB: клиент выполнил LDAP bind поверх SSL/TLS и не прошёл бы проверку channel binding token, если бы сервер её требовал. Возникает, когда клиент передаёт некорректно сформированный или не совпадающий токен. Типичные причины — TLS, который терминирует промежуточный прокси или балансировщик, и кривые библиотеки. Событие 3075: клиент выполнил bind поверх SSL/TLS и не передал сведения channel binding вовсе; при обязательной проверке такой bind будет отклонён. Оба события пишутся в журнал Directory Service с IP-адресом клиента и учётной записью — этого достаточно, чтобы найти источник.

Остальные номера — для контекста. 3039 фиксирует bind, который не прошёл проверку CBT, когда проверка уже действует: если видите его после перехода в When Supported или Always, клиент уже получил отказ. 3040 и 3041 — сводное и рекомендательное события, их формулировки в разных источниках описаны по-разному, поэтому читайте текст в своём журнале. 2889 относится к LDAP signing, а не к channel binding: клиент выполнил SASL-bind без запроса подписи или simple bind по открытому каналу. Его удобно собирать тем же скриптом, но решение по нему — отдельная история.

Исторический контекст помогает понять, на каких сборках что увидите. По KB4520412 события 3074 и 3075 появились в Windows Server 2022 с обновлением от 8 августа 2023 года и в Windows Server 2019 — от 10 октября 2023-го, сначала выключенными. Необходимость включать их вручную убрали 14 ноября 2023 года для 2022 и 9 января 2024 года для 2019. Контроллер без этих обновлений полноценного аудита не даст — и это ещё один аргумент его обновить или вывести.

• 3074 — CBT передан, но не прошёл бы проверку (некорректный или чужой токен).
• 3075 — CBT не передан вовсе; при обязательной проверке bind будет отклонён.
• 3039 — bind уже отклонён действующей проверкой CBT.
• 2889 — SASL без подписи или simple bind по открытому каналу (это LDAP signing).

Как включить аудит channel binding на всех контроллерах: порядок и скрипты

Порядок у меня всегда одинаковый. Сначала включаю диагностику на всех контроллерах и увеличиваю журнал Directory Service: на уровне 2 LDAP-событий много, и журнал по умолчанию перезаписывается за часы. Вы честно ждёте месяц, а потом смотрите статистику за полдня. Я ставлю не меньше 256 МБ, а при возможности настраиваю пересылку событий на отдельный сервер.

$dcs = (Get-ADDomainController -Filter *).HostName
foreach ($dc in $dcs) {
  Invoke-Command -ComputerName $dc -ScriptBlock {
    reg add "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics" /v "16 LDAP Interface Events" /t REG_DWORD /d 2 /f
    wevtutil sl "Directory Service" /ms:268435456 /rt:false
  }
}

Имя параметра содержит пробелы и цифру, кавычки обязательны. Откат — то же значение 0.

Затем — режим channel binding. В рабочем домене я задаю его групповой политикой «Domain controller: LDAP server channel binding token requirements» (Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options) на OU Domain Controllers, а реестр использую для проверки фактического состояния на каждом DC.

:: 0 = Never, 1 = When Supported, 2 = Always
reg query "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" /v LdapEnforceChannelBinding
reg query "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" /v LDAPServerIntegrity

When Supported задуман как совместимый режим: судя по формулировкам KB, клиенты из 3074 и 3075 в нём ещё пропускаются — события говорят «не прошёл бы» и «будет отклонён при обязательной проверке». Но это всё равно изменение политики безопасности на всех контроллерах, а поведение отдельных клиентов вы пока не знаете. Поэтому переключаю в согласованное окно и в первые часы смотрю на 3039 и на звонки пользователей.

События собираю не через Event Viewer, а выгрузкой в CSV с группировкой по IP: глазами тысячи записей не разобрать.

$dcs  = (Get-ADDomainController -Filter *).HostName
$from = (Get-Date).AddDays(-30)
$rows = foreach ($dc in $dcs) {
  Get-WinEvent -ComputerName $dc -ErrorAction SilentlyContinue -FilterHashtable @{
    LogName = 'Directory Service'; Id = 3039, 3074, 3075; StartTime = $from
  } | ForEach-Object {
    $ip  = ([regex]'Client IP address:\s*(\S+)').Match($_.Message).Groups[1].Value
    $who = ([regex]'authenticate as:\s*(.+)').Match($_.Message).Groups[1].Value
    [pscustomobject]@{ DC = $dc; Id = $_.Id; Time = $_.TimeCreated; IP = ($ip -replace ':\d+$',''); Identity = $who.Trim() }
  }
}
$rows | Group-Object IP, Id | Select-Object Name, Count,
  @{n='Last'; e={($_.Group.Time | Measure-Object -Maximum).Maximum}},
  @{n='Identity'; e={($_.Group.Identity | Select-Object -Unique) -join '; '}} |
  Sort-Object Count -Descending | Export-Csv .\cbt-audit.csv -Encoding UTF8 -NoTypeInformation

Регулярки рассчитаны на английский текст события. На русской локали сервера формулировки другие — откройте одно событие и поправьте шаблон под свой журнал, прежде чем доверять пустым колонкам.

Дальше ждём. Тридцать дней — минимально осмысленное окно: месячные регламентные задания, редко включаемые МФУ, отпуска, ночные выгрузки. Параллельно разбираю уже найденное: верхние пять адресов обычно дают основную массу событий. Если вам интересна соседняя тема с таким же подходом «сначала аудит, потом запрет», посмотрите мой разбор зависимостей от RC4 в Kerberos — там журнал тоже молчит, пока его не заставить говорить.

• Шаг 1 — «16 LDAP Interface Events» = 2 на всех DC.
• Шаг 2 — журнал Directory Service 256 МБ и больше или пересылка событий.
• Шаг 3 — режим When Supported в окно обслуживания, контроль 3039 и жалоб.
• Шаг 4 — минимум 30 дней сбора 3074/3075 со всех DC.
• Шаг 5 — исправить найденное и только потом Always.

Разбор: «Отель Полярная звезда», 27 рабочих мест и 11 скрытых LDAP-клиентов

Условный клиент — «Отель Полярная звезда»: 27 рабочих мест (ресепшен, бронирование, бухгалтерия, служба размещения, ресторан), два контроллера домена — DC01 на Windows Server 2019 и DC02 на 2022, оба с актуальными обновлениями. Задача пришла от страховой, которая перед продлением полиса киберрисков прислала опросник с пунктом про LDAP signing и channel binding. Внутренний администратор был уверен: «у нас всё на LDAPS, включаем и живём». Журнал на DC02 — чистый. Ответы на мои три вопроса: LdapEnforceChannelBinding = 0 на обоих, диагностика 0, смотрели только DC02.

Включили диагностику на обоих контроллерах, подняли журналы до 256 МБ и настроили пересылку событий на сервер резервного копирования. Через двое суток, после согласования со службой приёма, перевели домен в When Supported. 3039 за первые часы не появилось. За 30 дней собрали 3075 с 9 уникальных адресов и 3074 с 2 адресов — 11 клиентов, из которых в инвентаризации значились только три.

Картина по 3075: три МФУ с адресной книгой из AD и сканированием в почту, NAS с доменной авторизацией, межсетевой экран с LDAP-аутентификацией VPN для управляющей и бухгалтера, IP-АТС с телефонным справочником из AD, сервер системы электронных замков, через который служба размещения программирует ключ-карты, и два ноутбука ресторана со старым кассовым ПО, авторизовавшимся в домене своей библиотекой. Два адреса в 3074 оказались одним сценарием: система управления отелем ходила в AD не напрямую, а через LDAPS-прокси на старом интеграционном сервере, который принимал TLS на себя и открывал новое соединение к DC. Токен клиента физически не мог совпасть — прошивкой такое не лечится.

Итог: шесть недель от старта аудита до Always. Прошивки МФУ и NAS обновили, VPN перевели на RADIUS через NPS — как это делается, я показывал на примере NPS и RADIUS для Wi-Fi. Прокси убрали, систему управления отелем перенастроили на прямое подключение к DC по Kerberos. Для АТС и системы замков поставщики прислали обновления, а кассовые ноутбуки вывели из домена — там два пользователя, огород городить незачем. Always включили во вторник в 10:00, вне заезда гостей; за первую неделю — ни одного 3039 и ни одного звонка с ресепшена.

• 2 DC, 27 рабочих мест, 11 LDAP-клиентов вне Windows-парка.
• 3075 — 9 адресов: МФУ, NAS, VPN, АТС, замки, касса.
• 3074 — 2 адреса: одна интеграция через LDAPS-прокси с терминацией TLS.
• 6 недель от аудита до Always, простоев нет.

Кто ломается чаще всего: МФУ, NAS, прокси и simple bind

Список повторяется от проекта к проекту, и его можно использовать как чек-лист ещё до аудита. Первое место — печатающая техника с интеграцией в AD: адресные книги, сканирование в папку и в почту, авторизация по карте. Прошивки там живут своей жизнью. Второе — NAS и межсетевые экраны с LDAP-аутентификацией. Третье — всё самописное и узкоотраслевое: системы управления отелем или складом, АТС, СКУД, замки, кассовое ПО. Про безопасность сетевых МФУ в целом я писал отдельно, а общую картину защиты домена — в статье защита Active Directory за 12 шагов.

Отдельно о simple bind, потому что это спорная зона. Статья Learn говорит, что channel binding важен при NTLM и simple bind поверх SSL/TLS, однако на практике поведение простого bind при Always администраторы описывают по-разному. Я не берусь давать категоричный ответ и поступаю проще: все интеграции с simple bind считаю подозрительными по умолчанию и проверяю их на тестовом DC до включения. Это полдня работы, которые экономят сутки аварии.

Архитектурная несовместимость — терминация TLS на промежуточном узле. Балансировщик, реверс-прокси или LDAP-прокси, который принимает TLS на себя и открывает новое соединение к контроллеру, разрывает ту самую привязку между сессией и токеном. Это не «старый клиент», и обновлением не лечится: убираете прослойку или переводите клиента на прямое подключение, лучше по Kerberos.

И хорошая новость, чтобы не нагнетать. Актуальные Windows-клиенты и доменные машины проходят проверку без действий с вашей стороны. В «Полярной звезде» ни один компьютер сотрудников не попал в список — только периферия и интеграции. Массового ужаса не будет, но и «просто включить» тоже не получится.

• МФУ и принтеры с адресной книгой и сканированием из AD.
• NAS, межсетевые экраны и VPN с LDAP-аутентификацией.
• Отраслевые системы: управление отелем, АТС, СКУД, замки, касса.
• Java- и PHP-приложения со старыми LDAP-библиотеками.
• Любые схемы с терминацией TLS перед контроллерами домена.

Windows Server 2025 и план включения: что сделать сначала, а что не делать

В Windows Server 2025 Microsoft сдвинула умолчания для новых развёртываний AD: LDAP signing требуется через политику «Domain controller: LDAP server signing requirements enforcement», channel binding стоит в When supported, аудит channel binding включён, шифрование LDAP-клиента предпочитается. Там же и в Windows 11 24H2 появились клиентские счётчики производительности LDAP с разбивкой по процессам — удобно, когда нужно понять, какая программа на машине ходит в AD.

Подводных камней два. Первый: при обновлении существующего контроллера до 2025 прежние LDAP-политики сохраняются. Обновились — не значит «стало безопаснее»; проверьте реестр, это минута. Второй зеркальный: если вы поднимаете новый домен на 2025 и переносите в него старую периферию, обязательная подпись LDAP действует сразу, без переходного периода. Старое МФУ, десять лет работавшее со старым доменом, в новом просто не заведётся, и вы будете искать причину в правах и OU. Инвентаризацию LDAP-клиентов делайте до миграции.

Приоритеты, если времени мало. Сначала — диагностика 2 на всех DC и увеличенный журнал: это ничего не ломает и даёт видимость. Затем — When Supported в окно с контролем 3039. Затем — разбор 3074: их мало, но они указывают на архитектурные проблемы вроде прокси. Потом 3075 по убыванию числа событий. Always — только после месяца статистики и пустого списка.

Чего я не делаю. Не оставляю один «мягкий» контроллер для несовместимых клиентов: значение локальное, технически это возможно, но клиенты выбирают DC динамически, и вы получите домен, где одно и то же приложение работает или нет в зависимости от контроллера. И не воюю за каждый адрес: если устройство списано производителем, дешевле вывести его из домена или перевести на локальные учётные записи. Реальная эксплуатация отсутствия CBT требует позиции «человек посередине» в вашей сети, но защита эта дешёвая и включается один раз — лучше по плану за шесть недель, чем авралом за два дня после письма аудитора.

• Новое развёртывание на 2025: signing обязателен, CB = When supported, аудит включён.
• Обновление до 2025: прежние политики сохраняются — проверьте реестр.
• 2019/2022: CB = Never по умолчанию, аудит требует ручной настройки.
• Не делать: разные режимы CBT на разных DC и Always без месяца статистики.

Частые вопросы