Постоянно блокируется учетная запись в домене windows 10

В этой статье мы покажем, как отслеживать события блокировки учетных записей пользователей на котроллерах домена Active Directory, определять с какого компьютера и из какой конкретно программы постоянно блокируется учетная запись. Для поиска источника блокировки аккаунтов пользователей можно использовать журнал безопасности Windows, скрипты PowerShell или утилиту Account Lockout and Management Tools (Lockoutstatus.exe).

Учетная запись пользователя заблокирована и не может быть использована для входа в сеть

Политика безопасности учетных записей в большинстве организаций требует обязательного блокирования учетной записи пользователя в домене Active Directory, если он несколько раз подряд ввел неправильный пароль. Обычно учетная запись блокируется контроллером домена на несколько минут (5-30), в течении которых вход пользователя в домен невозможен. Через определение время (задается в политике безопасности домена), учетная запись пользователя автоматически разблокируется. Временная блокировка учетной записи позволяет снизить риск подбора пароля (простым брутфорсом) к учетным записям пользователей AD.

Если учётная запись пользователя в домене заблокирована, то при попытке входа в Windows появляется предупреждение:

Учетная запись пользователя заблокирована и не может быть использована для входа в сеть.

The referenced account is currently locked out and may not be logged on to ….

Как проверить, что аккаунт пользователя AD заблокирован?

Вы можете проверить, что аккаунт заблокирован в графический консоли ADUC или с помощью комнадлета Get-ADUser из модуля Active Directory для PowerShell:

Get-ADUser -Identity aaivanov -Properties LockedOut,DisplayName | Select-Object samaccountName, displayName,Lockedout

Или:

Get-ADUser avivanov2 -Properties Name,Lockedout, lastLogonTimestamp,lockoutTime,logonCount,pwdLastSet | Select-Object Name, Lockedout,@{n='LastLogon';e={[DateTime]::FromFileTime($_.lastLogonTimestamp)}},@{n='lockoutTime';e={[DateTime]::FromFileTime($_.lockoutTime)}},@{n='pwdLastSet';e={[DateTime]::FromFileTime($_.pwdLastSet)}},logonCount

Учетная запись сейчас заблокирована и не может быть использована для авторизации в домене (Lockedout = True). Также в выводе команды вы видите информацию о времени смены пароля пользователя в домене и времени блокировки аккаунта.

Можно вывести сразу все заблокированные аккаунты в домене с помощью командлета Search-ADAccount:

Search-ADAccount -UsersOnly -lockedout

Вы можете вручную снять блокировку учетной записи с помощью консоли ADUC, не дожидаясь автоматической разблокировки. Для этого в свойствах учетной записи пользователя на вкладке Account, включите опцию Unlock account. This account is currently locked out on this Active Directory Domain Controller (Разблокируйте учетную запись. Учетная запись на этом контроллере домена Active Directory на данный момент заблокирована) и сохраните изменения.

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

Get-ADUser -Identity aaivanov | Unlock-ADAccount

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

Политики блокировки учетных записей и паролей обычно задаются сразу для всего домена политикой Default Domain Policy в консоли gpmc.msc. Интересующие нас политики находятся в разделе Computer Configuration -> Windows Settings -> Security Settings -> Account Policy -> Account Lockout Policy (Конфигурация Windows -> Параметры безопасности -> Политики учетных записей -> Политики блокировки учетных записей). Это политики:

• Account lockout threshold (Пороговое значение блокировки) – через сколько неудачных попыток набора пароля учетная запись должна быть заблокирована;
• Account lockout duration (Продолжительность блокировки учетной записи) – на какое время будет заблокирована учетная запись (по истечении этого времени блокировка будет снята автоматически);
• Reset account lockout counter after (Время до сброса счетчика блокировки) – через какое время будет сброшен счетчик неудачных попыток авторизации.

Для защиты от перебора паролей рекомендуется использовать стойкие пароли пользователей в AD (использовать длину пароля не менее 8 символов и включить требования сложности. Это настраивается в разделе Password Policy в политиках Password must meet complexity requirements и Minimum password length. Периодически нужно выполнять аудит паролей пользователей.

Ситуации, когда пользователь забыл свой пароль и сам вызвал блокировку своей учетки случаются довольно часто. Но в некоторых случаях блокировка учеток происходит неожиданно, без каких-либо видимых причин. Т.е. пользоваться “клянется”, что ничего особого не делал, ни разу не ошибался при вводе пароля, но его учетная запись почему-то заблокировалась. Администратор по просьбе пользователя может вручную снять блокировку, но через некоторое время ситуация повторяется.

Чтобы решить проблему самопроизвольной блокировки учетной записи пользователя, администратору нужно разобраться с какого компьютера и какой программой была заблокирован аккаунт пользователя Active Directory.

События блокировки пользователей EventID 4740, 4625

В первую очередь администратору нужно разобраться с какого компьютера/сервера домена происходят попытки ввода неверных паролей и идет дальнейшая блокировка учетной записи.
Чтобы в журналах контроллеров домена записывались события блокировки учетных записей, нужно включить следующие подкатегории аудита на контроллерах домена в секции Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy -> Logon/Logoff:

• Audit Account Lockout
• Audit Logon
• Audit Logoff

Затем перейдите в раздел Account Management и включите политику:

• Audit User Account Management: Success

Проще всего включить эти параметры GPO через консоль
gpmc.msc
, отредактировав политику Default Domain Controller Policy.

Если пользователь ввел неверный пароль, то ближайший к пользователю контроллер домена перенаправляет запрос аутентификации на DC с FSMO ролью эмулятора PDC (именно он отвечает за обработку блокировок учетных записей). Если проверка подлинности не выполнилась и на PDC, он отвечает первому DC о невозможности аутентификации. Если количество неуспешных аутентификаций превысило значение, заданное для домена в политике Account lockout threshold, учетная запись пользователя временно блокируется.

При этом в журнале обоих контроллеров домена фиксируются событие с EventID 4740 с указанием DNS имени (IP адреса) компьютера, с которого пришел первоначальный запрос на авторизацию пользователя. Чтобы не анализировать журналы на всех DC, проще всего искать это события в журнале безопасности на PDC контроллере. Найти PDC в домене можно так:

(Get-AdDomain).PDCEmulator

Событие блокировки учетной записи домена можно найти в журнале Security (Event Viewer > Windows Logs) на контролере домена. Отфильтруйте журнал безопасности (Filter Current Log) по событию с Event ID 4740. Должен появиться список последних событий блокировок учетных записей контроллером домена. Переберите все события, начиная с самого верхнего и найдите событие, в котором указано, что учетная запись нужного пользователя (имя учетной записи указано в строке Account Name) заблокирована (A user account was locked out).

Примечание. В большой инфраструктуре AD, в журнале безопасности фиксируется большое количество событий, которые постепенно перезаписываются более новыми. Поэтому желательно увеличить максимальный размер журнала на DC и приступать к поиску источника блокировки как можно раньше.

Откройте данное событие. Имя компьютера (или сервера), с которого была произведена блокировка указано в поле Caller Computer Name. В данном случае имя компьютера – WKS-TEST1.

Если в поле Computer Name указано неизвестное имя компьютера/устройства, который не резолвится в вашей сети через DNS (недоменный компьютер, или не Windows устройство с поддержкой Kerberos аутентфикации), вы можете получить IP адрес этого устройства. Для этого нужно включить следующие параметры аудита в Default Domain Controller Policy. Перейдите в раздел Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Configuration и настройте следующие параметры:

Account Logon

• Audit Kerberos Authentication Service: Success, Failure
• Audit Kerberos Service Ticket Operations: Success, Failure

Logon/Logoff

• Audit Special Logon: Success, Failure

Откройте журнал Event Viewer -> Security и включите фильтр по Event ID 4740 и 4741. Обратите внимание, что теперь перед появлением события блокировки пользователя (4740) появляется событие 4771 (неуспешная kerberos аутентфикация) от Kerberos Authentication Service. В нем указано имя пользователя, который пытался выполнить аутентификацию и IP адрес устройства (поле Network Information -> Client Address), с которого пришел запрос.

Если удаленное устройство использует NTLM для аутентификации в домене, нужно выполнить поиск события EventID 4625 (неуспешная NTLM аутентификация) на контроллерах домена (оно появится только на DC, через который была выполнена попытка аутентифицироваться через NTLM).

Откройте последнее найденное событие с EventID 4625 для вашего пользователя (Account name). Здесь видно, что при попытке выполнить NTLM аутентификацию (Authentication Package: NTLM, Logon Process: NtLmSsp) учетная запись была заблокирована (
Failure Reason: Account locked out, Status: 0xC0000234
). В описании события указаны как имя компьютера (Workstation Name), так и его IP адрес (Source Network Address).

Если вы не можете найти событие блокировки пользователя в журнале Event Viewer, можно включить расширенный лог netlogon на контроллере домена. Выполните команду:

nltest /dbflag:2080ffffff

Перезапустите службу Netlogon

net stop netlogon && net start netlogon

Выполните поиск в файле netlogon.log событий:

• 0xc000006a – An invalid attempt to login has been made by the following user
• 0xc0000234 – The user account has been automatically locked because too many invalid logon attempts or password change attempts have been requested.

Можно найти события блокировки пользователя a.berg в файле netlogon.log с помощью команды:

type C:Windowsdebugnetlogon.log | findstr a.berg| findstr /i "0xC000006A"

В данном примере видно, что пользователь a.berg блокируется с устройства DESKTOP-74G6LB.

Поиск компьютера, с которого блокируется пользователь с помощью PowerShell

Можно воспользоваться следующим PowerShell скриптом для поиска источника блокировки конкретного пользователя на PDC. Данный скрипт вернет дату блокировки и компьютер, с которого она произошла. Скрипт выполняет поиск событий с Event ID в Event Log:

$Username = 'username1'
$Pdce = (Get-AdDomain).PDCEmulator
$GweParams = @{
‘Computername’ = $Pdce
‘LogName’ = ‘Security’
‘FilterXPath’ = "*[System[EventID=4740] and EventData[Data[@Name='TargetUserName']='$Username']]"
}
$Events = Get-WinEvent @GweParams
$Events | foreach {$_.Properties[1].value + ' ' + $_.TimeCreated}

Аналогичным образом можно опросить из PowerShell все контроллеры домена в Active Directory:

$Username = 'username1'
Get-ADDomainController -fi * | select -exp hostname | % {
$GweParams = @{
‘Computername’ = $_
‘LogName’ = ‘Security’
‘FilterXPath’ = "*[System[EventID=4740] and EventData[Data[@Name='TargetUserName']='$Username']]"
}
$Events = Get-WinEvent @GweParams
$Events | foreach {$_.Computer + " " +$_.Properties[1].value + ' ' + $_.TimeCreated}
}

Утилита Microsoft Account Lockout and Management Tools

Для поиска источника блокировки пользователя можно использовать графическую утилиту Microsoft Account Lockout and Management Tools —
Lockoutstatus.exe
(скачать ее можно тут). Данная утилита проверяет статус блокировки учетной записи на всех контроллерах домена.

Запустите утилиту Lockoutstatus.exe, укажите имя заблокированной учетной записи (Target User Name) и имя домена (Target Domain Name).

В появившемся списке будет содержаться список DC и состояние учетной записи (Locked или Non Locked). Дополнительно отображается время блокировки и компьютер, с которого заблокирована данная учетная запись (Orig Lock).

Атрибуты badPwdCount и LastBadPasswordAttempt не реплицируются между контролерами домена.

Прямо из утилиты Lockoutstatus можно разблокировать пользователя, или сменить его пароль.

Основной недостаток утилиты LockoutStatus – она довольно долго опрашивает все контроллеры домена (некоторые из них могут быть недоступны).

Как определить программу, из которой блокируется учетная запись пользователя?

Итак, мы определили с какого компьютера или устройства была заблокирована учетная запись. Теперь нужно понять, какая программа или процесс выполняет неудачные попытки входа и является источником блокировки.

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

• Сетевые диски, подключенные через
  net use
  (Map Drive);
• Задания планировщика Windows Task Scheduler;
• Ярлыки с настроенным режимом
  RunAs
  (используется для запуска от имени другого пользователя);
• В службах Windows, которые настроены на запуск из-под доменной учетной записи;
• Сохранённые пароли в менеджере паролей в панели управления (Credential Manager). Выполните команду
  rundll32.exe keymgr.dll, KRShowKeyMgr
  и удалите сохраненные пароли;

  Пароли пользователей могут быть сохранены в контексте SYSTEM. Чтобы вывести их, нужно запустить командную строку от имени SYSTEM с помощью
  psexec -i -s -d cmd.exe
  и выполнить команду
  rundll32 keymgr.dll,KRShowKeyMgr
  чтобы открыть список сохраненных паролей для NT AUTHORITYSYSTEM.

• Программы, которые хранят и используют закэшировнный пароль пользователя;
• Браузеры;
• Мобильные устройства (например, использующееся для доступа к корпоративной почте);
• Программы с автологином или настроенный автоматический вход в Windows;
• Незавершенные сессии пользователя на других компьютерах или терминальных RDS фермах или RDP серверах (поэтому желательно настраивать лимиты для RDP сессий);
• Сохраненные пароли для подключения к Wi-FI сетям (WPA2-Enterprise 802.1x аутентификацию в беспроводной сети);
• Если пользователь недавно сменил пароль и забыл его, вы можете сбросить его.

Совет. Существует ряд сторонних утилит (в основном коммерческих) позволяющих администратору выполнить проверку удаленной машины и детектировать источник блокировки учетных записей. В качестве довольно популярного решения отметим Account Lockout Examiner от Netwrix.

Для более детального аудита блокировок на найденном компьютере необходимо включить ряд локальных политик аудита Windows. Для этого на компьютере, на котором нужно отследить источник блокировки, откройте редактор локальной групповой политики gpedit.msc и включите следующие параметры в разделе Compute Configurations -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy:

• Audit process tracking: Success , Failure
• Audit logon events: Success , Failure

Затем обновите настройки групповых политик на клиенте:

gpupdate /force

Дождитесь очередной блокировки учетной записи и найдите в журнале безопасности (Security) события с Event ID 4625. В нашем случае это событие выглядит так:

An account failed to log on.
Failure Reason: Account locked out.

Из описания события видно, что источник блокировки учетной записи (Caller Process Name) – процесс mssdmn.exe (является компонентом Sharepoint). Осталось сообщить пользователю о том, что ему необходимо обновить свой пароль на веб-портале Sharepoint.

После окончания анализа, выявления и наказания виновника не забудьте отключить действие включенных групповых политик аудита.

Если вы так и не смогли найти причину блокировки учетной записи на конкретном компьютере, попробуйте просто переименовать имя учетной записи пользователя в Active Directory (измените SAMaccountName и UPN пользователя в домене AD). Это как правило самый действенный метод защиты от внезапных блокировок определенного пользователя, если вы не смогли установить источник блокировки.

В последние дни наблюдаю возросшую блокировку учетных записей в результате применения политики учетных записей в AD. Но с одним пользователем имею проблему. Учетная запись блокируется несколько раз за день. Провели антивирусную
проверку, очистили кэш паролей, удалили все лишние программы. Но найти причину блокировки так и не смог. Использование утилиты Netwrix Account Lockout Examiner также не дало ответ на причины блокировки.

До достижения предела числа сбойных попыток входа в журнале событий периодически регистрируется событие:

Источник: Microsoft Windows security auditing.

Категория: Проверка учетных данных

ID: 4776

Компьютер попытался проверить учетные данные учетной записи.

Пакет проверки подлинности: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Учетная запись входа: baranova
Исходная рабочая станция: PC-BARANOVA3
Код ошибки: 0xC000006A

C000006A — ввод неверного пароля.

Далее учетная запись блокируется. Регистрируется сообщение в журнале событий:

Источник: Microsoft Windows security auditing.
Категория: Управление учетными записями
ID: 4740
Заблокирована учетная запись пользователя.

Субъект:
 Идентификатор безопасности:  СИСТЕМА
 Имя учетной записи:  SRV-AD1$
 Домен учетной записи:  SFH
 Идентификатор входа:  0x3E7

Заблокированная учетная запись:
 Идентификатор безопасности:  SFHBaranova
 Имя учетной записи:  Baranova

Дополнительные сведения:
 Имя вызывающего компьютера: PC-BARANOVA3

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

Источник: Microsoft Windows security auditing.
Категория: Проверка учетных данных
ID: 4776
Компьютер попытался проверить учетные данные учетной записи.

Пакет проверки подлинности: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Учетная запись входа: baranova
Исходная рабочая станция: PC-BARANOVA3
Код ошибки: 0xC0000234

На рабочей станции (Windows 7 Pro SP1) в журнале регистрируется ошибка:

Источник: Microsoft Windows security auditing.
Категория: Вход в систему
ID: 4625
Учетной записи не удалось выполнить вход в систему.

Субъект:
 ИД безопасности:  СИСТЕМА
 Имя учетной записи:  PC-BARANOVA3$
 Домен учетной записи:  SFH
 Код входа:  0x3e7

Тип входа:   2

Учетная запись, которой не удалось выполнить вход:
 ИД безопасности:  NULL SID
 Имя учетной записи:  Baranova
 Домен учетной записи:  SFH

Сведения об ошибке:
 Причина ошибки:  Неизвестное имя пользователя или неверный пароль.
 Состояние:   0xc000006d
 Подсостояние:  0xc000006a

Сведения о процессе:
 Идентификатор процесса вызывающей стороны: 0x298
 Имя процесса вызывающей стороны: C:WindowsSystem32winlogon.exe

Сведения о сети:
 Имя рабочей станции: PC-BARANOVA3
 Сетевой адрес источника: 127.0.0.1
 Порт источника:  0

Сведения о проверке подлинности:
 Процесс входа:  User32
 Пакет проверки подлинности: Negotiate
 Промежуточные службы: —
 Имя пакета (только NTLM): —
 Длина ключа:  0

Данное событие возникает при неудачной попытке входа. Оно регистрируется на компьютере, попытка доступа к которому была выполнена.

Поля «Субъект» указывают на учетную запись локальной системы, запросившую вход. Обычно это служба, например, служба «Сервер», или локальный процесс, такой как Winlogon.exe или Services.exe.

В поле «Тип входа» указан тип выполненного входа. Наиболее распространенными являются типы 2 (интерактивный) и 3 (сетевой).

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

Поля «Сведения о сети» указывают на источник запроса на удаленный вход. Имя рабочей станции доступно не всегда, и в некоторых случаях это поле может оставаться незаполненным.

Поля сведений о проверке подлинности содержат подробные данные о конкретном запросе на вход.
 — В поле «Промежуточные службы» указано, какие промежуточные службы участвовали в данном запросе на вход.
 — Поле «Имя пакета» указывает на подпротокол, использованный с протоколами NTLM.
 — Поле «Длина ключа» содержит длину созданного ключа сеанса. Это поле может иметь значение «0», если ключ сеанса не запрашивался.

Обычно в статьях, посвященных поиску причин блокировки, указывается, что с помощью этого сообщения можно найти процесс или программу, приведшую к блокировке. Но в данном случае я вижу, что это — процесс winlogon.

Может быть кто-нибудь кто-нибудь подскажет, как найти источник проблемы.

В этой статье мы покажем вам, как отслеживать события блокировки учётной записи пользователя на контроллерах домена Active Directory, определять с какого компьютера и какой программой постоянно блокируется учётная запись. Чтобы найти источник блокировки учётной записи, вы можете использовать журнал безопасности Windows, скрипты PowerShell или средство блокировки и управления учётной записью MSFT (Lockoutstatus.exe).

Разница между отключённой, просроченной и заблокированной учётной записью

Данная статья посвящена заблокированным аккаунтом (в английской версии это locked out). Но кроме блокировки аккаунта, возможны следующие причины, почему пользователь не может войти в домен:

• аккаунт отключён
• аккаунт просрочен
• пользователь ограничен определённым временем или компьютером для входа

Отключённые аккаунты (disabled)

Администратор домена может вручную отключить (деактивировать) аккаунт пользователя. Если пользователь отключён, то будет выведено сообщение:

Ваша учётная запись отключена. Обратитесь к системному администратору.

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

Заблокированные аккаунты (locked out)

Учётная запись может быть заблокирована автоматически в соответствии с политикой блокировки учётной записи организации. Если пользователь ввёл неправильный пароль более определённого количества раз (порог устанавливается политикой паролей), то его аккаунт автоматически блокируется на время, которое также устанавливается политикой паролей.

На период блокировки пользователь будет получать следующее сообщение при каждой попытке входа:

Учётная запись заблокирована и не может использоваться для входа в сеть.

Блокировка может быть снята автоматически после истечения сроки блокировки, установленной в политике паролей домена. Также администратор может ускорить этот процесс и снять блокировку вручную.

Если время разблокировки в групповой политике пароля установлено на 0, то такая учётная запись никогда не будет разблокирована автоматически, для её разблокировки требуется действие администратора домена.

Учётные записи с истекшим сроком действия (expired)

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

Запрет доступа по другим причинам

Пользователю может быть разрешено входить только на определённые компьютеры и/или только в определённые часы. Пример сообщения, когда пользователю не разрешено выполнить вход на этом компьютере:

Вы не можете пользоваться этим компьютером из-за ограничений вашей учётной записи. Попробуйте воспользоваться другим компьютером.

Пример сообщения, когда пользователь пытается войти в неурочное время или день:

Вы не можете сейчас войти в систему из-за ограничений вашей учётной записи. Попробуйте ещё раз позже.

Данные ограничения могут перестать действовать в определённые часы или на определённых компьютерах. Эти ограничения устанавливает и снимает администратор домена.

Учётная запись заблокирована и не может использоваться для входа в сеть

Политика безопасности аккаунтов домена в большинстве организаций требует обязательной блокировки учётной записи пользователя Active Directory, если неверный пароль вводился несколько раз подряд. Обычно учётная запись блокируется контроллером домена на несколько минут (5–30), в течение которых пользователь не может войти в домен AD. Через некоторое время (установленное политикой безопасности домена) учётная запись пользователя автоматически разблокируется. Временная блокировка учётной записи AD снижает риск атак методом переборы (брут-форс) на пароли учётных записей пользователей AD.

Если учётная запись пользователя в домене заблокирована, при попытке входа в Windows появляется предупреждение:

Учётная запись заблокирована и не может использоваться для входа в сеть

В Windows на английском языке сообщение выглядит так:

The referenced account is currently locked out and may not be logged on to ….

Как проверить, заблокирована ли учётная запись пользователя?

Проверить, заблокирована ли учётная запись, можно в графической консоли ADUC или с помощью командлета Get-ADUser из модуля Active Directory для PowerShell:

Get-ADUser -Identity Alex -Properties LockedOut,DisplayName | Select-Object samaccountName,displayName,Lockedout

Учётная запись в данный момент заблокирована и не может использоваться для аутентификации в домене (Lockedout = True).

Вы можете вывести список всех заблокированных на данный момент учётных записей в домене с помощью командлета Search-ADAccount:

Search-ADAccount -LockedOut

Вы можете разблокировать учётную запись вручную с помощью консоли ADUC, не дожидаясь автоматической разблокировки. Найдите учётную запись пользователя, щёлкните правой кнопкой мыши и выберите Properties («Свойства»). Перейдите на вкладку Account («Учётная запись») и установите флажок Unlock account. This account is currently locked out on this Active Directory Domain Controller (в русскоязычной версии «Разблокируйте учётную запись. Учётная запись на этом контроллере домена Active Directoryв на данный момент заблокирована»). Затем кликните «ОК».

Вы также можете сразу разблокировать нужную учётную запись, используя следующую команду PowerShell:

Get-ADUser -Identity Alex | Unlock-ADAccount

Вы можете проверить время блокировки учётной записи, количество неудачных попыток ввода пароля, время последнего успешного входа в систему в свойствах учётной записи в консоли ADUC (на вкладке Attribute Editor «Редактора атрибутов»)

   

или с помощью PowerShell:

Get-ADUser Alex -Properties Name,lastLogonTimestamp,lockoutTime,logonCount,pwdLastSet | Select-Object Name,@{n='LastLogon';e={[DateTime]::FromFileTime($_.lastLogonTimestamp)}},@{n='lockoutTime';e={[DateTime]::FromFileTime($_.lockoutTime)}},@{n='pwdLastSet';e={[DateTime]::FromFileTime($_.pwdLastSet)}},logonCount

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

Политики блокировки учётных записей обычно устанавливаются в Default Domain Policy для всего домена с помощью оснастки gpmc.msc. Необходимые политики можно найти в Computer configuration→ Policies→ Windows Settings → Security Settings → Account Policies → Account Lockout Password (в русскоязычной версии это соответственно Конфигурация компьютера → Политики → Конфигурация Windows → Параметры безопасности → Политики учетных записей → Политика блокировки учётной записи). Это следующие политики:

• Account Lockout Threshold (Пороговое значение блокировки) – количество неудачных попыток входа в систему (с неправильным паролем), которое может быть выполнено пользователем до блокировки его учётной записи;
• Account Lockout Duration (Продолжительность блокировки учётной записи) — как долго будет заблокирована учётная запись, если пользователь несколько раз ввёл неверный пароль;
• Reset account lockout counter after (Время до сброса счётчика блокировки) — количество минут, по истечении которых счётчик порога блокировки учётной записи будет сброшен.

Чтобы защитить учётные записи пользователей вашего домена от взлома пароля, рекомендуется использовать надёжные пароли пользователей в AD (длина пароля не менее 8 символов и включение требований к сложности пароля). Это настраивается в разделе Password Policy («Политика паролей»): Password must meet complexity requirements (Пароль должен отвечать требованиям сложности) и Minimum password length (Минимальная длина пароля). Периодически нужно проверять пароли пользователей.

Случаи, когда пользователь забывает пароль и сами вызывают блокировку учётной записи, происходят довольно часты. Если пользователь недавно сменил пароль и забыл его, вы можете сбросить его. Но в некоторых случаях блокировка учётной записи происходит без какой-либо очевидной причины. То есть пользователь заявляет, что никогда не ошибался при вводе пароля, но его учётная запись по каким-то причинам заблокирована. Администратор может разблокировать аккаунт вручную по запросу пользователя, но через некоторое время ситуация может повториться.

Чтобы решить проблему пользователя, администратору необходимо выяснить, с какого компьютера и программы учётная запись пользователя в Active Directory была заблокирована.

Политики аудита входа в систему для контроллеров домена

Чтобы включить фиксацию события блокировки учётной записи в журналах контроллера домена, необходимо активировать следующие политики аудита для контроллеров домена. Перейдите в раздел GPO Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy → Logon/Logoff и включите следующие политики:

• Audit Account Lockout
• Audit Logon
• Audit Logoff

В русскоязычной версии это соответственно Конфигурация компьютера → Политики → Конфигурация Windows → Параметры безопасности → Конфигурация расширенной политики аудита → Политика аудита → Вход/Выход, политики:

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

Самый простой способ включить эту политику — через консоль gpmc.msc, отредактировав Default Domain Controller Policy или используя Default Domain Policy на уровне всего домена.

Обратите внимание, что для использования параметров «Конфигурация расширенной политики аудита» также необходимо в Локальной политике безопасности (secpol.msc) включить по пути Параметры безопасности → Локальные политики → Параметры безопасности параметр «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии)». Это значение по умолчанию установлено на «Включён», поэтому если вы не отключали эту политику, то вам не нужно о ней беспокоиться.

