Структура компонентов групповой политики. Часть 2

Продолжение. Начало см. здесь.

Архитектура результирующей групповой политики

Многие из вас уже не раз пользовались возможностями результирующей групповой политики (RSoP) и знают о том, что данная возможность обеспечивает удаленный метод определения применения объектов групповой политики к пользователю или компьютеру с учетом блокирования наследования, всех связей, включая принудительные, а также фильтры безопасности и фильтрации WMI. Также, ни для кого не окажется секретом, что результирующая политика может работать в двух режимах: режиме журналирования (также называемым режимом протоколирования или входа) и режиме планирования. Режим журналирования позволяет вам работать с отчетом по результатам применения параметров групповой политики к существующему пользователю или компьютеру. Этот режим доступен для любой операционной системы Windows, начиная с Windows XP. В свою очередь, режим планирования позволяет имитировать результаты политики, основываясь на анализе «что-если», которые могут быть применены в будущем к конкретному пользователю или компьютеру на основании указанных вами переменных. Данный режим целесообразно применять в том случае, если планируете переместить пользователя или компьютер между сайтами, доменами или подразделениями, а также в том случае, если у пользователя будет изменена группа безопасности, под область которой попадает целевой объект Active Directory. Оба режима результирующей политики интерпретируются при помощи оснастки «Управление групповой политики», причем, режим журналирования реализуется при помощи результатов групповой политики, а режим планирования – средствами моделирования групповой политики.

Для того чтобы определить параметры групповой политики, распространяемые на целевого пользователя или компьютер, результирующая политика во время своей работы использует инструментарий управления Windows (WMI). Поставщик WMI позволяет создавать отчеты по заданным в мастере результирующей политики параметрам, а также определяет, когда именно выполнялась обработка объекта групповой политики, какие параметры были применены, какие ошибки возникли в процессе применение и так далее. Для выполнения сбора информации, как на контроллере домена, так и на клиентском компьютере должна быть запущена служба «Инструментарий управления Windows» (Winmgmt.exe), при помощи которой информация иерархии WMI моделируется как иерархия стандартов объектов общей модели данных (Common Information Model, CIM). Такая иерархия является расширением, позволяющим разным службам и приложениям предоставлять поставщику WMI информацию о конфигурации. Вся информация, которая собирается поставщиком, сохраняется в базе данных WMI на локальном компьютере, также известном, как база данных CIMOM. Так как сгенерированные поставщиком WMI данные могут быть динамическими и статическими, а, в свою очередь, статические данные хранятся в базе CIMOM для того, чтобы они могли быть извлечены в любое время, при выполнении запросов результирующей политики генерируются статические данные WMI. При помощи запросов результирующей групповой политики в базу данных WMI на контроллере домена сохраняется информация о политиках целевого компьютера, после чего вся эта информация отображается в оснастке «Управление групповой политикой». Также при обработке результирующей политики стоит обратить внимание на работу поставщика результирующего набора политики. Работу поставщика результирующего набора групповой политики можно проанализировать на примере режима планирования результирующей политики. В этом режиме, для генерации отчета результирующей политики даже не нужно присутствие в сети самого клиентского компьютера, так как информация рассчитывается на основании существующих объектов групповой политики, которые будут применяться к текущему объекту. В этом случае, на контроллере домена, поставщик результирующего набора политики выполняет определенные функции клиентской операционной системы, требуемые для применения объектов GPO. Данный поставщик при обработке режима планирования результирующей групповой политики использует три следующих параметра:

Область управления (Scope of management, SOM), которая является сочетанием объектов пользователя и компьютера;

WMI фильтр, который может применяться к целевому объекту во время генерирования отчета результирующей политики;

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

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

• На целевом компьютере должна быть установлена операционная система не ниже Windows XP;
• У учетной записи, которая генерирует отчет RSoP на конечном компьютере, должны быть привилегии администратора;
• На обоих компьютерах должна быть запущена служба «Инструментарий управления Windows»;
• Для того чтобы иметь доступ к WMI, на конечном компьютере должны быть открыты порты 135 и 445;
• В том случае, если генерируется отчет RSoP для определенного пользователя, этот пользователь должен как минимум один раз выполнить вход в домен под своей учетной записью.

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

Увеличить рисунок

Рис. 1. Схема работы результирующей групповой политики в режимах журналирования и планирования

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

1. Во время выполнения пользователем входа в домен, процесс Gpsvc при использовании контекста безопасности пользователя или компьютера получает список объектов групповой политики из домена Active Directory, которые распространяются на этот объект;
2. Процесс Gpsvc последовательно сохраняет в базу данных WMI экземпляры расширений клиентской стороны объектов групповой политики;
3. Список зарегистрированных расширений групповой политики извлекается из базы данных и на конечный компьютер выводится подробный отчет в динамическом формате HTML, после чего в самой консоли отображается динамическое содержимое отчета результирующей групповой политики.

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

1. При помощи мастера утилита результирующей групповой политики, RSoP моделирует применение политики с помощью службы групповой политики доступа к каталогу (GPDAS) и извлекает из контроллера домена имя пользователя или компьютера и подключается к базе данных WMI;
2. Служба WMI на том же компьютере, на котором генерируется отчет результирующей политики вызывает поставщика WMI, а затем получает список объектов групповой политики, которые распространяются на определенного пользователя или компьютер в Active Directory;
3. База данных WMI заполняется экземплярами объектов групповой политики для определенного пользователя или компьютера;
4. После чего извлекается список зарегистрированных расширений клиентской стороны, где каждое расширение загружается последовательно. После того как данные были занесены в базу данных, поставщик результирующего набора групповой политики возвращает список имен и передает их инструменту результирующей политики;
5. Результирующая политика подключается к пространству имен базы данных WMI на контроллере домена и при помощи API интерфейса WMI получает данные о групповой политике. На конечный компьютер выводится подробный отчет в динамическом формате HTML, после чего в самой консоли отображается динамическое содержимое отчета результирующей групповой политики.

Расширения клиентской стороны CSE

Как вы уже поняли из всего вышеизложенного, каждая группа параметров групповой политики обслуживается определенным расширением клиентской стороны (Client-side Extension, CSE), установленном и зарегистрированном в процессе установки операционной системы Windows. По сути, расширений клиентской стороны можно разделить на логические категории, соответствующие определенным узлам, расположенным в дереве консоли оснастки «Редактор управления групповой политикой». Сами расширения CSE состоят из динамически подключаемых библиотек, вызываемых при помощи модуля групповой политики, который для определения параметров групповой политики, применяемых к целевому компьютеру или пользователю, использует информацию шаблона групповой политики из контейнера групповой политики. Соответственно, расширения клиентской стороны применяются на целевой компьютер только в том случае, если изменены соответствующие параметры групповой политики. Физически, все библиотеки DLL, отвечающие за расширения клиентской стороны можно найти в папке %windir%\System32, однако, если какое-то определенное расширение CSE было написано сторонним производителем, оно может храниться в расположении отличном от расположения CSE по умолчанию. Несмотря на то, что большинство параметров групповой политики применяются так, чтобы ни пользователь, ни администратор клиентского компьютера не могли изменить соответствующий системный параметр при помощи графического интерфейса, некоторые параметры, управляемые расширениями CSE все-таки можно изменить. Стоит обратить внимание на то, что все библиотеки DLL для каждого расширения клиентской стороны регистрируются в операционной системе и просмотреть список расширений CSE можно при помощи редактора системного реестра в разделе HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions.

Как вы уже, наверное, догадались, судя по информации из раздела, посвященного контейнеру групповой политики, к каждому расширению клиентской стороны привязывается идентификатор GUID, включающий в себя набор определенных атрибутов, позволяющих указать разные параметры конфигурации обработки групповой политики. В контейнере GPC вы могли увидеть эти идентификаторы в атрибутах gPCMachineExtensionNames и gPCUserExtensionNames. Находясь в разделе идентификатора GUID определенного расширения CSE, вы можете с легкостью узнать имя библиотеки DLL, отвечающей за текущее расширение клиентской стороны, посмотрев на значение параметра Dllname. Все расширения клиентской стороны, созданные при установке операционной системы, связаны с идентификаторами GUID, предоставленными в следующей таблице:

Продолжение следует.