DC виснет на логоне: как я лечил переполнение Security Log у клиента

Меня зовут Семёнов Евгений Сергеевич, я директор АйТи Фреш. За 15 лет обслуживания AD-доменов в Москве я разобрал сотни случаев странного поведения контроллеров. Один из самых коварных — когда DC работает вроде нормально, но пользователи по утрам стоят и ждут по 3–5 минут, прежде чем логин пройдёт. В 80 % случаев это переполненный Security Log. Рассказываю, как я это ловил, лечил и как предотвращаю повторение.

Первый звонок от клиента: «После 9:00 вся работа встаёт»

Понедельник, 9:15 утра. Мне звонит директор производственной компании в Химках, 42 рабочих места, два контроллера домена Windows Server 2019. Возмущённым голосом: «У нас с пятницы какой-то ужас. Утром люди приходят, пытаются войти — минут по пять ждут, некоторые не могут войти вообще. Бухгалтер орёт, склад простаивает. Что это у вас?»

Сажусь за ноутбук, подключаюсь по RDP к основному DC01. Windows открывается за 30 секунд — никаких висяков. Запускаю Event Viewer — и там первый же сигнал: журнал Security отображается пустым. Странно. Смотрю свойства:

Log size: 20 MB
Current size: 20.00 MB
Oldest event: 08.04.2026 05:13:27
Retention policy: Overwrite events as needed

20 MB лога, последнее событие 5 утра. При 42 активных пользователях и стандартной настройке аудита за час генерируется 15–25 тысяч событий, а 20 MB лога хватает примерно на 20–30 тысяч событий. То есть лог ротируется каждые час-полтора — звучит безобидно, но иногда приводит к блокировкам LSA-сервиса при записи.

Почему DC зависает при переполненном логе

Проблема в архитектуре. Процесс LSASS (Local Security Authority), который обрабатывает все аутентификации в домене, при каждом успешном и каждом неуспешном логине вызывает API AuthzReportSecurityEvent для записи аудита в Security Log. Если лог переполнен и политика — «перезаписывать по мере необходимости», то LSASS:

1. Захватывает эксклюзивный lock на файл лога.
2. Пытается найти самое старое событие для перезаписи.
3. Если индекс лога фрагментирован — операция занимает 500–1500 миллисекунд.
4. Во время lock все остальные потоки LSASS ждут.
5. Параллельно приходят логоны от 30 пользователей в 9:05 — они выстраиваются в очередь.

В результате первый пользователь входит за 3 секунды, десятый за 40 секунд, двадцатый — за 3 минуты, а тридцатый получает таймаут на стороне клиента с ошибкой «Сервер отклонил попытку входа».

Диагностировать проблему помогает счётчик Security System-Wide Statistics\Authentication Packages и Performance Counter LSASS\PrivateBytes — если видите, что LSASS выжирает RAM и CPU при одновременных логонах — проблема точно в журнале или в дефрагментированной NTDS.

Диагностика: три команды, которые решают 80 % случаев

Когда приезжаю к клиенту с такой жалобой, первым делом выполняю на DC:

# 1. Размер и состояние Security Log
Get-WinEvent -ListLog Security | Format-List *

# 2. Статистика событий за последний час
Get-WinEvent -FilterHashtable @{LogName='Security'; StartTime=(Get-Date).AddHours(-1)} |
    Group-Object Id | Sort-Object Count -Descending | Select-Object -First 10

# 3. Конкретно что генерирует больше всего событий
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=(Get-Date).AddHours(-1)} |
    Select-Object -ExpandProperty Properties |
    Group-Object Value | Sort-Object Count -Descending | Select-Object -First 10

У клиента в Химках вывод был таким: 73 % событий — это 4624 (успешный логон), причём 60 % от одной учётной записи sv_1c_agent. Оказалось, на сервере 1С стоял агент Zabbix, который раз в 10 секунд через WMI подключался к DC для чтения групп пользователей. 6 подключений в минуту × 60 × 24 = 8 640 событий в сутки только от одной учётки. Плюс ещё семь таких же сервисов — и получаем 60+ тысяч событий ежедневно.

Быстрое решение: расширяем лог и чистим

Немедленно снимаем боль. Увеличиваем размер Security Log до 4 GB и переводим политику на «архивировать при заполнении, не перезаписывать».

# Увеличиваем размер до 4 GB
wevtutil sl Security /ms:4294967296

# Автоматически архивировать при заполнении
wevtutil sl Security /ab:true /rt:false

# Создаём папку для архивов
New-Item -Path C:\EventLogArchive\Security -ItemType Directory -Force

# Прописываем путь архивов через реестр
Set-ItemProperty `
    -Path "HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\Security" `
    -Name "AutoBackupLogFiles" -Value 1 -Type DWord

# Экспортируем текущий лог в архив
wevtutil epl Security C:\EventLogArchive\Security\Security-$(Get-Date -Format yyyy-MM-dd).evtx

# Чистим активный лог
wevtutil cl Security

После этой последовательности пользователи начинают входить нормально. Продолжительность процедуры — 3–5 минут. Клиенту возвращаются деньги в виде не потерянного рабочего времени.

Долгосрочное решение: снижаем шум в логе