Идентификатор события блокировки учётной записи 4740

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

Если ближайший к пользователю контроллер домена определяет, что пользователь пытается войти в систему с недопустимыми учётными данными, он перенаправляет запрос проверки подлинности на контроллер домена с ролью FSMO эмулятора основного контроллера домена (этот конкретный контроллер домена отвечает за обработку блокировок учётных записей). Если аутентификация на PDC завершается неудачно, он отвечает на первый DC, что аутентификация невозможна. Если количество неудачных проверок подлинности превышает значение, установленное для домена в политике Account Lockout Threshold (Пороговое значение блокировки), учётная запись пользователя временно блокируется.

В этом случае событие с EventID 4740 записывается в журнал безопасности обоих контроллеров домена. Событие содержит DNS-имя (IP-адрес) компьютера, с которого пришел первоначальный запрос на авторизацию пользователя. Чтобы не анализировать журналы на всех контроллерах домена, проще всего искать события блокировки в журнале безопасности на PDC контроллера домена. Вы можете найти PDC в своём домене следующим образом:

(Get-AdDomain).PDCEmulator

События блокировки учётной записи домена можно найти в журнале безопасности на контроллере домена. Чтобы его увидеть, запустите Event Viewer («Просмотр событий»), его можно открыть в командной строке:

