Код ошибки 0xc0000234

Все началось с того что пара пользователей стали регулярно блокироваться. Стандартный поиск по «Просмотр событий» показал вот такую картину:

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

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

Хочется отметить, что «Исходная рабочая станция» — пусто, никаких данных нет.

Так же в логах присутствовали коды ошибок 0xc000006a и 0xc0000234

Интернет подсказал что они означают:

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.

Гугление и чтение умных и полезных статеек (например вот: https://habrahabr.ru/company/netwrix/blog/148501/) привели к необходимости включить расширенный лог — на контроллерах домена включил

nltest /dbflag:0x2080ffff

не забыть потом выключить командой

nltest /dbflag:0x0

и начал анализировать результат в файле C:\Windows\debug\netlogon.log руками или чем-то вроде

type C:\Windows\debug\netlogon.log | findstr MYLOGIN

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

10/13 21:32:39 [LOGON] MY-DOMAIN: SamLogon: Transitive Network logon of MY-DOMAIN\TESTER from  (via DC03) Entered
10/13 21:32:39 [LOGON] MY-DOMAIN: SamLogon: Transitive Network logon of MY-DOMAIN\TESTER from  (via DC03) Returns 0xC000006A

Понятно, работает какая-то зараза. Ну что же — мяч не на нашей стороне и это уже хорошо. Через некоторое время коллеги ответили — действительно, долбились через их RDP-сервера. Прикрутили скриптик, блокирующий перебирателей и наступила тишина. Кстати, на свежеподнятом linux-сервере я всегда первым делом ставлю fail2ban, это уже рефлекс.

Решений существует куча, например:

Как вариант защиты пользователей — можно разрешить вход только с определенных компьютеров чтобы обезопасить учетные записи (Учетная запись пользователя → Свойства → Учетная запись → Вход на… → Только на указанные компьютеры).

RRS feed

  • Remove From My Forums
  • Question

  • I am coming across several instances where a user will get the error code 0xC0000234 for event 4776 and Failure Reason: Account Locked Out for event 4625 but the account never actually locks out. I cannot find a corresponding event 644 (windows 2003) or
    4740 (Server 2008 and up) on any of our AD servers.

    Any idea why this would register as an account being locked out, but not actually lock the account out?

    Thanks!

All replies

  • Hi,

    According to your description, you mentioned that this accounts hasn’t been actually lockout, do you mean that this account can log on successfully?

    What is the time when the event 4776 with code: 0xC0000234 logged?

    Best Regards,

    Amy

  • The 0xC0000234 event happens several times and then within a couple seconds to minutes, I see successful logon events. I have checked and the user didnt experience a lock out, which is really odd. Could it be that the server that locks it out isnt passing
    the event to all the member DCs?

  • Hi,

    Sounds a little weird to me.

    Would you please check the account lockout policy, and post out the configured value for
    Account lockout duration,
    Account lockout threshold and Reset account lockout counter after?

    More information for you:

    Account Policy Settings

    http://technet.microsoft.com/en-us/library/cc757692(v=WS.10).aspx

    If the Account lockout duration and Reset account lockout counter after settings are set too low, the account will be unlocked very quickly after it’s locked.

    Best Regards,

    Amy

    • Marked as answer by

      Tuesday, May 27, 2014 5:53 AM

    • Unmarked as answer by
      Amy Wang_
      Wednesday, June 4, 2014 1:30 AM

  • This isnt the case. The account lockout and reset account lockouts are set as they should be, not too low if at all. So this isnt the answer for this scenario.

  • Hi,

    If that’s the case, would you please post out related event messages for further troubleshooting?

    Best Regards,

    Amy

  • 0xc0000234 – The user account has been automatically locked because too many invalid logon attempts or password change attempts have been requested.

  • We are seeing this repeat pattern in our SIEM as well for a privileged account. The pattern is first a series of:

    Object Name 0xC0000234
    Vendor Message ID 4776
    Vendor Info The computer attempted to validate the credentials for an account.

    Then followed by: 

    Vendor Message ID 4776
    Vendor Info The computer attempted to validate the credentials for an account.

Error code 0xc0000234 – The user account has been automatically locked because too many invalid logon attempts or password change attempts have been requested.

Error code 0xc0000234 log details log under Event Id 4776 in event viewer.

Event ID 4776 0xc0000234 – user account has been automatically locked every after few seconds and the user failed to logins.

In this article, we will discuss a solution to solve the error code 0xc0000234 or event id-4776 by enabling debug logging for the netlogon service.

When DC ( Domain Controller) successfully authenticates a user via NTLM, it logs this event.

Authentication Package: Always “MICROSOFT_AUTHENTICATION_PACKAGE_V1_0”

Logon Account: ShellOper

Source Workstation:
Error Code: 0xc0000234

In the event log, it shows the above information

This event is also logged on member servers and workstations when someone attempts to log on with a local account.

Cool Tip: How to manipulate Active Directory UserAccountControl flags in PowerShell!

Error Code 0xc0000234 Solution

To know the source of the login attempt, we have to enable verbose netlogon logging on Domain Controller.

To enable the verbose netlogon logging follow given below steps

  1. Open a Cmd (Command Prompt) with Administrator privileges.
  2. Run below command
Nltest /DBFlag:2080FFFF
  1. Netlogon service stop and restart not required.
  2. If you want to turn off the verbose netlogon logging, run below command
Nltest /DBFlag:0x0

Netlogon related events are available in file %windir%\debug\netlogon.log

To read the events of the above file, open the log file with run as administrator.

netlogon.log file contains the user logon attempt and its source location.

This will help you to trace the workstation from where the login attempt was coming.

You can enable or disable netlogon logging using the registry method.

  1. Open the registry editor
  2. If Reg_SZ value for the below registry entry exists, delete it
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DBFlag

3. Create REG_DWORD with the same word and assign value 2080FFFF hexadecimal value.

Cool Tip: Event Id 4625 Status Code 0xc000006a – Fix to find the source of attempt!

Conclusion

I hope the above article on error code 0xc0000234 logs under event id 4776 is helpful to you.

Error Status code 0xc0000234 – User account has been automatically locked because of too many invalid logon or password change attempts.

Cool Tip: Event Id 4634 – An Account was logged off!

Using enabling the verbose logging for the netlogon service on the Domain controller will help you to find out logon attempt location.

Cool Tip: Event Id 4771 – Kerberos pre-authentication failed!

You can find more topics about PowerShell Active Directory commands and PowerShell basics on the ShellGeek home page.

You can read more on other windows security and system event logs as given:

  • Event Id 4670 – System restart or shutdown
  • Event Id 4624 – An account was successfully logged on.

RRS feed

  • Remove From My Forums
  • Question

  • I am coming across several instances where a user will get the error code 0xC0000234 for event 4776 and Failure Reason: Account Locked Out for event 4625 but the account never actually locks out. I cannot find a corresponding event 644 (windows 2003) or
    4740 (Server 2008 and up) on any of our AD servers.

    Any idea why this would register as an account being locked out, but not actually lock the account out?

    Thanks!

All replies

  • Hi,

    According to your description, you mentioned that this accounts hasn’t been actually lockout, do you mean that this account can log on successfully?

    What is the time when the event 4776 with code: 0xC0000234 logged?

    Best Regards,

    Amy

  • The 0xC0000234 event happens several times and then within a couple seconds to minutes, I see successful logon events. I have checked and the user didnt experience a lock out, which is really odd. Could it be that the server that locks it out isnt passing
    the event to all the member DCs?

  • Hi,

    Sounds a little weird to me.

    Would you please check the account lockout policy, and post out the configured value for
    Account lockout duration,
    Account lockout threshold and Reset account lockout counter after?

    More information for you:

    Account Policy Settings

    http://technet.microsoft.com/en-us/library/cc757692(v=WS.10).aspx

    If the Account lockout duration and Reset account lockout counter after settings are set too low, the account will be unlocked very quickly after it’s locked.

    Best Regards,

    Amy

    • Marked as answer by

      Tuesday, May 27, 2014 5:53 AM

    • Unmarked as answer by
      Amy Wang_
      Wednesday, June 4, 2014 1:30 AM

  • This isnt the case. The account lockout and reset account lockouts are set as they should be, not too low if at all. So this isnt the answer for this scenario.

  • Hi,

    If that’s the case, would you please post out related event messages for further troubleshooting?

    Best Regards,

    Amy

  • 0xc0000234 – The user account has been automatically locked because too many invalid logon attempts or password change attempts have been requested.

  • We are seeing this repeat pattern in our SIEM as well for a privileged account. The pattern is first a series of:

    Object Name 0xC0000234
    Vendor Message ID 4776
    Vendor Info The computer attempted to validate the credentials for an account.

    Then followed by: 

    Vendor Message ID 4776
    Vendor Info The computer attempted to validate the credentials for an account.

Error code 0xc0000234 – The user account has been automatically locked because too many invalid logon attempts or password change attempts have been requested.

Error code 0xc0000234 log details log under Event Id 4776 in event viewer.

Event ID 4776 0xc0000234 – user account has been automatically locked every after few seconds and the user failed to logins.

In this article, we will discuss a solution to solve the error code 0xc0000234 or event id-4776 by enabling debug logging for the netlogon service.

When DC ( Domain Controller) successfully authenticates a user via NTLM, it logs this event.

Authentication Package: Always “MICROSOFT_AUTHENTICATION_PACKAGE_V1_0”

Logon Account: ShellOper

Source Workstation:
Error Code: 0xc0000234

In the event log, it shows the above information

This event is also logged on member servers and workstations when someone attempts to log on with a local account.

Cool Tip: How to manipulate Active Directory UserAccountControl flags in PowerShell!

Error Code 0xc0000234 Solution

To know the source of the login attempt, we have to enable verbose netlogon logging on Domain Controller.

To enable the verbose netlogon logging follow given below steps

  1. Open a Cmd (Command Prompt) with Administrator privileges.
  2. Run below command
Nltest /DBFlag:2080FFFF
  1. Netlogon service stop and restart not required.
  2. If you want to turn off the verbose netlogon logging, run below command
Nltest /DBFlag:0x0

Netlogon related events are available in file %windir%debugnetlogon.log

To read the events of the above file, open the log file with run as administrator.

netlogon.log file contains the user logon attempt and its source location.

This will help you to trace the workstation from where the login attempt was coming.

You can enable or disable netlogon logging using the registry method.

  1. Open the registry editor
  2. If Reg_SZ value for the below registry entry exists, delete it
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParametersDBFlag

3. Create REG_DWORD with the same word and assign value 2080FFFF hexadecimal value.

Cool Tip: Event Id 4625 Status Code 0xc000006a – Fix to find the source of attempt!

Conclusion

I hope the above article on error code 0xc0000234 logs under event id 4776 is helpful to you.

Error Status code 0xc0000234 – User account has been automatically locked because of too many invalid logon or password change attempts.

Cool Tip: Event Id 4634 – An Account was logged off!

Using enabling the verbose logging for the netlogon service on the Domain controller will help you to find out logon attempt location.

Cool Tip: Event Id 4771 – Kerberos pre-authentication failed!

You can find more topics about PowerShell Active Directory commands and PowerShell basics on the ShellGeek home page.

You can read more on other windows security and system event logs as given:

  • Event Id 4670 – System restart or shutdown
  • Event Id 4624 – An account was successfully logged on.

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

Содержание:

  • Учетная запись пользователя заблокирована и не может быть использована для входа в сеть
  • Как проверить, что аккаунт пользователя AD заблокирован?
  • Политики блокировки учетных записей в домене
  • События блокировки пользователей EventID 4740, 4625
  • Поиск компьютера, с которого блокируется пользователь с помощью PowerShell
  • Утилита Microsoft Account Lockout and Management Tools
  • Как определить программу, из которой блокируется учетная запись пользователя?

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

Политика безопасности учетных записей в большинстве организаций требует обязательного блокирования учетной записи пользователя в домене 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). Также в выводе команды вы видите информацию о времени смены пароля пользователя в домене и времени блокировки аккаунта.

