Картина знакома многим системным администраторам: утро понедельника, сотрудники приходят на работу, начинают логониться — и вдруг всё замирает. Профиль грузится минуту, две, три. Иногда вход вообще не завершается. При этом диспетчер задач показывает нормальную загрузку процессора и памяти на контроллере домена, сеть не перегружена, репликация с виду в порядке. Виновник чаще всего скрывается не там, где его ищут — в переполненном журнале безопасности Windows. Этот материал разберёт проблему досконально: почему журнал Security Log блокирует логон, как это диагностировать за пять минут и что сделать, чтобы ситуация не повторилась.

Почему переполненный журнал блокирует вход в систему

В Windows Server существует групповая политика «Audit: Shut down system immediately if unable to log security audits» (в русскоязычном интерфейсе — «Аудит: немедленно отключить систему, если невозможно внести в журнал записи об аудите безопасности»). По умолчанию она отключена, но сама по себе переполненность журнала создаёт другую проблему.

Когда журнал Security достигает максимального размера и для него установлена политика хранения «Do not overwrite events» (не перезаписывать события), Windows прекращает принимать новые записи аудита. Подсистема Local Security Authority (LSA), которая отвечает за проверку учётных данных и выдачу токена при логоне, пытается зафиксировать события аудита входа (Event ID 4624, 4634, 4648 и др.) — и зависает в ожидании, когда журнал освободится. Результат: процедура входа пользователя зависает на десятки секунд или вовсе не завершается.

На практике это выглядит так: экран «Добро пожаловать» или «Подготовка рабочего стола» висит неприлично долго, Winlogon.exe потребляет нетипично высокий CPU, а пользователи звонят в техподдержку с жалобами на «зависший компьютер», хотя проблема — целиком на стороне контроллера домена.

Шаг 1. Быстрая диагностика — проверяем состояние журнала

Первым делом нужно убедиться, что причина именно в переполненном журнале. Откройте PowerShell от имени администратора на контроллере домена и выполните:

Get-WinEvent -ListLog Security | Select-Object LogName, RecordCount, MaximumSizeInBytes, IsLogFull

Команда вернёт одну строку. Обратите внимание на поле IsLogFull: если оно равно True — диагноз поставлен. Поле MaximumSizeInBytes покажет текущий лимит (по умолчанию обычно 20 МБ — ничтожно мало для нагруженного DC), а RecordCount — количество записей в журнале.

Для более детальной проверки посмотрите на политику перезаписи:

Get-WinEvent -ListLog Security | Select-Object LogName, LogMode, MaximumSizeInBytes

Поле LogMode может принимать значения:

Если видите Retain — именно это и вызывает зависание. Задача: либо срочно очистить журнал, либо изменить режим, либо и то и другое.

Шаг 2. Срочное решение — очищаем журнал

Если логоны сейчас зависают и нужно восстановить работу немедленно — очищайте журнал. Важно: перед очисткой сохраните архив, чтобы не потерять записи аудита (это может быть важно для compliance и расследований инцидентов).

Вариант А — через wevtutil (быстро, из командной строки)

Сначала сохраняем архив:

wevtutil epl Security C:\Logs\Security_backup_%DATE:~6,4%%DATE:~3,2%%DATE:~0,2%.evtx

Затем очищаем:

wevtutil cl Security

Команда выполняется секунды. После неё журнал пуст и готов принимать новые события — логоны пользователей немедленно ускорятся.

Вариант Б — через PowerShell

$log = [System.Diagnostics.Eventing.Reader.EventLogConfiguration]::new("Security")
$log.IsEnabled  # убедиться, что журнал активен
Clear-EventLog -LogName Security

Шаг 3. Увеличиваем размер журнала

Очистка — это тактическое решение, которое даст вам время. Стратегически нужно увеличить размер журнала до разумного значения. Для нагруженного контроллера домена рекомендуемый минимум — 512 МБ, для крупных инфраструктур — 1–4 ГБ.

Установить размер через wevtutil:

wevtutil sl Security /ms:524288000

Здесь /ms: — это максимальный размер в байтах. Формула простая: нужные мегабайты умножаем на 1 048 576. Примеры:

Тот же результат через групповую политику (более правильный путь для доменной среды):

Computer Configuration → Policies → Windows Settings → Security Settings → Event Log, параметр Maximum security log size. Задайте значение в килобайтах: для 512 МБ введите 524288.

Шаг 4. Меняем политику перезаписи

Изменить режим перезаписи на «Circular» через wevtutil:

wevtutil sl Security /rt:false