eventvwr.msc

В окне Event Viewer («Просмотр событий») перейдите по пути Event Viewer (Local) → Windows Logs → Security (в русскоязычной версии это Просмотр событий (локальный) → Журналы Windows → Безопасность).

В Event Viewer («Просмотр событий») отфильтруйте журнал безопасности по Event ID («Код события») указав значение 4740, для этого нажмите Filter Current Log («Фильтр текущего журнала») и введите в поле <All Event Ids> («Все коды событий») значение 4740.

Вы должны увидеть список последних событий блокировки учётной записи. Найдите событие с нужной вам учётной записью пользователя (имя пользователя указано в значении поля Account Name («Имя учётной записи»). В описании события вы увидите строку A user account was locked out («Учетная запись пользователя была заблокирована»).

Подсказка: в большой среде AD в журнал безопасности на контроллерах домена записывается большое количество событий, которые постепенно перезаписываются новыми. Поэтому рекомендуется увеличить максимальный размер журнала на контроллерах домена и как можно скорее приступить к поиску источника блокировки.

Откройте найденное событие. Имя компьютера (сервера), с которого была произведена блокировка, указывается в поле Caller Computer Name. В моём случае имя компьютера — HACKWARE-WIN.

Как с помощью PowerShell найти компьютер на котором была заблокирована учётная запись

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

$Usr = 'Alex'
$Pdc = (Get-AdDomain).PDCEmulator
$ParamsEvn = @{
	'Computername' = $Pdc
	'LogName' = 'Security'
	'FilterXPath' = "*[System[EventID=4740] and EventData[Data[@Name='TargetUserName']='$Usr']]"
}
$Evnts = Get-WinEvent @ParamsEvn 
$Evnts | ForEach-Object {$_.Properties[1].value + ' ' + $_.TimeCreated + ', UserName: ' + $Usr}

Пример полученных данных:

HACKWARE-WIN 09/29/2021 07:31:59
HACKWARE-WIN 09/29/2021 06:53:12
HACKWARE-WIN 09/29/2021 05:44:18

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

$Usr = 'Alex'
$Date = (Get-Date).AddDays(-2)
$Evnts = Get-WinEvent -FilterHashtable @{ LogName='Security'; StartTime=$Date; Id='4740'; Data="$Usr";  }
$Evnts | ForEach-Object {$_.Properties[1].value + ' ' + $_.TimeCreated + ', UserName: ' + $_.Properties[0].value}

Точно так же вы можете опросить все контроллеры домена в Active Directory из PowerShell:

$Usr = 'MiAl'
Get-ADDomainController -Filter * | Select-Object -exp hostname | % {
	$ParamsEvn = @{
		'Computername' = $Pdc
		'LogName' = 'Security'
		'FilterXPath' = "*[System[EventID=4740] and EventData[Data[@Name='TargetUserName']='$Usr']]"
	}
	$Evnts = Get-WinEvent @ParamsEvn
	$Evnts | ForEach-Object {$_.MachineName + " " + $_.Properties[1].value + ' ' + $_.TimeCreated + ', UserName: ' + $_.Properties[0].value}
}

Microsoft Account Lockout and Management Tools (Инструменты блокировки и управления учётной записью от Microsoft)

Чтобы найти источник блокировки учётной записи пользователя, вы можете использовать набор инструментов Microsoft Account Lockout and Management Tools, а именно инструмент Lockoutstatus.exe (его можно скачать здесь). Этот графический инструмент проверяет состояние блокировки учётной записи и событий блокировки на всех контроллерах домена.

Запустите средство Lockoutstatus.exe, укажите имя заблокированной учётной записи (Target User Name) и имя домена (Target Domain Name).

Появившийся список будет содержать список контроллеров домена и статус учётной записи (Locked или Non Locked). Кроме того, отображается время блокировки и компьютер, на котором эта учётная запись заблокирована (Orig Lock), но в моём случае компьютер, который стал причиной блокировки, показан неверно.

Атрибуты badPwdCount и LastBadPasswordAttempt не реплицируются между контроллерами домена.

Вы можете разблокировать учётную запись пользователя или изменить пароль прямо из окна Lockoutstatus.

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

Как отследить, какой процесс блокирует учётную запись домена

Итак, мы выяснили, с какого компьютера или сервера была заблокирована учётная запись. Теперь было бы здорово узнать, какая программа или процесс являются источником блокировки учётной записи.

Часто пользователи начинают жаловаться на блокировку своих учётных записей домена после изменения паролей. Это говорит о том, что старый (неправильный) пароль сохраняется в определённой программе, скрипте или службе, которая периодически пытается аутентифицироваться на контроллере домена с неверным паролем. Рассмотрим наиболее распространённые места, в которых пользователь мог сохранить старый пароль:

• Подключённые сетевые диски (через net use);
• Работы Windows Task Scheduler (Планировщика заданий Windows);
• Службы Windows, настроенные для запуска из учётной записи домена;
• Сохранённые учётные данные в Credential Manager (Диспетчере учётных данных) (в Панели управления);
• Браузеры;
• Мобильные устройства (например, те, которые используются для доступа к корпоративному почтовому ящику);
• Программы с автоматическим входом или настроенная функция автоматического входа в Windows;
• Отключённые/незанятые сеансы RDP на других компьютерах или серверах RDS (поэтому рекомендуется установить ограничения для сеансов RDP);

Подсказка: существует ряд сторонних инструментов (в основном коммерческих), которые позволяют администратору проверять удалённый компьютер и определять источник блокировки учётной записи. В качестве достаточно популярного решения отметим Lockout Examiner от Netwrix.

Чтобы выполнить подробный аудит блокировки учётной записи на найденном компьютере, необходимо включить ряд локальных политик аудита Windows. Для этого откройте локальный редактор групповой политики (gpedit.msc) на компьютере (на котором вы хотите отслеживать источник блокировки) и включите следующие политики в разделе Computer Configurations → Windows Settings → Security Settings → Local Policies → Audit Policy:

• Audit process tracking: Success , Failure
• Audit logon events: Success , Failure

В русскоязычной версии это соответственно: Конфигурации компьютера → Конфигурация Windows → Параметры безопасности → Локальные политики → Политика аудита:

• Аудит отслеживания событий: Успех, Отказ
• Аудит событий входа в систему: Успех, Отказ

Дождитесь следующей блокировки учётной записи и найдите события с идентификатором события 4625 в журнале безопасности. В нашем случае это событие выглядит так:

An account failed to log on.
Failure Reason: Account locked out.

На русском это:

Учетной записи не удалось выполнить вход в систему.
Причина ошибки: Учетная запись блокирована.

Как видно из описания события, источником блокировки учётной записи является процесс mssdmn.exe (компонент Sharepoint). В этом случае пользователю необходимо обновить пароль на веб-портале Sharepoint.

После завершения анализа и выявления и устранения причины блокировки не забудьте отключить локальные политики аудита.

Если вам по-прежнему не удаётся найти источник блокировки учётной записи на определённом компьютере, просто попробуйте переименовать имя учётной записи пользователя в Active Directory. Обычно это наиболее эффективный метод защиты от внезапных блокировок конкретного пользователя, если вы не смогли установить источник блокировки.

Вы также можете вывести список событий с кодом 4625 в PowerShell:

Get-WinEvent -FilterHashtable @{ LogName='Security'; Id='4625'; }

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

Get-WinEvent -FilterHashtable @{ LogName='Security'; Id='4625'; Data="MiAl" }

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

Get-WinEvent -FilterHashtable @{ LogName='Security'; Id='4625'; Data="MiAl" } | Format-List

Эта команда аналогична предыдущей, но покажет события только за последние 2 дня:

$Date = (Get-Date).AddDays(-2); Get-WinEvent -FilterHashtable @{ LogName='Security'; Id='4625'; Data="MiAl"; StartTime=$Date; } | Format-List

Обновлено 05.01.2023

net stop netlogon && net start netlogonДобрый день! Уважаемые читатели и гости, крупного IT блога Pyatilistnik.org. В прошлый раз мы с вами рассматривали границы применения групп Active Directory, и надеюсь вы разобрались, где и какие следует использовать. Сегодня я хочу рассмотреть, очень частую и жизненную ситуацию, которая есть в любой доменной среде, а именно блокировка учетной записи Windows в Active Directory. Данную проблему вы легко встретите на предприятиях, где есть свои политики PSO и политики смены паролей. Так, что давайте прокачаем свои знания и научимся разбираться в данной ситуации.

Причина блокировки пользователя Active Directory

Давайте разбираться, какие существуют причины блокирования учетных записей пользователей в Active Directory. Как я и говорил выше, данная ситуация существует в компаниях, где есть политики паролей, которые подразумевают блокировку учетной записи при вводе определенного количества не правильных паролей, это правильно с точки зрения безопасности и выявления таких случаев, когда кто-то пытается скомпрометировать ваши ресурсы.

Вот так вот выглядит сообщение о блокировке:

Как видите в моем примере, пользователь по имени Барбоскин Геннадий Викторович не может начать работать, так как залочен.

Если в оснастке Active Directory — Пользователи и компьютеры, посмотреть свойства заблокированной учетной записи на вкладке «Учетная запись», то вы обнаружите статус:

Ставим галку и разблокируем учетную запись. После этого нужно выявлять причины.

Из основных причин блокировки я могу выделить:

• Идет подбор пароля, так называемый брутфорс, что в итоге приводит к блокировкам
• Бывают моменты, что человек пришел из отпуска и напрочь забыл свой пароль, ввел его несколько раз не правильно, чем вызвал блокирование
• После изменения пароля, у пользователя остались старые подключения WIFI на компьютере или телефоне со старыми учетными данными, которые пытаются автоматически подключиться к сервисам компании, это является основной причиной блокировки в Active Directory
• Как и в случае с WIFI, у пользователя после смены пароля, могут быть закэшированные, старые пароли в доступах к сетевым шарам, Outlook календарям и другим программам, которые однажды попросили ввести логин и пароль.
• Иногда бывают задания в планировщике Windows, которые запускались от имени пользователя, а не системы
• Забытые сессии на удаленном рабочем столе, был у меня случай когда у пользователя были права и он подключался по RDP к серверу. потом у него права забрали, а сессию разлогинить забыли, в итоге у него меняется пароль и его начинает каждый день по 5-10 раз блокировать, пака сессию не убили, проблема была актуальной.
• Сохраненные пароли в браузерах
• Службы работающие из под доменной учетной записи

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

По рекомендациям компании Microsoft, политику блокировки учетной записи Windows настраивают на уровне домена, и чаще всего используют для этого уже имеющуюся политику «Default Domain Policy».  Открываем редактор групповой политики и щелкаем правым кликом мыши по политике «Default Domain Policy», из контекстного меню выберите пункт «Изменить».

Переходим с вами по пути: Конфигурация компьютера — Политики — Конфигурация Windows -> Параметры безопасности -> Политики учетных записей -> Политики блокировки учетных записей (Computer Configuration -> Windows Settings -> Security Settings -> Account Policy -> Account Lockout Policy)

Тут в политике будет три пункта:

• Время до сброса счетчика блокировки (Reset account lockout counter after) — в данном параметре задается, через какое количество времени система обнулит счетчик неудачных попыток авторизации. (Этот параметр безопасности определяет количество минут, которые должны пройти после неудачной попытки входа в систему до того, как счетчик неудачных попыток входа будет сброшен до 0. Допустимые значения: от 1 до 99999 минут. Если определено пороговое значение блокировки учетной записи, то время сброса должно быть меньше или равно длительности блокировки учетной записи. ). В моем примере я настроил политику «Время до сброса счетчика блокировки» на 10 минут, думаю больше не стоит.

• Пороговое значение блокировки (Account lockout threshold) — Тут вы задаете, сколько будет допустимых неправильных попыток ввода, после превышения которых учетная запись Windows будет заблокирована (Количество неудачных попыток входа в систему может составлять от 0 до 999. Если установить это значение равным 0, то учетная запись никогда не будет разблокирована.Неудачные попытки ввода паролей на рабочих станциях или серверах-членах домена, заблокированных с помощью клавиш CTRL+ALT+DELETE или с помощью защищенных паролем заставок, считаются неудачными попытками входа в систему).  Я в своей политике задал пороговое значение блокировки равным 5-ти, этого думаю хватит, чтобы правильно ввести свой пароль.

• Продолжительность блокировки учетной записи (Account lockout duration) — ну тут все просто, собственно время блокировки учетной записи Windows в Active Directory. Допустимые значения: от 0 до 99999 минут. Если продолжительность блокировки учетной записи равна 0, то учетная запись будет заблокирована до тех пор, пока администратор не разблокирует ее. Если определено пороговое значение блокировки учетной записи, то длительность блокировки учетной записи должна быть больше или равна времени сброса.

Как выяснить причину блокировки учетной записи

Выше я вас рассказал, из-за чего может все лочиться, теперь нужно выяснить с какого компьютера или устройств, это происходит. Ко мне на работе за неделю попадает 5-7 заявок с подобным вопросом, пользователь сменил пароль и у него началась веселая игра под названием угадайка, где я оставил свои старые данные, по которым меня банит контроллер домена. Чтобы однозначно ответить на этот вопрос вам как системному администратору необходимо настроить специальную политику аудита, призванную следить за соответствующими событиями по которым вы сможете дать однозначный ответ по причинам блокировок. По умолчанию данный вид аудита не настроен.

Про аудит Active Directory я подробно рассказывал, можете посмотреть по ссылке, тут я приведу легкую его выдержку, для полноты статьи. Нам нужно включить политику аудита входа, на уровне домена. (Так же вы можете подробно почитать про расширенный аудит, дающий более тонкие настройки https://technet.microsoft.com/ru-ru/library/mt431761%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396)

Включение политики аудита входа

Открываем редактор групповой политики и находим в нем дефолтную политику «Default Domain Policy», открываем ее и переходим по такому пути.

Тут будут такие политики:

1. Аудит входа в систему
2. Аудит доступа к объектам
3. Аудит доступа к службе каталогов
4. Аудит изменений политики
5. Аудит использования привилегий
6. Аудит отслеживания процессов
7. Аудит системных событий
8. Аудит событий входа в систему
9. Аудит управления учетными записями

Нас будет интересовать включение аудита входа в систему, именно данный вид будет генерировать события 4771 и 4624. Открываем ее и ставим галки «Успех и отказ»

Так же советую задать политику аудита событий входа в систему, так же установите «Успех и отказ»

Ну и настроим еще таким же способом «Аудит управления учетными записями«, чтобы мы видели события с кодом 4740.

Когда политика настроена, то вы можете ее принудительно обновить или дождаться автоматического обновления в течении 90-120 минут.

Какие события отслеживать в журнале безопасность

Чтобы отследить устройство вызывающее блокировки учетной записи, нужно понять алгоритм работы данного механизма. Когда кто-то пытается вводить учетные данные в Active Directory, то он идет на ближайший к нему контроллер домена (Кстати выяснить какой контроллер домена вас аутентифицировал можно очень просто, я об этом рассказывал, если интересно, то посмотрите). Данный контроллер домена видит, что пользователь предоставляет некорректные учетные данные и отсылает этот запрос аутентификации на контроллер, который обладает ролью PDC и FSMO. Так как данная роль PDC-эмулятор и отвечает в доменной среде за обработку блокировок учетных записей. Если PDC-эмулятор видит не корректные данные, то он возвращает ответ контроллеру домена, который ему это прислал, что аутентификация не возможна, и в следствии этого генерируется событие 4740, на обоих контроллерах

• 4771 — Это событие возникает каждый раз, когда не удается центром распространения ключей для выдачи Kerberos билетов предоставить билета (TGT). Это может произойти, когда контроллер домена не установлен сертификат для проверки подлинности смарт-карты (например, с помощью «Контроллера домена» или «Проверка подлинности контроллера домена» шаблона), истек срок действия пароля пользователя или неправильный пароль был предоставленные. 4771 на контроллере домена указывает на неудачную попытку войти через Kerberos на рабочей станции с доменной учетной записью. (Подробнее про 4771 https://docs.microsoft.com/ru-ru/windows/security/threat-protection/auditing/event-4771)

• 4776 — Событие 681/4776 на контроллере домена указывает на неудачную попытку входа в систему через NTLM с доменной учетной записью. Код ошибки указывает, почему именно аутентификация была неудачной. Если происходит сбой попытки проверки учетных данных, вы увидите, что событие отказов с значение параметра Код ошибки не равно «0x0» (Подробнее про событие 4476 https://docs.microsoft.com/ru-ru/windows/security/threat-protection/auditing/event-4776)

• 4740 — Учетная запись указанного пользователя была заблокирована после нескольких попыток входа (Подробнее про событие 4740 https://docs.microsoft.com/ru-ru/windows/security/threat-protection/auditing/event-4740)
• 4662 — Это событие создается только в том случае, если соответствующие SACL настроен для объекта Active Directory и выполнить операцию не удалось (Подробнее https://docs.microsoft.com/ru-ru/windows/security/threat-protection/auditing/event-4662).
• 5136 — Объект службы каталогов был изменен (A directory service object was modified)

Как удобно отслеживать события блокировки

Я приведу примеры, как это делаю я и как это можно автоматизировать и оповещать вас заранее, чем это сделает представитель технической поддержки. Самый правильный вариант, это использование систем мониторинга, таких как SCOM или Zabbix, но если их нет, то можно упростить себе жизнь вот такими утилитами. Могу точно сказать, что у вас в компании, как минимум не один контроллер домена, в противном случае у вас проблемы. Бегать по каждому из контроллеров домена, это не лучший вариант, правильнее будет либо перенаправлять все события на централизованный коллектор или же воспользоваться двумя волшебными утилитами, которые вам упростят жизнь.

Я вам рассказывал про набор утилит от компании Microsoft под названием Active Directory ALTools. Там была утилита LockoutStatus.exe. В задачи которой и входило определение статуса пользовательской учетной записи, заблокирована она или нет, и если до, то на каком контроллере домена. Скачайте ее и запустите. Нажимаете пункт меню «File — Select Target», для того чтобы выбрать логин нужной учетной записи.

В поле «Target User Name» вы указываете логин пользователя, кто подвергся блокировке в Active Directory.

На выходе вы получите отчет по всем контроллерам в домене, о статусе вашей учетной записи. Как видите, мой Барбоскин Геннадий Викторович заблокирован и имеет статус «Locked», видно количество попыток неправильного ввода пароля (Bad Pwd Count) и на каких контроллерах домена, на них мы и будем искать нужные нам события, о которых я говорил выше.

Открываем просмотр событий на нужном контроллере домена. Переходим в журнал «Безопасность (Security)» именно в нем кроется причина блокировки учетной записи Барбоскина Геннадия. Так как событий огромное количество, то нам нужно отфильтровать наш журнал событий. Для этого есть кнопка «Filter Current Log (Фильтр текущего журнала)», она позволит нам выбрать только те события, которые нам нужны.

В поле «Logged (Дата)» указываем за какой срок нужны данные, я укажу 12 часов, и в поле все события, укажем номер ID 4740 и нажимаем «Ок»

Видим нашлось 50 событий, но может быть и больше и чтобы ускорить поиск нужного события, мы воспользуемся поисков, для этого нажмите кнопку «Find (Поиск)»

В поисковом поле указываем нужный вам логин учетной записи Windows и нажимаем поиск, если сообщений много, то он может слегка подвисать, не переживайте по этому поводу.

В итоге у меня нашлось событие с кодом 4740, из которого видна причина блокировки учетной записи. В данном случае это рабочая станция с именем SVTTSETMAIN01, это тестовая виртуальная машина, как видите тут статус «A user account was locked out», можно переходить на эту машину и смотреть в чем там дело.

В событиях 4740 вы можете встреть еще вот такие причины блокировки учетной записи Active Directory, так например у меня имя сервера, где происходит блокирование EXchange, означает, что проблема в Outlook или его календарем. Я вам рассказывал, где кэшируются его данные доступа, в заметка Outlook постоянно запрашивает пароль.

В моей компании используются сервисы Google, такие как G-Sute и общие файловые диски, и вот при смене пароля пользователем, в данных утилитах могут остаться старые данные, в результате чего вы будите видеть в логах в компьютере блокировки имя WORKSTATION. Думаю с событием 4740 все понятно, но оно не всегда показывает подробный источник блокировки, поэтому нужно смотреть событие 4771.

Вот пример блокировки из-за WiFI подключения, об это мне говорит имя компьютера CISCO точки доступа. Как видите причин может быть очень много.

Более подробную причину блокировки учетной записи Windows на покажет событие 4771. Сделаем так же фильтрацию и по нему. Основное сообщение тут «Kerberos pre-authentication failed», обратите внимание тут есть IP-адрес, что уже хорошо, это дополнительная информация, показывающая территориальный источник. В ошибка есть код отказа Kerberos, таблица была представлена выше.

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

Кстати получив IP-адрес вы можете посмотреть его mac адрес на DHCP сервере или же на сетевом оборудовании, например, Cisco, я показывал как там узнать mac-адрес.

Далее с помощью специальных сервисов можно определить, что за производитель у данного mac-адреса, сайтов в интернете полно, которые вам помогу, например, https://2ip.ua/ru/services/information-service/mac-find. Будет полезно с мобильными устройствами.

Еще полезным будет изучение события 4625, там вы можете обнаружить процесс из-за которого происходит блокировка учетных записей.

Если вы у себя в Active Directory используете определение имени системы куда был залогинен пользователь в последний раз, то для вас будет полезно событие IS 5136. Тут в конкретное поле у меня записывается имя компьютера, и вот пробежавшись по таким событиям, я обнаружил, что имя компьютера там бывает разное, что подсказывает, где еще от имени пользователя могут идти попытки с неправильным паролем и как следствие, блокировка учетной записи.

Как видите утилита от компании Mirosoft отлично работает, но можно посмотреть, что-то более удобное, мне нравится утилита Account Lockout Examiner от Netwrix, она бесплатная и позволяет создавать портал для технической поддержки, где они могут видеть кто заблокирован и разблокировать его, а так же причину и она умеет посылать оповещения по электронной почте.

Утилита Account Lockout Examiner проста в установке и потребует от вас две вещи:

1. Указание имени домена для поиска событий блокировки учетных записей Windows
2. Учетные данные от имени которых будет обращение к контроллерам домена

Через некоторое время вы получите табличку со всем пользователями у кого наблюдаются проблемы с блокировкой учеток. Тут вы увидите столбец «Workstation» в котом вы увидите адрес устройства блокировки, есть поле Bad Pwd Count показывающее количество попыток неправильно введенного пароля и дата последнего ввода. В самом конце вы увидите статусы пользователей Not locked или Locked.

Тут же вы можете через правый клик разблокировать пользователя.

В настройках Account Lockout Examine вы можете указать адрес электронной почты и сервер, для уведомлений, о событиях блокировки пользователей.

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

Поиск компьютера блокирующего пользователя через PowerShell

PowerShell, очень мощное средство позволяющее сделать очень многое, вот пример поиска устройства из-за которого блокируется учетная запись. Открываем PowerShell ISE и вводим код:

Единственное не забудьте поменять в $Username = ‘username1’ на своего пользователя, можете скачать уже готовый скрипт у меня. На выходе вы получаете имя компьютера.

Аналогичным образом можно опросить из PowerShell все контроллеры домена в Active Directory:

Еще один вариант скрипта, тут я обращаюсь к конкретному серверу, куда идет форвардинг событий со всех контроллеров домена.

Надеюсь, что мой скромный опыт слегка вам поможет в поиске причин, по которым у вас в домене блокируются учетные записи Active Directory.

Включение ведения расширенного журнала отладки для службы Netlogon (Обновление 04.01.2023)

Январские праздники, идеальное время чтобы забыть пароль, после чего конечно же человека заблокирует. Вот реальный пример, есть коллега отвечающий за работу 1С, потребовалось выполнить какую-то работу в начале января, но сотрудник не смог его учетная запись была заблокирована. В логах видно, что 3от имени учетной записи пользователя в секунду прилетает по несколько неудачных попыток входа, о чем говорит код 0x000006A, а после чего идет статус «Заблокирована учетная запись пользователя«, при активации учетной записи, все мгновенно повторяется.

После этого журнал был забит:

К сожалению описанные выше ID событий толком не помогли и не показали, откуда идет блокировка, забегу вперед, это оказалась Linux виртуальная машина, поэтому она и не представилась службе Netlogon и не фигурировала в поле «Caller Computer Name«

Еще так же вы можете увидеть ID 4740, но со странным содержанием:

Тут главное запомнить на каком контроллере оно появилось, не всегда это PDC эмулятор, далее откройте вкладку «Details» и включите XML View. Там подробнее все будет структурировано, но к сожалению вы не увидите. откуда проблема.

Чтобы решить эту ситуацию с блокировкой учетной записи, нам нужно на контроллере домена, где это происходит включить ведения расширенного журнала отладки для службы Netlogon.

Это позволит записывать трассировки для Netlogon и получать кучу дополнительных сведений. Описанная ниже команда подойдет для Windows Server 2019/2022,  Windows Server 2016 и Windows Server 2012 R2. К командной строке в режиме администратора введите:

Далее перезапустим службу:

После того, как вы активировали ведение расширенного журнала Netlogon, у вас по пути %windir%debugnetlogon.log будет файл лог.

Для отключения расширенного режима (Когда посчитаете нужным) введите:

Я начал изучать логи на DC1. Быстро пробежаться по файлу можно командой:

kom — это искомый логин.

Или как я это делаю в LogViewPlus. В результате я обнаружил, что события блокировки идут от другого контроллера домена из корневого домена. Включаю на DC07 так же режим расширенного ведения логов Netlogon.

На DC07, я уже в журнале netlogon.log увидел кто обращается к контроллеру DC07. оказалось, что это файловая нода кластера DFS. Идем на нее и смотрим логи.

И вот уже анализируя логи на DFS ноде, я увидел в событии ID 4625, что учетной записи не удалось выполнить вход в систему с сетевого адреса источника, где указан был его IP-адрес. БИНГО. После того, как утилита nslookup показа кто, это стало все понятно. Это был Linux сервер, которому до лампочки на службу Netlogon, чтобы ей представляться, внутри этого сервера была смонтирована сетевая шара на эту DFS ноду с учетными данным пользователя.

В результате от монтировали файловую шару и учетную запись удалось разблокировать.

Блокировка учетной записи не в домене Active Directory

В случае с Active Directory все понятно, а как быть если учетная запись заблокировалась на вашем локальном, домашнем компьютере. Тут две ситуации, если у вас есть заблокировалась одна из нескольких учетных записей и у других записей есть права администратора, то вы можете все разблокировать, и вторая ситуация, если у вас одна учетная запись и она залочилась, тут будет повеселее, но так же все поправимо. Я опущу причины блокировки, вероятнее всего у вас стоит политика блокировки и вы ее можете поправить через локальную, для этого в окне выполнить напишите gpedit.msc и отключите пункты, о которых я писал в самом начале, либо же с вами кто-то подшутил таким образом выставив вам эту политику, но не суть.

Как разблокировать учетную запись в Windows 10 имея вторую учетку

Если у вас блокировка учетной записи windows 10 уже свершилась, и есть в наличии вторая учетная запись, например у папы своя у мамы своя, то сделайте следующее. Чтобы снять блокировку активируйте учетную запись, откройте окно выполнить, через сочетание клавиш WIN и R и введите название оснастки lusrmgr.msc

Открываем контейнер «Пользователи» и находим нужного нам, переходим в его свойства

Снимаем у нее галку «Заблокировать учётную запись» и нажимаем применить, все учетная запись теперь будет в рабочем состоянии.

Как разблокировать свою учётную запись Windows, если нет административного доступа

Чтобы обойти блокировку учетной записи, можно пойти двумя путями, легким и посложнее. Самый простой способ разблокировать учетную запись не имя административных прав, это воспользоваться загрузочным диском SonyaPE. Когда вы сделаете из него загрузочную флешку и загрузитесь с нее, то получите рабочий стол Windows 7. Там есть утилита Active@ Password Changer Professional 3.8, которая позволит вам включить и сбросить пароль от встроенной учетной записи Администратор, которая есть в любой операционной системе Windows, далее зайдя под ней вы разблокируете нужную нам учетную запись, как я описывал выше.

Как видите этот метод позволяет обойти блокировку учетной записи, но он не единственный, допустим у вас под рукой нет такого диска, как SonyaPE, что делать. Можно воспользоваться встроенными средствами восстановления Windows или же ими, но на любом установочном диске с Windows вашей редакции. В заметке «Как вернуть предыдущую версию виндоус 10» я показал метод попадания в дополнительные инструменты Windows 10.

Либо вы можете попасть в эти утилиты, через инструменты восстановления системы, о которых шла речь в заметке про восстановление загрузчика Windows 10.

В том и в другом случае, вам необходимо открыть командную строку.

Выбираем раздел HKEY_LOCAL_MACHINE, после чего в меню «Файл» выберите пункт «Загрузить куст».

У вас откроется проводник Windows. В моем компьютере, перейдите по пути WindowsSystem32Config. В этой папке лежит файл локальной базы данных пользователей, по имени SAM. Выбираем его и открываем.

Задаем имя новому кусту, для примера это будет 777.

Внутри раздела реестра HKEY_LOCAL_MACHINE теперь наблюдаем новую ветвь 777. Переходим в ней по пути: 777 – SAM – Domains – Account – Users – Names. Тут вам необходимо идентифицировать вашу учетную запись, которая находится в блокировке. В моем примере, это Василий. Выбрав Васю, посмотрите, что по умолчанию он имеет значение 0x3f8

Выбираем теперь куст 00003f8. В правой панели реестра ищем параметр «F» и двойным кликом раскрываем его.

В окошке параметра нам нужна строка 0038. Её первые два значения (у нас это 10 и 00) заменяем.

Двойным кликом щёлкаем по очереди на каждом из двух значений, и когда те выделятся синим, вписываем другие значения. А эти другие значения должны быть 10 и 02 соответственно.

Теперь в окне реестра кликаем на загруженный и отредактированный куст, у нас это 777. И выгружаем его: жмём «Файл», далее «Выгрузить куст». Все необходимые изменения внесены.

Перезагружаем ваш компьютер и пробуем войти под вашей учетной записью, она уже не должна быть заблокирована. На этом все, с вами был Семин Иван, автор и создатель IT блога Pyatilistnik.org.

Возможные причины блокировки пользователя в Active Directory

Данная ситуация существует в компаниях, где настроена политика блокировки учетной записи при вводе определенного количества не правильных паролей, это правильно с точки зрения кибербезопасности так как помогает защититься от брутфорса.

Из основных причин блокировки можно выделить:

• — Постоянный маппинг дисков со старыми учетными данными
• — Мобильные устройства, использующие корпоративные сервисы
• — Учетные записи служб, использующие кэшированные пароли, которые были изменены в ходе технического обслуживания
• — Запланированные задачи с устаревшими паролями
• — Программы, использующие сохраненные пароли, которые были изменены
• — Отключенные сеансы сервера терминалов
• — Проблемы с репликацией Active Directory
• — Неправильно настроенные параметры политики домена
• — Вредоносная активность, например, атака перебора паролей.

Где настраивается политика блокировки учетных записей

Открываем редактор групповой политики, создаем новую политику, называем ее например Account Lockout Policy и щелкаем на нее правой кнопкой мыши и выбираем «Изменить».

• Ставим время до сброса счетчика блокировки на 30 минут
• Пороговое значение блокировки – 5 ошибок входа в систему
• Продолжительность блокировки учетной записи – 30 минут.

Закрываем, применяем политику на домен и на целевой машине запускаем gpupdate /force

Как выяснить причину блокировки учетной записи

Теперь, когда политика включена нам нужно определять из-за чего может все лочиться, и с какого компьютера или устройств, это происходит. Чтобы ответить на этот вопрос нужно настроить специальную политику аудита, призванную следить за соответствующими событиями, по которым вы сможете найти причину блокировок. По умолчанию данный вид аудита не настроен.

Снова открываем редактор групповой политики, создаем политику Audit Policy открываем ее и переходим по такому пути.

Конфигурация компьютера -> Политики -> Конфигурация Windows -> Параметры безопасности -> Локальные политики -> Политика аудита

Нам нужно включить аудит входа в систему, именно данная политика генерирует события 4771 и 4624. Настраиваем ее на «Успех и отказ».

Так же нужно задать политику аудита событий входа в систему на «Успех и отказ», а так же «Аудит управления учетными записями», чтобы видеть события 4740.

Принудительно обновляем политику и запускаем gpupdate /force на целевой машине

Какие события отслеживать в журнале безопасность

При некорректном вводе данных генерируется событие 4740, на всех контроллерах домена если он не один. С кодами отказов Kerberos:

• 6 – имя пользователя не существует
• 12 – Ограничение времени входа в систему
• 18 – Учетная запись деактивирована, заблокирована или истек срок ее действия
• 23 – Истек срок действия пароля пользователя
• 24 – Предварительная аутентификация не удалась(неверный пароль)
• 32 – Истек срок действия тикета
• 37 – Время компьютера давно не синхронизировалось с доменным

и кодами ошибок NTLM

Код ошибки (десятичная система) — Код ошибки (16-ричная система) — Описание

• 3221225572 — С0000064 — Такого имени пользователя не существует
• 3221225578 — С000006А — Верное имя пользователя, но неверный пароль
• 3221226036 — С0000234 — Учетная запись пользователя заблокирована
• 3221225586 — С0000072 — Учетная запись деактивирована
• 3221225583 — С000006Е — Пользователь пытается войти в систему вне обозначенного периода времени
• 3221225584 — С0000070 — Ограничение рабочей станции
• 3221225875 — С0000193 — Истек срок действия учетной записи
• 3221225585 — 0000071 — Истек срок действия пароля
• 3221226020 — С0000224 — Пользователь должен поменять пароль при следующем входе в систему

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

Открываем журнал событий и идем в журнал безопасность (Security)» именно в нем собираются EventID которые могут помочь определить причину блокировки. Там очень много событий, так что отфильтруем их с помощью «Filter Current Log (Фильтр текущего журнала)», она позволит нам выбрать только те события, которые нам нужны. В поле Logged указываем за какой срок нужны данные, в поле Event ID указываем 4740 и нажимаем «Ок»

В отфильтрованных записях с помощью поиска (Find) находим имя интересующей нас учетной записи. В итоге должны отфильтроваться события по указанному логину с кодом 4740 в котором можно найти причину блокировки, например в поле Caller Computer Name будет указано имя компьютера с которого идут феилд логоны и который этим вызывает блокировку. Затем нужно перейти на этот компьютер и смотреть евент логи там, чтобы определить почему данная машина пытается залогиниться под некорректными кредами.

В событиях 4740 можно встреть еще такие причины блокировки как имя сервера, где происходит блокирование Exchange сервер организации – это значит, что проблема в Outlook, почтовом мобильном клиенте или его календарем. Чтобы расследовать данную блокировку нужно смотреть логи IIS на Exchange сервере. Так же можно использовать команду Get-ActiveSyncDeviceStatistics в PowerShell, чтобы увидеть проблемные мобильные устройства.

Microsoft ALTools

У компании Microsoft есть собственный инструмент для помощи в устранения проблем с блокировкой учетных записей — Microsoft Account Lockout and Management Tool (AlTools.exe). Download Account Lockout Status (LockoutStatus.exe) from Official Microsoft Download Center.

Этот инструмент отображает информацию о заблокированной учетной записи с ее состоянием пользователя и временем блокировки на каждом контроллере домена и позволяет разблокировать ее, щелкнув правой кнопкой мыши на соответствующей записи.

Запустите LockoutStatus.exe > File > Select target > Введите имя учетной записи и домен > OK

Он покажет все статусы связанные с блокировкой по данному аккаунту.

Инструмент EventCombMT

EventCombMT Tool собирает определенные события с нескольких различных серверов в одно центральное место.

Запустите EventCombMT.exe > Щелкните правой кнопкой мыши на поле Select to search > Выберите Get DCs in Domain > Отметьте контроллеры домена для поиска. — Нажмите меню Searches (Поиск) > Built In Searches (Встроенный поиск) > Account Lockouts (Блокировка учетных записей).

Другие причины блокировок пользовательских учетных записей

Если проблема локаута кроется в сервисах Google Workspaces (Gmail, Gdrive…) то в логах будет отображаться, что феилд логоны идут с компьютера WORKSTATION. Так же подробную информацию о блокировке можно посмотреть в событии 4771. Там можно найти Керберос коды, которые были описаны выше и IP адрес устройства с которого идут фейлд логоны.

Если в полях Caller Computer Name ивента 4770 и Client Address 4771 пусто – это значит что вас скорее всего брутфорсят!

Чтобы определить источник фейлд логонов в этом случае необходимо включить netlogon и смотреть его логи.

NETLOGON Netlogon — это процесс Windows Server, который аутентифицирует пользователей и другие службы в домене. Включите ведение журнала Netlogon: Пуск > Выполнить > введите:

nltest /dbflag:2080ffff > OK

После перезапуска службы Netlogon соответствующая активность может быть записана в %windir%/debug/netlogon.log.

Можно так же разобрать журналы Netlogon с помощью скрипта:

type netlogon.log |find /i "0xC000006A" > failedpw.txt type netlogon.log |find /i "0xC0000234" > lockedusr.txt

Внимание! Не забудьте отключить Netlogon после того, как вы зафиксировали события, так как производительность системы может быть немного снижена из-за процесса дебаггинга. Отключите ведение журнала Netlogon:

Пуск > Выполнить > введите:
nltest /dbflag:0 > OK

В логах можно найти айпишники тех компьютеров, с которых идут скрытые фейлд логоны, это могут быть терминальные сервера или RDP на которые ведется атака по перебору паролей.

Возвращаемся к журналу событий безопасности. Еще может быть полезным событие с кодом 4776, тут тоже можно найти с какой рабочей станции была попытка ввода учетных данных.

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

Еще полезным будет изучение события 4625, там вы можете обнаружить процесс, из-за которого происходит блокировка учетных записей. Используйте Process Hacker или Process Monitor для просмотра учетных данных активных процессов.

Проблемой блокировки может быть планировщик задач Windows — возможно, есть задача, настроенная на запуск с использованием учетной записи, пароль к которой поменялся.

На локальной машине могут быть сохраненные учетные данные, найти которые можно так:

Пуск> Выполнить > rundll32 keymgr.dll, KRShowKeyMgr > OK.

Или Netplwiz:

Пуск> Выполнить > введите: netplwiz > OK Перейдите на вкладку Дополнительно, а затем нажмите Управление паролями.

Блокировку может вызывать сессия сервера терминалов с устаревшими учетными данными. Для отключения RDP сессии выполните следующие команды в командной строке (Win+R > «cmd»), заменив «server_ip», «name» и «password» на необходимые учетные данные:

net use \server_ip /USER:name password

Это позволит вам войти на удаленный сервер без использования RDP.

query session /server:name

Замените «name» на имя сервера. Здесь вы получите идентификатор сессии.

reset session id /server:server_ip

Это завершает активную сессию на удаленном сервере.

Блокировку учетки может вызывать репликация AD, когда обновление пароля не было реплицировано на все контроллеры домена. Для принудительной репликации выполните следующую команду на вашем DC:

repadmin /syncall /AdeP