Как я выстраиваю мониторинг Active Directory: репликация, DNS, SYSVOL и аутентификация в одной цепочке

От пользовательского входа иду назад к первой причине

Когда пользователь не может войти в домен, отдельные зелёные проверки контроллеров почти ничего мне не объясняют. Меня зовут Семёнов Евгений Сергеевич; я основатель IT Fresh. Как технический директор IT Fresh я задаю границы решения, а как ведущий системный администратор лично проверяю его эксплуатационную логику. Я раскладываю услугу в направленную цепочку: изменение каталога должно сойтись между партнёрами, контроллер должен корректно рекламироваться через DNS, клиент обязан найти подходящий узел, этот узел должен иметь готовый SYSVOL с политиками, а KDC — выдать билет при согласованном времени и корректной идентичности службы. Такая последовательность важна не только для расследования. Она задаёт, какие события считаются первичными, какие остаются симптомами и где мониторинг обязан остановиться со значением unknown. В IT Fresh мы не превращаем один неудачный вход в вывод о поломке всего домена. Сначала я спрашиваю: какой контроллер выбрал клиент, свежи ли данные о нём и какой переход впервые не получил доказательства. Если репликация каталога уже нарушена, последующие расхождения DNS, политик или учётных данных могут быть следствием. Если каталог сходится, но DC Locator получает неверный ответ, ветвь смещается к DNS. Так дежурный видит не перечень красных ламп, а порядок безопасной проверки.

Репликацию измеряю по партнёрам и разделам каталога

Первый слой строю вокруг входящей репликации каждого контроллера. Вывод repadmin /showrepl рассматриваю как таблицу связей: destination DSA, source DSA, naming context, время последнего успеха, число последовательных ошибок и код результата. Общий статус сервера здесь недостаточен. Конфигурационный раздел способен сходиться, пока доменный раздел отстаёт, а один партнёр может быть недоступен при рабочей альтернативной связи. Я сохраняю также timestamp запуска и код завершения команды, чтобы старый успешный файл не выглядел текущим здоровьем. Периодически использую сводный read-only запуск repadmin /showrepl * /csv для сверки охвата, но не вызываю из мониторинга принудительную синхронизацию. Порог возраста привязываю к расписанию сайта и наблюдаемой длительности, а не к универсальному числу. В событии указываю контроллер, источник, раздел и класс ошибки, но группирую одинаковую сетевую причину. Восстановлением считаю новый успешный цикл на той же связи, а не исчезновение текста ошибки после очистки истории или acknowledge.

DNS проверяю как мост от каталога к выбранному контроллеру

После репликации проверяю не абстрактную доступность DNS-сервера, а записи, которыми реально пользуется DC Locator. Контроллеры публикуют SRV для LDAP, Kerberos, глобального каталога и сайтов; клиент сначала запрашивает такие записи, затем проверяет доступность найденного узла. Поэтому я разделяю наличие ожидаемого SRV, корректность его target, разрешение target в адрес и достижимость нужного сервиса. Запрос выполняю из той же клиентской или прокси-точки, где должна работать аутентификация: ответ локального resolver на контроллере не доказывает путь пользователя. Инвентарь ожидаемых записей строю из фактических сайтов и ролей, а не из случайного ответа. DCDiag /test:DNS применяю как диагностическое подтверждение и отдельно сохраняю результат DNSBasic либо регистрации записей. Если каталог реплицируется, но один DNS-узел отдаёт устаревшую цель, проблема уже имеет понятную границу. Если SRV правильный, а адрес target не разрешается, я не поднимаю событие KDC: сначала должен восстановиться мост обнаружения.

SYSVOL связываю с DFSR и состоянием каталога

