Выгрузка доменных пользователей powershell

Введение

Active Directory (AD) является фундаментальным компонентом инфраструктуры большинства крупных организаций в России — и особенно актуальным для сегмента защищённых ИТ-контуров. Работа с учетными записями пользователей в AD связана не только с обычным администрированием, но и с регулярным аудитом, выявлением отклонений от безопасности, анализом соответствия законодательству (ФСТЭК России, 152-ФЗ «О персональных данных»). Автоматизированная выгрузка пользователей с помощью PowerShell — это ключевой инструмент для системных администраторов, специалистов по информационной безопасности и compliance.

Процесс экспорта и анализа данных о пользователях позволяет:

Оценить состояние учетных записей на соответствие корпоративным и регуляторным требованиям.
Обнаружить устаревшие, аномальные или потенциально опасные учетные записи.
Подготовиться к проверкам или предоставить отчетность по контролю доступа и учетам, что крайне важно при прохождении аудитов ФСТЭК или Роскомнадзора.

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

[ИЗОБРАЖЕНИЕ: Схема процесса выгрузки пользователей из Active Directory в файлы для аудита]

Запуск сценария PowerShell

Экспорт информации о доменных пользователях обычно реализуется через автоматизацию — запуск подготовленного PowerShell-скрипта с консоли, под учетной записью с необходимыми правами просмотра данных. В большинстве случаев корпоративная политика запрещает работу с AD из-под доменных администраторов, поэтому запуск происходит от имени выделенных служб мониторинга или через согласованные с ИБ процессы.

Базовый пример вызова скрипта:

powershell -ExecutionPolicy Bypass -File .ExportADUsers_ADSI.ps1

Скрипт, например, с именем ExportADUsers_ADSI.ps1, должен быть предварительно проверен ИБ-службой на соответствие внутренней политике сканирования и анализа учетных записей. Чаще всего он собирает:

Основные параметры каждого доменного пользователя (имя, логин, описание, принадлежность к группам, состояния флагов безопасности).
Детализацию по паролям (есть ли запрет на смену, устаревание, политика сложности).
Атрибуты активности (время последнего входа, блокировки, ошибки входа).
Признаки принадлежности к привилегированным или сервисным учетам.

Результирующий CSV-файл можно интегрировать в системы SIEM, выполнять сравнение в динамике, передавать аудиторам и экспертам по ИБ. Такой подход позволяет обрабатывать и хранить информацию на постоянной основе, что повышает прозрачность управления доступом.

Ключевые флаги UserAccountControl (UAC)

В каждом объекте учетной записи AD атрибут UserAccountControl хранит множество битовых флагов, отражающих критические свойства безопасности. Игнорирование некоторых из этих флагов часто приводит к нарушению требований нормативных актов (приказов ФСТЭК, Роскомнадзора) и создает возможности для атакующих.

Флаг UAC	Описание	Актуальность для ИБ и регуляторики
PwdNotRequired	Отсутствие требования пароля для входа	ФСТЭК и 152-ФЗ требуют обязательности аутентификации. Аккаунт без пароля – критический риск.
PwdCannotChange	Пользователь не может сам менять пароль	Ограничивает пользователя, но «замораживает» его секреты, что противоречит принципу периодического обновления.
ReversibleEncryption	Пароль хранится с возможностью обратного дешифрования	Абсолютно недопустимо по регуляторике — явное нарушение требований к хранению данных.
DelegationAllowed	Включено делегирование Kerberos	Увеличивает поверхность атаки на инфраструктуру, требует строгого учета и отдельного мониторинга.

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

[ИЗОБРАЖЕНИЕ: Таблица с основными UAC-флагами и маппингом на регуляторные требования]

Признаки привилегированных и уязвимых учетных записей

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

AdminAccount (adminCount=1): Атрибут adminCount=1 выставляется системой каждому объекту, который хотя бы раз входил в состав защищённой привилегированной группы (Domain Admins, Enterprise Admins, Administrators и др). Важно: даже после удаления пользователя из этих групп adminCount=1 сохраняется навсегда, и объект остается под особым контролем механизма SDProp. Такая «призрачная» привилегия — постоянный источник нестандартных допусков и объект для отдельных ИБ-процедур (например, анализа наследования разрешений).
HasSPN: Наличие у учетной записи Service Principal Name (SPN) означает, что эта учетная запись используется приложением/службой для аутентификации на сервере. SPN-учетки часто становятся целью Kerberoasting-атак, что требует их отдельного отбора для аудита.
Превышение прав за счет ошибок операции: Если пользователя перевели из привилегированной группы обратно в «обычные», но не сбросили параметры SD, учетная запись может не наследовать политики безопасности и оставаться в аномальном состоянии.
Сервисные аккаунты: Учетки сервисов зачастую имеют повышенные права ради стабильной работы, при этом слабо контролируются. Для ФСТЭК такая категория должна подвергаться ежемесячному аудиту.

Анализ этих признаков и автоматическая фильтрация по ним позволяют быстро реагировать на риски и готовить инцидентные отчеты для ИБ.

Параметры активности учетных записей

Важной частью экспорта и анализа учетных записей является мониторинг активности (или неактивности) пользователей. Игнорирование признаков неиспользуемых, устаревших, ранее скомпрометированных учеток — один из типичных источников инцидентов, попадающих в отчеты ФСТЭК и независимых аудиторов.

DaysPwdAge: Количество дней с последней смены пароля — один из самых показательных критериев. Современные рекомендации и требования (в том числе 152-ФЗ) устанавливают максимальный возраст пароля 45–60 дней. Любые превышения должны строго фиксироваться и являться поводом для анализа.
LastBadPwd (Последняя ошибка ввода пароля): Возникающие многократно ошибки попыток входа — частый признак брутфорс-атак или остатка устаревших процессов/скриптов с неверными паролями. Регулярное появление ошибок — повод для ИБ-расследования.
AccountExpires: Используется для установки сроков действия временных учетных записей: подрядчиков, подрядных организаций, временных сотрудников ИТ или операторов. Отсутствие или несвоевременное закрытие таких учетных записей часто фиксируется ФСТЭК как нарушение.
LastChanged: Дата последнего изменения объекта (в т.ч. атрибутов, групповых членств) в AD — индикатор активности не только пользователя, но и потенциально сотрудников ИБ/системных администраторов. Аномальные изменения в ночное время или в праздники — предмет мониторинга.
HasHomeDir: Признак наличия домашней директории или файлового ресурса за учетной записью. Отсутствие такой директории — возможный индикатор неактуальности учетки; наоборот, множество связанных каталогов — объект для отдельной проверки.

Регулярный анализ перечисленных параметров становится основой политики «минимально необходимого доступа» и соблюдения внутренних требований безопасности.

Особенности управления паролями

Управление сроками действия и сложностью паролей — центральный компонент политики информационной безопасности в AD-контуре. Комбинации флагов, контролирующих временные параметры доступа, оказывают существенное влияние на устойчивость системы против атак социальной инженерии и перебора паролей.

PwdNoExpire: Учетная запись с признаком «пароль не истекает». Допустимо для некоторых сервисных учеток (в исключительных случаях с обоснованием и отдельным контролем), для обычных пользователей — грубое нарушение требований ФСТЭК.
OldPwdNNd: Пароль не менялся более N дней (стандартное значение по политике — 60/90 дней для большинства организаций). В связке с флагом PwdNoExpire — почти гарантированный инцидент.
ForcedChange: Признак «требовать смены пароля при следующем входе» — полезная мера при снятии блокировки после инцидента.
PasswordHistory: В настройках можно хранить определённое количество предыдущих паролей — предотвращает обратный откат.

Контроль этих параметров интегрируется в ежедневные и месячные чек-листы ИБ, а результаты выгрузки через PowerShell используются для быстрой фильтрации учетных записей по критическим отклонениям и последующей ликвидации рисков.