poweshell: проверить что пользователь ad заблокирован - атрибут lockedout

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

Search-ADAccount -UsersOnly -lockedout

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

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

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

Get-ADUser -Identity aaivanov | Unlock-ADAccount

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

Get-ADUser aaivanov -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

powershell узнать время блокировки пользователя

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

Политики блокировки учетных записей и паролей обычно задаются сразу для всего домена политикой 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.

политика аудита событий блокировки на контроллерах домена Audit Account Lockout

Если пользователь ввел неверный пароль, то ближайший к пользователю контроллер домена перенаправляет запрос аутентификации на 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 и приступать к поиску источника блокировки как можно раньше.

Событие блокировки учетной записи на контроллере домена AD. eventid 4740

Откройте данное событие. Имя компьютера (или сервера), с которого была произведена блокировка указано в поле 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), с которого пришел запрос.

4711 ip адрес устройтва-источника блокировки пользователя через kerberos аутентфикацию

Если удаленное устройство использует 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).

4625 IP адрес устройства, с которого выполняется блокировка пользователя при использовании NTLM аутентфикации

Если вы не можете найти событие блокировки пользователя в журнале 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"

поиск источника блокировки пользователя в логе debugnetlogon.log

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

Не забудьте отключить расширенный лог на DC:

nltest /dbflag:0x0

