В этой статье мы опишем, как отслеживать события блокировки учетных записей пользователей на котроллерах домена Active Directory, определять с какого компьютера и из какой конкретно программы выполняется постоянная блокировка. Рассмотрим использование для поиска источника блокировки журнала безопасности Windows и скриптов PowerShell.
Политика безопасности учетных записей в большинстве организаций требует обязательного блокирования учетной записи пользователя в домене Active Directory в случае n-кратного неправильного набора пароля пользователем. Обычно учетная запись блокируется контроллером домена после нескольких попыток ввести неправильный пароль на несколько минут (5-30), в течении которых вход пользователя в систему невозможен. Через определение время, заданное политиками безопасности, учетная запись домена автоматически разблокируется. Временная блокировка учетной записи позволяет снизить риск подбора пароля (простым брутфорсом) учетных записей пользователей AD.
В том случае, если учётная запись пользователя в домене заблокирована, при попытке авторизации в Windows появляется предупреждение:
Политики блокировки учетных записей в домене
Политики блокировки учетных записей и паролей обычно задается сразу для всего домена политикой Default Domain Policy. Интересующие нас политики находятся в разделе Computer Configuration -> Windows Settings -> Security Settings -> Account Policy -> Account Lockout Policy (Конфигурация Windows -> Параметры безопасности -> Политики учетных записей -> Политики блокировки учетных записей). Это политикии:
- Account lockout threshold (Пороговое значение блокировки) – через сколько неудачных попыток набора пароля учетная запись должна быть заблокирована
- Account lockout duration (Продолжительность блокировки учетной записи) – на какое время будет заблокирована учетная запись (по истечении этого времени блокировка будет снята автоматически)
- Reset account lockout counter after (Время до сброса счетчика блокировки)– через какое время будет сброшен счетчик неудачных попыток авторизации
Совет. Вручную снять блокировку учетной записи, не дожидаясь автоматической разблокировки, можно с помощью консоли ADUC . Для этого в свойствах учетной записи пользователя на вкладке Account, поставив чекбокс на Unlock account. This account is currently locked out on this Active Directory Domain Controller.
Довольно полезную информацию о времени блокировки, задания пароля, количестве попыток набора пароля и прочее можно получить в свойствах учетной записи в консоль ADSIEdit или на дополнительной вкладке Additional Account Info в свойствах пользователя (проще).
Ситуации, когда пользователь забыл свой пароль и сам вызвал блокировку своей учетки случаются довольно часто. Но в некоторых случаях блокировка учеток происходит неожиданно, без каких-либо видимых причин. Т.е. пользоваться «клянется», что ничего особого не делал, не разу не ошибался при вводе пароля, но его учетная запись почему-то заблокировалась. Администратор по просьбе пользователя может вручную снять блокировку, но через некоторое время ситуация повторяется.
Для того, чтобы решить проблему пользователя администратору нужно разобраться с какого компьютера и какой программой была заблокирована учетная запись пользователя в Active Directory.
Поиск компьютера, с которого была заблокирована учетная запись
В первую очередь администратору нужно разобраться с какого компьютера / сервера происходят попытки ввода неверных паролей и идет дальнейшая блокировка учетной записи.
В том случае, если ближайший к пользователю контроллер домена определил, что пользователь пытается авторизоваться под неверным паролем , он перенаправляет запрос аутентификации на DC с FSMO ролью эмулятора PDC (именно он отвечает за обработку блокировок учетных записей). Если проверка подлинности не выполнялась и на PDC, он отвечает первому DC о невозможности аутентификации.
При этом в журнале обоих контроллеров домена фиксируются события 4740 с указанием DNS имени (IP адреса) компьютера, с которого пришел первоначальный запрос на авторизацию пользователя. Логично, что в первую очередь необходимо проверить журналы безопасности на PDC контроллере. Найти PDC в домене можно так:
(Get-AdDomain).PDCEmulator
Событие блокировки учетной записи домена можно найти в журнале Security на контролере домена. Отфильтруйте журнал безопасности по событию с Event ID 4740. Должен появится список последних событий блокировок учетных записей на контроллере домена. Начиная с самого верхнего переберите все события и найдите событие, в котором указано что учетная запись нужного пользователя (имя учетной записи указано в строке Account Name) заблокирована (A user account was locked out).
Откройте данное событие. Имя компьютера (или сервера), с которого была произведена блокировка указано в поле Caller Computer Name. В данном случае имя компьютера – TS01.
Можно воспользоваться следующим PowerShell скриптом для поиска источника блокировки конкретного пользователя на PDC. Данный скрипт вернет дату блокировки и компьютер, с которого она произошла:
$Username = ‘username1’
$Pdce = (Get-AdDomain).PDCEmulator
$GweParams = @{
‘Computername’ = $Pdce
‘LogName’ = ‘Security’
‘FilterXPath’ = "*[System[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}
}