Наличие SYSVOL и NETLOGON проверяю на каждом контроллере, но никогда не объявляю это полным доказательством. Публикация общей папки показывает готовность одного интерфейса, а не сходимость файлов. Поэтому рядом собираю состояние службы DFS Replication, состояние replicated folder для SYSVOL и релевантные события канала DFS Replication. Microsoft отдельно предупреждает, что ошибки upstream-контроллера и восстановление после некорректного завершения способны оставить другой узел без готового SYSVOL. События ожидания начальной синхронизации, её завершения и остановки репликации я трактую как переходы состояния, а не как изолированные номера. В цепочке есть важная причинность: конфигурация DFSR хранится в каталоге, поэтому проблема репликации AD может мешать распространению самой конфигурации SYSVOL. Я сначала подтверждаю каталог, затем DFSR, затем доступность общих ресурсов и только после этого делаю вывод о готовности политик. Автоматически удалять базу DFSR, выставлять authoritative-признак или вручную публиковать SYSVOL из Zabbix недопустимо.

Аутентификацию подтверждаю короткой синтетической цепочкой

Финальный слой — не счётчик работающей службы KDC, а разрешённая клиентская проверка. С выделенного узла я фиксирую результат обнаружения контроллера, имя выбранного DC, разрешение его адреса, доступность Kerberos и получение билета тестовой доменной учётной записью. Секрет не передаётся параметром item и не попадает в history; запуск выполняет защищённый локальный механизм под заранее ограниченным контекстом. Я различаю отказ найти контроллер, DNS-ошибку, недоступность KDC, рассинхронизацию часов, отказ предварительной проверки и проблему имени службы. Kerberos использует временные метки, поэтому расхождение часов собираю самостоятельным сигналом и связываю с источником времени. Успешная выдача билета подтверждает пройденную часть пути, но не гарантирует доступ к каждому приложению: дальше могут влиять SPN, права и целевая служба. Такой тест замыкает цепь пользователя, не подменяя её бесконтрольной попыткой входа во все системы. Повторные ошибки ограничиваю, чтобы мониторинг сам не вызвал блокировку учётной записи.

Технический пример делаю читаемым и закрытым для изменений

Коллектор возвращает один JSON, чтобы результаты одного цикла имели общее время. Упрощённый фрагмент выглядит так: `repadmin /showrepl $env:COMPUTERNAME /csv`; `Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.$Domain`; `Get-SmbShare -Name SYSVOL,NETLOGON -ErrorAction SilentlyContinue`; `Get-Service DFSR,Netlogon,Kdc`. В рабочем варианте список доменов не принимается из key, а хранится в защищённой локальной конфигурации; stdout каждой команды разбирается с учётом кода возврата и версии ОС. Zabbix получает `ad.chain.raw` как master item. Dependent items извлекают возраст последнего успеха по связи, число ошибочных связей, полноту ожидаемых SRV, факт публикации ресурсов, состояние служб и результат клиентской проверки. Ошибка разбора не преобразуется в ноль: item становится unsupported либо выдаёт явный unknown. События Windows получаю отдельными active checks `eventlog[]`, фильтруя канал, источник и разрешённые идентификаторы. Текст события храню ограниченно и без имён пользователей; для корреляции достаточно контроллера, слоя, класса результата и времени.

Сигналы превращаю в уровни и зависимости

Я использую уровни как смысл реакции, а не как эмоциональную оценку. Information сообщает о переходе топологии или восстановлении, Warning — о единичном сбое при сохранённой альтернативе и свежем сборе, Average — об устойчивом нарушении одной ветви, High — о потере подтверждённой функции контроллера или сайта, Disaster оставляю для доказанной недоступности аутентификации без здорового пути. Эти уровни калибруются по конкретной архитектуре. Trigger dependencies повторяют направление цепочки: недоступный или просроченный коллектор подавляет выводы из старых dependent items; подтверждённая потеря репликационного пути удерживает производные уведомления о данных этого контроллера; ошибка DNS-обнаружения подавляет отдельный вызов по синтетическому Kerberos-тесту, но не стирает его историю. Я не создаю циклические зависимости и не скрываю независимый отказ второго слоя. Recovery разрешаю только на новом значении соответствующего источника. Теги `layer`, `dc`, `site`, `partner` и `naming_context` позволяют группировать события и строить панель от причины к пользовательскому эффекту.

Альтернативы выбираю по доступности и цене доказательства

