Event ID 4767: Учетная запись разблокирована (Account Unlocked)
Архитектура блокировок AD и симптомы
Событие 4767 логируется в журнале Security на контроллерах домена, когда с учетной записи пользователя снимается блокировка (Account Unlocked). Это парное (антонимичное) событие для 4740 (Account Locked Out). Блокировка в AD возникает автоматически при превышении порога неверных паролей (Account Lockout Threshold), а разблокировка может происходить как автоматически (по истечении времени), так и вручную администратором.
Типы разблокировки (Ручная vs Системная)
| Инициатор (Subject) | Что это означает |
|---|---|
| Имя Администратора (например, Admin_IT) | Сотрудник техподдержки вручную зашел в ADUC (dsa.msc) и снял галочку 'Unlock account'. Это должно сверяться с заявкой в HelpDesk. |
| NT AUTHORITY\SYSTEM | Истекло время автоматической блокировки (Account lockout duration), заданное в GPO. Ядро контроллера домена само разблокировало пользователя. |
| Учетная запись IAM-системы (например, svc_idm) | Сработал скрипт портала самообслуживания (SSPR), где пользователь сам сбросил себе пароль через СМС/Почту. |
Пошаговое дерево решений (Мониторинг HelpDesk)
Сценарий 1: Аудит ручных разблокировок (SIEM)
Ручная разблокировка УЗ без смены пароля — это риск. Если учетку заблокировал хакер (Brute-force), а админ просто снял блок по просьбе 'по телефону', хакер продолжит перебор.
Скрипт мониторинга (PowerShell):# Поиск ручных разблокировок за 24 часа (Исключаем SYSTEM)
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4767; StartTime=(Get-Date).AddDays(-1)} |
Where-Object {$_.Properties[4].Value -notmatch 'SYSTEM'} |
Select-Object TimeCreated,
@{N='TargetUser';E={$_.Properties[0].Value}},
@{N='AdminWhoUnlocked';E={$_.Properties[4].Value}} | Format-Table -AutoSizeСценарий 2: Расследование 'Пинг-Понг' блокировок
Если в логах вы видите цикл: 4740 -> 4767 -> 4740 -> 4767 каждые 5 минут, значит администратор снимает блокировку, но не устраняет причину. Устройство с 'залипшим' старым паролем (например, смартфон с Exchange ActiveSync или зависшая служба) немедленно блокирует учетку снова. Решение: Найдите источник блокировки в событии 4740 (Caller Computer Name) и очистите Диспетчер учетных данных (Credential Manager) на этом устройстве.
Типовые ошибки администраторов
- Ожидание 4767 при смене пароля: Сброс пароля (Событие 4724) не снимает блокировку автоматически! Администратор должен явно поставить галочку 'Разблокировать учетную запись' в ADUC, иначе пользователь с новым паролем все равно получит ошибку 'Учетная запись заблокирована'.
Ручной сброс паролей и разблокировки 'съедают' до 30% времени ИТ-отдела. Делегируйте рутину инженерам ITSTM: мы внедрим портал самообслуживания (SSPR), защитим периметр от брутфорс-атак и настроим автоматизированные пайплайны IAM.
Частые вопросы (FAQ)
Почему 4767 не содержит IP-адрес администратора?
События Directory Service Access (к которым относится 4767) логируются на уровне базы NTDS.dit. База не знает, откуда пришел RPC-запрос. Чтобы найти IP, сопоставьте поле 'SubjectLogonId' из 4767 с событием 4624 (Успешный вход) в том же журнале.
Как автоматизировать снятие блокировки?
В Default Domain Policy (или FGPP) настройте параметр 'Reset account lockout counter after' (Время до сброса счетчика) и 'Account lockout duration' (Время блокировки). Например, установите 15 минут. Через 15 минут ядро (SYSTEM) само сгенерирует 4767.
Генерируется ли 4767 при снятии галочки 'Account is disabled'?
Нет. Вы путаете 'Disabled' (Отключена администратором) и 'Locked' (Заблокирована системой защиты). Включение УЗ логируется событием 4722.
Можно ли разблокировать пользователя через PowerShell?
Да, выполните командлет Unlock-ADAccount -Identity 'Имя_пользователя'. Это мгновенно сгенерирует событие 4767.
Почему после 4767 пользователь все равно не может войти?
Проблема репликации AD. Вы разблокировали УЗ на контроллере DC01, а ПК пользователя опрашивает DC02, до которого изменение еще не доехало. Форсируйте репликацию (repadmin /syncall) или подождите.