Просто расширить лог — это лечение симптома. Настоящая проблема — избыточный аудит. На DC по умолчанию включены слишком много категорий, и половина из них для небольшого офиса не нужны. Я пересматриваю advanced audit policy и отключаю всё лишнее.

В gpedit для GPO Default Domain Controllers Policy иду в:

Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Audit Policies

Моя стандартная конфигурация для офиса 20–60 пользователей:

После применения такой политики объём генерируемых событий на типовом DC снижается в 5–10 раз. У клиента в Химках после перенастройки Security Log стал заполняться вместо 90 минут — раз в 18 часов.

Централизованный сбор логов: Wazuh или WEF

Если клиент крупнее 50 человек или есть требования compliance — локального лога мало. Нужен централизованный сбор. Два рабочих варианта из моей практики:

Windows Event Forwarding (WEF) — встроенное в Windows решение. Один сервер-коллектор собирает Subscription-события со всех DC и серверов. Плюс: бесплатно, нативно, работает стабильно. Минус: нет встроенного поиска и алертов — нужны сторонние парсеры.

Wazuh — open-source SIEM, бесплатный и мощный. Ставится на отдельный Linux-сервер (2 vCPU, 4 GB RAM хватает для офиса 50 ПК), на DC ставится Winlogbeat или Wazuh Agent, события шифрованно отправляются в SIEM. Поиск по логам через Kibana, готовые алерты на brute-force, изменение admin-групп, несанкционированные логины в нерабочее время.

Для клиента в Химках я развернул Wazuh на виртуалке Hyper-V. Теперь у них:

• Security Log на DC вмещает 8 часов активных событий (≈1 GB).
• Архивные копии автоматически создаются при заполнении.
• Через WEF всё собирается в Wazuh на отдельном сервере.
• В Wazuh настроены алерты на Telegram: событие 4740 (блокировка аккаунта), 4625 (неуспешный логон) более 20 раз в минуту, 4728 (добавление в admin-группу).

Мониторинг, который предупреждает проблему заранее

Лучшее лечение — профилактика. У меня на каждом DC клиентов стоит Zabbix-агент с шаблоном «Template OS Windows by Zabbix agent». Я добавил туда три кастомных элемента:

# Использование Security Log (%)
UserParameter=security.log.percent,(Get-WinEvent -ListLog Security).FileSize / `
    (Get-WinEvent -ListLog Security).MaximumSizeInBytes * 100

# Events per hour (последний час)
UserParameter=security.events.hourly,(Get-WinEvent -FilterHashtable @{LogName='Security'; `
    StartTime=(Get-Date).AddHours(-1)}).Count

# Время ответа LSASS на аутентификацию
UserParameter=lsass.logon.time,(Measure-Command { `
    Test-ComputerSecureChannel }).TotalMilliseconds

Триггеры:

• Security Log заполнен больше чем на 80 % — warning, на Telegram.
• Security Log заполнен больше чем на 95 % — disaster, SMS директору АйТи Фреш.
• События в час больше 50 000 — warning (аномалия, разобраться).
• Время ответа LSASS больше 3 секунд — warning (возможный висяк логона).

Благодаря этому мониторингу за последние 14 месяцев у клиентов на обслуживании не случилось ни одного повторения ситуации «DC виснет по утрам».

Что я изменил в стандарте обслуживания после этого случая

Этот кейс стал для меня поводом переписать наш внутренний чек-лист первичного аудита AD-инфраструктур. Теперь при приёме нового клиента я обязательно проверяю:

1. Размер всех Event Log на DC (Security, System, Application, Directory Service).
2. Политики аудита — нет ли избыточно включённых категорий.
3. Учётные записи с аномально высоким количеством логонов (часто это забытые сервисные аккаунты).
4. Наличие процесса архивирования логов.
5. Последнюю проверку времени отклика LSASS под нагрузкой.

На новом клиенте с 30+ пользователями и AD такой аудит занимает 2 часа и входит в стоимость первичного обследования (бесплатно). В 7 из 10 случаев находим переразмер аудита или переполненные логи — и чиним до того, как они начинают реально мешать работе.

FAQ — частые вопросы по Security Log

Почему Security Log на DC может переполниться?

Стандартный размер Security Log — 20 MB, это хватает на 20–40 тысяч событий. На DC с 50+ пользователями при стандартном аудите лог заполняется за 2–3 часа, после чего система начинает тормозить.

Какой оптимальный размер Security Log для DC?

Для домена до 100 пользователей я ставлю 2 GB, для 100–500 — 4 GB, для 500+ — 8 GB. Политика перезаписи — «перезаписывать по мере необходимости», если нет требований по хранению логов по compliance.

Опасно ли очищать Security Log?

Если нет требований на сохранение — безопасно. Перед очисткой я всегда делаю экспорт в .evtx для архива. В регулируемых отраслях (финансы, медицина) лог чаще отправляется в SIEM-систему и хранится там.

Нужен ли централизованный сбор логов через SIEM?

Для офиса до 50 человек обычно нет — достаточно увеличить размер локального лога. Для средних компаний (50–200 человек) рекомендую Wazuh или ElasticSearch + Winlogbeat — бесплатно и решает задачу compliance.

Как предотвратить повторение проблемы?

Мониторинг свободного места в логе, алерты при заполнении на 80 %, автоматический архивный экспорт при ротации. В Zabbix есть готовый шаблон для Windows Event Log мониторинга.