Флаг /rt:false отключает режим «Retain» (не перезаписывать) и переключает на стандартную циклическую перезапись — старые события начнут вытесняться новыми, когда журнал заполнится. Для большинства организаций это правильное поведение.

Через групповую политику: тот же раздел Event Log, параметр Retention method for security log — установите Overwrite events as needed.

Шаг 5. Настраиваем автоматическую архивацию

Идеальное решение — не просто увеличить журнал, а настроить автоматическое архивирование по расписанию. Создайте задачу в Task Scheduler, которая еженедельно сохраняет архив и при необходимости очищает журнал.

Скрипт для Task Scheduler (сохраните как C:\Scripts\backup-security-log.ps1):

# Создаём папку для архивов, если не существует
$archiveDir = "C:\Logs\SecurityArchive"
if (-not (Test-Path $archiveDir)) { New-Item -ItemType Directory -Path $archiveDir }

# Имя файла с датой и временем
$timestamp = Get-Date -Format "yyyy-MM-dd_HH-mm"
$archivePath = "$archiveDir\Security_$timestamp.evtx"

# Экспортируем журнал
wevtutil epl Security $archivePath

# Проверяем заполненность — если более 80%, очищаем
$log = Get-WinEvent -ListLog Security
$fillPercent = ($log.RecordCount / 100000) * 100  # примерный порог
if ($log.IsLogFull) {
    Write-Host "Журнал переполнен, выполняем очистку..."
    wevtutil cl Security
}

Write-Host "Архив сохранён: $archivePath"

Зарегистрируйте задачу:

$action = New-ScheduledTaskAction -Execute "PowerShell.exe" `
    -Argument "-NonInteractive -File C:\Scripts\backup-security-log.ps1"
$trigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Sunday -At "03:00"
$settings = New-ScheduledTaskSettingsSet -RunOnlyIfNetworkAvailable $false
Register-ScheduledTask -TaskName "BackupSecurityLog" -Action $action `
    -Trigger $trigger -Settings $settings -RunLevel Highest -Force

Шаг 6. Снижаем объём событий аудита

Ещё один подход к проблеме — разобраться, почему журнал заполняется так быстро. Часто оказывается, что включены избыточные категории аудита. Посмотрите, что сейчас включено:

auditpol /get /category:*

Обратите внимание на категории, которые генерируют тысячи событий в час:

• Detailed Tracking → Process Creation — полезно для расследований, но очень шумно
• Object Access → File System — если включён на системных дисках, создаёт лавину событий
• DS Access → Directory Service Access — аудит обращений к объектам AD, может быть избыточным

Отключить конкретную субкатегорию:

auditpol /set /subcategory:"Process Creation" /success:disable /failure:disable

Сделайте это через групповую политику, чтобы настройки не слетали: Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration.

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

После применения всех настроек убедитесь, что всё работает корректно:

# Проверяем состояние журнала
Get-WinEvent -ListLog Security | Select-Object LogName, RecordCount, MaximumSizeInBytes, IsLogFull, LogMode

# Смотрим последние 10 событий входа
Get-WinEvent -LogName Security -MaxEvents 10 | Where-Object {$_.Id -eq 4624} |
    Select-Object TimeCreated, Message | Format-List

Попросите кого-нибудь из пользователей выйти и снова войти — логон должен занять не более 10–20 секунд в нормальной доменной среде.

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

• Установите размер Security Log не менее 512 МБ на каждом DC
• Используйте режим «Overwrite» или «AutoBackup», но не «Retain» без централизованного сбора логов
• Настройте мониторинг заполненности журнала: Event ID 1104 (журнал очищен) и Event ID 1102 (аудит отключён) — маркеры проблем
• Создайте алерт, когда журнал заполнен на 80% — через SCOM, Zabbix, или простой скрипт по расписанию
• Ежеквартально пересматривайте политики аудита: отключайте шумные категории, которые реально не используются в расследованиях
• Если DC несколько — применяйте настройки через GPO, а не вручную на каждом сервере

Итоги

Переполненный журнал безопасности — одна из тех проблем, которые не бросаются в глаза при первичной диагностике, потому что CPU, RAM и сеть выглядят нормально. Но именно она способна парализовать вход сотен пользователей в самый неудобный момент. Алгоритм действий прост: проверить состояние журнала командой Get-WinEvent -ListLog Security, очистить через wevtutil cl Security, поднять лимит до 512 МБ+, переключить режим на Circular и настроить автоархивацию. Этот набор мер займёт 20 минут, но избавит вас от внеплановых инцидентов на годы вперёд.