Влияние флагов на политику безопасности

Некоторые системные атрибуты оказывают влияние не только на отдельные учетные записи, но и на всю политику управления доступом в AD. Как пример — adminCount=1: при его наличии на объекте отключается наследование большинства политик через GPO, на объекте ‘замораживаются’ разрешения с помощью механизма SDProp.

Это создаёт следующую цепочку рисков:

Удаленный из Domain Admins пользователь сохраняет статус «привилегированного по наследству», если adminCount=1 не сбрасывается вручную.
Учётка может остаться вне новых политик безопасности, быть открыта нежелательным разрешениям (например, из устаревших ACL) или не попадать под периодический аудит.
SDProp-контроль отдельно интересует аудиторов ФСТЭК: отсутствие прозрачности и документированного сброса статуса у переведённых пользователей — формальное основание для претензий.

Помимо этого, ряд флагов UAC позволяет сделать выводы о необходимости пересмотра политики хранения и обновления паролей, пересмотра прав на делегирование задач, изъятия сервисных учетных записей из зон с особыми рисками (например, Kerberos Delegation), а также внедрения автоматизированных средств контроля изменений в групповых членствах.

Закладывая обработку этих признаков в PowerShell-отчеты, организация создает задел по быстрому реагированию на аудит, инциденты, внеочередные проверки клиента или регулятора.

Структура и логика PowerShell-скрипта

В большинстве случаев правильно построенный PowerShell-скрипт осуществляет:

Перебор всех пользовательских объектов в целевом домене AD с помощью ADSI (или модулей ActiveDirectory).
Анализ состояния ключевых атрибутов (userPrincipalName, sAMAccountName, description, userAccountControl, lastLogonTimestamp, pwdLastSet и т.п.).
Сравнение UAC-флагов с допустимыми политиками (например, пароли без срока действия, разрешение на обратимое хранение и т. д.).
Определение признаков привилегированности при помощи анализа adminCount и членства в специальных группах.
Выгрузку результата в структурированный CSV-файл с последующей передачей в системы мониторинга или анализа (SIEM, Excel, внутренние аудиторские решения).

Пример содержимого отчета по каждой учетной записи:

Имя пользователя	Логин	Описание	Дата последнего входа	LastPwdChange	UAC-флаги	Сервис/SID	Привилегия (adminCount)	Пароль бессрочный	Возраст пароля
ivanov.a	ivanov.a	Отдел ИБ	2024-06-17	2024-04-01	PwdNoExpire	No	1	Да	78
Petrov.I	petrovi	Сервисная учетная запись	2024-05-10	2024-04-28	DelegationAllowed	Yes	0	Нет	43

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

[ИЗОБРАЖЕНИЕ: Пример структурированного CSV-отчета с ключевыми параметрами AD-пользователей]

[КОД: PowerShell-скрипт, экспортирующий данные пользователей AD в CSV, фильтрующий по adminCount, UAC-флагам, SPN, правильным срокам паролей и активности]

Практическое применение отчета

Экспортированный отчет дает конкретные инструменты для:

Аудита соответствия законодательству (ФСТЭК, 152-ФЗ): Проверка сроков действия паролей, обязательности их наличия, запретов на постоянные пароли, выявление аномалий в делегировании прав.
Контроля за учетной политикой: Фильтрация и анализ всех учетных записей с устаревшими, нестандартными или подозрительными параметрами и их своевременное исправление.
Мониторинга использования ресурсов: Поиск устаревших, дублирующихся или неиспользуемых учетных записей для удаления. Поддержание актуальности учетных данных по штатным расписаниям.
Обеспечения прозрачности для аудиторов и проверяющих: Готовая доказательная база при проведении внешнего или внутреннего аудита, минимизация времени на подготовку документов и снижение риска штрафов за несоответствие политике.
Отслеживания устранения уязвимостей: Возможность отслеживать динамику по устранению конкретных уязвимых параметров с помощью регулярных выгрузок (например, динамика «бессмертных» паролей за последний год или количество некорректных флагов UAC).
Обогащения данных SIEM: Интеграция с системами корреляции событий для автоматизации реагирования на попытки несанкционированного доступа или массового перебора паролей.

