В этой статье мы опишем, как отслеживать события блокировки учетных записей пользователей на котроллерах домена Active Directory, определять с какого компьютера и из какой конкретно программы выполняется постоянная блокировка. Рассмотрим использование для поиска источника блокировки журнала безопасности Windows и скриптов PowerShell.
Политика безопасности учетных записей в большинстве организаций требует обязательного блокирования учетной записи пользователя в домене Active Directory в случае n-кратного неправильного набора пароля пользователем. Обычно учетная запись блокируется контроллером домена после нескольких попыток ввести неправильный пароль на несколько минут (5-30), в течении которых вход пользователя в систему невозможен. Через определение время, заданное политиками безопасности, учетная запись домена автоматически разблокируется. Временная блокировка учетной записи позволяет снизить риск подбора пароля (простым брутфорсом) учетных записей пользователей AD.
В том случае, если учётная запись пользователя в домене заблокирована, при попытке авторизации в Windows появляется предупреждение:
Политики блокировки учетных записей в домене
Политики блокировки учетных записей и паролей обычно задается сразу для всего домена политикой Default Domain Policy. Интересующие нас политики находятся в разделе Computer Configuration -> Windows Settings -> Security Settings -> Account Policy -> Account Lockout Policy (Конфигурация Windows -> Параметры безопасности -> Политики учетных записей -> Политики блокировки учетных записей). Это политикии:
- Account lockout threshold (Пороговое значение блокировки) – через сколько неудачных попыток набора пароля учетная запись должна быть заблокирована
- Accountlockoutduration (Продолжительность блокировки учетной записи) – на какое время будет заблокирована учетная запись (по истечении этого времени блокировка будет снята автоматически)
- Resetaccountlockoutcounterafter (Время до сброса счетчика блокировки)– через какое время будет сброшен счетчик неудачных попыток авторизации
Совет. Вручную снять блокировку учетной записи, не дожидаясь автоматической разблокировки, можно с помощью консоли ADUC . Для этого в свойствах учетной записи пользователя на вкладке Account, поставив чекбокс на Unlock account. This account is currently locked out on this Active Directory Domain Controller.
Довольно полезную информацию о времени блокировки, задания пароля, количестве попыток набора пароля и прочее можно получить в свойствах учетной записи в консоль ADSIEdit или на дополнительной вкладке Additional Account Info в свойствах пользователя (проще).
Ситуации, когда пользователь забыл свой пароль и сам вызвал блокировку своей учетки случаются довольно часто. Но в некоторых случаях блокировка учеток происходит неожиданно, без каких-либо видимых причин. Т.е. пользоваться «клянется», что ничего особого не делал, не разу не ошибался при вводе пароля, но его учетная запись почему-то заблокировалась. Администратор по просьбе пользователя может вручную снять блокировку, но через некоторое время ситуация повторяется.
Для того, чтобы решить проблему пользователя администратору нужно разобраться с какого компьютера и какой программой была заблокирована учетная запись пользователя в Active Directory.
Поиск компьютера, с которого была заблокирована учетная запись
В первую очередь администратору нужно разобраться с какого компьютера / сервера происходят попытки ввода неверных паролей и идет дальнейшая блокировка учетной записи.
В том случае, если ближайший к пользователю контроллер домена определил, что пользователь пытается авторизоваться под неверным паролем , он перенаправляет запрос аутентификации на DC с FSMO ролью эмулятора PDC (именно он отвечает за обработку блокировок учетных записей). Если проверка подлинности не выполнялась и на PDC, он отвечает первому DC о невозможности аутентификации.
При этом в журнале обоих контроллеров домена фиксируются события 4740 с указанием DNS имени (IP адреса) компьютера, с которого пришел первоначальный запрос на авторизацию пользователя. Логично, что в первую очередь необходимо проверить журналы безопасности на PDC контроллере. Найти PDC в домене можно так:
Событие блокировки учетной записи домена можно найти в журнале Security на контролере домена. Отфильтруйте журнал безопасности по событию с Event ID 4740. Должен появится список последних событий блокировок учетных записей на контроллере домена. Начиная с самого верхнего переберите все события и найдите событие, в котором указано что учетная запись нужного пользователя (имя учетной записи указано в строке Account Name) заблокирована (A user account was locked out).
Откройте данное событие. Имя компьютера (или сервера), с которого была произведена блокировка указано в поле Caller Computer Name. В данном случае имя компьютера – TS01.
Можно воспользоваться следующим PowerShell скриптом для поиска источника блокировки конкретного пользователя на PDC. Данный скрипт вернет дату блокировки и компьютер, с которого она произошла:
$Username = ‘username1’
$Pdce = (Get-AdDomain).PDCEmulator
$GweParams = @<
‘Computername’ = $Pdce
‘LogName’ = ‘Security’
‘FilterXPath’ = "*[System[Event ]]"
>
$Events = Get-WinEvent @GweParams
$Events | foreach
$Username = ‘username1’
Get-ADDomainController -fi * | select -exp hostname | % <
$GweParams = @<
‘Computername’ = $_
‘LogName’ = ‘Security’
‘FilterXPath’ = "*[System[Event ]]"
>
$Events = Get-WinEvent @GweParams
$Events | foreach <$_.Computer + " " +$_.Properties[1].value + ‘ ‘ + $_.TimeCreated>
>
Выявляем программу, причину блокировки учетной записи в AD
Итак, мы определили с какого компьютера или устройства была заблокирована учетная запись. Теперь хотелось бы понять, какая программа или процесс выполняет неудачные попытки входа и является источником блокировки.
Часто пользователи начинают жаловаться на блокировку своей учетной записи в домене после плановой смены пароля своей доменной учетной записи . Это наталкивает на мысль, что старый (неверный) пароль сохранен в некой программе, скрипте или службе, которая периодически пытается авторизоваться в домене с устаревшим паролем. Рассмотрим самые распространение места, в которых пользователь мог использовать свой старый пароль:
- Монтирование сетевого диска через net use (Map Drive)
- В заданиях планировщика Windows (Task Scheduler)
- В службах Windows, которые настроены на запуск из-под доменной учетной записи
- Сохранённые пароли в менеджере паролей в панели управления (Credential Manager)
- Браузеры
- Мобильные устройства (например, использующееся для доступа к корпоративной почте)
- Программы с автологином
- Незавершенные сессии пользователя на других компьютерах или терминальных серверах
- И др.
Для более детального аудита блокировок на найденной машине необходимо включить ряд локальных политик аудита Windows. Для этого на локальном компьютере, на котором нужно отследить источник блокировки, откройте редактор групповых политик Gpedit.msc и в разделе Compute Configurations -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy включите политики:
- Audit process tracking: Success , Failure
- Audit logon events: Success , Failure
Дождитесь очередной блокировки учетной записи и найдите в журнале безопасности (Security) события с Event ID 4625. В нашем случае это событие выглядит так:
Из описания события видно, что источник блокировки учетной записи – процесс mssdmn.exe (является компонентом Sharepoint). Осталось сообщить пользователю о том, что ему необходимо обновить свой пароль на веб-портале Sharepoint.
После окончания анализа, выявления и наказания виновника не забудьте отключить действие активированных групповых политик аудита.
В том случае, если вы так и не смогли выяснить причину блокировки учетной записи на конкретном компьютере, чтобы избежать постоянной блокировки учетки, стоит попробовать переименовать имя учетной записи пользователя в Active Directory. Это как правило самый действенный метод защиты от внезапных блокировок определенного пользователя.
Необходимые исходные условия.
Да, чудес не бывает, и для поиска причины блокировки пользователей потребуется некоторая настройка аудита безопасности на контроллерах домена. Должны быть включены следующие подкатегории аудита на контроллерах домена:
| Категория аудита | Подкатегория аудита | Тип аудита | Интересующий нас eventID |
|---|---|---|---|
| Audit Account Logon Events (Вход учётной записи) | Kerberos Authentication Service (Аудит службы проверки подлинности Kerberos) | Отказ | 4771 Kerberos pre-authentication failed. |
| Audit Logon Events (Вход/Выход) | Logon (Аудит входа в систему) | Отказ | 4625 An account failed to log on. |
| Audit Logon Events (Вход/Выход) | Account Lockout (Аудит блокировки учётных записей) | Успех | 4740 Account locked |
Алгоритм поиска источника блокировки
- Определить какой контроллер является владельцем роли PDC-эмулятора
- Найти в журнале безопасности PDC-эмулятора событие с кодом 4740 в поле «TargetUserName», которого указано имя интересующего нас пользователя
- В поле «TargetDomainName» того же события найти имя контроллера домена, обслужившего авторизацию
- Найти в журнале безопасности контроллера, обслужившего авторизацию, событие с кодом 4625 (неуспешная NTLM авторизация) или 4771 (неуспешная kerberos авторизация)
- Из найденного события получить значения полей «IpAddress» — адрес ПК с которого была попытка авторизации
Этих действий будет достаточно для быстрого поиска ПК с вредоносным ПО, подбирающим пароли пользователей. Как правило достаточно быстро вычислить источник проблемы и изолировать его для дальнейшего расследования. Алгоритм поиска процесса непосредственно вызывающего блокировку пользователя сильно зависит от ПО, установленного на конечном ПК.
Используемые командлеты PowerShell
- Get-ADDomainController — для определения владельца роли PDC-эмулятора
- Get-WinEvent — «волшебный» командлет, благодаря которому и стал возможным быстрый поиск
В чём «магия» Get-WinEvent?
Во-первых он ищет события с конца и имеет параметр -MaxEvents, позволяющий найти только самое последнее событие или неколько самых последних событий.
Во-вторых он имеет прекрасный параметр -FilterHashtable, который позволяет очень гибко задать условия поиска события.
Скрипт поиска
Для себя я подготовил небольшой PowerShell скрипт.
На входе скрипт принимает либо имя пользователя, для которого необходимо найти источник блокировки, либо количество (по умолчанию — 1) последних заблокированных пользователей.
Учетная запись пользователя в Active Directory блокируется, если пользователь неправильно набрал пароль несколько раз подряд.
В этой статье мы покажем вам, как найти и разблокировать учетную запись одного пользователя или всех заблокированных пользователей домена AD одновременно.
Пороговое значение для количества попыток ввода неправильного пароля и времени лизиса учетной записи определяется в Политике домена по умолчанию в разделе объекта групповой политики GPO.
Для этого вам потребуется установить модуль Active Directory для модуля Windows PowerShell.
На Windows Server вы можете установить его с помощью команды: