код события смены пароля windows

Код события смены пароля windows

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

I have a task to find out the event ID for password change

I am using domain account, when i change my account password by doing Alt+Ctrl+Del (change password)

what is the event ID will be generated on DC.

As as, when i do password change from webportals, like OWA

On which DC event will be found (I have 24 DC’s across the World)

Answers

4723 is the correct Event ID for a password change for Windows Server 2008 and up. Keep in mind that User Auditing must be turned on in your environment for these to be collected.

Also, password change events are not replicated to every domain controller. You will need to query every DC to collect all of the events.

Gary G. Gray
MCP, MCTS, MCITP, MCT Alumni

Please remember to mark the replies as answers if they are helpful.

This posting is provided AS-IS with no warranties or guarantees and confers no rights.

Источник

Настройка аудита смены паролей пользователей AD с Powershell и Event Viewer

Используя групповые политики Active Directory можно настроить аудит смены паролей и других действий связанные с пользователями. Эти события можно получить используя оснастку Event Viewer и Powershell. В этой статье мы разберем эти возможности на примерах и создадим команду Powershell, которая сделает этот процесс более простым.

Навигация по посту

Настройка политики аудита

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

В примерах я использую OU Moscow. Через Powershell создать и привязать политику тоже можно. Это делается следующим образом:

Политика, которая нам нужна, называется ‘Audit account management/Аудит управления учетной записью’. Она включает аудит связанный с изменением пользователя, пароля и групп. Что бы это сделать пройдите по следующему пути

В этой политике нужно включить учет успешных попыток изменения данных (Success) и провала (Failure):

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

Ниже, для примера, показано как через Powershell устанавливается политика включающая заставку через 900 секунд:

На клиентских компьютерах запустим обновление политик:

Получение событий

Учитывая, что включенная политика касается не только паролей, можно настроить фильтр через Powershell или GUI. Мы настроим фильтры, которые будут выводить события связанные с определенными идентификаторами ‘Event ID’. Нас интересуют следующие идентификаторы:

Фильтрация логов с Event Viewer

Эти фильтры мы можем применить зайдя в соответствующее меню:

В новом окне мы должны указать идентификаторы событий, их источник и категорию:

После этих установок у нас будут отображаться только нужные события.

Фильтрация логов с Powershell

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

Обе команды имеют параметр ‘ComputerName’, с помощью которого можно подключаться удаленно.

У получения логов средствами Powershell есть две проблемы:

Что бы максимально ускорить процесс получения логов можно использовать 3 параметра фильтрации: FilterXPath, FilterHashtable, FilterXml.

Команда, которая получит подобные логи с домен-контроллера ‘AD1’ и используя запрос XPath, будет выглядеть следующим образом:

Аналогичное можно сделать использовав HashTable. Мы не должны указывать тип логов, т.к. это сделано в массиве:

Если вам больше нравится вариант с запросом через hashtable, но вы не понимаете как правильно его составить, можно использовать следующий подход. Мы должны найти хоть один лог, который нам нужен используя любые средства Powerhsell. Затем мы выводим все свойства через ‘SELECT *’ и заполняем ими нашу таблицу:

Создание команды

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

Что бы получить события начинающиеся с определенной даты мы можем использовать существующее свойство ‘StartTime’ в массиве. ‘EndTime’ указывает обратное. В примере ниже мы получим события созданные за сутки:

Готовая функция, выводящая информацию об этих событиях, будет следующей:

Источник

Код события смены пароля windows

Добрый день! Уважаемы подписчики и просто гости, одного из крупнейших IT блогов рунета Pyatilistnik.org. В прошлый раз мы с вами разобрали причины отказа доступа, которые не давали нам произвести смену пароля у пользователя. В сегодняшней заметке я бы хотел немного поговорить про аудит сброса пароля пользователя в Active Directory. Мы научимся определять по логам Windows, когда пользователь последний раз менял пароль или кто его принудительно поменял. Уверен, что данная информация вам окажется полезной при изучении событий безопасности.

Постановка задачи

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

Настройка политики аудита сброса паролей

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

Открываем с вами оснастку gpmc.msc (Управление групповой политикой). Разверните структуру вашего леса и выберите необходимый домен. В моем случае, это root.pyatilistnik.org. Я вам советую включать политику аудита всегда на уровне домена и использовать для этого уже имеющуюся политику «Default Domain Policy», в принципе сама Microsoft на этот момент не против, но никто вам не мешает создать новую и прилинковать ее к вашему домену. Щелкаем по ней правым кликом и из контекстного меню выбираем «Изменить»

Нужные нам параметры находятся в настройках на компьютер. Переходим по пути:

Нас тут будет интересовать пункт «Аудит управления учетными записями (Audit User Account Management )». Щелкаем по данному пункту двойным кликом и у вас откроется окно свойств. Установите галки:

Активировав галки, сохраняем настройки нажав ok.

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

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

