Что такое редактор локальной групповой политики и как его использовать

Порядок применения групповых политик в домене

В этой обзорной статье я постараюсь разобрать типовые причины, из-за которых та или иная групповая политика может не применяться к подразделению (OU) или конкретному компьютеру / пользователю. Я думаю эта статья будет полезна как новичкам, так и профессионалам групповых политик AD для понимания принципов работы и архитектуры GPO. В первую очередь в статье я расскажу о возможных проблемах применения GPO, связанные с настройками самих политик на уровне домена, а не о траблшутинге применения GPO на клиентах. Практически все настройки, описанные в статье, выполняются в консоли редактора доменных групповых политик — Group Policy Management Console (GPMC.msc).

Если некой параметр политики не применятся на клиенте, проверьте область действия (scope) групповой политики. Если вы настраиваете параметр в секции Конфигурация компьютера (Computer Configuration), значит ваша групповая политика должна быть привязана к OU с компьютерами. Соответственно, если настраиваемый параметр относится к Конфигурация пользователя (User configuration).

Также проверьте, что объект, к которому вы пытаетесь применить политику находится в нужном OU с компьютерами или пользователями. Можно воспользоваться поиском по домену. OU, в котором находится объект содержится на вкладке Object в консоли ADUC.

Т.е целевой объект должен находится в OU, на который назначена политика (или во вложенном контейнере).

Что такое локальная групповая политика?

По определению, групповая политика — это функция Windows, которая предлагает вам централизованный способ управления и настройки операционной системы Windows, программ и пользовательских настроек с компьютеров, подключенных к одному домену. Групповые политики наиболее полезны, если вы являетесь сетевым администратором и вам необходимо применять определенные правила или параметры на компьютерах или пользователях, находящихся в сети, которой вы управляете.

Локальная групповая политика — это вариант групповой политики, который также позволяет управлять отдельными компьютерами, в отличие от всех компьютеров, зарегистрированных в домене. Хорошим примером является ваш домашний компьютер с Windows 10, Windows 8.1 или Windows . Это означает, что этот инструмент может быть полезен как для домашних пользователей, так и для сетевых администраторов. Проще говоря, вы должны думать о локальной групповой политике как о наборе правил, управляющих работой Windows на вашем компьютере или устройстве.

Клиентский и серверный компоненты групповых политик

Выделяют два компонента групповых политик — клиентский и серверный, т.е. формируется структура “клиент-сервер”.

Серверный компонент представляет оснастка MMC (Microsoft Management Console), предназначенная для настройки групповой политики. MMC можно использовать для создания политик, а также для контроля и управления административными шаблонами, настройками безопасности (установка ПО, скрипты и т.п.). Обобщенное название “возможностей” называется расширением. Каждое расширение может иметь дочернее расширение, которое разрешает добавление новых или удаление старых компонентов, а также их обновление.

Клиентский компонент получает и применяет настройки групповой политики. Клиентские расширения являются компонентами запускаемыми на клиентской ОС, которые отвечают за интерпретацию и обработку объектов групповой политики.

Для администрирования GPO используют оснастки MMC — Group Policy Management Console (GPMC) и Group Policy Management Editor.

Сценарии использования Active Directory GPO:

• Централизованная настройка пакета программ Microsoft Office.
• Централизованная настройка управлением питанием компьютеров.
• Настройка веб-браузеров и принтеров.
• Установка и обновление ПО.
• Применение определенных правил в зависимости от местоположения пользователя.
• Централизованные настройки безопасности.
• Перенаправление каталогов в пределах домена.
• Настройка прав доступа к приложениям и системным программам.

Почему встроенные инструменты работы с GPO недостаточно удобны

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

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

Но самое ужасное во всей этой истории с безопасностью GPO — изменения настроек не отслеживаются в собственных журналах безопасности, нет предупреждений, следовательно, невозможно отслеживать такие нарушения, даже если использовать SIEM-систему.

Работа с административными шаблонами

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

Например, давайте представим, что после нескольких часов поиска вы все-таки нашли групповую политику Удалить меню «Файл» из проводника, которую уже очень давно мечтали применить. Как оказалось, она находится в разделе Конфигурация пользователя > Административные шаблоны > Компоненты Windows > Проводник Windows.

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

Как правило, каждая групповая политика может иметь три состояния.

Не задан — если политика установлена в данное состояние, значит, параметр, на основе которого она работает, в реестре еще не существует. А значит, операционная система использует свои стандартные настройки.

Включен — если политика установлена в данное состояние, тогда, как правило, значение параметра реестра, используемого ею, равно 1. А значит, ограничение или настройка, определяемая политикой, установлена.

Отключен — если политика установлена в данное состояние, тогда, как правило, значение параметра реестра, используемого ею, равно 0.

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

Трюк 6. Используем переменные среды

Когда начинаешь мучить групповые политики, то приходит осознание, что для создания защищенной системы потребуется попотеть. Дело трудное и с большим количеством тонкостей. Например, разработчики предлагают админам использовать удобный хинт — указывать переменные среды в качестве путей для ограничений SRP. Да вот здесь проблема. У пользователя, если их жестко не прищучить, есть возможность их переопределять. Указал, например, админ, что из папки %TEMP% можно запускать exe’шники, а юзер взял да и переопределил следующей командой:

