Windows server кто создал пользователя



HelpDesk под колпаком. Аудит создания учетных записей пользователей в AD

Еще только в начале своего познания профессии системного администратора мой начальник поведал мне о такой профессии (вернее ее направлении) как дизайнер AD. Эти люди наводят порядок в домене и приводят в порядок учетные записи. Кто с этим сталкивался и возился может понять то раздражение, которое вызывают корявые имена учетных записей, созданных каким-нибудь сотрудником, который чихал на твой порядок.
Взяв в руки PowerShell мы дали им бой!

Не надо мусорить!

Суть состоит в том, что для HelpDesk было создано специально подразделение в AD (назовем его NewUsers), в котором они могли создавать новые учетные записи (делегирование прав пользователям здесь обсуждать не будем).
Их задача — по необходимости создавать новые учетные записи в этом подразделении.
Моя задача — отслеживать правильность заполнения нужных полей (особенно login) и перемещать по отделам.

Оказалось, что люди не хотели совершенно задумываться о том, что и как и попросту бродили ко мне с просьбами создай вот такую запись. Несколько недель я отмахивался словами: вы сами все можете!
И наконец я достучался до них, но это оказалось только началом истории.

В итоге я получил кучу учетных записей, непонятно чьих, и самое главное — непонятно кем созданных. На вопрос: «кто это создал?», все работники дружно отнекивались. Естественно, что я не горел желанием разбираться в этих учетках, и без того дел хватало.
Как ответственный за домен, отвечать перед начальником за Tania и Gosha приходилось мне.

На глаза попалось замечательное слово — аудит.

Способы решения

Выходов из этой ситуации было несколько. С одной стороны можно было всем долго и упорно метать бисер объяснять какие поля и как заполнять. С другой, отслеживать создание учетных записей и, выявляя нарушителей системы, тыкать их носом в корявые имена.

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

Для начала мне надо было установить политику аудита для определенных подразделений (в нашем случае папка NewUsers) и добавить к аудиту группу, за которой будем просматривать (можно не раздумывать о группах и добавить просто всех пользователей).
Вот здесь можно почитать про аудит доменных служб Active Directory, а вот здесь Вас ждет пошаговая инструкция, как настроить аудит.
В итоге в журнале безопасности контроллера домена будут появляться события создания новых объектов пользователей.
Нас же интересует событие с кодом 5137 (Создание объекта в каталоге).

Переходим к сбору информации с контроллеров. Конечно, если у вас 1 КД, вам достаточно просто настроить фильтр журнала, и забыть про остальную часть статьи, но тогда Вам придется превратиться в дядю Ваню, сторожа кукурузного поля, который всегда на посту. Другими словами — есть свободное время? Загляни в журнал безопасности.
Если же хочется остаться самим собой и у вас более 1 КД, стоит читать дальше.

А что же PowerShell?

В PowerShell просматривать журнал на помогает cmndlet Get-eventlog. С помощью него мы и будем выбирать нужные нам сообщения. Дабы обойти проблемы с подписанием скриптов, мы поступили так: засунули нужный нам код в файл профиля и определили его как функцию.

Для тех, кто не знаком с профилями, можно почитать это или, кому не хочется покидать Хабр, это.
Так же, для загрузки профиля понадобится выполнить команду:

Вернемся к нашим баранам. Собственно, код нашей функции:

function Audit
<
Get-eventlog security -InstanceID «5137» -Newest 1 |
Where-Object <$_.Message -match "OU=NewUsers,DC=contoso,DC=com">|
Select-object TimeWritten,Message,MachineName | Format-list | out-file \\MyComp\d$\Audit.txt -append
>

Для себя я выбираю только время записи события, сообщение и имя КД, на котором все это происходило. Если кому то этой информации недостаточно, можно расширить список. Пишем:
Get-eventlog security -InstanceID «5137» | get-member
и получаем полный список всех свойств.
Вывод осуществляется в текстовый файл, который находится на моем рабочем компьютере.
Так же меня интересуют учетные записи только в определенном подразделении, так что мы выбираем сообщения, в которых присутствует путь к нашей папке (OU=NewUsers,DC=contoso,DC=com).
Если интересно, почему я выбираю только 1 последнюю запись, читаем далее.

Нам надо вызывать эту функцию каждый раз, когда в журнале будут появляться нужные нам события. Для этого воспользуемся стандартным планировщиком заданий. Как создавать задание я рассказывать не буду, остановлюсь на важных моментах:
Действие: Запуск программы
Программа или сценарий: powershell
Добавить аргументы: -windowstyle Hidden audit
Триггер:
Назначить задачу: При событии
Журнал: Безопасность
Код события: 5137

Так же не забываем поставить галочки:
«Выполнять вне зависимости от регистрации пользователя» — дабы задача могла выполняться не требуя нашего присутствия.
«Выполнять с наивысшими правами» — дабы у нас был доступ к журналу Безопасность.

После создания задания, можно экспортировать его в xml файл и таким образом распространить его на остальные КД.

Источник

Политики аудита изменений в Active Directory

Любой администратор Active Directory рано или поздно сталкивается с необходимостью аудита изменения в Active Directory, и этот вопрос может встать тем острее, чем больше и сложнее структура Active Directory и чем больше список лиц, кому делегированы права управления в том или ином сайте или контейнере AD. В сферу интересов администратора (или специалиста по ИБ) могут попасть такие вопросы как:

  • кто создал/ удалил пользователя или группу AD
  • кто включил / заблокировал пользователя
  • с какого адреса был изменен / сброшен пароль пользователя домена

В ОС семейства Windows существуют встроенные средства аудита изменений в различных объектах, которые, как и многие другие параметры Windows, имеют возможности управления с помощью групповых политики.

Разберем на конкретном примере методику включения аудит изменений параметров пользователей и членства в группах Active Directory (согласно данной методики можно включить отслеживание и других категорий событий).

Расширенные политики аудита Windows

Создадим новый объект GPO (групповую политику) с именем «Audit Changes in AD». Перейдите в раздел редактирования и разверните ветку Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Configuration. В данной ветке групповых политик находятся расширенные политики аудита, который можно активировать в ОС семейства Windows для отслеживания различных событий. В Windows 7 и Windows Server 2008 R2 количество событий, для которых можно осуществлять аудит увеличено до 53. Эти 53 политики аудита (т.н. гранулярные политики аудита) находятся в ветке Security Settings\Advanced Audit Policy Configuration сгруппированы в 10 категориях:

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

Настройка аудита изменений учетных записей и групп Active Directory

В данном случае, нас интересует категория Account Management, позволяющая включить аудит изменений в группах Audit Security Group Management) и аудит учетных записей пользователей (политика Audit User Account Management). Активируем данные политики аудита, задав отслеживание только успешных изменений (Success).

Осталось прилинковать данную политику к контейнеру, содержащему учетные записи контроллеров домена (по умолчанию это OU Domain Controllers) и применить эту политику (выждав 90 минут или выполнив команду gpupdate /force).

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

По умолчанию журнал отображает все события безопасности, попавшие в лог. Чтобы упростить поиск нужного события, журнал можно отфильтровать по конкретному Event ID. В том случае, если нас интересуюсь только события, например, качающиеся сброса пароля пользователя в домене, необходимо включить фильтр по id 4724.

Ниже приведен список некоторых ID событий, которые могут понадобиться для поиска и фильтрации событий в журнале Security практике:
ID событий, в контексте изменений в группах AD:

4727 : A security-enabled global group was created.
4728 : A member was added to a security-enabled global group.
4729 : A member was removed from a security-enabled global group.
4730 : A security-enabled global group was deleted.
4731 : A security-enabled local group was created.
4732 : A member was added to a security-enabled local group.
4733 : A member was removed from a security-enabled local group.
4734 : A security-enabled local group was deleted.
4735 : A security-enabled local group was changed.
4737 : A security-enabled global group was changed.
4754 : A security-enabled universal group was created.
4755 : A security-enabled universal group was changed.
4756 : A member was added to a security-enabled universal group.
4757 : A member was removed from a security-enabled universal group.
4758 : A security-enabled universal group was deleted.
4764 : A group’s type was changed.

ID событий, в контексте изменений в учетных записей пользователей в AD:

4720 : A user account was created.

Основные недостатки встроенной системы аудита Windows

Однако у штатных средств просмотра и анализа логов в Windows есть определенные недостатки.

