Структура компонентов групповой политики. Часть 2Источник: oszoneru Дмитрий Буланов
Продолжение. Начало см. здесь. Архитектура результирующей групповой политикиМногие из вас уже не раз пользовались возможностями результирующей групповой политики (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 фильтр, который может применяться к целевому объекту во время генерирования отчета результирующей политики; Членство в группах безопасности объектов компьютеров и пользователей, определяющее реальные группы безопасности, членами которых являются целевой пользователь или компьютер. Помимо всего указанного выше, следует также обратить внимание на то, что для успешного генерирования отчета результирующей групповой политики, должны быть соблюдены следующие обязательные условия:
Принципы работы результирующей политики в режиме журналирования и планирования отображены на следующей иллюстрации: Увеличить рисунок Рис. 1. Схема работы результирующей групповой политики в режимах журналирования и планирования Исходя из предоставленной выше иллюстрации, режим журналирования результирующей групповой политики работает следующим образом:
В свою очередь, при выполнении результирующей групповой политики в режиме планирования, поставщик результирующего набора политики выполняет следующие действия:
Расширения клиентской стороны 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, предоставленными в следующей таблице:
Продолжение следует. |