В этой статье мы покажем, как отслеживать события блокировки учеток пользователей на котроллерах домена Active Directory, определять с какого компьютера и из какой конкретно программы постоянно блокируется учетная запись пользователя. Для поиска источника блокировки аккаунтов пользователей можно использовать журнал безопасности Windows, скрипты PowerShell или утилиту Account Lockout and Management Tools (Lockoutstatus.exe).
- Учетная запись пользователя заблокирована и не может быть использована для входа в сеть
- Как проверить, что аккаунт пользователя AD заблокирован?
- Политики блокировки учетных записей в домене
- Политики аудита входа на DC
- EventID 4740: событие блокировки учетной записи
- Поиск компьютера/сервера, с которого блокируется пользователь с помощью PowerShell
- Утилита Microsoft Account Lockout and Management Tools
- Как определить программу, из которой блокируется учетной запись пользователя?
Учетная запись пользователя заблокирована и не может быть использована для входа в сеть
Политика безопасности учетных записей в большинстве организаций требует обязательного блокирования учетной записи пользователя в домене Active Directory, если он несколько раз подряд ввел неправильный пароль. Обычно учетная запись блокируется контроллером домена на несколько минут (5-30), в течении которых вход пользователя в домен невозможен. Через определение время (задается в политике безопасности домена), учетная запись пользователя автоматически разблокируется. Временная блокировка учетной записи позволяет снизить риск подбора пароля (простым брутфорсом) к учетным записям пользователей AD.
Если учётная запись пользователя в домене заблокирована, то при попытке входа в Windows появляется предупреждение:
Как проверить, что аккаунт пользователя AD заблокирован?
Вы можете проверить, что аккаунт заблокирован в графический консоли ADUC или с помощью комнадлета Get-ADUser из модуля Active Directory для PowerShell:
Get-ADUser -Identity aaivanov -Properties LockedOut,DisplayName | Select-Object samaccountName, displayName,Lockedout
Учетная запись сейчас заблокирована и не может быть использована для авторизации в домене (Lockedout = True).
Можно вывести сразу все заблокированные аккаунты в домене с помощью Search-ADAccount:
Search-ADAccount -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
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
Политики блокировки учетных записей в домене
Политики блокировки учетных записей и паролей обычно задаются сразу для всего домена политикой 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 (Время до сброса счетчика блокировки)– через какое время будет сброшен счетчик неудачных попыток авторизации.
Ситуации, когда пользователь забыл свой пароль и сам вызвал блокировку своей учетки случаются довольно часто. Но в некоторых случаях блокировка учеток происходит неожиданно, без каких-либо видимых причин. Т.е. пользоваться “клянется”, что ничего особого не делал, ни разу не ошибался при вводе пароля, но его учетная запись почему-то заблокировалась. Администратор по просьбе пользователя может вручную снять блокировку, но через некоторое время ситуация повторяется.
Чтобы решить проблему самопроизвольной блокировки учетной записи пользователя, администратору нужно разобраться с какого компьютера и какой программой была заблокирован аккаунт пользователя Active Directory.
Политики аудита входа на DC
Чтобы в журналах контроллеров домена записывались события блокировки учетных записей, нужно включить следующие подкатегории аудита на контроллерах домена в секции Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy -> Logon/Logoff:
- Audit Account Lockout
- Audit Logon
- Audit Logoff
Проще всего включить эту политику через консоль gpmc.msc, отредактировав политику Default Domain Controller Policy, либо на уровне всего домена с помощью Default Domain Policy.
EventID 4740: событие блокировки учетной записи
В первую очередь администратору нужно разобраться с какого компьютера/сервера домена происходят попытки ввода неверных паролей и идет дальнейшая блокировка учетной записи.
Если пользователь ввел неверный пароль, то ближайший к пользователю контроллер домена перенаправляет запрос аутентификации на 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).
Откройте данное событие. Имя компьютера (или сервера), с которого была произведена блокировка указано в поле Caller Computer Name. В данном случае имя компьютера – TS01.
Поиск компьютера/сервера, с которого блокируется пользователь с помощью PowerShell
Можно воспользоваться следующим PowerShell скриптом для поиска источника блокировки конкретного пользователя на PDC. Данный скрипт вернет дату блокировки и компьютер, с которого она произошла:
$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).
Прямо из утилиты Lockoutstatus можно разблокировать пользователя, или сменить его пароль.
Основной недостаток утилиты LockoutStatus – она довольно долго опрашивает все контроллеры домена (некоторые из них могут быть недоступны).
Как определить программу, из которой блокируется учетной запись пользователя?
Итак, мы определили с какого компьютера или устройства была заблокирована учетная запись. Теперь нужно понять, какая программа или процесс выполняет неудачные попытки входа и является источником блокировки.
Часто пользователи начинают жаловаться на блокировку своей учетной записи в домене после плановой смены пароля. Чаще всего это значит, что старый (неверный) пароль сохранен в некой программе, скрипте или службе, которая периодически пытается авторизоваться в домене с устаревшим паролем. Рассмотрим самые распространенные места, в которых пользователь мог сохранить свой старый пароль:
- Монтирование сетевого диска через net use (Map Drive);
- В заданиях планировщика Windows (Task Scheduler);
- В службах Windows, которые настроены на запуск из-под доменной учетной записи;
- Сохранённые пароли в менеджере паролей в панели управления (Credential Manager);
- Браузеры;
- Мобильные устройства (например, использующееся для доступа к корпоративной почте);
- Программы с автологином или настроенный автоматический вход в Windows;
- Незавершенные сессии пользователя на других компьютерах или терминальных серверах (поэтому желательно настраивать лимиты для RDP сессий);
- Если пользователь недавно сменил пароль и забыл его, вы можете сбросить его.
Для более детального аудита блокировок на найденном компьютере необходимо включить ряд локальных политик аудита Windows. Для этого на локальном компьютере, на котором нужно отследить источник блокировки, откройте редактор групповых политик gpedit.msc и в разделе Compute Configurations -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy включите политики:
- Audit process tracking: Success , Failure
- Audit logon events: Success , Failure
Дождитесь очередной блокировки учетной записи и найдите в журнале безопасности (Security) события с Event ID 4625. В нашем случае это событие выглядит так:
An account failed to log on. Failure Reason: Account locked out.
Из описания события видно, что источник блокировки учетной записи – процесс mssdmn.exe (является компонентом Sharepoint). Осталось сообщить пользователю о том, что ему необходимо обновить свой пароль на веб-портале Sharepoint.
После окончания анализа, выявления и наказания виновника не забудьте отключить действие включенных групповых политик аудита.
Если вы так и не смогли найти причину блокировки учетной записи на конкретном компьютере, попробуйте просто переименовать имя учетной записи пользователя в Active Directory. Это как правило самый действенный метод защиты от внезапных блокировок определенного пользователя, если вы не смогли установить источник блокировки.
По ссылке Account Lockout and Management tool значится достаточно давний (2002) софт, который как указано на сайте — для максимум Win2003. Скажите — есть ли возможность вернуть закладочку Additional info в консоли ADUC для домена на базе Win2008R2? ADSI editor как-то не очень симпатичен, хочется проверенное и привычное….
Спасибо за сайт и полезную информацию!
Спасибо за отзыв!
По сабжу: в консоли ADUC Windows 7 и выше, если включить в свойствах отображение дополнительных полей полей (View -> Advanced Features) в свойствах учетной записи появляется новая вкладка Attribute Editor — она по-сути показывает то же самое, что и консоль ADS, только без необходимости поиска.
Если отфильтровать содержимое окна и включить «отображать только атрибуты со значениями) — то можно довольно быстро найти всю инфу, которую раньше выдавала вкладка Additional info (accountExpires, whenChanged и тп.)
Подробно описал как вернуть вкладку Additional info в домене на базе Win2008R2 и выше в этой статье.
Спасибо за интересную идею статьи!
Добрый!
На контроллерах домена(2k8)- их 3 штуки, нет события. политика аудита для контроллеров домена настроена по всем пунктам успех/отказ. Но событий 4740-нет, учетка блочится…
В журналах безопасности другие события аудита отображаются?
Доброго дня у меня тоже в журналах пусто по ID события и по username.
Но учётка заблокировалась. один DC 2008R2 второй 2012R2.
Событие блокировки искали на PDC?
Аудит событий точно ведется?
По ID 4625 искал
Аудит включен для контролеров.
https://image.ibb.co/chFcSq/Audit.png
какой именно аудит настроить?
@Валерий 08.11.2018
какой именно аудит настроить?
https://winitpro.ru/index.php/2017/12/04/kak-uznat-kto-sbrosil-parol-polzovatelya-v-active-directory/
Компьютер найден.
Как выяснить без похода к ПК Что за Advapi?
—
4625
0
0
12544
0
0x8010000000000000
431964
Security
COMP-41.contoso.ru
—
S-1-5-18
COMP-41$
contoso
0x3e7
S-1-0-0
W
contoso
0xc000006d
%%2313
0xc000006a
4
Advapi
Negotiate
COMP-41
—
—
0
0x90c
C:\Windows\System32\svchost.exe
—
—
Скорее всего то что предшествует запросу Advapi :
Попытка выполнения операции с привилегированным объектом.
Субъект:
ИД безопасности: Contoso\Admin.USER
Имя учетной записи: Admin.USER
Домен учетной записи: Contoso
Код входа: 0x1188E4A
Объект:
Сервер объекта: Security
Тип объекта: -
Имя объекта: -
Дескриптор объекта: 0x3074
Сведения о процессе:
Идентификатор процесса: 0x25bc
Имя процесса: C:\Windows\SystemApps\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\MicrosoftEdgeCP.exe
Запрошенная операция:
Требуемый доступ: 1048577
Привилегии: SeBackupPrivilege
При этом.
Пользователь является локальным админом!
Добрый день!
В этой статье указано что включить, если учетка блокируется, а событий 4740 нет в журналах.
После инструкций, написанных в статье, у меня появились события с id 4740
https://community.spiceworks.com/topic/1778627-event-id-4740-for-account-lockouts-not-logging-in-event-viewer
Добрый день.
А возможно ли по средством powershell команды получить информацию о причинах блокировки учетной записи? Если можно, то, просьба, укажите её.
Добрый!
Причина блокировки всегда одна — попытки аутентифицироваться под пользователем с неверным паролем (в соответствии с настройками политик блокировки)
Безусловно да, но я имел в виду выявление самого источника блокировки, т.е. либо это какой-то компьютер, либо какое-нибудь мобильное устройство и т.д. Чтобы понимать где искать проблему.
К примеру вот такой скрипт по мотивам статьи https://winitpro.ru/index.php/2016/05/04/prostaya-sistema-audita-udaleniya-fajlov-i-papok-dlya-windows-server/
Фильтруем журнал по событию блокировки (id=4740), выводим время блокировки, учетку и имя компьютера, с которого прилетела блокировка:
Get-WinEvent -FilterHashTable @{LogName=»Security»;id=4740} | Foreach {
$event = [xml]$_.ToXml()
if($event)
{
$Time = Get-Date $_.TimeCreated -UFormat «%Y-%m-%d %H:%M:%S»
$User = $event.Event.EventData.Data[0].»#text»
$source = $event.Event.EventData.Data[1].»#text»
write-host «Time:» $Time — » User » $User » Source » $source
}
}
Безусловно да, но я имел в виду выявление самого источника блокировки, т.е. компьютер/сервер или мобильное устройство и т.д.
Так то да, но я имел в виду получить выгрузку по источнику блокировки (компьютер, сервер, мобильное устройство и т.д.)
Это понятно, но я хотел как бы выгрузку отчета об источнике блокировки, т.е. имя компьютера/сервера.
Источник блокировки (имя компьютера) выводится скриптом. Он содержится в переменной $source
Не подскажешь, что такое может быть. Запускаю выполнение скрипта и получаю следующее сообщение:
—
PS C:\Windows\System32\WindowsPowerShell\v1.0> D:\Cache\blok_account.ps1
Невозможно загрузить файл D:\Cache\blok_account.ps1, так как выполнение сценариев отключено в этой системе. Для получения дополнительных сведений
см. about_Execution_Policies по адресу _http://go.microsoft.com/fwlink/?LinkID=135170.
+ CategoryInfo : Ошибка безопасности: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : UnauthorizedAccess
—
У меня используется Windows 8.1 с установленным обновлением Win8.1AndW2K12R2-KB3066437-x64.msu
Разрешите выполнение скриптов командой:
Set-ExecutionPolicy RemoteSigned
Account Lockout Examiner от Netwrix помогла найти источник блокировки. На ПК сидел вирус КИДО, который подбирал пароли ко всем учеткам в домене
Переводческий блокируется пользователь (время блокировки всегда разное) в журналах
только
Учетной записи не удалось выполнить вход в систему.
Субъект:
ИД безопасности: система
Имя учетной записи: ATR-VED-01$
Домен учетной записи: AZARD
Код входа: 0x3e7
Тип входа: 5
Учетная запись, которой не удалось выполнить вход:
ИД безопасности: NULL SID
Имя учетной записи: UpdatusUser
Домен учетной записи: ATR-VED-01
Сведения об ошибке:
Причина ошибки: Неизвестное имя пользователя или неверный пароль.
Состояние: 0xc000006d
Подсостояние: 0xc0000064
Сведения о процессе:
Идентификатор процесса вызывающей стороны: 0x264
Имя процесса вызывающей стороны: C:\Windows\System32\services.exe
Сведения о сети:
Имя рабочей станции: ATR-VED-01
Сетевой адрес источника: -
Порт источника: -
Сведения о проверке подлинности:
Процесс входа: Advapi
Пакет проверки подлинности: Negotiate
Промежуточные службы: -
Имя пакета (только NTLM): -
Длина ключа: 0
Проверьте на компьютере ATR-VED-01 нет ли служб или заданий планировщика, запускаемых от имени пользователя UpdatusUser
Возможна ли блокировка именно компьютера?
Теоретически все атрибуты для этого есть. Однако на практике, если у компьютере перестает совпадать его пароль с доменным паролем учетки, он вываливается из домена (перестают работать доверительные отношения) и авторизоваться в домене на таком компьютере не получится.
Заблокирована учетная запись пользователя.
Субъект:
Идентификатор безопасности: СИСТЕМА
Имя учетной записи: DC01$
Домен учетной записи: DOMAIN
Идентификатор входа: 0x3E7
Заблокированная учетная запись:
Идентификатор безопасности: DOMAIN\Manager2
Имя учетной записи: Manager2
Дополнительные сведения:
Имя вызывающего компьютера: MSTSC
Но такого пк в домене нет, как найти источник?
Посмотрите в вашем DNS-е, может быть есть запись для MSTSC.
ещё раз посмотрел в ДНС, такого имени нет
2Аlex
08.11.2018
По ID 4625 искал
Аудит включен для контролеров
Событие блокировки учетки (4740) фиксируется на DC . По нему можно найти компьютер, с которого выполняется блокировка.
4625 это событие нужно искать на рабочих станциях (это второй шаг), соотвествнно политику аудита нужно включать на рабочих станциях (через доменную или локальную политику).
>По нему можно найти компьютер, с которого выполняется блокировка.
server 2008 r2, по событию 4740 в строке , где должен показываться компьютер, пусто 🙁
Как быть тогда?
to Аlex 12.11.2018
Точно определить где именно используется старый пароль проблематично, запуск ведь в рамках svchost.exe. Начните с перезагрузки.
Если не поможет — см. секцию статьи «смотрим самые распространение места, в которых пользователь мог использовать свой старый пароль». Там описаны все самые распространенные места, где мог быть сохранен старый пароль пользователя.
«смотрим самые распространение места, в которых пользователь мог использовать свой старый пароль».
9 наверное ))
Дело в том что пароль не менялся. на новом\проблемном ПК установлена windows 10 — единственный в домене.
Нашёл где ошибка: Eсть ряд заданий настроенных через GPP\GPO
пример одного :
И на ПК c win7 выполняются и добавляются в список планировщика для компьютера.
На проблемном пк их нет.
Вспомнил, недавно думая как раз про пункт — 2. В заданиях планировщика Windows (Task Scheduler)
Удалил эти задания чтоб они создались по новой.
UP^
Есть мысли? Может надо сбросить учётку ПК на котором не синхронизируются GPP?
Немного не понял вашей ситуации. В
ы обнаружили, что блокировка вызывалась заданием с неверным паролем и удалили его?
От кого запускается задание? Вы имя и пароль пользователя задавали тоже через политику, но на Win 7 это работает, а на Win 10 — нет
to @itpro Есть назн. задания через GPO GPP.
часть из них создаётся на локальном ПК, часть нет. с ошибкой:
Элемент предпочтения компьютер "StopDelete" в объекте групповой политики
"folders&files {B317CC1D-2D27-46ED-9BDF-D683A51AAC48}"
не применен по причине ошибки с кодом '0x8007052e
Неверное имя пользователя или пароль.' Эта ошибка была отключена.
Сейчас заметил служба gpsvc «Клиент групповой политики» остановлена
и возможность включить не активна.
из под админа AD
SC \\HP01 Start gpsvc
или
SC \\HP01 Start gpsvc obj= Contoso\admin password= 11password11
[SC] StartService: OpenService FAILED 5:
Access is denied.
Из под
а если заблокировалась учётка администратора домена, как тогда быть?)
Не должна, потому как не должна ни где использоваться.
+
net user administrator /active:yes
Должно помочь из под сервисного аккаунта.
ну если злоумышленник будет брутфорсить?
>Должно помочь из под сервисного аккаунта.
сервисный — это какой?
Ну во первых: В больших конторах может быть несколько админов(людей) а у них или делегированы
права, или есть под каждого Логин из группы domain admins.
любой сможет разблокировать.
Ну если даже один человек всем управляет, желательно иметь несколько учёток для разных задач.
Планировщик, какие либо устройства.
Ну а с доменом ничего и не должно быть если учётка заблокирована. (могу не прав быть что скажет itpro ) нужна только для восстановления AD или DC.
Да шо там говорить, есть же белые странички: http://www.oszone.net/5796
Ну вообще свести к минимуму возможность брутфорсить в вашей локалке.
Под учеткой administrator домена работать как правило не нужно. Ее пароль должен храниться в сейфе 🙂
Заведите дополнительные (выделенные) учетки с правами домен админа для администарторов и выполняйте задачи доменного администрирования из под-нее. Например ivanov_admin и т.п. В этом случае вы не будете зависеть от одной учетки и ее пароль не уйдет налево 🙂
зачем хранить пароль в сейфе, если его может сменить любой другой пользователь из группы администратров домена? ) Меня всегда это волновало
2 Макс (20.11.2018)
Как правило в средних и небольших компаний 2-3 человека с правами доменного админа. Представьте ситуацию, что в какой-то момент один отпуске, другой заболел, а третий уволился, а в домене нужно что-то делать хотя бы силами сторонних консультантов. Понятно, что ситуация чисто теоретическая, но эти риски бизнесу нужно учитывать и быть к ним готовыми.
я представил ситуацию, когда помощника админа обидели-сократили-уволили и он положил весь домен…
ребят, выручайте. периодично, раз в час блочится учетка админа.
событие 4740
Заблокирована учетная запись пользователя.
Субъект:
Идентификатор безопасности: система
Имя учетной записи: AQUARIUS$
Домен учетной записи: BIZNES
Идентификатор входа: 0x3e7
Заблокированная учетная запись:
Идентификатор безопасности: BIZNES\sasha
Имя учетной записи: sasha
Дополнительные сведения:
Имя вызывающего компьютера: AQUARIUS
и вместе с этим несколько вот этих событий 4625
Учетной записи не удалось выполнить вход в систему.
Субъект:
ИД безопасности: NULL SID
Имя учетной записи: —
Домен учетной записи: —
Код входа: 0x0
Тип входа: 3
Учетная запись, которой не удалось выполнить вход:
ИД безопасности: NULL SID
Имя учетной записи: sasha
Домен учетной записи: BIZNES.LOCAL
Сведения об ошибке:
Причина ошибки: Учетная запись блокирована.
Состояние: 0xc0000234
Подсостояние: 0x0
Сведения о процессе:
Идентификатор процесса вызывающей стороны: 0x0
Имя процесса вызывающей стороны: —
каждому событию 4625 предшествует событие 4648
Выполнена попытка входа в систему с явным указанием учетных данных.
Субъект:
ИД безопасности: NETWORK SERVICE
Имя учетной записи: AQUARIUS$
Домен учетной записи: BIZNES
Код входа: 0x3e4
GUID входа: {00000000-0000-0000-0000-000000000000}
Были использованы учетные данные следующей учетной записи:
Имя учетной записи: sasha
Домен учетной записи: BIZNES.LOCAL
GUID входа: {00000000-0000-0000-0000-000000000000}
Целевой сервер:
Имя целевого сервера: aquarius.biznes.local
Дополнительные сведения: aquarius.biznes.local
Сведения о процессе:
Идентификатор процесса: 0x828
Имя процесса: C:\Windows\System32\svchost.exe
Сведения о сети:
Сетевой адрес: —
Порт: —
Данное событие возникает, когда процесс пытается выполнить вход с учетной записью, явно указав ее учетные данные. Это обычно происходит при использовании конфигураций пакетного типа, например, назначенных задач, или выполнении команды RUNAS.
помогите разобраться кто стучится в дверь моя
Смотрите, вспоминайте в каких программах, процессах был сохранен пароль учетной записи BIZNES\sasha на компьютере AQUARIUS. Список типовых мест в системе, где мог быть сохранен пароль пользователя перечислен в статье.
Доброго дня.
В домене появился второй пк с win10 установка с нуля.
И тоже стал блокировать учётку админа.
Чистый паролей нигде не сохранено. Всё как описывал ранее(выше).
Вызвана привилегированная служба.
Субъект:
ИД безопасности: contoso\Admin
Имя учетной записи: Admin
Домен учетной записи: contoso
Код входа: 0x4E61E
Служба:
Сервер: Security
Имя службы: -
Процесс:
Идентификатор процесса: 0x1a08
Имя процесса: C:\Windows\explorer.exe
Сведения о запросе службы:
Привилегии: SeLoadDriverPrivilege
ИЛИ----------
Идентификатор процесса: 0xe4c
Имя процесса: C:\Windows\System32\svchost.exe
Сведения о запросе службы:
Привилегии: SeProfileSingleProcessPrivilege
4625
Учетной записи не удалось выполнить вход в систему.
Субъект:
ИД безопасности: СИСТЕМА
Имя учетной записи: HP400-PC$
Домен учетной записи: contoso
Код входа: 0x3E7
Тип входа: 4
Учетная запись, которой не удалось выполнить вход:
ИД безопасности: NULL SID
Имя учетной записи: Admin
Домен учетной записи: contoso
Сведения об ошибке:
Причина ошибки: Неизвестное имя пользователя или неверный пароль.
Состояние: 0xC000006D
Подсостояние: 0xC000006A
Сведения о процессе:
Идентификатор процесса вызывающей стороны: 0xa88
Имя процесса вызывающей стороны: C:\Windows\System32\svchost.exe
Сведения о сети:
Имя рабочей станции: HP400-PC
Сетевой адрес источника: -
Порт источника: -
Сведения о проверке подлинности:
Процесс входа: Advapi
Пакет проверки подлинности: Negotiate
Промежуточные службы: -
Имя пакета (только NTLM): -
Длина ключа: 0
С блокировкой разобрался. В GPP путём выставления в свойствах Назн.Задания «Выполнять только для зарегистрированного пользователя» и затем «Выполнять вне зависимости от регистрации пользователя» Добился запроса реквизитов учётки из под которой должно запускаться. Не помогала даже смена учётки.
Но сами задания не создаются на машине с win 10.
Элемент предпочтения компьютер «GpUpDateW10» в объекте групповой политики «GPP-W10 {BF00B521-C7C1-47C7-9346-
FA75CE8EA532}» не применен по причине ошибки с кодом ‘0x80090005 Плохие данные.’ Эта ошибка была отключена.
https://winitpro.ru/index.php/2016/06/20/pochemu-perestali-rabotat-nekotorye-gpo-posle-ustanovki-ms16-072/ сделал.
та же проблема, только не регистрируются источники (имя рабочей станции или сетевой адрес источника). Так же имя процесса вызывающей стороны C:\Windows\System32\svchost.exe, а процесс входа IAS
Учетной записи не удалось выполнить вход в систему.
Субъект:
ИД безопасности: система
Имя учетной записи: SRV1C8$
Домен учетной записи: CAPITAL
Код входа: 0x3e7
Тип входа: 3
Учетная запись, которой не удалось выполнить вход:
ИД безопасности: NULL SID
Имя учетной записи: admin
Домен учетной записи: CAPITAL
Сведения об ошибке:
Причина ошибки: Неизвестное имя пользователя или неверный пароль.
Состояние: 0xc000006d
Подсостояние: 0xc000006a
Сведения о процессе:
Идентификатор процесса вызывающей стороны: 0x454
Имя процесса вызывающей стороны: C:\Windows\System32\svchost.exe
Сведения о сети:
Имя рабочей станции:
Сетевой адрес источника: —
Порт источника: —
Сведения о проверке подлинности:
Процесс входа: IAS
Пакет проверки подлинности: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Промежуточные службы: —
Имя пакета (только NTLM): —
Длина ключа: 0
происходит на одном серваке, не контроллере домена, примерно каждые полчаса и обязательно по 3 раза. На сервере поднят RDP для локалки, доступ из интернета только по VPN.
Что может быть?
Всем привет!
Похоже данная тема мучает всех… У меня такая же проблема, блокируется админская доменная учетка.
Запускаю программу LockoutStatus, вижу что учетка заблокирована, на таком-то сервере, ок, иду на это сервер, захожу в журнал событий, но у меня нет Эвентов с ID 4740 или 4625. Политики у меня включены согласно вашим скринам. Кто-нить может подсказать, почему не отображаются данные События в журналах DC???
нашел бяку. В вашем случае, конечно, может быть иная причина, а у меня она такова — у меня поднят PPTP VPN на 2008 виндах. А вот пользователи имеющих доступ к VPN серверу и пользователи RDP разделены, т.е. если USER1 вошел на VPN, то хрена лысого он попадет на RDP (типа безопасность решил так замутить). Так вот, оказалось что я воткнул VPN доступ админу(т.е. себе, но зачем — не помню, а переделывать не стал) и какой-то гусь подбирал пароли по PPTP, собсно давно известно что PPTP не есть хорошо, но тем не менее. И все что нужно было сделать — это расширить логи по VPN серверу (точнее по Internet Access Server). В течение 5 минут нашел IP с которого фигарили атаки, оказались из Румынии. Ну и блокирнул. Логи лежат в C:\Windows\tracing.
Что-то вы совсем не мой случай описали)))
Сегодня новый рекорд, учетка блочится каждые 20 минут, в логах ничего найти не могу
Если на сервере, с которого блокируется учетка вы не находите событие с кодом 4625 с помощью филтра, попытайтесь в просмотрщике события отфильтровать все события со статусом Audit Failure и пробежаться по ним глазами. Может что и увидите интересного.
Я так тоже пробовал, Audit Failure пустой на на всех DC, при этом в политиках в разделе Compute Configurations -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy все включено.
проверьте размер файла аудита, возможно он мал и события затираются
(Get-AdDomain).PDCEmulator
Команда не работает в PS, с чем может быть это связано?
Скорее всего у вас не установлен модуль ActiveDirectory для PowerShell: https://winitpro.ru/index.php/2019/07/18/modul-active-directory-dlya-powershell/
Что делать если через owa exchange можно блочить любые учетки в домене?
Найти безобразника и наказать… Или у вас наружу owa выставлен?
К сожалению, да)
Самый простой вариант — перед открытием OWA использовать дополнительную проверку пароля через .htacess или наподобие.
Если есть бюджет — внешний анализатор трафика с блокировкой IP.
Ну еще один метод — блокировка часто долбящихся IP с ошибкой авторизации после n попыток на windows firewall. По аналогии со статьей https://winitpro.ru/index.php/2019/10/02/blokirovka-rdp-atak-firewall-powershell/
С одной стороны можно включить Basic-аутентификацию…
С другой стороны может где-то есть настройка BaseDN, где OWA или ECP ищет пользователей через Form-Based?
Добрый день! А есть ли способ узнать с какого недоменного устройства (типа: МФУ) блокируется учетная запись. Думаю, многим бы хотелось узнать об этом.
Тут разницы нет. В логе на PDC должен быть IP адрес устройства. Но тут ест нюанс — если мфу авторизируется для отправки только на почтовом сервере, то в журнале PDC будет источник блокировка — ваш почтовый сервер. для более детального выявления устройства, с которого прилетает неверный пароль, придется смотреть логи почтового сервера.
Добрый день.
Почему эти политики, после решения проблемы нужно отключить?
Audit process tracking: Success , Failure
Audit logon events: Success , Failure
Чтобы не забивать журнал безопасности на компах лишними данными. Если вам постоянно нужна эта инфа — оставляет политики аудита включенными. Не проблема.
Коллеги, поступила информация, что в Netwrix Account Lockout Examiner 4.1 и ранних версиях была обнаружена уязвимость системы безопасности. Эта проблема может позволить злоумышленникам получить учетные данные администратора домена, используемые для запуска Account Lockout Examiner.
Всем пользователям Netwrix Account Lockout Examiner 4.1 или более ранней версии следует рассмотреть вопрос о немедленном обновлении до версии 5.1 и выполнить два дополнительных действия, чтобы снизить риски ущерба от этой уязвимости. В частности, мы рекомендуем вам сделать следующее:
1. Скачать и установить последнюю версию Netwrix Account Lockout Examiner.
2. Отключить исходящий трафик аутентификации NTLM на рабочей станции, которая используется для запуска Netwrix Account Lockout Examiner.
3. Удалите Netwrix Account Lockout Examiner 4.1 или более раннюю версию.
Но версия 5.1 служит только анализатором процесса блокировки, но ни как не программой мониторинга блокировки. Вот такие плохие новости.
Что бы регистрировались события 4740 дополнительно надо включить Аудит управления учетными записями пользователя. Об этом в статье почему то не пишется