Не в каждой среде можно безопасно запускать repadmin из-под агента. Тогда я выношу фиксированный скрипт в планировщик Windows, подписываю его, ограничиваю права и даю Zabbix читать только итоговый JSON и возраст файла. Это слабее прямого контроля кода возврата, поэтому freshness становится обязательным. Для событий можно использовать локальные active checks или утверждённую систему Windows Event Forwarding, но Zabbix agent не читает журнал Forwarded Events через eventlog item, и эту границу учитываю заранее. DCDiag полезен как периодическая широкая проверка, однако он тяжелее точечных команд и не должен запускаться часто без замера длительности. Синтетический вход можно заменить проверкой обнаружения DC и наличия KDC, если политика запрещает тестовую учётную запись; тогда честно обозначаю, что финальный шаг не подтверждён. Если нет прав на WMI-состояние DFSR, остаются события и shares, но уверенность ниже. Я выбираю вариант, который даёт проверяемое evidence без расширения привилегий и воздействия на домен.

Стоп-критерии отделяют наблюдение от опасного ремонта

Я прекращаю расширение шаблона, если не подтверждён полный список контроллеров и сайтов, коллектор требует Domain Admin, команда допускает произвольные параметры, время источников нельзя сопоставить или результат старого запуска выглядит свежим. Другой стоп-критерий — неоднозначный authoritative-контроллер при проблеме SYSVOL: мониторинг не выбирает источник истины. Не продолжаю controlled test при неожиданной блокировке тестовой учётной записи, росте очереди агента, длительном RPC-вызове, появлении чувствительных данных в history или множестве unsupported items. Во время инцидента останавливаю причинный вывод, когда upstream-слой имеет unknown: из отсутствующих данных нельзя заключать, что downstream исправен или неисправен. Любая идея изменить DNS-запись, запустить syncall, возобновить DFSR, поправить SPN, сбросить secure channel или синхронизировать часы становится отдельной операционной работой с владельцем, резервной копией и планом возврата. Эта дисциплина сохраняет роль Zabbix: он показывает доказанную границу отказа и последовательность, но не маскирует причину автоматическим лечением.

Откат возвращает наблюдение, а вывод сохраняет причинность

До подключения сохраняю экспорт шаблона, конфигурацию агента, контрольную сумму коллектора, права файлов, macros, preprocessing и зависимости triggers. Если пилот даёт шум или влияет на узел, отключаю новые active checks и master item, возвращаю предыдущую конфигурацию и подтверждаю прекращение запусков. Затем проверяю, что старые items снова обновляются, очередь не растёт, а временная read-only роль отозвана. Инфраструктуру этим откатом не трогаю: службы, репликация, DNS, DFSR, SYSVOL, KDC, SPN и время остаются в исходном состоянии. В итоге моя панель читается слева направо: сходимость каталога, обнаружение через DNS, готовность SYSVOL, возможность аутентификации. Для каждого перехода видны freshness, источник и класс ошибки, а runbook начинается с первого неподтверждённого звена. Эту причинную модель применяю при разборе каждого неподтверждённого перехода цепочки. Основа материала: Практика внедрения IT Fresh. Обсудить внедрение можно через https://itfresh.ru/ , написать мне — https://t.me/ITfresh_Boss , позвонить — tel:+79037296241.

Отвергнутые альтернативы

• Считать доступность LDAP достаточным признаком здоровья доменаLDAP-сеанс с одним контроллером не доказывает сходимость разделов каталога, корректность DNS-рекламы, готовность SYSVOL и успешную клиентскую аутентификацию.
• Оповещать о каждой ошибке repadmin как об отдельной аварииОдин сетевой или DNS-сбой способен затронуть несколько naming contexts и партнёров. Без группировки получается каскад производных событий вместо границы отказа.
• Проверять SYSVOL только по наличию общей папкиРесурс может оставаться опубликованным при проблеме DFSR или устаревшем содержимом. Нужны состояние репликации, свежие события и согласованность с каталогом.
• Исправлять проблему принудительной синхронизацией из мониторингаКоманда изменения может скрыть первопричину, выбрать неверное направление и повредить данные. Zabbix должен собирать evidence, а не принимать роль оператора восстановления.
• Считать любой отказ входа ошибкой KDCДо KDC клиент зависит от DNS, выбора контроллера и времени, а после выдачи билета — от имени службы, SPN и целевого сервера. Класс ошибки определяет ветвь проверки.