Теперь когда у вас политика аудита настроена и применена к серверам и компьютерам, можно изучать логи операционной системы. Открываем просмотр событий Windows. Переходим в журнал «Безопасность», именно в него пишутся события, сброса пароля пользователя Active Directory и изменения пароля самим пользователем.

Перед тем, как искать информацию, нам необходимо определиться, какой номер ID события нам интересен. В журнале безопасности нужно искать:

Код события 4723 показывает нам информацию, была ли попытке изменить пользователем свой пароль, и два варианта получилось это сделать или нет.

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

Еще полезным будет почитать про описание событий системы безопасности в Windows https://support.microsoft.com/ru-ru/help/977519/description-of-security-events-in-windows-7-and-in-windows-server-2008

В журнале безопасность нажмите «Фильтр текущего журнала». В настройках фильтрации поля «Все коды событий» введите 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.

Источник

4724 (S, F): была предпринята попытка сбросить пароль учетной записи.

Описание события:

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

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

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

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

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

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

Примечание. Рекомендации приведены в разделе Рекомендации по мониторингу безопасности для этого события.

XML события:

Необходимые роли сервера: нет.

Минимальная версия ОС: Windows Server 2008, Windows Vista.

Версии события: 0.

Описания полей:

Тема:

Имя учетной записи [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».

Рекомендации по контролю безопасности

Для 4724 (S, F): была предпринята попытка сбросить пароль учетной записи.

Если у вас есть домен высокой стоимости или учетная запись локального пользователя, для которой необходимо отслеживать каждую попытку сброса пароля, отслеживайте все события 4724 с помощью «Target Account\Security ID», соответствующего учетной записи.

Если у вас есть домен высокой стоимости или локализованная учетная запись, для которой необходимо отслеживать каждое изменение, отслеживайте все события 4724 с помощью «Target Account\Security ID», соответствующего учетной записи.

Если у вас есть доменные или локальные учетные записи, для которых пароль никогда не должен быть сброшен, вы можете отслеживать все события 4724 с помощью «Target Account\Security ID», соответствующего учетной записи.

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

Источник

Event ID, которые нужно знать системным администраторам AD

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

После включения аудита необходимо тем или иным способом (например, через Powershell script) проверять логи на интересующие вас Event ID. Обратите внимание, что аудит логи хранятся на ADC очень короткое время, поэтому надо или настроить их экспорт во внешнюю систему или успеть найти нужное событие в реальном времени.

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

Ниже приводится список событий, которые необходимо мониторить. Трехзначные Event ID соответствуют уровню домена и леса (functional level) 2003.

События в аудит логах контроллеров доменов

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
(Аудит системных событий)
Указанный пользователь очистил журнал безопасности

Локальные события. Вход и выход из системы (Logon/Logoff)

528 или 4624 — Успешный вход в систему
529 или 4625 — Отказ входа в систему – Неизвестное имя пользователя или неверный пароль
530 или 4625 Отказ входа в систему – Вход в систему не был осуществлен в течение обозначенного периода времени
531 или 4625 — Отказ входа в систему – Учетная запись временно деактивирована
532 или 4625 — Отказ входа в систему – Срок использования указанной учетной записи истек
533 или 4625 — Отказ входа в систему – Пользователю не разрешается осуществлять вход в систему на данном компьютере
534 или 4625 или 5461 — Отказ входа в систему – Пользователь не был разрешен запрашиваемый тип входа на данном компьютере
535 или 4625 — Отказ входа в систему – Срок действия пароля указанной учетной записи истек
539 или 4625 — Отказ входа в систему – Учетная запись заблокирована
540 или 4624 — Успешный сетевой вход в систему (Только Windows 2000, XP, 2003)

Типы входов в систему (Logon Types)

Тип входа в систему — Описание

2 — Интерактивный (вход с клавиатуры или экрана системы)
3 — Сетевой (например, подключение к общей папке на этом компьютере из любого места в сети или IIS вход — Никогда не заходил 528 на Windows Server 2000 и выше. См. событие 540)
4 — Пакет (batch) (например, запланированная задача)
5 — Служба (Запуск службы)
7 — Разблокировка (например, необслуживаемая рабочая станция с защищенным паролем скринсейвером)
8 — NetworkCleartext (Вход с полномочиями (credentials), отправленными в виде простого текст. Часто обозначает вход в IIS с “базовой аутентификацией”)
9 — NewCredentials
10 — RemoteInteractive (Терминальные службы, Удаленный рабочий стол или удаленный помощник)
11 — CachedInteractive (вход с кешированными доменными полномочиями, например, вход на рабочую станцию, которая находится не в сети)

Коды отказов 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 — Пользователь должен поменять пароль при следующем входе в систему

Был ли наш пост полезен?

Нажмите на звезду, чтобы оценить мои труды!

Средний рейтинг: 0 / 5. Количество голосов: 0

Источник