Найти источник блокировки учетной записи в Active Directory

Аудит сетевых ресурсов и точная информация об устройствах вашей сети необходимы для безопасности и оперативной работы. ADAudit Plus — инструмент с профессиональными возможностями, который предоставляет:

• Отслеживание и мониторинг изменений в документах
• Детальную сводку активности входов и выхода пользователей
• Соответствие требованиям SOX, PCI, HIPAA, GDPR и другим
• Простую и быструю установку

Получите удобный инструмент аудита для инфраструктуры. Попробуйте ADAudit Plus.

Аудит Active Directory важен, потому что он помогает проверить права доступа, отслеживать создание новых учетных записей и быстро находить причины сбоев доступа. По умолчанию Active Directory не регистрирует все события безопасности. Если вам нужно развернуть AD, у нас есть руководство по установке Active Directory на Windows Server.

Одна из распространённых задач администратора — определить источник частых блокировок учётных записей. Ниже — три надёжных способа: через редактор групповой политики, через PowerShell и через специализированный инструмент.

Как найти источник блокировки учётной записи Active Directory

1. Использование редактора групповой политики

1. Войдите на контроллер домена с правами администратора.
2. Нажмите Win + R для открытия окна Выполнить.
3. Введите gpedit.msc и нажмите Enter.
4. Разверните раздел «Computer Configuration».
5. Выберите «Windows Settings».
6. Разверните «Security Settings».
7. Выберите «Local Policies».
8. Нажмите на «Audit Policy».
9. Откройте «Audit process tracking» и отметьте «Success» и «Failure».
10. Нажмите OK.
11. Откройте «Audit logon events» и отметьте «Success» и «Failure».
12. Нажмите OK.
13. Нажмите клавишу Win и откройте Event Viewer.
14. Перейдите в журнал Security и ищите события с кодом 4625 (failed logon) и 4740 (account locked out).
15. По событиям вы найдёте машину-источник или сервис, который вызывает блокировку.

Важно: включение аудита может быстро увеличить объём логов. Планируйте хранение и ротацию логов заранее.

2. Использование Windows PowerShell

1. Откройте меню Пуск и запустите Windows PowerShell от имени администратора.
2. Установите модуль Active Directory, если он не установлен, командой:

Install-WindowsFeature RSAT-AD-PowerShell

3. Проверьте установку:

Get-WindowsFeature -Name RSAT-AD-PowerShell

4. Найдите заблокированные аккаунты:

Search-ADAccount -LockedOut | FT Name,ObjectClass -A

Этот метод быстро даёт список заблокированных учётных записей. Однако он не указывает, откуда пришли неверные попытки входа. Для этого нужно смотреть события безопасности на контроллерах домена (4625/4740) и/или кореллировать логи.

3. Использование специализированного инструмента

1. Скачайте ManageEngine ADAudit Plus.
2. Установите программу.
3. Запустите приложение.
4. Нажмите Reports в верхнем меню.
5. Выберите Active Directory.
6. Перейдите в User Management.
7. Откройте Account Lockout Analyzer.
8. Нажмите Details в разделе ANALYZER DETAILS.
9. В отчёте вы увидите возможные причины каждой блокировки.

Используя ADAudit Plus, вы получаете не только список заблокированных учётных записей, но и коррелированные данные: какую машину или сервис инициировал неудачные входы, время, частоту и предполагаемую причину. Это сокращает время расследования и повышает эффективность службы поддержки.

Over 10,000+ организаций по всему миру используют ManageEngine ADAudit Plus с Active Directory.

Как проводить анализ блокировок: пошагово

1. Откройте Account Lockout Analyzer и отфильтруйте по аккаунту.
2. Посмотрите секцию Recent Logon — она обычно даёт ключ к источнику.

Ключевые поля для анализа:

• User name — имя аккаунта
• Client IP address — IP машины-источника
• Client host name — имя хоста
• Domain controller — контроллер, на котором зарегистрировалась попытка
• Logon time — время попытки
• Event type — тип события (например, failed logon)
• Failure reason — причина отказа (пароль неверен, учётная запись истекла и т.д.)
• Event number — код события (4625, 4740 и т.д.)