Конфигурация и сбор

Сбор выполняется отдельной учётной записью с минимальными правами на чтение состояния каталога, DNS, служб, общих ресурсов и журналов событий. Коллектор не запускает синхронизацию, не изменяет зоны, записи, членство DFSR, политики, SPN, пароли или время. Разрешённые команды фиксированы, их параметры не поступают от входных данных Zabbix.

• Составить инвентарь контроллеров, сайтов, ожидаемых naming contexts, партнёров входящей репликации, DNS-зон и точки клиентской проверки.
• На каждом контроллере получить одним фиксированным PowerShell-скриптом JSON со временем сбора, результатами read-only команд и явными кодами unknown для недоступных проверок.
• Передать JSON master item, а значения репликации, DNS, SYSVOL, DFSR, служб и аутентификации выделить dependent items с fail-closed preprocessing.
• Настроить теги слоя и контроллера, уровни событий, hysteresis и trigger dependencies только после сопоставления ручного вывода с историей Zabbix.

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

Пилот начинаю на одном согласованном контроллере и одной выделенной доменной тестовой учётной записи без административных прав. Сначала дважды сравниваю read-only вывод с dependent items и проверяю свежесть. Негативные ветви воспроизвожу на сохранённых обезличенных JSON: отсутствующий партнёр, просроченный timestamp, ошибку DNS, отсутствие SYSVOL и отказ получения билета. Реальную репликацию, DFSR, DNS, службу KDC или часы ради теста не останавливаю. Допустимая сквозная проверка — разрешение доменных SRV из клиентской точки, обнаружение контроллера и получение билета тестовой учётной записью без обращения к рабочим данным. Если проверка создаёт блокировку, неожиданный аудит или нагрузку, тест прекращаю.

Фрагмент рабочего регламента

• Проверить свежесть master item, код возврата коллектора и часы источника; при nodata остановить причинный вывод по сохранённым значениям.
• Разобрать входящую репликацию по каждому контроллеру, naming context и source DSA: последний успех, последовательные ошибки и код результата.
• Из той же точки проверить ожидаемые LDAP и Kerberos SRV, их цели и адреса, затем сопоставить их с инвентарём сайтов и контроллеров.
• Проверить службы DFSR и Netlogon, наличие SYSVOL и NETLOGON, состояние replicated folder и относящиеся к окну события DFS Replication.
• С клиентской точки определить выбранный контроллер, проверить разрешение имени, рассинхронизацию времени и итог получения Kerberos-билета тестовой учётной записью.
• Зафиксировать первый сломанный переход цепочки; изменения репликации, DNS, DFSR, SPN и времени вынести в отдельный согласованный план.

Откат

Перед пилотом экспортирую прежний template и фиксирую конфигурацию агента, UserParameter, macros, preprocessing, discovery, triggers, dependencies и права учётной записи. Откат отключает новые active checks и master item, отвязывает только пилотный template, возвращает предыдущие интервалы и выражения, затем подтверждает поступление прежних данных без роста unsupported items. Временную read-only роль и разрешение сети удаляет владелец после проверки отсутствия обращений. Откат мониторинга не запускает репликацию, не перезапускает DFSR, Netlogon, DNS или KDC, не меняет SYSVOL, SPN и часы. Если инфраструктурный дефект остаётся, я фиксирую его отдельно: возврат наблюдения не является восстановлением доменной службы.

Ограничения вывода

Команды диагностики показывают состояние в момент запуска и не заменяют разбор топологии, журналов, сетевого пути и изменений. Успешная входящая репликация не доказывает исходящую доступность каждого партнёра. Наличие SRV не подтверждает достижимость указанного узла. Общие ресурсы SYSVOL и NETLOGON не доказывают тождество содержимого. Полученный Kerberos-билет не подтверждает доступ ко всем службам и корректность каждого SPN. Состав каналов событий и доступность счётчиков зависят от поддерживаемой версии Windows Server и настроенного аудита. Порог возраста и длительность подтверждения определяются топологией сайтов, расписанием и базовой линией конкретной среды; отсутствие данных всегда остаётся unknown, а не нормой.