Поиск компьютера, с которого блокируется пользователь с помощью 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 скрипт ждя поиска источника блокировки пользователя по событию 4740

Аналогичным образом можно опросить из 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).

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

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

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

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

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

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). Это как правило самый действенный метод защиты от внезапных блокировок определенного пользователя, если вы не смогли установить источник блокировки.

Все началось с того что пара пользователей стали регулярно блокироваться. Стандартный поиск по «Просмотр событий» показал вот такую картину:

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

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

Хочется отметить, что «Исходная рабочая станция» — пусто, никаких данных нет.

Так же в логах присутствовали коды ошибок 0xc000006a и 0xc0000234

Интернет подсказал что они означают:

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.

Гугление и чтение умных и полезных статеек (например вот: https://habrahabr.ru/company/netwrix/blog/148501/) привели к необходимости включить расширенный лог — на контроллерах домена включил

nltest /dbflag:0x2080ffff

не забыть потом выключить командой

nltest /dbflag:0x0

и начал анализировать результат в файле C:Windowsdebugnetlogon.log руками или чем-то вроде

type C:Windowsdebugnetlogon.log | findstr MYLOGIN

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

10/13 21:32:39 [LOGON] MY-DOMAIN: SamLogon: Transitive Network logon of MY-DOMAINTESTER from  (via DC03) Entered
10/13 21:32:39 [LOGON] MY-DOMAIN: SamLogon: Transitive Network logon of MY-DOMAINTESTER from  (via DC03) Returns 0xC000006A

Понятно, работает какая-то зараза. Ну что же — мяч не на нашей стороне и это уже хорошо. Через некоторое время коллеги ответили — действительно, долбились через их RDP-сервера. Прикрутили скриптик, блокирующий перебирателей и наступила тишина. Кстати, на свежеподнятом linux-сервере я всегда первым делом ставлю fail2ban, это уже рефлекс.

Решений существует куча, например:

Как вариант защиты пользователей — можно разрешить вход только с определенных компьютеров чтобы обезопасить учетные записи (Учетная запись пользователя → Свойства → Учетная запись → Вход на… → Только на указанные компьютеры).

Понравилась статья? Поделить с друзьями:
  • Код ошибки 0xc0000225 что делать
  • Код ошибки 0xc0000225 windows 10 как исправить
  • Код ошибки 0xc0000225 при установке windows 10
  • Код ошибки 0xc0000225 при загрузке ноутбука
  • Код ошибки 0xc0000225 при загрузке windows 10 компьютера