3. Экспортируйте отчёт в CSV/PDF/XML/HTML для передачи в службу поддержки или для архивации.
4. Сопоставьте время блокировок с журналами приложений и планировщиками задач (службы, которые могут использовать старые пароли).
5. Установите источник: устройство пользователя (например, мобильный клиент с кешированным паролем), служба/сервер или внешний сервис (VPN, MDM).
6. Устраните причину: сброс пароля, обновление сохранённых учётных данных в сервисе, изменение политики блокировки.

Важно: частые блокировки указывают на автоматическую систему (службу, скрипт или устройство) с устаревшими учётными данными. Ручные ошибки обычно реже и нерегулярны.

Таблица соответствия основных Event ID

Эти события помогут понять цепочку: сначала 4625 — повторяющиеся неудачные входы, затем 4740 — срабатывание блокировки.

Практическое руководство расследования (playbook)

1. Получите имя заблокированного аккаунта.
2. На контроллере домена найдите события 4740 и связанные с ними 4625 в окне ±10 минут.
3. Определите Client IP и hostname.
4. Проверьте, какой сервис/устройство использует этот хост (почтовый клиент, мобильное устройство, синхронизатор, скрипт).
5. Если источник — пользовательское устройство, попросите пользователя:
   • выйти и снова войти в приложения;
   • обновить сохранённые пароли;
   • перезагрузить устройство.
6. Если источник — сервер/служба, обновите учётные данные в конфигурации службы и перезапустите сервис.
7. После исправления мониторьте наличие повторных блокировок в течение 24–72 часов.

Чек-листы по ролям

Администратор:

• Включить аудит входов и процессов.
• Проверить журналы контроллеров домена (4625, 4740).
• Проверить период хранения логов и ротацию.

Helpdesk:

• Получить скрин или отчёт с датой/временем блокировки.
• Спросить пользователя об изменениях пароля и устройствах.
• Очистить кеш учётных данных на устройстве пользователя.

Команда безопасности:

• Проверить подозрительную активность с IP источника.
• Поднять инцидент, если наблюдаются массовые неудачные входы.
• Настроить предупреждения на SIEM.

Когда этот подход не подходит

• Если у вас гибридная среда с Azure AD Connect и причиной блокировок является облачный сервис — потребуется анализ логов Azure AD.
• При распределённых контроллерах с задержками репликации события могут появляться на разных контроллерах; нужно проверять все контроллеры.
• Если логов недостаточно (аудит не включён) — сначала включите аудит и накопите данные.

Альтернативные инструменты и подходы

• Нативный просмотр Security журналов через Event Viewer.
• PowerShell-скрипты и EventComb (утилиты для выборки событий).
• SIEM-системы для корреляции логов (Splunk, ELK, Microsoft Sentinel).
• Инструменты MDM/Endpoint для определения мобильных источников.

Схема принятия решений

flowchart TD
  A[Начало расследования] --> B{Есть событие 4740?}
  B -- Нет --> C[Проверить 4625 и аудит]
  B -- Да --> D[Получить Client IP/hostname]
  D --> E{Источник сервер или клиент?}
  E -- Клиент --> F[Helpdesk: очистить кеш, перезапустить]
  E -- Сервер/служба --> G[Админ: обновить учётные данные сервиса]
  F --> H[Мониторинг 24–72 ч]
  G --> H
  C --> I[Включить аудит и ждать данных]
  I --> H

Критерии приёмки

• Источник блокировки идентифицирован (IP/hostname или служба).
• Повторные блокировки прекратились в течение 72 часов.
• Произведены исправления (обновление пароля в сервисах, очистка кеша на устройствах).
• Документирован инцидент и добавлены предупреждения/алерты на будущее.

Краткая методика предотвращения повторных блокировок

• Ограничьте число неудачных попыток до разумного значения.
• Контролируйте сервисы и учётные записи с високими правами.
• Внедрите мониторинг и оповещения по 4625/4740.
• Проводите периодические проверки сохранённых учётных данных на серверах и в планировщике задач.

Сводка

• Включите аудит входов и процессов, чтобы собирать необходимые события.
• Для быстрой идентификации используйте ADAudit Plus или эквивалентный инструмент для корреляции логов.
• PowerShell удобен для быстрого списка заблокированных аккаунтов, но не даёт источник блокировки по умолчанию.
• Следуйте playbook и чек-листам по ролям, чтобы ускорить восстановление доступа и минимизировать простои.

Если у вас есть опыт с одним из описанных методов, напишите, какой именно вы использовали и какие результаты получили. Это поможет другим выбрать оптимальный подход.