Организации, внедрившие регулярные выгрузки и централизованный анализ состояния учетных записей AD с помощью PowerShell, к проверкам регуляторов и аудиторских компаний подходят более подготовленно. Это наглядно сокращает время на реагирование на замечания и повышает общий уровень зрелости управления доступом.

Дополнительные рекомендации для регуляторного комплаенса

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

Результаты экспорта должны регулярно анализироваться сотрудниками ИБ и пересматриваться при изменении политик.
Аномалии (учетные записи без срока действия пароля, «призрачные» привилегии, сервисные учетки с избыточными правами) должна оперативно фиксироваться в журнале инцидентов с обязательным закрытием по процедуре.
Все сценарии и логи выгрузки необходимо хранить в защищенном сегменте, с разграничением доступа к скриптам и отчетам, чтобы предотвратить несанкционированное изучение учеток потенциальным злоумышленником изнутри.
При изменении доменной политики, процессов найма/увольнения сотрудников или переходе ИТ-услуг к внешним подрядчикам процессы аудита учеток должны запускаться внепланово.
Используйте хеш-суммы или цифровые подписи для проверки целостности экспортированных данных (важно для критических объектов ПДн и корпоративной тайны).
Отчетность следует интегрировать в общий реестр технических и административных мер защиты информации согласно приказу ФСТЭК № 239 и других релевантных документов.

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

Ошибки и частые проблемы в реальных внедрениях

Формальный сброс паролей без изменения флагов: нередки случаи, когда пароль принудительно меняют, но флаги не пересматривают: например, остаются бессрочные или с разрешением на обратимое хранение. Необходима регулярная проверка именно состояния BitMask’а UAC по всем учетным записям.
Ошибки в трактовке adminCount: админы часто ошибочно полагают, что удалив пользователя из привилегированной группы, они сняли с него все связанные риски. На самом деле, без ручного сброса adminCount и проверки разрешений уязвимость остается.
Недостаточный контроль сервисных учетных записей: этим учетам обычно выдается максимум прав (SecureString в скриптах, делегирование), однако политики слежения за сроками действия и уникальностью паролей отсутствуют.
Пропуск неактивных/«заброшенных» учетных записей: в крупных компаниях такие учетные записи могут жить годами — особенно, если их собственники давно не работают в организации. Это прямое нарушение ФСТЭК и 152-ФЗ.
Хаотичное хранение выгруженных отчетов: CSV-файлы с данными о пользователях хранятся без контроля доступа или резервного копирования, что создает риск компрометации информации или утери доказательной базы.

Описанные ошибки систематически выявляются в ходе регуляторных проверок и приводят к предписаниям на исправление, а порой и к штрафам.

Заключение

Выгрузка и аудит учетных записей пользователей AD с помощью автоматизированных сценариев PowerShell — один из столпов эффективного управления корпоративной ИТ- и ИБ-инфраструктурой. Современные требования к защищённости, в том числе требования ФСТЭК и 152-ФЗ, неизменно повышают значимость этой процедуры. Одна из главных целей — своевременно выявлять потенциальные уязвимости, устранять последствия человеческого фактора, поддерживать актуальность учетной политики и формировать убедительную отчетность к любым видам аудита.

Комплексный подход складывается из технических средств (сценарии экспорта, автоматические анализаторы CSV), организационных мер (регулярность проверок, формализация процессов инцидент-менеджмента), а также из грамотного распределения ответственности между ИТ-подразделением и службой ИБ. Только при соблюдении этих принципов организация может уверенно соответствовать требованиям законодательства, защищать критически важную инфраструктуру от инцидентов и минимизировать возможные последствия проверки внешних органов.