Событие смены пароля пользователя windows
Обновлено: 04.07.2024
Разберемся, как в доменной среде Active Directory по журналам контроллеров домена определить, кто из администраторов сбросил пароль учетной записи определенного пользователя.
В первую очередь, в политиках домена нужно включить аудит событий управления учётными записями. Для этого:
Откройте консоль управления групповыми политиками Group Policy Management (gpmc.msc) и отредактирует политику домена Default Domain Policy.
- Затем в консоли редактора групповых политик, перейдите в раздел Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy
Найдите и включите политику Audit User Account Management (если нужно фиксировать в журнале как успешные, та и неудачные попытки смены пароля, выберите опции Success и Failure).Примечание. Эту же политику можно включить и в разделе расширенных политик аудита (Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Configuration)
- После прохождения цикла обновления групповых политик на клиентах можно попробовать изменить пароль любого пользователя в AD.
В списке событий останутся только события успешной смены пароля (An attempt was made to reset an account’s password.). При этом в расширенном представлении события можно увидеть имя учётной записи администратора, которая выполнила смену пароля (Subject:) и, собственно, учетную запись пользователя, чей пароль был сброшен (Target Account:).
Совет . В контексте получения полной информации о событиях смены пароля пользователя, в фильтр можно добавить следующие идентификаторы событий:
- 4724 (628 — в старых версиях Windows Server) – An attempt was made to reset an account’s password (сброс пароля пользователя администратором)
- 4723 (627 — в старых версиях Windows Server) – An attempt was made to change an account’s password (смена пароля самим пользователем)
Описание события:
Это событие создает каждый раз, когда пользователь пытается изменить пароль.
Для учетных записей пользователей это событие создается на контроллерах доменов, серверах членов и рабочих станциях.
Для учетных записей домена создается событие Отказа, если новый пароль не соответствует политике паролей.
Для локальных учетных записей создается событие отказа, если новый пароль не соответствует политике паролей или старый пароль является неправильным.
Для учетных записей домена, если старый пароль был неправильным, на контроллере домена будет создан"4771:предварительная проверка подлинности Kerberos" или"4776:компьютер, пытаемый проверить учетные данные учетной записи", будет создан на контроллере домена, если на нем включены определенные подкатегории.
Обычно вы увидите 4723 события с одинаковыми полями Subject\\Security ID и Target Account\Security ID, что является нормальным поведением.
Примечание. Рекомендации приведены в разделе Рекомендации по мониторингу безопасности для этого события.
XML события:
Необходимые роли сервера: нет.
Минимальная версия ОС: Windows Server 2008, Windows Vista.
Версии события: 0.
Описания полей:
Тема:
- Security ID [Type = SID]: SID учетной записи, которая предприняла попытку изменить пароль учетной записи Target. Средство просмотра событий автоматически пытается разрешить идентификатор безопасности SID и отобразить имя учетной записи. Если идентификатор безопасности разрешить не удается, в событии будут отображены исходные данные.
Примечание. . Идентификатор безопасности (SID) представляет собой строковое значение переменной длины, которое используется для идентификации доверенного лица (субъекта безопасности). Каждая учетная запись имеет уникальный идентификатор безопасности, выданный центром сертификации, таким как контроллер домена Active Directory, который хранится в базе данных безопасности. Каждый раз, когда пользователь входит в систему, система получает идентификатор безопасности этого пользователя из базы данных и помещает ее в маркер доступа этого пользователя. Система использует идентификатор безопасности в маркере доступа для идентификации пользователя во всех последующих операциях с Безопасностью Windows. Если идентификатор SID использовался как уникальный идентификатор для пользователя или группы, он не может использоваться повторно для идентификации другого пользователя или группы. Дополнительные сведения о SID см. в разделе Идентификаторы безопасности.
Имя учетной записи [Type = UnicodeString]: имя учетной записи, предприняв попытку изменить пароль учетной записи Target.
Account Domain [Type = UnicodeString]: домен субъекта или имя компьютера. Форматы различаются и включают в себя следующее:
Пример имени домена NETBIOS: CONTOSO
Полное имя домена в нижнем регистре: contoso.local
Полное имя домена в верхнем регистре: CONTOSO.LOCAL
Для некоторых известных субъектов безопасности, таких как LOCAL SERVICE или ANONYMOUS LOGON, значение этого поля равно "NT AUTHORITY".
Для учетных записей локальных пользователей это поле будет содержать имя компьютера или устройства, к которым принадлежит эта учетная запись, например: "Win81".
Logon ID [Type = HexInt64]: шестнадцатеричное значение, которое может помочь сопоставить это событие с недавними событиями содержащими тот же идентификатор входа, например: “4624: Учетная запись успешно вошла в систему.”
Целевая учетная запись: учетная запись, для которой запрашивалось изменение пароля.
Security ID [Type = SID]: SID учетной записи, для которой было запросят изменение пароля. Средство просмотра событий автоматически пытается разрешить идентификатор безопасности SID и отобразить имя учетной записи. Если идентификатор безопасности разрешить не удается, в событии будут отображены исходные данные.
Имя учетной записи [Type = UnicodeString]: имя учетной записи, для которой было запророшно изменение пароля.
Домен учетной записи [Type = UnicodeString]: домен или имя компьютера целевой учетной записи. Форматы различаются и включают в себя следующее:
Пример имени домена NETBIOS: CONTOSO
Полное имя домена в нижнем регистре: contoso.local
Полное имя домена в верхнем регистре: CONTOSO.LOCAL
Для учетных записей локальных пользователей это поле будет содержать имя компьютера или устройства, к которым принадлежит эта учетная запись, например: "Win81".
Дополнительные сведения:
- Привилегии [Type = UnicodeString]: список привилегий пользователей, которые использовались во время операции, например SeBackupPrivilege. Этот параметр может не быть захвачен в событии, и в этом случае отображается как "-". Полный список привилегий пользователей см. в таблице "Таблица 8. Привилегии пользователей.".
Рекомендации по контролю безопасности
Для 4723 (S, F): была предпринята попытка изменить пароль учетной записи.
Если у вас есть домен высокой стоимости или учетная запись локального пользователя, для которой необходимо отслеживать каждую попытку изменения пароля, отслеживайте все события 4723 с помощью "Target Account\Security ID", соответствующего учетной записи.
Если у вас есть домен высокой стоимости или локализованная учетная запись, для которой необходимо отслеживать каждое изменение, отслеживайте все события 4723 с помощью "Target Account\Security ID", соответствующего учетной записи.
Если у вас есть доменные или локальные учетные записи, для которых пароль не следует менять, вы можете отслеживать все события 4723 с помощью "Target Account\Security ID", соответствующего учетной записи.
Рэнди Франклин Смит (CISA, SSCP, Security MVP) имеет в своем арсенале очень полезный документ, рассказывающий о том, какие события (event IDs) обязательно должны отслеживаться в рамках обеспечения информационной безопасности Windows. В этом документе изложена крайне полезная информация, которая позволит Вам “выжать” максимум из штатной системы аудита. Мы подготовили перевод этого материала. Заинтересованных приглашаем под кат.
О том, как настроить аудит, мы уже обстоятельно писали в одном из наших постов. Но из всех event id, которые встречаются в журналах событий, необходимо остановить свое внимание на нескольких критических важных. На каких именно – решать каждому. Однако Рэнди Франклин Смит предлагает сосредоточить внимание на 10 важных событиях безопасности в Windows.
Контроллеры доменов
Event ID — (Категория) — Описание
1) 675 или 4771
(Аудит событий входа в систему)
Событие 675/4771 на контроллере домена указывает на неудачную попытку войти через Kerberos на рабочей станции с доменной учетной записью. Обычно причиной этого является несоответствующий пароль, но код ошибки указывает, почему именно аутентификация была неудачной. Таблица кодов ошибок Kerberos приведена ниже.
2) 676, или Failed 672 или 4768
(Аудит событий входа в систему)
Событие 676/4768 логгируется для других типов неудачной аутентификации. Таблица кодов Kerberos приведена ниже.
ВНИМАНИЕ: В Windows 2003 Server событие отказа записывается как 672 вместо 676.
3) 681 или Failed 680 или 4776
(Аудит событий входа в систему)
Событие 681/4776 на контроллере домена указывает на неудачную попытку входа в систему через
NTLM с доменной учетной записью. Код ошибки указывает, почему именно аутентификация была неудачной.
Коды ошибок NTLM приведены ниже.
ВНИМАНИЕ: В Windows 2003 Server событие отказа записывается как 680 вместо 681.
4) 642 или 4738
(Аудит управления учетными записями)
Событие 642/4738 указывает на изменения в указанной учетной записи, такие как сброс пароля или активация деактивированной до этого учетной записи. Описание события уточняется в соответствие с типом изменения.
5) 632 или 4728; 636 или 4732; 660 или 4756
(Аудит управления учетными записями)
Все три события указывают на то, что указанный пользователь был добавлен в определенную группу. Обозначены Глобальная (Global), Локальная (Local) и Общая (Universal) соответственно для каждого ID.
6) 624 или 4720
(Аудит управления учетными записями)
Была создана новая учетная запись пользователя
7) 644 или 4740
(Аудит управления учетными записями)
Учетная запись указанного пользователя была заблокирована после нескольких попыток входа
8) 517 или 1102
(Аудит системных событий)
Указанный пользователь очистил журнал безопасности
Event Id — Описание
Типы входов в систему (Logon Types)
Тип входа в систему — Описание
Коды отказов Kerberos
Код ошибки — Причина
6 — Имя пользователя не существует
12 — Ограничение рабочей машины; ограничение времени входа в систему
18 — Учетная запись деактивирована, заблокирована или истек срок ее действия
23 — Истек срок действия пароля пользователя
24 — Предварительная аутентификация не удалась; обычно причиной является неверный пароль
32 — Истек срок действия заявки. Это нормальное событие, которое логгируется учетными записями компьютеров
37 — Время на рабочей машины давно не синхронизировалось со временем на контроллере домена
Коды ошибок NTLM
Код ошибки (десятичная система) — Код ошибки (16-ричная система) — Описание
3221225572 — C0000064 — Такого имени пользователя не существует
3221225578 — C000006A — Верное имя пользователя, но неверный пароль
3221226036 — C0000234 — Учетная запись пользователя заблокирована
3221225586 — C0000072 — Учетная запись деактивирована
3221225583 — C000006F — Пользователь пытается войти в систему вне обозначенного периода времени (рабочего времени)
3221225584 — C0000070 — Ограничение рабочей станции
3221225875 — C0000193 — Истек срок действия учетной записи
3221225585 — C0000071 — Истек срок действия пароля
3221226020 — C0000224 — Пользователь должен поменять пароль при следующем входе в систему
Постановка задачи
Я перед собой ставлю настройку аудита доменных служб Active Directory, таким образом, чтобы я мог получать информацию, об изменении пользователем или оператором второй линии паролей учетной записи Active Directory, для мониторинга и улучшения безопасности.
Настройка политики аудита сброса паролей
Давайте рассматривать, как узнать, кто сбросил пароль пользователя в Active Directory. Так как это у нас домен, то все свои действия мы будем выполнять с помощью групповых политик. Первым делом нам необходимо включить в политике аудита распространяемой на ваш домен, логирование и занесение в журнал нужных нам событий безопасности, напоминаю, они будут появляться на ваших контроллерах домена.
Открываем с вами оснастку gpmc.msc (Управление групповой политикой). Разверните структуру вашего леса и выберите необходимый домен. В моем случае, это root.pyatilistnik.org. Я вам советую включать политику аудита всегда на уровне домена и использовать для этого уже имеющуюся политику "Default Domain Policy", в принципе сама Microsoft на этот момент не против, но никто вам не мешает создать новую и прилинковать ее к вашему домену. Щелкаем по ней правым кликом и из контекстного меню выбираем "Изменить"
Нужные нам параметры находятся в настройках на компьютер. Переходим по пути:
Конфигурация компьютера - Политики - Конфигурация Windows - Параметры безопасности - Локальные политики - Политика аудита(Computer Configuration - Policies - Windows Settings - Security Settings - Local Policies - Audit Policy)
Нас тут будет интересовать пункт "Аудит управления учетными записями (Audit User Account Management )". Щелкаем по данному пункту двойным кликом и у вас откроется окно свойств. Установите галки:
- Определить следующие параметры политики
- Успех (Success)
- Отказ (Failure)
Активировав галки, сохраняем настройки нажав ok.
При такой настройке, у вас будут писаться все изменения происходящие с учетной записью, например, членство в группах, или переименовывание, отключение и многое другое. Если нужно более тонко аудировать события и не переполнять журналы безопасности лишними событиями, то вы можете воспользоваться расширенным аудитомВ расширенном аудите сброс или изменение пароля настраивается в таком разделе:
Конфигурация компьютера - Политики - Конфигурация Windows - Параметры безопасности - Конфигурация расширенной политики аудита - Политика аудита - Управление учетными записями (Computer Configuration - Policies - Windows Settings - Security Settings - Advanced Audit Policy Configuration - Account Management)Тут вам нужно найти параметр "Аудит управления учетными записями пользователей", именно он и даст возможность отслеживания смены пароля, а так же его сброс.
Хочу отметить, что расширенный аудит более приоритетный по сравнению с обычным, и их по рекомендации Microsoft, нужно использовать по отдельности, определитесь и выберите один из вариантов аудита, я выбираю общий, чтобы писалось больше логов
Теперь когда у вас политика аудита настроена и применена к серверам и компьютерам, можно изучать логи операционной системы. Открываем просмотр событий Windows. Переходим в журнал "Безопасность", именно в него пишутся события, сброса пароля пользователя Active Directory и изменения пароля самим пользователем.
Перед тем, как искать информацию, нам необходимо определиться, какой номер ID события нам интересен. В журнале безопасности нужно искать:
- Event ID - 4723 (S, F): предпринята попытка изменить пароль учетной записи
- Event ID - 4724 (S, F): предпринята попытка изменить пароль учетной записи
Код события 4723 показывает нам информацию, была ли попытке изменить пользователем свой пароль, и два варианта получилось это сделать или нет.
Код события 4724 покажет вам информацию, когда и кто пытался произвести сброс пароля учетной записи пользователя Active Directory, данная информация бывает необходимой в случае компрометации учетной записи и расследовании.
В журнале безопасность нажмите "Фильтр текущего журнала". В настройках фильтрации поля "Все коды событий" введите 4723 и нажмите применить.
Ваш журнал будет отфильтрован и вы не получите того огромного количества событий, которое в нем присутствует. Вы увидите попытки смены пароля пользователя Active Directory. Тут будут успешные и неудачные. Неудачные попытки будут полезны при диагностике блокировки учетной записи Active Directory.
Вот пример события ID 4723, где пользователь Барбоскин Геннадий, успешно поменял свой пароль.
Выполнена попытка изменения пароля учетной записи.
Субъект:
Идентификатор безопасности: ROOT\barboskin.g
Имя учетной записи: barboskin.g
Домен учетной записи: ROOT
Идентификатор входа: 0x179CA0D6Целевая учетная запись:
Идентификатор безопасности: ROOT\barboskin.g
Имя учетной записи: barboskin.g
Домен учетной записи: ROOT
А вот вам пример ID 4723, где Барбоскин не смог изменить свой пароль.
Теперь давайте изменим фильтр на событие ID 4724. Вот пример, где пользователь Администратор, произвел успешно смену пароля для учетной записи barboskin.g.
Выполнена попытка сброса пароля учетной записи.
Субъект:
Идентификатор безопасности: ROOT\Администратор
Имя учетной записи: Администратор
Домен учетной записи: ROOT
Идентификатор входа: 0x1799B159Целевая учетная запись:
Идентификатор безопасности: ROOT\barboskin.g
Имя учетной записи: barboskin.g
Домен учетной записи: ROOT
Теперь сбросим фильтр и заточим его на поиск событий 4724, напоминаю, это когда кто-то сбрасывает пароль учетной записи Active Directory, через оснастку ADUC. В моем примере видно из события ID 4724, что пользователь ROOT\Администратор произвел сброс пароля для пользователя barboskin.g.
Получение информации, через PowerShell
Для большей автоматизации, вы можете написать скрипт и запускать его через PowerShell. Ниже я вам приведу пример такого простого сценария, который ходит по всем контроллерам домена и собирает все нужные события по определенному ID. Но правильнее будет, это иметь сервер коллектор, на который будут перенаправляться все события с контроллеров, и вот с него уже проще получать нужную информацию, так сказать централизованно.
Сам код вы можете проверить открыв оболочку PowerShell ISE. Вот мы получили события 4723, когда пользователи меняли свои пароли Active Directory.
А вот пример поиска событий 4724, когда кто-то целенаправленно произвел сброс и смену пароля пользователя в ADUC.
Читайте также: