«Под капотом» групповой политики

Введение

Меня часто спрашивают, как работает групповая политика. Это не всегда с точки зрения редактирования объекта групповой политики, установки флажков для политик и того, что делает каждый параметр политики, а скорее того, насколько интеллектуальна групповая политика, чтобы перейти от процесса загрузки к контроллеру домена и найти правильные объекты групповой политики. Ну, об этом вся статья. Мы проверяем «под капотом», чтобы увидеть, как работает механизм групповой политики. Когда вы закончите читать эту статью, у вас должно быть гораздо лучшее понимание того, как и когда групповая политика работает и не работает. Это отличный урок по устранению труднодоступных проблем групповой политики!

Первоначально компьютер загружается

В нашем примере мы будем обсуждать рабочий стол для вашей инфраструктуры Active Directory.

Ваш рабочий стол Windows загружается и должен получить IP-адрес. Если IP-адрес настроен статически, IP-адрес, настроенный для DNS, «ДОЛЖЕН» быть DNS-сервером, который поддерживает саму Active Directory. Если IP-адрес является динамическим, DHCP-сервер должен иметь всю правильную информацию об IP-адресе, включая IP-адрес DNS-сервера, поддерживающего Active Directory.

На этом этапе ваш рабочий стол настроен с правильной информацией об IP-адресе, которая как минимум будет включать:

• IP-адрес для рабочего стола
  
• Маска подсети
  
• IP-адрес DNS-сервера для Active Directory

Разговор с DNS

Теперь, когда рабочий стол имеет IP-адрес для DNS, он будет использовать службу NETLOGON для связи с DNS-сервером, чтобы узнать список IP-адресов для всех контроллеров домена для домена, к которому принадлежит рабочий стол. Контроллеры домена перечислены в базе данных DNS в записях SRV (локатор ресурсов службы). Эти записи вводятся динамически при обновлении контроллера домена с сервера до контроллера домена для этого домена. (Если используется DNS, который не поддерживает динамические обновления, его нужно будет вводить вручную!)

Однако список контроллеров домена не является произвольным, он несколько усложнен. Список контроллеров домена будет контролироваться сайтом Active Directory, на котором расположен рабочий стол. Сайты контролируются подсетями IP-адресов, настроенными администратором предприятия после настройки Active Directory. Первоначальный список контроллеров домена, возвращенный из DNS, будет теми контроллерами домена, которые находятся на сайте настольных компьютеров. После этого списка контроллеров домена будет список всех остальных контроллеров домена в домене.

Для получения более подробной информации об этой части процесса перейдите по этой ссылке.

Взаимодействие с контроллером домена

Теперь, когда получен список контроллеров домена, рабочий стол будет связываться с контроллером домена для аутентификации. Это взаимодействие происходит по защищенному каналу между рабочим столом и контроллером домена. Связь происходит через общие папки, доступные на контроллере домена. Это общие ресурсы SYSVOL и NETLOGON. SYSVOL — это C:WindowsSYSVOLsysvol, а netlogon — это C:WindowsSYSVOLsysvol<имя домена>SCRIPTS.

Объекты групповой политики хранятся в общей папке SYSVOL, а сценарии входа — в общей папке NETLOGON. Именно через это общение и общий ресурс доставляются настройки в GPO.

Определение объектов групповой политики

Поскольку на данном этапе мы говорим только о входе в систему компьютера (настольного компьютера), важны только те объекты групповой политики, которые относятся к части конфигурации компьютера всех объектов групповой политики. Контроллер домена определит, какие объекты групповой политики следует применить к рабочему столу, исходя из расположения учетной записи компьютера рабочего стола в Active Directory. Он также определяет, к какому сайту принадлежит рабочий стол, поэтому объекты групповой политики, связанные с этим сайтом, также доставляются на рабочий стол. Части Active Directory, имеющие значение для того, где находится рабочий стол, включают:

• Домен
  
• Сайт
  
• Организационная единица

Все объекты групповой политики, связанные с доменом, сайтом и подразделением, в котором находится учетная запись настольного компьютера, будут доставлены на рабочий стол. (Конечно, есть и другие факторы, влияющие на этот список объектов групповой политики. Фильтрация безопасности, фильтрация WMI, вложенные подразделения и т. д.)

Отслеживание объектов групповой политики на рабочем столе

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

HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionGroup PolicyHistory

Этот список можно увидеть на рисунке 1.

Рисунок 1: Список объектов групповой политики, связанных с рабочим столом, хранящихся в реестре

Обратите внимание, что в списке объектов групповой политики используется GUID объекта групповой политики, а не понятное имя объекта групповой политики. Это распространено, поскольку операционная система и Active Directory не заботятся об имени объекта групповой политики, а только о GUID.

Теперь пользователь входит в систему

Совершенно очевидно, что рабочий стол уже получил все настройки объекта групповой политики, связанные с конфигурацией компьютера объекта групповой политики, исключительно потому, что он загрузился. Однако это только половина картины. Теперь пользователь должен войти в систему и получить часть объекта групповой политики «Конфигурация пользователя», которая применяется к тому месту, где учетная запись пользователя находится в Active Directory.

Поскольку информация об IP-адресе, связь, связанная с DNS, и подключение к контроллеру домена уже установлены, эта часть картины завершена. Важно то, где находится пользователь в Active Directory, чтобы можно было применить правильные объекты групповой политики. Когда объекты групповой политики применяются к учетной записи пользователя, их хранилище аналогично хранению компьютера, но они хранятся в части реестра HKEY_Current_User по адресу:

HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionGroup PolicyHistory

На рис. 2 показано, как выглядит этот список.

Рисунок 2: Объекты групповой политики, сохраненные пользователем в реестре

Обновление групповой политики

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

Для клиента этот номер версии хранится в реестре под номером HistoryGUID, как показано на рисунках 1 и 2. На рисунке 3 показано, как будет выглядеть номер версии для одного из перечисленных GUID GPO.

Рис. 3. Номер версии объекта групповой политики, указанный в реестре рабочего стола.

Контроллер домена хранит номер версии в GPT.ini под GUID для объекта групповой политики в SYSVOL. Он также сохраняет номер версии в базе данных Active Directory вместе с объектом для объекта групповой политики. Это гарантирует синхронизацию баз данных SYSVOL и AD с правильной версией и данными, хранящимися в объекте групповой политики.

Резюме

Обработка групповой политики довольно сложна и состоит из множества движущихся частей. В этом обсуждении обсуждаются только некоторые аспекты высокого уровня, тогда как скрытых аспектов гораздо больше. Однако это должно дать любому администратору хорошее представление о том, что важно в процессе входа в систему как компьютера, так и пользователя, а также где может произойти сбой обработки групповой политики. При таком большом количестве движущихся частей важно отслеживать все ключевые конфигурации при устранении неполадок с объектами групповой политики. DNS, записи SRV, SYSVOL, идентификаторы GUID, фильтрация безопасности, фильтры WMI, расположение объектов в AD и т. д. В любой момент можно изменить нужные параметры групповой политики, если параметры и расположение неверны.