Время на прочтение
Групповая политика — важный элемент любой среды Microsoft Active Directory (AD). Её основная цель — дать ИТ-администраторам возможность централизованно управлять пользователями и компьютерами в домене. Групповая политика, в свою очередь, состоит из набора политик, называемых объектами групповой политики (GPO). У Microsoft реализованы тысячи разных политик и настроек, в которых можно утонуть и потом не всплыть. Все они подробно описаны в справочной таблице.
Как устроены групповые политики
При создании домена AD автоматически создаются два объекта групповой политики:
Политика домена по умолчанию устанавливает базовые параметры для всех пользователей и компьютеров в домене в трех плоскостях: политика паролей, политика блокировки учетных записей и политика Kerberos.
Политика контроллеров домена по умолчанию устанавливает базовые параметры безопасности и аудита для всех контроллеров домена в рамках домена.
Для вступления настроек в силу, объект групповой политики необходимо применить (связать) с одним или несколькими контейнерами Active Directory: сайт, домен или подразделение (OU). Например, можно использовать групповую политику, чтобы потребовать от всех пользователей в определённом домене использовать более сложные пароли или запретить использование съемных носителей на всех компьютерах только в финансовом подразделении данного домена.
Объект групповой политики не действует, пока не будет связан с контейнером Active Directory, например, сайтом, доменом или подразделением. Любой объект групповой политики может быть связан с несколькими контейнерами, и, наоборот, с конкретным контейнером может быть связано несколько объектов групповой политики. Кроме того, контейнеры наследуют объекты групповой политики, например, объект групповой политики, связанный с подразделением, применяется ко всем пользователям и компьютерам в его дочерних подразделениях. Аналогичным образом, объект групповой политики, применяемый к OU, применяется не только ко всем пользователям и компьютерам в этом OU, но и наследуется всем пользователям и компьютерам в дочерних OU.
Настройки различных объектов групповой политики могут перекрываться или конфликтовать. По умолчанию объекты групповой политики обрабатываются в следующем порядке (причем созданные позднее имеют приоритет над созданными ранее):
- Локальный (индивидуальный компьютер)
- Сайт
- Домен
- Организационная единица
В эту последовательность можно и нужно вмешиваться, выполнив любое из следующих действий:
Изменение последовательности GPO. Объект групповой политики, созданный позднее, обрабатывается последним и имеет наивысший приоритет, перезаписывая настройки в созданных ранее объектах. Это работает в случае возникновения конфликтов.
Блокирование наследования. По умолчанию дочерние объекты наследуют все объекты групповой политики от родительского, но вы можете заблокировать это наследование.
Принудительное игнорирование связи GPO. По умолчанию параметры родительских политик перезаписываются любыми конфликтующими политиками дочерних объектов. Вы можете переопределить это поведение.
Отключение связей GPO. По умолчанию, обработка включена для всех связей GPO. Вы можете предотвратить применение объекта групповой политики для конкретного контейнера, отключив связь с объектом групповой политики этого контейнера.
Иногда сложно понять, какие политики фактически применяются к конкретному пользователю или компьютеру, определить т.н. результирующий набор политик (Resultant Set of Policy, RSoP). Microsoft предлагает утилиту командной строки GPResult, который умеет генерировать отчет RSoP.
Для управления групповыми политиками Microsoft предоставляет консоль управления групповыми политиками (GPMC). Используя этот бесплатный редактор групповой политики, ИТ-администраторы могут создавать, копировать, импортировать, создавать резервные копии и восстанавливать объекты групповой политики, а также составлять отчеты по ним. Microsoft также предлагает целый набор интерфейсов GPMC, которые можно использовать для программного доступа ко многим операциям, поддерживаемым консолью.
По умолчанию любой член группы администраторов домена может создавать объекты групповой политики и управлять ими. Кроме того, существует глобальная группа под названием «Владельцы-создатели групповых политик»; его члены могут создавать объекты групповой политики, но они могут изменять только созданные ими политики, если им специально не предоставлены разрешения на редактирование других объектов групповой политики.
В этой же консоли можно делегировать вспомогательным ИТ-администраторам разрешения для различных действий: создание, редактирование и создание связей для определенных объектов групповой политики. Делегирование — ценный инструмент; например, можно предоставить группе, ответственной за управление Microsoft Office, возможность редактировать объекты групповой политики, используемые для управления настройками Office на рабочем столе пользователей.
Управление групповой политикой и делегирование
Делегирование— та вещь, которая быстро выходит из-под контроля. Права делегируются то так то эдак и, в конце концов, не те люди могут получить не те права.
Ценность групповой политики заключается в ее силе. Одним махом вы можете применить политики в домене или подразделении, которые значительно укрепят безопасность или улучшат производительность бизнеса. Или наоборот.
Но этой властью также можно злоупотребить, намеренно или случайно. Одно неправильное изменение объекта групповой политики может привести к нарушению безопасности. Взломщик или злонамеренный администратор могут легко изменить объекты групповой политики, чтобы, например:
- Разрешить неограниченное количество попыток угадать пароль учетной записи.
- Включить возможность подключения съемных носителей для упрощения кражи данных.
- Развернуть вредоносное ПО на всех машинах в домене.
- Заменить сайты, сохранённые в закладках браузеров пользователей, вредоносными URL-адресами.
- Запустить вредоносный сценарий при запуске или завершении работы компьютера.
Интересно, что хакерам даже не нужно много навыков, чтобы взломать объекты групповой политики. Все, что им нужно сделать, это получить данные учетной записи, имеющую необходимые права для нужного объекта групповой политики. Есть инструмент с открытым исходным кодом BloodHound (прямо как известная группа, только без Gang), который предоставит им список этих учетных записей. Несколько целевых фишинговых атак и хакер контролирует объект групповой политики. Политика домена по умолчанию (Default Domain Policy) и политика контроллеров домена по умолчанию (Default Domain Controllers Policy) — наиболее популярные цели, т.к. они создаются автоматически для каждого домена и контролируют важные параметры.
Почему встроенные инструменты работы с GPO недостаточно удобны
К сожалению, встроенные инструменты не всегда позволяют в удобном формате поддерживать безопасность и контроль групповой политики. Изменения, внесенные в объекты групповой политики, по умолчанию вступают в силу, как только окно закрывается — отсутствует кнопка «Применить», которая могла бы дать администраторам шанс остановиться, одуматься и выявить ошибки, прежде чем организация подвергнется атаке.
Из-за того, что разрешения безопасности основаны на объектах групповой политики, любой администратор домена может изменять любой параметр безопасности объекта групповой политики. И даже параметры, которые должны препятствовать злонамеренным действиям этого человека. Например, администратор может отключить объект групповой политики, который отвечает за разрешение входа в систему на определенном сервере, на котором размещены конфиденциальные данные. Ну, а дальше скопировать часть или весь ценный контент на свой компьютер
и продать в даркнете
Но самое ужасное во всей этой истории с безопасностью GPO — изменения настроек не отслеживаются в собственных журналах безопасности, нет предупреждений, следовательно, невозможно отслеживать такие нарушения, даже если использовать SIEM-систему.
Как обезопасить GPO (объекты групповой политики)
Лучший способ минимизировать риск неправильной настройки объектов групповой политики — это создать многоуровневую структуру безопасности, которая дополняет собственные инструменты. Для надёжной защиты групповой политики нужны решения, которые позволят:
- Понять, кто и к каким объектам групповой политики имеет доступ.
- Внедрить воркфлоу с опцией согласования и разделением обязанностей для управления изменениями в GPO.
- Отслеживать, выполнять мониторинг и оповещать об изменениях в GPO.
- Предотвратить изменение наиболее важных настроек GPO.
- Быстро откатывать нежелательные изменения в GPO.
В интерфейсе можно выбрать избыточные или конфликтующие параметры групповой политики и объединить их в один объект групповой политики или создать новый.
Откат. Можно легко откатиться к предыдущим версиям объектов групповой политики и устранить негативные последствия.
Политики защищенных настроек. Определите список параметров, по которым проверяются разрешенные настройки для политик.
Управление объектами. В интерфейсе легко определить, кто отвечает за управление определенными политиками.
Подтверждение по электронной почте. Утверждать или отклонять запросы на изменение объекта групповой политики можно прямо из письма в почте.
Пользовательские шаблоны писем. Для определенных ролей шаблоны писем можно кастомизировать.
Синхронизация GPO. Доступна возможность синхронизации настроек между несколькими GPO.
Сравнение GPO. Обеспечьте целостность настроек GPO и снизьте риск нарушения политики.
А еще у нас есть:
Тема использования PowerShell для администрирования крайне актуальна, и на Хабре появляется все больше и больше статей на эту тему. Предыдущий перевод статьи Джеффри Хикса, который мы опубликовали в прошлую пятницу, вызвал волну интереса. И как тут не вспомнить замечательное выступление того же автора на TechEd North America 2012. Доклад, который Джеффри Хикс проводил вместе с Джереми Московицем (Jeremy Moskowitz), был посвящен анализу объектов групповых политик и формированию отчетов. Оригинальный материал (видео) здесь, мы же приводим крактко содержание + скрипты. В любом случае рекомендуем посмотреть само видео.
В фокусе доклада было два вопроса:
- Строит отчеты по групповым политикам
- Проводим анализ групповых политик
Подробности – под катом.
Используем PowerShell в связке с групповыми политиками
Чтобы использовать PowerShell при работе с групповыми политиками, нам необходимы:
- Собственно сам PowerShell v2.0 или выше
- Опционально: рекомендуется Microsoft Active Directory Provider
Последовательность наших действий:
- Импортируем модуль групповых политик (Import-module GroupPolicy)
- Получаем объект групповых политик с помощью PowerShell (Get a GPO PowerShell Object)
- Строим отчет на основе этого объекта
- Строим HTML/XML-отчеты по объектам групповых политик
- Парсим и осуществляем поиск в XML для целей анализа
- Осуществляем поиск с помощью Select-XML и Xpath
Строим отчеты по групповым политикам
Проблема №1. Необходимо получить информацию о том, что в настоящий момент происходит в групповых политиках
В данном случае вместо JeremyGPO выступает отображаемое имя (DisplayName) объекта групповых политик. Выводится такая табличка
Решение проблемы: создаем отчеты.
Например, перед нами стоит задача получить список всех объектов групповых, которые были изменены за последние 30 дней, отсортированные по убыванию (последние наверху) с тремя значениями (отображаемое имя, время изменения, описание). Полученную информацию необходимо экспортировать в .csv файл (GPOModReport.csv в данном примере). Как это выглядит в PowerShell:
Примеры дополнительных команд
Проблема №2. Слишком много GPO, которые не используются.
Задача: найти пустые GPOs
- Определить объекты групповых политик без настроек
- Ищем XML ExtensionData
Проблема №3.
Кто обращался к объекту групповой политики?
Имеются ли GPO, в которых половина политики деактивирована (“Are there any GPOs with ‘half’ the policy disabled?”)
Имеются ли GPO, в которых все политики деактивированы (“Are there any GPOs with ‘all’ the policy disabled?”)
Применяем фильтр по статусу GPO (GPOStatus). Каждому из трех вопросов выше соответствуют три команды:
Анализируем объекты групповых политик
Проблема №4. Обнаруживаем GPO без связей
Проблема 5. Объекты групповых политик с излишними настройками в реестре (“Extra Registry Settings”)
Находим излишние настройки в реестре
Еще раз обозначим, что мы привели в посте лишь сухой остаток того, что было продемонстрировано в докладе. Сам доклад можно посмотреть здесь.
Также для построения отчетов по групповым политикам вы можете воспользоваться нашей программой NetWrix Group Policy Change Reporter.
Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org, в прошлый раз я вам показал, как я делал досрочное погашение ипотеки Сбербанка, поделился свои жизненным опытом. Сегодня я хочу вас научить, как находить и диагностировать причины, по которым у вас может не применяться назначенная вами групповая политика к компьютеру или пользователю или целому организационному подразделению. Мы рассмотрим все этапы, через которые проходит происходит взаимодействие с GPO. Разберем утилиты, которыми должен владеть системный администратор в задачи которого входит создание и назначение политик. Уверен, что данный пост будет вам полезен и интересен.
За, что Active Directory от Microsoft получила такую популярность? Одним из ответов на данный вопрос, будет функционал групповой политики. Все администраторы, как и большинство современных людей, существа очень ленивые и любят, когда все централизованно управляется и по возможности автоматизированно. Именно объекты GPO, позволяют производить настройки десятков, сотен и тысяч компьютеров, из одного места и практически по всем направлениям, например добавление принтеров, скриптов входа, профилей WiFi и многое другое.
Очень частые ситуации, что системный администратор создал новую групповую политику, применил ее на нужный ему объект, но эффекта это не дало и нужно понять почему она не применилась и вот тут начинающие системные администраторы попадают в просак, не понимая, где и что нужно искать. Ниже мы с вами разберем алгоритм действий, который поможет вам найти причину и восстановить работу применения групповой политики на нужный объект.
К чему применяется групповая политика (GPO)
Первое, на что я хочу обратить внимание, это ответить, что делает групповая политика. Все мы прекрасно знаем, что операционная система Windows, это набор служб и ключей реестра. Все настройки, которые вы видите и меняете в графическом режиме, по сути меняют ключи реестра. Понимая, это сразу можно сделать вывод:
- что реестр есть как для объекта компьютер
- и реестр есть для объекта пользователь
Именно эту две сущности являются конечными объектами в политике GPO. В Active Directory объекты пользователей и компьютеров не лежат просто так, а располагаются в двух видах папок:
- Это контейнер – по сути простая папка, важно, что к ней нельзя применять объекты групповой политики.
- Второй тип, это организационные подразделения (OU) – это специальные папки для объединения объектов AD по принципам. Именно с OU связываются объекты групповой политики, для применения их к компьютерам и пользователям. Внешне контейнер отличается от организационной утилитой, тем что у OU, есть дополнительная лычка на значке, это показано на скриншоте.
Алгоритм устранения проблем с GPO
Предположим, что у меня есть групповая политика, которая применяется на организационное подразделение “Client Computers”. Политика называется “Управление UIPI”. По какой-то причине пользователь жалуется, что она у него не применилась.
Из информации, об области действия групповой политики, первое на что нужно обратить свое внимание, это находится ли объект пользователя или компьютера по нужному пути. Сделать, это просто в оснастке “Управление групповой политикой” найдите вашу политику и посмотрите к каким OU она применяется, это видно на вкладке “Область (Scope)”, ее еще называют областью действия политики. В моем случае, это путь root.pyatilistnik.org/Client Computers.
Так как Active Directory, это иерархическая структура, то одна OU можете быть часть дерева из других и сама включать в себя большое количество организационных подразделений. Поэтому если у вас есть вложенность, то просто зайдя в нужную OU вы можете сразу не найти нужный объект. В таком случае воспользуйтесь поиском по Active Directory. Например у меня есть рабочая станция с которой идут жалобы на применение объекта GPO. В поиске выбираем в поле “Найти” компьютеры и в имени указываем w10-cl01, после чего нажимаем “Найти”. В результатах поиска вы получите выдачу. Щелкаем по нужному объекту и переходим в нем на вкладку “Объект”, где смотрим “Каноническое имя объекта”, по сути это его путь расположения в Active Directory. Сравниваем его с тем, что получили из области применения групповой политики и делаем вывод, попадает объект под действие или нет.
Далее убедитесь, что у вас элементарно включена связь объекта групповой политики с нужным организационным подразделением. Для этого в оснастке управления GPO, щелкните правым кликом по нужной политике и в контекстном меню проверьте, что установлена галка “Связь включена”, ее так же можно проверить на вкладке “Область” в столбце “Связь задействована”, должно стоять значение “да”.
Следующим моментом необходимо проверить, что политика не отключена на определенный объект. Для этого перейдите на вкладку “Сведения” на нужной GPO. Нас интересует строка “Состояние GPO”. По умолчанию там стоит значение “Включено”, означающее, что политика будет пытаться примениться заданные в ней настройки к обоим типам объектов (Пользователю и компьютеру). Но может быть выставлено значение:
- Параметры конфигурации компьютера отключены (Computer configuration settings disabled)
- Все параметры отключены (All setting disabled) – запретит применение политики для любого объекта
Сделано, это для ускорения применения политики к объекты. Согласитесь, что если у вас в GPO настроены изменения только для пользователя, то нет смысла проверять политику для компьютера. Поэтому системные администраторы могут отключать это, но могут и ошибиться, выключив не тот объект
Выше я вам писал, что структура OU иерархическая, а это означает, что политика прилинкованная с вышестоящего организационного подразделения применяется на нижестоящее. Но вот если у нижестоящей OU отключено наследование сверху, то он не сможет применить данную политику. Проверяется очень просто, найдите нужную вам OU, щелкните по ней правым кликом и удостоверьтесь, что не стоит пункт “Блокировать наследование”.
Он кстати будет иметь характерный значок с восклицательным знаком. Данный механизм создан специально, чтобы изолировать данную OU от ненужных политик GPO.
Проверка прав на политику
Объекты групповой политики, так же имеют свой ACL (лист доступа), это означает, что вы можете более тонко настраивать к каким объектам применяется данная политика. В редакторе “Управление групповой политикой” выберите ваш GPO. На вкладке “Область” найдите раздел “Фильтры безопасности”, он отображает к каким объектам применяется политика. Данный фильтр безопасности может включать объекты:
- Пользователь
- Компьютер
- Группа безопасности
Если у вас тут выставлена другая группа или отдельные записи, то убедитесь, что нужный объект состоит в данном ACL. Хочу отметить, что если даже нужный объект присутствует в списке фильтра безопасности, то это не означает, что политика к нему применяется и тут дело все в том, что в 2014 году Microsoft изменила принцип чтения политики, таким образом, что у вас в делегированном фильтре безопасности обязательно должна присутствовать группа “Компьютеры домена” или “Прошедшие проверку” у которой должны быть прав на чтение политики. Вся соль в том, что когда вы удаляете группу “Прошедшие проверку” из фильтра безопасности, она удаляется и из вкладки делегирование.
Чтобы параметры групповой политики для пользователя успешно применялись, она требует наличия у каждой учетной записи компьютера разрешения на считывание данных GPO из контроллера домена. Удаление группы “Прошедшие проверку” может предотвратить обработку групповых политик для пользователя. добавьте группу безопасности “Пользователи, прошедшие проверку подлинности” или “Компьютеры домена”, у которой есть по крайней мере разрешение только для чтения (https://support.microsoft.com/en-us/kb/316622)
Поэтому перейдите на вкладку “Делегирование” и проверьте наличие любой из групп “Прошедшие проверку” или “Компьютеры домена” и, что есть права на чтение. Если групп нет, то добавьте любую из них. Для этого нажмите кнопку “Дополнительно”, далее добавить и выберите “Прошедшие проверку”.
Удостоверьтесь, что выставлена галка “Чтение”.
Тут же убедитесь, что нет запретов на нужный вам объект, в моем примере, это W10-CL03. Если есть снимите.
Обратите внимание на группу “КОНТРОЛЛЕРЫ ДОМЕНА ПРЕДПРИЯТИЯ (Enterprise Domain Controllers)” данная группа определяет, будет ли происходить репликация данной политики на другие контроллеры или нет, так что если политика отсутствует в папке SYSVOL на других контроллерах, то проверьте права у данной группы.
Еще одним механизмом фильтрации групповой политики, может выступать WMI фильтры. Если они есть и ваш объект не соответствует его требованиям, то вы не сможете применить политику. Посмотреть, это можно в соответствующем разделе. В моем примере есть WMI фильтр для ноутбуков, который не даст применения политики на стационарные компьютеры. Подробнее, о создании WMI фильтров и механизме проверки WMI фильтров, читайте по ссылкам. Ниже я покажу, как на конечном компьютере увидеть, что он не подошел из-за фильтрации GPO по WMI.
Инструменты диагностики групповой политики
Выше мы разобрали возможные места, где могла быть проблема, но по мимо них еще есть несколько инструментов, которые могут дать системному администратору информацию, о причинах, которые мешают применению GPO к нужному объекту.
Существуют три инструмента, которые вам покажут информацию, о применяемых политиках на объекты:
- Утилита командной строки gpresult
- Утилита rsop
- Моделирование групповой политики в оснастке gpmc.msc
- Результаты групповой политики
Диагностика GPO через gpresult
Gpresult первое средство, которое позволит системному администратору определить на каком этапе есть проблемы с выполнением GPO. Откройте на клиентском компьютере или ноутбуке командную строку от имени администратора и введите команду:
В моем примере у меня есть политика для компьютера “Управление UIPI”, поэтому я воспользуюсь gpresult для компьютера. Выполнив gpresult /r /scope:computer я вижу, что моя политика не применилась и числится в списке “Следующие политики GPO не были применены, так как они отфильтрованы”. Фильтрация отказано в доступе (Безопасность). Из этого видно, что у компьютера просто нет прав на чтение политики.
Так же в логах Windows вы можете обнаружить событие с кодом ID 5313:
Код 5313: Следующие объекты групповой политики не были применены, так как они были отфильтрованы:
Local Group Policy Не применяется (пусто) Управление UIPI Отказано (безопасность)
А вот пример 5313, но с уже WMI фильтром:
Local Group Policy Не применяется (пусто) Управление UIPI Отказано (фильтр WMI)
Я для исключаю его из запрета применения и пробую новую попытку применения политики. Я делаю для начала обновление групповой политики через gpupdate /force и затем снова выполняю команду gpresult /r /scope:computer, где теперь вижу, что политика не применилась из-за WMI фильтра. Теперь уже понятно куда копать.
Получение данных GPResult с удаленного компьютера GPResult /s server01 /r, поможет администратору или технической поддержке собрать диагностические данные. Аналогичные действия вы можете выполнять и для пользователя, тут все аналогично. Теперь воспользуемся утилитой RSOP. Откройте окно выполнить и введите rsop.msc.
Начнется сбор применяемых политик.
По результатам, у вас откроется окно результирующей политики. Похожее на то, где вы редактируете политику GPO. Тут вы можете перемещаться по веткам и смотреть текущие значения.
Но это не удобно и мы можем совместить две утилиты gpresult и Resultant Set of Policies (RSoP), получив выгодный симбиоз. В командной строке введите:
GPResult /h c:
eport.html /f
На выходе вы получите удобный html отчет, о всех примененных или отфильтрованных политиках. Открыв отчет, вы легко поймете ,какие политики были применены, а какие нет и можете сразу посмотреть значения настроек.
Результаты групповой политики
В оснастке GPMC есть возможность посмотреть какие политики применяются к нужному объекту групповой политики. Данный мастер называется “Результат моделирования групповой политики”. Щелкаем по нему правым кликом и открываем мастер.
Выбираем нужный компьютер, к которому мы хотим проверить применение политики.
Если в момент добавления компьютера у вас выскочит ошибка “Сервер RPC-недоступен”, то проверьте, что у вас запущена на нем служба WMI и в брандмауэре открыты порты для подключения к ней.
Так как я проверяю GPO для компьютера, то мне нет смысла отображать политику для пользователей.
Нажимаем далее. У вас появится отчет. Раскрыв его на вкладке “Сведения” вы увидите, какие политики применены, а какие нет.
Раскрыв подробнее политику, которая не смогла примениться, я вижу, что причиной всему был WMI фильтр.
Последним удобным инструментом диагностики и моделирования групповой политики, выступает функционал GPMC, под названием “Моделирование групповой политики”. В задачи которого входит проверка применения политики в существующей ситуации, так и просто тест без реальной прилинковки к OU, указав нужный объект. В оснастке GPMC выберите пункт “Моделирование групповой политикой” и щелкните по нему правым кликом, выбрав “Мастер моделирования групповой политики”.
На первом шаге мастера моделирования групповой политики, будет простое уведомление, что к чему, нажимаем далее.
Далее вам будет предложен выбор, дабы указать нужный контроллер домена.
Теперь выбираем нужную OU, для которой мы будем тестировать групповую политику. Делается все через кнопку “Обзор”. Я выбрал “Client Computers”
На следующем шаге мастера моделирования групповой политики, вам предоставят сэмулировать таки параметры:
- Медленное сетевое подключение, меньше 500 кб/с
- Обработка петлевого адреса (Замыкание групповой политики – loopbacl policy) – это опция когда вы применяете для OU в которой находятся компьютеры, например терминальные сервера, политики для пользователя. Делается это для того, чтобы политики применяемые к пользователю на его рабочей станции или другом сервере от тех, что в данной OU. Можете подробно почитать, что такое замыкание групповой политики.
- Выбор сайта.
Указываем в какой группе находится наш объект, к которому будет применяться политика.
далее вы можете применить любой из фильтров WMI, который вы хотите тестировать.
В итоге мы получаем результат моделирования групповой политики, тут можно посмотреть, что применилось, что нет.
На этом у меня все. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org. Надеюсь, что статья оказалась полезной.
Постановка задачи
Предположим, что вы сделали новую групповую политику и к какому-то пользовательскому компьютеру она не применилась, перед тем, как искать причину обработки GPO, вам нужно вычислить дату последнего обновления. В статье нам нужно изучить методы и инструменты, которые позволят это сделать.
Методы определения времени применения групповых политик
- Утилита Gpresult
- PowerShell
- Утилита GP Time
- Rsop
- Реестр Windows
Как выяснить время обновления GPO через командную строку
Самый просто способ, это использование всем известной утилиты командной строки под названием Gpresult. Открываем cmd и вводим команду:
При необходимости gpresult может вывести информацию, только по пользователю или компьютеру, для этого есть ключ /scope:
или более детально отфильтровать через findstr
Как выяснить время обновления GPO через RSOP
RSoP (Resultant Set of Policy) – это отчет обо всех параметрах групповой политики в Active Directory, который показывает, как эти параметры могут влиять на сеть или как существующие объекты групповой политики (GPO) влияют на различные комбинации пользователей и компьютеров, когда локальная политика безопасности прилетели.
Чтобы запустить RSOP вы можете воспользоваться множеством методов, я бы выделил через командную строку или через окно выполнить. В командной строке просто введите:
В результате у вас будет произведен сбор сводных данных
Тоже самое через окно “Выполнить” в котором нужно вписать rsop.msc.
В результате вы получите отчет результирующей политики, тут вы увидите так же два раздела. Один для компьютера, второй для пользователя. Щелкните правым кликом по нужному разделу и выберите из контекстного меню пункт “Свойства”.
В окне свойств перейдите на вкладку “Сведения об ошибке” и найдите пункт “Инфраструктура групповой политики”, в области сведений вы увидите время обновления групповой политики.
Как выяснить время обновления GPO через PowerShell
Естественно у Microsoft есть отдельные командлеты, который позволяет вычислить время применения GPO, называется они Get-GPResultantSetOfPolicy и Get-GPOReport. Чтобы ими воспользоваться на клиентской системе, такой как Windows 10, вам необходимо установить RSAT пакет и импортировать модуль GroupPolicy. в противном случае вы будите получать ошибку:
Чтобы иметь возможность использовать эти командлеты, установите пакет RSAT, в операционных системах Windows Server, это не нужно. Далее установите модуль GroupPolicy, через команду:
Install-WindowsFeature –Name GPMC
После его установки введите команду для просмотра доступных модулей:
Get-Command -Module GroupPolicy
В итоге я вижу:
Чтобы вычислить время последнего обновления групповых политик через командлет Get-GPResultantSetOfPolicy, выполните команду:
Get-GPResultantSetOfPolicy -ReportType HTML -Path “c:
eport.html”
Где -ReportType, это вид конечного файла, может быть и xml, -Path, это путь до конечного файла, подробнее можно почитать на https://docs.microsoft.com/en-us/powershell/module/grouppolicy/get-gpresultantsetofpolicy?view=win10-ps.
В результате вы получите отчет в виде html файла, который легко открывается через браузер. В самом верху отчета вы увидите сводку по времени последнего обновления политики для пользователя и компьютера.
Так же Get-GPResultantSetOfPolicy может получать данные и с удаленного компьютера, для этого нужно добавить ключ -Computer, в итоге команда примет вот такой вид:
Get-GPResultantSetOfPolicy -Computer dc01 -ReportType HTML -Path “c:
eport.html”
Как выяснить время обновления GPO через реестр Windows
Логично предположить, что gpresult, rsopm powershell получают все значения из реестра Windows и я вам покажу, где располагаются данные ветки. Для начала давайте посмотрим для компьютера. Для этого откройте реестр Windows и перейдите в раздел:
тут вы обнаружите 6 ключей:
- EndTimeHi
- EndTimeLo
- LoggingStatus
- StartTimeHi
- StartTimeLo
- Status
Как вы можете обратить, эти данные для вас не особо читаемы, так как имеют шестнадцатиричное значение, но вы можете воспользоваться моим скриптом, который легко, это поправить.
Вы можете воспользоваться готовым скриптом по определению времени обработки политик, слева ссылка на его скачивание, а ниже его тест:
На выходе я вижу 19 ноября 2019 г. 17:25:51.
Узнаем время обновления GPO через gptime
gptime.exe – это удобная небольшая утилита предназначена для быстрого и краткого отчета о том, когда в последний раз компьютер и пользовательская групповая политика запускались в локальной или удаленной системе. Если в систему вошли более одного пользователя, инструмент сообщит о времени обработки GP для всех найденных пользователей.
Этот инструмент предоставляет время запуска и остановки для последнего цикла обработки, а также общее истекшее время, что может быть полезно. Вам необходим Для работы требуется .Net Framework 2.0, установленный на компьютере, на котором вы запускаете эту утилиту.
В командной строке перейдите в каталог с gptime.exe и запустите ее. В моем примере видно, когда были обновлены политики для компьютера, а так же для всех пользователей, чьи профили были обнаружены на компьютере.
Удаленное определение времени применения GPO
Я вам уже неоднократно рассказывал про утилиты Марка Руссиновича PSTools, а конкретнее PsExec. Утилита при наличии административных прав на целевом компьютере может запускать командную строку или оболочку PowerShell из которой уже легко делать, то что нужно. Открываем командную строку, переходим в папку с утилитой PsExec. Подключаться я буду с контроллера домена dc01 к удаленному серверу SVT2019S01. Для начала через команды hostname и whoami я виду исходные данные и, что cmd запущенна именно на исходном сервере.
PsExec64.exe \svt2019s01.root.pyatilistnik.org -u rootАдминистратор
\svt2019s01.root.pyatilistnik.org это имя моего сервера
Еще получить данные с удаленного компьютера, вы можете через командлет PowerShell Enter-PSSession. Для этого введите команду:
Enter-PSSession -ComputerName svt2019s01
далее подключившись к серверу вы все так же выполняете gpresult /R.
На этом мои методы закончились, я допускаю, что существует еще огромное количество утилит, но мне достаточно и этих. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.
Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов по системному администрированию Pyatilistnik.org. В прошлый раз мы с вами научились отключать защитник Windows 8.1, у каждого была своя причина произвести данное действие. Сегодня я хочу вас научить очень полезной вещи, без которой системный администратор управляющий групповой политикой не сможет активно и гибко ее применять. И речь пойдет про применение фильтров на разных этапах применения групповой политики к компьютерам и пользователям.
Для чего нужен механизм фильтрации GPO
Какую бы вы сложную иерархию Active Directory не создавали у вас рано или поздно появится ситуация, что вам нужно для двух и более объектов находящихся в одном OU иметь разные настройки, а для кого-то вообще запретить применение определенной групповой политики, но перемещать объект нельзя, так как в текущей иерархии он получает все настройки по корпоративному стандарту, и усложнять структуру не представляется возможным.
Лично я стараюсь не создавать лишних организационных подразделений, так как, чем проще система, тем проще ею управлять. У вас может быть вообще одна OU и все навалено в ней, но это вам не мешает грамотно применять политики к конкретным объектам, благодаря фильтрации на разных этапах GPO.
Виды фильтрации групповых политик
- Это фильтр безопасности
- Это фильтр WMI
- Это фильтр на вкладке делегирование
- Это фильтр на вкладке сведения
Фильтр безопасности GPO
Данный метод метод ограничения применений групповой политикой самый очевидный и используемый. Тут логика простая, что если вы хотите применить групповую политику, только к определенным объектам:
- Пользователям
- Компьютерам
- Группам
Теперь нам необходимо удалить группу по умолчанию “Прошедшие проверку”, напоминаю, что в нее входят все компьютеры и пользователи домена.
Вам сделают подсказку, о том что удаление группы “Пользователи, прошедшие проверку подлинности” может предотвратить обработку групповых политик.Ниже я расскажу, что это значит
В итоге мы видим в фильтрах безопасности одну нашу группу. Пробуем зайти на компьютер, где она должна отработать.
В начале 2016 года я столкнулся с тем, что моя политика не отработала, хотя все фильтры безопасности были настроены правильно. Открыв вывод команды gpresult/ r, я обнаружил статус (Unknown reason).
Начав разбираться, все пришло к тому, что новые обновления Microsoft (KB3159398, KB3163017, KB3163018) закрывал одну нехорошую вещь, которая длилась с 2000 года. Проблема заключалась в том, что злоумышленник мог применять атаку “Человек посередине (Man in the Middle)”, тем самым делать подмену ответа от контроллера домена на целевом компьютере, это выливалось в то, что он подделывал политику безопасности, которая давала ему права локального администратора для скомпрометированной учетной записи.
Microsoft долго билась с этой проблемой и пришла к решению поменять порядок считывания политики, теперь это могут делать только компьютеры домена. Раньше политики пользователя считывал пользователь, политики компьютера, компьютер. Установив KB3163622 теперь для считывания GPO используется только компьютер и если он не входит в фильтр безопасности политики, то она не применится (Подробнее можете посмотреть вот тут https://support.microsoft.com/en-us/help/3163622/ms16-072-security-update-for-group-policy-june-14-2016).
Исходя из данной ситуации, чтобы политики успешно применялись Microsoft предложило добавлять одну из групп безопасности в ACL политики “Прошедшие проверку” или “Все компьютеры”. Переходим к ACL.
Фильтрация GPO через ACL (Запрет GPO)
Уровень прав оставляем “Чтение”, этого будет достаточно.
Пробуем проверить применение нашей политики. В качестве испытуемого у меня идет виртуальная машина с Windows 10. После загрузки, я открываю командную строку и смотрю применение политики, для этого пишем команду:
В итоге я вижу, что среди примененных объектов групповой политики, моя “Настройка MaxTokenSize” в списке присутствует.
Если бы пользователь не был членом группы, которая фигурирует с фильтре безопасности, то мы видели бы вот такую картину, что следующие политики GPO не были применены, так как они отфильтрованы по причине отказано (Безопасность). Как видим нет прав на чтение.
Еще вкладку “Делегирования” используют и для запрещения, простой пример вы сделали политику которая для всех пользователей домена применяет корпоративные обои на рабочий стол. Допустим, что вам для администраторов домена или для круга избранных нужно сделать так, чтобы к ним не применялась политика. Вы создаете группу и уже ей запрещаете чтение данной политики, хоть пользователи и будут по прежнему входить в группу “Прошедшие проверку”, но прочитать они ее не смогут так как явный запрет для другой группы куда они входят, гораздо сильнее и приоритетнее чем права чтения.
Добавляем группу для которой хотим запретить применение политики, у меня это Forbidden MaxTokenSize.
Далее даем права “Чтение”.
Далее нажимаем кнопку “Дополнительно”, у вас откроется окно параметром безопасности. Тут вы выбираете нужную вам группу, для которой вы хотите запретить применение групповой политики и ставите галку “Запретить”. В таком случае данная группа будет получать при попытке считать GPO “Отказано (безопасность)”.
Фильтрация GPO по WMI
Еще одним действенным методом фильтровать получателей групповой политики, это использование WMI фильтров. Мы с вами их уже применяли, когда нужно было применить политику только к ноутбукам.
Простой пример вы создали политику и хотели бы ее применить скажем только на компьютеры у кого установлена операционная система Windows 7. Для нашей задачи нам необходимо создать WMI фильтр, для этого перейдем в “Фильтры WMI”, где выбираем соответствующий пункт.
Задаем имя WMI фильтра, после чего нажимаем кнопку “Добавить”. Откроется окно для составления запроса. Конструкция для Windows 7 будет такая:
SELECT * FROM Win32_OperatingSystem WHERE Version LIKE “6.1%” AND ProductType = “1”
Номера для Win32_OperatingSystem
- Windows Server 2019Windows 10 1809 – 10.0.17763
- Window Server 2016Windows 10 — 10.0
- Window Server 2012 R2Windows 8.1 — 6.3
- Window Server 2012Windows 8 — 6.2
- Window Server 2008 R2Windows 7 — 6.1
Тип продукта отвечает за назначение компьютера и может иметь 3 значения:
- 1 — рабочая станция;
- 2 — контроллер домена;
- 3 — сервер.
Вот вам пример вывода в PowerShell команды показывающей версию операционной системы:
Можете кстати еще посмотреть полезные WMI фильтры
Сохраняем наш WMI запрос.
Если хотите перед внедрение проверить будет ли применена групповая политика к нужному объекту, то можете провести тестирование в WMI Filter Validation Utility. Если все настроено корректно, но политика не применяется, почитайте по ссылке возможные варианты. Далее берем вашу политику и применяем к ней WMI.
Теперь если компьютер не соответствует критериям WMI фильтра, то вы увидите в gpresult /r /scope:computer вот такую запись (Отказано фильтр WMI)
Фильтрация через состояние GPO
Еще на вкладке “Сведения” есть такая настройка, как состояние GPO. Она необходима для ускорения обработки политики, путем отключения лишних веток. Например у вас политика исключительно на пользователя и вам смысла нет, чтобы компьютер при загрузке пытался прочитать настройки для компьютера, тратя на это время. В таких случаях отключают данный функционал. Тут есть варианты:
- Включено
- Все параметры отключены
- Параметры конфигурации компьютера отключены
- Параметры конфигурации пользователя отключены
На этом у меня все. Мы с вами разобрали все методы и механизмы фильтрации групповых политик, теперь вы готовы к любому сценарию. С вами был Иван Семин .автор и создатель IT портала Pyatilistnik.org.
Диагностика результирующих групповых политик
Утилита GPResult.exe – представляет собой консольное приложение, предназначенное для анализа настроек и диагностики групповых политик, которые применяются к компьютеру и/или пользователю в домене Active Directory. В частности, GPResult позволяет получить данные результирующего набора политик (Resultant Set of Policy, RSOP), список примененных доменных политик (GPO), их настройки и детальную информацию об ошибках их обработки. Утилита входит в состав ОС Windows начиная со времен Windows XP. Утилита GPResult позволяет ответить на такие вопросы: применяется ли конкретная политика к компьютеру, какая именно GPO изменила ту или иную настройку Windows, разобраться с причинами долгого применения GPP/GPO.
В этой статье мы рассмотрим особенности использования команды GPResult для диагностирования работы и отладки применения групповых политик в домене Active Directory.
Изначально для диагностики применения групповых политик в Windows использовалась графическая консоль RSOP.msc, которая позволяла получить настройки результирующих политик (доменных + локальных), примененные к компьютеру и пользователю в графическом виде аналогичном консоли редактора GPO (ниже на примере представления консоли RSOP.msc видно, что настройки обновлений заданы политикой WSUS_SERVERS).
Однако, консоль RSOP.msc в современных версиях Windows использовать нецелесообразно, т.к. она не отражает настройки, примененные различными расширениями групповых политик (client side extensions — CSE), например GPP (Group Policy Preferences), не позволяет выполнять поиск, предоставляет мало диагностической информации. Поэтому на данный момент именно команда GPResult является основным средством диагностики применения GPO в Windows (в Windows 10 даже появляется предупреждение, что RSOP не дает полный отчет в отличие от GPResult).