Выявляем программу, причину блокировки учетной записи в AD
Итак, мы определили с какого компьютера или устройства была заблокирована учетная запись. Теперь хотелось бы понять, какая программа или процесс выполняет неудачные попытки входа и является источником блокировки.
Часто пользователи начинают жаловаться на блокировку своей учетной записи в домене после плановой смены пароля своей доменной учетной записи. Это наталкивает на мысль, что старый (неверный) пароль сохранен в некой программе, скрипте или службе, которая периодически пытается авторизоваться в домене с устаревшим паролем. Рассмотрим самые распространение места, в которых пользователь мог использовать свой старый пароль:
- Монтирование сетевого диска через net use (Map Drive)
- В заданиях планировщика Windows (Task Scheduler)
- В службах Windows, которые настроены на запуск из-под доменной учетной записи
- Сохранённые пароли в менеджере паролей в панели управления (Credential Manager)
- Браузеры
- Мобильные устройства (например, использующееся для доступа к корпоративной почте)
- Программы с автологином
- Незавершенные сессии пользователя на других компьютерах или терминальных серверах
- И др.
Для более детального аудита блокировок на найденной машине необходимо включить ряд локальных политик аудита Windows. Для этого на локальном компьютере, на котором нужно отследить источник блокировки, откройте редактор групповых политик Gpedit.msc и в разделе Compute Configurations -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy включите политики:
- Audit process tracking: Success , Failure
- Audit logon events: Success , Failure
Дождитесь очередной блокировки учетной записи и найдите в журнале безопасности (Security) события с Event ID 4625. В нашем случае это событие выглядит так:
Из описания события видно, что источник блокировки учетной записи – процесс mssdmn.exe (является компонентом Sharepoint). Осталось сообщить пользователю о том, что ему необходимо обновить свой пароль на веб-портале Sharepoint.
После окончания анализа, выявления и наказания виновника не забудьте отключить действие активированных групповых политик аудита.
В том случае, если вы так и не смогли выяснить причину блокировки учетной записи на конкретном компьютере, чтобы избежать постоянной блокировки учетки, стоит попробовать переименовать имя учетной записи пользователя в Active Directory. Это как правило самый действенный метод защиты от внезапных блокировок определенного пользователя.
По ссылке 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
какой именно аудит настроить?
http://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
При этом.
Пользователь является локальным админом!
Добрый день.
А возможно ли по средством powershell команды получить информацию о причинах блокировки учетной записи? Если можно, то, просьба, укажите её.
Добрый!
Причина блокировки всегда одна — попытки аутентифицироваться под пользователем с неверным паролем (в соответствии с настройками политик блокировки)
Безусловно да, но я имел в виду выявление самого источника блокировки, т.е. либо это какой-то компьютер, либо какое-нибудь мобильное устройство и т.д. Чтобы понимать где искать проблему.
К примеру вот такой скрипт по мотивам статьи http://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 Плохие данные.’ Эта ошибка была отключена.
http://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: http://winitpro.ru/index.php/2019/07/18/modul-active-directory-dlya-powershell/