И вот так просто получил возможность запускать файлы из корня C:. Кроме того, не стоит забывать про стандартные директории, из которых разрешен запуск exe-файлов:

%HKEY_LOCAL_MACHINESOFTWAREMicrosoft Windows NTCurrentVersionSystemRoot%

%HKEY_LOCAL_MACHINESOFTWAREMicrosoft Windows NTCurrentVersionSystemRoot%*.exe

%HKEY_LOCAL_MACHINESOFTWAREMicrosoft Windows NTCurrentVersionSystemRoot%System32*.exe

Они разрешают запуск ПО только из папки Windows и Program Files для пользователей. У обычного пользователя нет возможности записи в них, но и здесь могут быть проблемы. Так как на самом деле права на запись у пользователя есть — по дефолту в папку C:windowssystem32spoolPrinters и C:windowstemp. Если у пользователя будет возможность писать в какой-то каталог с софтом, то, считай, соответствующие политики SRP уже не сработают. Кстати, для того чтобы на практике поверить, какие у пользователя есть права, поможет тулза — AccessChk от все того же Руссиновича.

VI. Наследование в групповых политиках

1. На все политики в домене распространяется наследование, т.е. политики, назначенные на родительский контейнер (домен или OU), последовательно применяются ко всем дочерним контейнерам. При необходимости это можно изменить, отключив наследование для отдельно взятого OU. Для этого необходимо перейти в управление групповой политикой (прим. Пуск > Администрирование > Управление групповой политикой), выбрать нужное OU (прим. в данном руководстве это OU-1), кликнуть на нем правой клавишей мыши и в контекстном меню отметить пункт Блокировать наследование. После этого для данного OU и его дочерних OU (при их наличии) отменяется воздействие всех вышестоящих политик (Рис.23).

Примечание! Политика Default Domain Policy содержит настройки, определяющие политику паролей и учетных записей в домене. Эти настройки не могут быть заблокированы.

Системная утилита quser.exe

Мы можем использовать системную программу quser, которая возвращает имя текущего пользователя и время его входа. Выглядит это так:

Quser так же может работать удаленно используя следующий синтаксис:

Первая проблема этого способа — это то, что quser работает через RPC. Если вы выполняете команду удаленно, а порты не открыты, вы получите ошибки:

• Error 0x000006BA enumerating sessionnames
• Error [1722]:The RPC server is unavailable.

Для примера, следующие команды исправят эти проблемы на одном компьютере, но скорее всего вы будете менять настройки через политики. Так же обратите внимание, что правило устанавливается на «Any», а не только «Domain»:

Вторая проблема — если вы будете выполнять команду через Invoke-Command, то могут быть проблемы с кодировками:

И третья проблема — у нас возвращается строка, а не объект. Что бы мы могли все эти данные, в дальнейшем, экспортировать (например в CSV), мы должны ее парсить. Это можно сделать так:

Далее нам нужно преобразовать все в специальный массив — PSCustomObject, т.к. только он может быть экспортирован в CSV и представляет собой более удобный вывод:

Метод substring убирает первый символ, так как программа возвращает имя пользователя либо с пробелом начали или символом «>».

Такой скрипт мы можем объединить в один командлет, который сможет работать локально и удаленно:

В функцию добавлено несколько деталей:

1. Функция имеет атрибут «ComputerName» в которую можно передать имя компьютера. Т.к. эта переменная является строкой мы не можем использовать одновременно несколько (конвейер передает по одному);
2. По умолчанию «ComputerName» выполняет $env:computername, что возвращает имя текущего компьютера;
3. Часть команды «quser /server:$ComputerName 2>Null » будет исключать некоторые ошибки, которые связаны с выключенными компьютерами. Иначе — будут выводиться красные сообщения мешающие выводу;
4. Добавлено несколько условий, которые различают логические ошибки (например фаервол), физические (компьютер выключен) и условие в случае если все хорошо;

Мы можем вызывать скрипт несколькими приемами:

Отмечу, что в случаях выключенных компьютеров запросы идут очень долго (около 2-3 секунд на компьютер). Способа снизить конкретно таймаут — я не знаю. Один из вариантов ускорить работу — фильтровать вывод с Get-ADComputer исключая отключенные учетные записи компьютеров. Так же можно попробовать использовать параллелизм.

Легче всего такой скрипт запускать на компьютерах пользователей, по событию входа в систему. На примере ниже я экспортирую эти данные в единый, для всех пользователей, файл CSV расположенный в доступности для пользователей:

Сам файл будет выглядеть так:

Отмечу следующие моменты:

1. Можно увидеть разницу во времени и датах. У меня одна ОС с американской локализацией, а другая с русской. В принципе у вас таких проблем быть не должно, но можно исправить через Get-Date (парсингом даты);
2. Из-за предыдущего пункта у меня бывали проблемы с кодировками, но они самоустранились быстрее, чем я смог предпринять действия.

Заключение

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

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

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