Естественно, консоль Event Viewer предоставляет лишь базовые возможности просмотра и поиска информации о тех или иных событиях в системе и не предполагает возможностей сложной обработки, группировки и агрегации информации. По сути эта задача целиком зависит от способностей и уровня подготовки системного администратора или инженера ИБ, который с помощью различных скриптов (например, powershell илл vbs) или офисных средств может разработать собственную систему импорта и поиска по журналам.

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

Кроме того, при организации системы аудита изменений в AD с помощью штатных средств Windows нужно учесть, что в журнал системы пишется огромное количество событий (зачастую ненужных) и это приводит к его быстрому заполнению и перезатиранию. Чтобы иметь возможность работы с архивом событий, необходимо увеличить максимальный размер журнала и запретить перезапись, а также разработать стратегию импорта и очистки журналов.

Именно по этим причинам, для аудита изменений в AD в крупных и распределенных системах предпочтительно использовать программные комплексы сторонних разработчиков. В последнее время на слуху, например, такие продукты, как NetWrix Active Directory Change Reporter или ChangeAuditor for Active Directory.

Источник

Аудит события входа пользователей в Windows

При расследовании различных инцидентов администратору необходимо получить информацию кто и когда заходил на определенный компьютер Windows. Историю входов пользователя в доменной сети можно получить из журналов контроллеров домена. Но иногда проще получить информацию непосредсвенно из логов компьютера. В этой статье мы покажем, как получить и проанализировать историю входа пользователей на компьютер/сервер Windows. Такая статистика поможет вам ответить на вопрос “Как в Windows проверить кто и когда использовал этот компьютере”.

Настройка политики аудита входа пользователей в Windows

Сначала нужно включить политик аудита входа пользователей. На отдельностоящем компьютере для настройки параметров локальной групповой политики используется оснастка gpedit.msc. Если вы хотите включить политику для компьютеров в домене Active Directorty, нужно использовать редактор доменных GPO ( gpmc.msc ).

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

После того как вы включили политики аудита входа, при каждом входе пользователя в Windows в журнале Event Viewer будет появляться запись о входе. Посмотрим, как она выглядит.

  1. Откройте оснастку Event Viewer ( eventvwr.msc );
  2. Разверните секцию Windows Logs и выберите журнал Security;
  3. Щелкните по нему правой клавишей и выберите пункт Filter Current Log;

Event ID Описание
4624 A successful account logon event
4625 An account failed to log on
4648 A logon was attempted using explicit credentials
4634 An account was logged off
4647 User initiated logoff

Если полистать журнал событий, можно заметить, что в нем присутствуют не только события входа пользователей на компьютер. Здесь также будут события сетевого доступа к этому компьютеру (при открытии по сети общих файлов или печати на сетевых принтерах), запуске различных служб и заданий планировщика и т.д. Т.е. очень много лишний событий, которые не относятся ко входу локального пользователя. Чтобы выбрать только события интерактивного входа пользователя на консоль компьютера, нужно дополнительно сделать выборку по значению параметра Logon Type. В таблице ниже перечислены коды Logon Type.

Код Logon Type Описание
0 System
2 Interactive
3 Network
4 Batch
5 Service
6 Proxy
7 Unlock
8 NetworkCleartext
9 NewCredentials
10 RemoteInteractive
11 CachedInteractive
12 CachedRemoteInteractive
13 CachedUnlock

В соответствии с этой таблицей событие локального входа пользователя на компьютер должно содержать Logon Type: 2.

Для фильтрации события входа по содержать Logon Type лучше использовать PowerShell.

Анализ событий входа пользователей в Windows с помощью PowerShell

Допустим, наша задача получить информацию о том, какие пользователи входили на этот компьютер за последнее время. Нам интересует именно события интерактивного входа (через консоль) с LogonType =2 . Для выбора события из журналов Event Viewer мы воспользуемся командлетом Get-WinEvent.

Следующий PowerShell скрипт выведет история входа пользователей на текущий компьютер и представит ее в виде графической таблицы Out-GridView.

Если нужно выбрать события входа за последние несколько дней, можно добавить pipe с таким условием:

Командлет Get-WinEvent позволяет получить информацию с удаленных компьютеров. Например, чтобы получить историю входов с двух компьютеров, выполните следующий скрипт:

‘msk-comp1’, ‘msk-comp2’ |
ForEach-Object <
Get-WinEvent -ComputerName $_ -FilterXml $query | Select-Object $properties
>

Источник

You may also like...