Создание сценария групповой политики

В очередной статье из цикла «конспект админа» мне хотелось бы освежить в памяти несколько нюансов использования групповых политик. Заодно поразвлекаемся с созданием своих шаблонов и с автоматизацией работы с этими самыми политиками.

Освежаем память

Я не буду рассказывать, что такое групповые политики, и остановлюсь лишь на основных моментах, которые стоит иметь в виду при работе с ними.

В системах Windows помимо доменных существуют и локальные групповые политики ― управлять ими можно при помощи оснастки gpedit.msc на системах редакции Professional и выше. Часто считается, что без домена можно настраивать локальные групповые политики только для всех пользователей на компьютере. Это не совсем верно ― с выходом Windows Vista появилась возможность использовать множественную локальную групповую политику или MLGPO. Этот механизм позволяет настраивать отдельные политики для разных пользователей.

Добраться до него можно через вызов консоли mmc: при добавлении оснастки «Управление объектами групповой политики» нажать кнопку «Обзор». Далее на вкладке «Пользователи» уже можно выбрать конкретного пользователя или группу «Администраторы» и «Не администраторы». К сожалению, управление для группы пользователей не реализовано.

Управление групповой политикой для отдельных пользователей.

Бывало и так, что на отдельностоящем терминальном сервере разворачивали Active Directory только для того, чтобы отдельному пользователю настроить поведение драйвера для EasyPrint. Не надо так.

При добавлении доменных групповых политик стоит помнить про порядок их применения ― политика, примененная последней, будет обладать наивысшим приоритетом (да и на собеседованиях часто спрашивают).

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

Локальная групповая политика.
Групповая политика сайта.
Групповая политика домена.
Групповая политика верхнего подразделения.
Групповая политика дочернего подразделения.

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

Блокировка наследования.

Любую групповую политику можно условно разделить на две конфигурации ― пользователя и компьютера. Обычно политики с настройками компьютеров назначаются на подразделение, в котором находятся компьютеры. А политики с настройками пользователей ― на пользователей.

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

Работа замыкания настраивается непосредственно в политике ― «Настройка компьютера ― Административные шаблоны ― Система ― Режим обработки замыкания пользовательской групповой политики». Подробнее про механизм уже писали в статье про использование MergeReplace в GPO. Я лишь добавлю, что режим замыкания групповой политики ― тоже частый вопрос на собеседовании.

Настройка замыкания групповой политики.

Физически доменные групповые политики находятся в папке SYSVOL на контроллерах домена. Папка реплицируется между контроллерами. Каждая групповая политика выглядит как папка с именем в виде GUID.

Групповые политики домена.

Правила фильтрации, настраиваемые через редактор групповой политики, соответствуют настройкам прав NTFS на соответствующую подпапку.

Говоря о правилах фильтрации, нельзя не упомянуть обновление MS16-072, которое «сломало» групповые политики. Теперь для того чтобы работали правила фильтрации, надо добавлять к каждому фильтру правило «на чтение», но не «на применение» группе Domain Computers.

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

В корне папки находится файл GPT.ini с настройками групповой политики, такими как ее название.
В подпапках Machine и User сидят файлы registry.pol с настройками соответствующих веток реестра.
По пути MicrosoftWindows NTSecEdit можно найти шаблон настроек безопасности ― GptTmpl.inf.
В подпапке Preferences находятся предпочтения групповых политик, представляющие из себя подпапки с файлами xml.
В подпапке Applications сидят дистрибутивы для развертывания через групповые политики.
В папке Scripts находятся скрипты на logonlogoff для пользователя и startupshutdown для компьютера.
В папке Documents and Settings есть настройки перенаправления пользовательских папок.
Наконец, в папке Adm находятся устаревшие шаблоны групповой политики.

Подробнее про структуру можно почитать в материале Group Policy Basics, поэтому перейдем сразу к шаблонам.

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

По сути своей административные шаблоны ― это специальные файлы с инструкциями по изменению клиентского реестра (ветки HKCU или HKLM) и настройками отображения изменяемых параметров через «Управление групповой политикой». В принципе, реестр можно менять и через «Предпочтения групповых политик». Но разница здесь не только в красивом интерфейсе.

Способ изменения реестра	Как ведет себя при удалении политики со стандартными настройками	Можно ли изменить параметр вручную	Можно ли изменить параметр через приложение
Шаблоны	Параметр реестра восстанавливается на значение «по умолчанию», если настройки по умолчанию есть в шаблоне	—	—
Предпочтения политик	Параметр реестра не изменяется	+	+

Сравнение предпочтения групповых политик и административных шаблонов.

Другими словами, настройка реестра через шаблоны групповых политик более строгая. Тогда как настройка через предпочтения групповых политик напоминает периодическое применение reg-файла. Конечно, предпочтения позволяют не только менять параметры реестра, но и довольно гибко настраиваются. Тем и ценны.

Это актуально при изменении ветки Policies, и настраиваемое приложение должно хранить свои настройки в реестре. Простое изменение параметров через Предпочтения и Шаблоны будет работать схожим образом, только шаблоны могут оказаться удобнее.

До появления Windows Vista2008 в качестве шаблона групповых политик брали исключительно стандарт .adm. Будучи с простой структурой, которую было легко редактировать вручную, этот стандарт обладал и рядом недостатков:

Для каждого языка приходилось создавать отдельный файл шаблона.
Файл шаблона физически находился в папке с групповой политикой. При использовании одного и того же шаблона он сохранялся в каждую папку, что увеличивало занимаемое место и время репликации.
Не поддерживались мультистроковые параметры и параметры QWORD.

На замену устаревшему стандарту появился новый. Новые шаблоны представляют собой два файла: сам шаблон, не зависимый от языка ― .admx и языковой «пакет» к нему ― файл .adml. Теперь шаблоны можно «положить» в центральное хранилище, и обращаться к нему, не плодя одинаковые файлы в папке SYSVOL.

Не обошлось без ложки дегтя ― теперь содержимое файла представляет собой популярный в индустрии формат XML. И создавать новые шаблоны в блокноте стало уже не так удобно.

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

MS Office 2016.
FireFox и Thunderbird.
Google Chrome.
Adobe Acrobat и Reader.
Каталог шаблонов для различного ПО.

Если возникает необходимость разработать и внедрить свой административный шаблон, то самый простой вариант ― это создать старый файл .adm и сконвертировать его в admx специальной утилитой. Вариант посложнее ― начинать сразу с .admx.

Создаем свой шаблон

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

Сразу скажу, что это можно провернуть через «Предпочтения групповых политик» ― в параметрах панели управления ― опции папки. Но мы легких путей не ищем и заодно не хотим, чтобы параметры отображения можно было менять вручную.

За необходимые нам параметры отвечают три ключа в реестре:

SoftwareMicrosoftWindowsCurrentVersionExplorerAdvancedHidden.
SoftwareMicrosoftWindowsCurrentVersionExplorerAdvancedHideFileExt.
SoftwareMicrosoftWindowsCurrentVersionExplorerAdvancedShowSuperHidden.

Содержимое ADM-шаблона, который разберем далее, под спойлером.

CLASS USER
CATEGORY !!ShowExplorer
    POLICY !!ShowHiddenFiles
        KEYNAME "SoftwareMicrosoftWindowsCurrentVersionExplorerAdvanced"
        EXPLAIN !!ShowHiddenFilesExplanation
        VALUENAME "Hidden"
        VALUEON NUMERIC "1"
        VALUEOFF NUMERIC "2"
    END POLICY

    POLICY !!ShowFileExtensions
        KEYNAME "SoftwareMicrosoftWindowsCurrentVersionExplorerAdvanced"
        EXPLAIN !!ShowFileExtensionsExplanation
        VALUENAME "HideFileExt"
        VALUEON NUMERIC "0"
        VALUEOFF NUMERIC "1"
    END POLICY

    POLICY !!ShowSuperHiddenFiles
        KEYNAME "SoftwareMicrosoftWindowsCurrentVersionExplorerAdvanced"
        EXPLAIN !!ShowSuperHiddenFilesExplanation
        VALUENAME "ShowSuperHidden"
        VALUEON NUMERIC "1"
        VALUEOFF NUMERIC "0"
    END POLICY
END CATEGORY

[strings]
ShowExplorer="Отображение файлов в проводнике"
ShowHiddenFiles="Показывать скрытые файлы"
ShowHiddenFilesExplanation="Когда эта настройка включена, проводник будет показывать скрытые файлы."
ShowSuperHiddenFiles="Показывать системные файлы"
ShowSuperHiddenFilesExplanation="Когда эта настройка включена, проводник будет показывать системные файлы"
ShowFileExtensions="Показывать расширения файлов"
ShowFileExtensionsExplanation="Когда эта настройка включена, проводник будет показывать расширения файлов"

Разберем подробнее синтаксис файла.

CLASS. Может принимать значение USER или MACHINE ― в зависимости от класса будет изменятся ветка реестра HKCU или HKLM соответственно.
CATEGORY. Строка, в которой задается имя «папки» политики.
POLICY. В строке задается название конкретной политики ― у нас таких будет три.
KEYNAME. Путь в реестре к изменяемым параметрам.
EXPLAIN. Отсылка к «переменной» с объяснением настройки.
VALUENAME. Название изменяемого параметра в реестре.
VALUEON**VALUEOFF**. Значение, которое будет принимать параметр при включении и выключении его в политике.
[strings]. Секция со значениями переменных, которые я использовал для текстовых строк. Можно их не использовать, но тогда могут быть проблемы из-за русского языка.

Помимо задействованных опций есть и другие, например:

EDITTEXT. Текстовое поле для ввода.
NUMERIC. Поле для ввода цифр.
CHECKBOX. Список, где можно отмечать параметры «галочками».
COMBOBOX. Список с «переключателем»
DROPDOWNLIST. Выпадающий список.
LISTBOX. Список для ввода нескольких элементов.

Подробнее со всеми параметрами можно ознакомится в разделе MSDN ADM Format.

Установить новый шаблон не просто, а очень просто ― достаточно щелкнуть правой кнопкой мыши по пункту «Административные шаблоны», выбрать «Добавление и удаление шаблонов» и добавить наш свежесозданный шаблон.

Добавленный шаблон.

После установки шаблона он отобразится в ветке «Классические административные шаблоны».

Теперь можно сконвертировать наш шаблон в .admx с помощью утилиты faAdmxConv из ADMX Migrator.

Конвертируем шаблон.

После конвертации получившийся шаблон .admx и папку Ru-ru с файлом локализации .adml нужно скопировать в папку %Systemroot%PolicyDefinitions для локальной политики или в папку SysvolPolicyDefinitions на контроллере домена.

Установленный шаблон .admx.

Полный листинг получившегося шаблона и файла локализации под спойлером.

Шаблон:

<?xml version="1.0" encoding="utf-8"?>
<policyDefinitions revision="1.0" schemaVersion="1.0">
  <policyNamespaces>
    <target prefix="fullarmor" namespace="FullArmor.6fb075d6-ddee-4302-9d06-50c4d83e1910" />
    <using prefix="windows" namespace="Microsoft.Policies.Windows" />
  </policyNamespaces>
  <supersededAdm fileName="E:1explorer.adm" />
  <resources minRequiredRevision="1.0" />
  <supportedOn>
    <definitions>
      <definition name="SUPPORTED_NotSpecified" displayName="$(string.ADMXMigrator_NoSupportedOn)" />
    </definitions>
  </supportedOn>
  <categories>
    <category name="ShowExplorer" displayName="$(string.ShowExplorer)" />
  </categories>
  <policies>
    <policy name="ShowHiddenFiles" class="User" displayName="$(string.ShowHiddenFiles)" explainText="$(string.ShowHiddenFilesExplanation)" presentation="$(presentation.ShowHiddenFiles)" key="SoftwareMicrosoftWindowsCurrentVersionExplorerAdvanced" valueName="Hidden">
      <parentCategory ref="ShowExplorer" />
      <supportedOn ref="SUPPORTED_NotSpecified" />
      <enabledValue>
        <decimal value="1" />
      </enabledValue>
      <disabledValue>
        <decimal value="2" />
      </disabledValue>
    </policy>
    <policy name="ShowFileExtensions" class="User" displayName="$(string.ShowFileExtensions)" explainText="$(string.ShowFileExtensionsExplanation)" presentation="$(presentation.ShowFileExtensions)" key="SoftwareMicrosoftWindowsCurrentVersionExplorerAdvanced" valueName="HideFileExt">
      <parentCategory ref="ShowExplorer" />
      <supportedOn ref="SUPPORTED_NotSpecified" />
      <enabledValue>
        <decimal value="0" />
      </enabledValue>
      <disabledValue>
        <decimal value="1" />
      </disabledValue>
    </policy>
    <policy name="ShowSuperHiddenFiles" class="User" displayName="$(string.ShowSuperHiddenFiles)" explainText="$(string.ShowSuperHiddenFilesExplanation)" presentation="$(presentation.ShowSuperHiddenFiles)" key="SoftwareMicrosoftWindowsCurrentVersionExplorerAdvanced" valueName="ShowSuperHidden">
      <parentCategory ref="ShowExplorer" />
      <supportedOn ref="SUPPORTED_NotSpecified" />
      <enabledValue>
        <decimal value="1" />
      </enabledValue>
      <disabledValue>
        <decimal value="0" />
      </disabledValue>
    </policy>
  </policies>
</policyDefinitions>

Файл локализации:

<?xml version="1.0" encoding="utf-8"?>
<policyDefinitionResources revision="1.0" schemaVersion="1.0">
  <displayName></displayName>
  <description></description>
  <resources>
    <stringTable>
      <string id="ShowExplorer">Отображение файлов в проводнике</string>
      <string id="ShowHiddenFiles">Показывать скрытые файлы</string>
      <string id="ShowHiddenFilesExplanation">Когда эта настройка включена, проводник будет показывать скрытые файлы.</string>
      <string id="ShowSuperHiddenFiles">Показывать системные файлы</string>
      <string id="ShowSuperHiddenFilesExplanation">Когда эта настройка включена, проводник будет показывать системные файлы</string>
      <string id="ShowFileExtensions">Показывать расширения файлов</string>
      <string id="ShowFileExtensionsExplanation">Когда эта настройка включена, проводник будет показывать расширения файлов</string>
      <string id="ADMXMigrator_UnresolvedString">ADMX Migrator encountered a string that is not present in the source ADM string table.</string>
      <string id="ADMXMigrator_NoSupportedOn">ADMX Migrator encountered a policy that does not have a supportedOn value.</string>
    </stringTable>
    <presentationTable>
      <presentation id="ShowHiddenFiles" />
      <presentation id="ShowFileExtensions" />
      <presentation id="ShowSuperHiddenFiles" />
    </presentationTable>
  </resources>
</policyDefinitionResources>

Действительно, xml в новом формате читается чуть хуже, чем старый .adm. Для облегчения работы с новым форматом в поставке ADMX Migrator есть утилита faAdmxEditor.msc. Помимо этой утилиты есть и скрипты для конвертации reg-файлов в шаблоны, и сторонние платные утилиты.

Конечно же, можно обойтись без вот-этого-всего и разобраться самостоятельно ― оставлю это в качестве домашнего задания. Благо на портале MSDN есть подробное описание XML-схемы, и есть неплохие материалы с примерами в сети. Например, «Административные шаблоны групповой политики».

Теперь перейдем к автоматизации.

Автоматическое управление

Работать с групповыми политиками из командной строки довольно тоскливо. Основных инструментов можно выделить три.

PowerShell. Есть набор командлетов для резервного копирования, восстановления и управления групповыми политиками. Создание новых политик ограничено ― можно лишь изменять реестр. Впрочем, в большинстве случаев и этого достаточно. В качестве примера создадим групповую политику, которая отключит автоматическое обновление Adobe Reader DC.

За отключение автоматического обновления отвечает ключ реестра bUpdater в ветке [HKEY_LOCAL_MACHINESOFTWAREPoliciesAdobeAcrobat ReaderDCFeatureLockDown]. Установив параметр в 0, мы отключим опцию.

Создание групповой политики на PowerShell будет выглядеть так:

Import-module -Name GroupPolicy
Write-Host "Создаем новый объект политики с именем Adobe_Reader_disable_autoupdate"
New-GPO -Name Adobe_Reader_disable_autoupdate
Write-Host "Добавляем нужное нам значение реестра"
Set-GPRegistryValue -Name "Adobe_Reader_disable_autoupdate" -key "HKLMSOFTWAREPoliciesAdobeAcrobat ReaderDCFeatureLockDown" -ValueName  bUpdater -TypeDWord -value 0
Write-Host "Прилинковываем новый объект к нужному OU"
Set-GPLink -Name Adobe_Reader_disable_autoupdate -Target "ou=Computers,dc=domain,dc=com" -LinkEnabled Yes

Свежесозданная групповая политика.

Полный список и описание командлетов доступны в материале Technet Group Policy Cmdlets in Windows PowerShell.

Интерфейс COM к GPMC (консоли управления групповой политикой). Способ позволяет сделать с политиками многое, на любом языке программирования, поддерживающим COM-интерфейсы. К сожалению, популярность он не приобрел и примеров в сети довольно мало, несмотря на богатое описание методов интерфейса на портале MSDN. Немногочисленные примеры использования доступны для загрузки в галерее Technet.

LGPO.exe. Не так давно Microsoft заменил набор утилит для работы с локальными групповыми политиками на единую утилиту. Скачать ее можно на официальном сайте. Утилита удобна для копирования и развертывания локальных групповых политик. Заявлена и поддержка MLGPO. Создавать свои политики тоже можно. Также программа удобна для создания и изменения файлов реестра registry.pol. Для примера изменим локальную групповую политику, добавив в нее отключение обновления несчастного Acrobat Reader DC.

Сделаем бэкап локальной групповой политики командой

lgpo.exe /b C:Temp /n "Backup"

В папке C:Temp появится подпапка с GUID по структуре схожая с доменными групповыми политиками:

Теперь развернем registry.pol в текстовый файл:

LGPO.exe /parse /m C:temp{GUID}DomainSysvolGPOMachineregistry.pol >> reg.txt

Синтаксис текстового файла очевиден. Добавим в него значения реестра для отключения автоматического обновления «Акробата»:

Добавленный в файл параметр реестра.

Теперь останется завернуть наш reg.txt обратно в registry.pol и импортировать изменившийся файл обратно в локальную групповую политику:

LGPO.exe /r C:Tempreg.txt /w C:Tempregistry.pol
LGPO.exe /m C:Tempregistry.pol

Все эти махинации, конечно же, можно завернуть в один скрипт и использовать для массового изменения локальной групповой политики привычным инструментом для запуска команд на удаленных компьютерах. Подробнее про методы запуска команд можно почитать в нашей статье «1000++ способ запуска команд на удаленном компьютере».

Конечно же, зная структуру доменной групповой политики, ничто не мешает сделать удобный именно вам инструмент для создания и управления политиками. Поделитесь в комментариях, есть ли у вас свои способы настройки реестров пользовательских машин?

Источник

Не так часто мне удавалось видеть рабочую конфигурацию «Сценария запуска для компьютера» и уж тем более не доводилось реализовать. Но вот возникла необходимость. И казалось-бы у Miscrosoft в редакторе GPO имеются для этого комфортные средства. Бери и делай! Но что-то пошло не так… и мои скрипты не захотели работать. Поэтому здесь я опишу то, с чем мне пришлось столкнуться в процессе решения такой задачи.

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

В Microsoft подразумевается, что свои скрипты вы будете размещать в папке, которая соответствует редактируемой политике. Но во-первых, это не всегда так, а во-вторых логично предположить, что права (хотя-бы на чтение) у компьютера, который будет обращаться к скрипту — имеются. Однако это тоже ложное мнение! Итак, первое, с чем мы определимся…

Выбор расположения скриптов и права доступа

Мои скрипты расположены не только в папке политики, которая их и будет выполнять.

Один скрипт у меня находится: \domen.localSysVoldomen.localPolicies{E4A966DE-1FFE-40C8-B3B2-50888E146A4D}MachineScriptsStartupMain.ps1

Второй скрипт вызывается из первого и у меня он находится: \domen.localNETLOGONzabbix_install.ps1

В случае первого скрипта необходимо: Открыть в редакторе GPO (нужной вам политики): Конфигурация компьютера — Политики — Конфигурация Windows — Сценарий (запуск/завершение) — выбрать Автозагрузка.

В открывшемся окне перейти на вкладку Сценарии PowerShell и нажать внизу кнопку: Показать файлы

Открывшаяся папка — то, что вам нужно. Сюда вы копируете свои скрипты, которые планируете выполнять этой политикой. И сразу проверяете права этой папки.

На вкладке Безопасность проверяем наличие прав доступа на чтение и выполнение — группе Domain Computers

Права для SYSTEM (Full) — как правило выставляются корректно изначально. Creator Owner — так же являются корректными.

Если права отсутствуют — добавляем их.

И это касается каждой папки, к которой планируется обращение от имени доменного компьютера!!!

Т.е. в моем случае — мне было необходимо дать такие права еще для папки \domen.localNETLOGON а так-же для шары, к которой обращается скрипт и пишет туда логи. \sharaLOG

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

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

Вы скопировали скрипт в папку используемой политики в этом-же окне жмете кнопку добавить и выбираете скрипт. Однако в окне скриптов (это видно на скрине выше) — пути к файлу нет. И это нормально. Я тестировал варианты: прописать путь до скрипта даже по сети, например: \sharaPSMain.ps1 и такое тоже выполнялось, если права на чтение папки компьютерами домена — присутствовало. Поэтому экспериментируйте.

По большому счету все. НО! По умолчанию, ваши PS скрипты не будут запускаться даже из сети, основываясь на безопасности GPO.

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

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

Изменение политики безопасности PowerShell — Выполнение сценариев

Находим нужную политику: Конфигурация Компьютера — Административные шаблоны — Компоненты Windows — Windows PowerShell и открываем политику: «Включить выполнение сценариев»

По умолчанию она выключена, а это значит, что выполнение скриптов ЗАПРЕЩЕНО!

Включая — нам становятся доступны опции политики выполнения и если вас не интересует подпись сертификатов — вы выбираете «Разрешить все сценарии«.

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

Для проверки текущей политики безопасности существует командлет:

Get-ExecutionPolicy

Restricted — блокируются любые скрипты.

AllSigned — разрешены только те, которые имеют цифровую подпись

RemoteSigned — скрипты, на локальном компьютере, можно запускать без ограничений. Скрипты, загруженные из интернета — только при наличии цифровой подписи.

Unrestricted — разрешены любые скрипты, но запуская неподписанный скрипт из интернета — программа может потребовать подтверждение.

Bypass — ничего не блокируется, никакие предупреждения и запросы не появляются.

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

powershell.exe -executionpolicy bypass -File C:scriptsbackup.ps1

Кстати запуск из cmd или bat — Это еще один наиболее простой запуск ps1 скрипта без заморочки на политику безопасности и подписании скриптов

Запуск скриптов в Windows Server 2012 R2 Windows 8.1 и выше

Это еще один подводный камень. По умолчанию, в версиях 2012 R2 и Windows 8.1 скрипты компьютера на запуск — имеют задержку на выполнение в 5 минут.

Чтобы это исправить необходимо скорректировать еще один пункт в политике безопасности.

На данный момент уровень моего домена и леса = 2012. Как и все контроллеры домена, под управлением Windows Server 2012. А в этих версиях отсутствует параметр управления этой задержкой. Поэтому первое, что необходимо сделать, это скачать административные шаблоны ADMX отсюда: http://www.microsoft.com/ru-ru/download/details.aspx?id=41193

Скачав файл Windows8.1-Server2012R2ADMX-RTM запустите его установку на одном из контроллеров домена. Путь по умолчанию будет: C:Program Files (x86)Microsoft Group PolicyWindows 8.1-Windows Server 2012 R2PolicyDefinitions Зайдите в эту папку и удалите лишние языковые директории. Я оставил лишь en-US и ru-RU т.к. имею в распоряжении русскую и английскую версию оснастки.

Теперь необходимо создать Централизованное хранилище политик. На контроллере домена скопировать папку PolicyDefinitions целиком из %systemroot% в папку %systemroot%sysvoldomainpolicies

Затем скопировать содержимое из папки C:Program Files (x86)Microsoft Group PolicyWindows 8.1-Windows Server 2012 R2PolicyDefinitions в папку %systemroot%sysvoldomainpoliciesPolicyDefinitions
В последствии эти шаблоны будут автоматически распространены и для других контроллеров домена. А вам необходимо только перезапустить оснастку редактора групповых политик.

Переходим к настройке: Конфигурация компьютера — Политики — Административные шаблоны — Групповая политика — Настроить задержку сценария входа

Включаем этот параметр и выставляем значением «0 мин». Таким образом мы полностью отключаем задержку сценария входа.

Теперь наши скрипты будут также успешно работать и в Windows 2012 R2 и Windows 8.1 при загрузке компьютера!

Продолжение:

GPO AD: Computer Startup scripts and Powershell (часть 2: Создание своего сертификата. Подпись скриптов)

GPO AD: Computer Startup scripts and Powershell (часть 3: PsExec. Ловим ошибки)

Также вы можете посмотреть мои обращения в Microsoft Technet, где мне успешно помогали решать эти задачи. За что коллегам отдельная благодарность!

Запуск f2.ps1 из f1.ps1 и вывод в лог.

Не срабатывает сценарий Logon в GPO для политики Компьютера

Источник

Наличие механизма групповых политик всегда являлась одной из главных отличительных черт Active Directory (AD), а в операционной системе Windows Server 2003 компания Microsoft существенно расширила функциональность объектов групповой политики (GPO) и возможность управления им, дополнив консоль MMC оснасткой Group Policy Management Console (GPMC). Компонент GPMC является довольно масштабным и достаточно сложным инструментом, поэтому для того, чтобы научиться максимально использовать все преимущества GPO в своей инфраструктуре необходимо хорошо разбираться в предмете. Чтобы получить базовые знания по GPMC, рекомендую вам прочитать статью Microsoft «Enterprise Management with the Group Policy Management Console» (http://www.microsoft.com/windowsserver2003/gpmc), а также познакомиться со справочником по GPMC Group Policy Management Console Reference на Web-сайте Microsoft http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gpmc/gpmc/group_policy_management_console_reference.asp. Отсюда же можно загрузить и саму эту оснастку.

С выходом Windows 2003 перед нами открылись новые возможности по использованию сценариев, в том числе и для автоматизации работы с GPMC. В результате теперь из сценариев можно обращаться к объектам GPO и решать типовые задачи администрирования, связанные с применением механизмов политик. Давайте познакомимся с основными операциями с GPO, которые можно автоматизировать в GPMC. К ним относятся включение и отключение GPO , связывание и отмена GPO для сайта, домена или организационного подразделения (OU), а также настройка других параметров политики.

Что такое GPO

Технология администрирования, построенная на основе политик, дает администратору возможность сначала детально настроить параметры рабочей среды для пользователей и компьютеров, а затем, в зависимости от системы, принудительно поддерживать данное состояние. В сетях Windows NT реализовать подобную среду с жестко заданными параметрами было довольно затруднительно, но с появлением AD и механизмов групповых политик процесс настройки параметров администрирования упростился, а сами возможности администрирования существенно расширились. Теперь администратор может разделять пользователей по категориям, основываясь на своей собственной классификации, в соответствии с ролями пользователей и выполняемыми ими работами. В результате, при каждом включении нового пользователя в ту или иную группу AD ему, в зависимости от его роли, автоматически будет назначена соответствующий набор параметров, а также установлено необходимое программное обеспечение. Каждый объект GPO может состоять из двух частей, одна из которых относится к компьютеру (например, сценарий регистрации или изменение системных разделов реестра), а другая — к пользователю (в частности, сценарий завершения сеанса или модификация пользовательских разделов реестра). В принципе объект GPO может содержать только пользовательские политики, только политики для компьютеров, либо сочетать в себе оба типа политик.

Процесс создания GPO является автономным. Затем, с помощью процесса, называемого связыванием (linking), он ассоциируется с одним или несколькими структурными компонентами дерева AD (ими могут быть отдельные компьютеры, сайты, домены или OU), к которым нужно применить данную политику. Для редактирования GPO обычно применяется оснастка Group Policy Object Editor, более известная как Group Policy Editor (GPE). Однако через Group Policy Object Editor в одном сеансе можно управлять не более чем одним GPO. Для преодоления этого ограничения компания Microsoft разработала компонент GPMC.

Имея в своем распоряжении GPMC можно через единственный интерфейс выполнять практически все действия с GPO (включая редактирование GPO с помощью Group Policy Object Editor) — в Windows 2000 для этого требовалось три или четыре инструментальных средства. При установке GPMC также создаются несколько специальных COM-объектов, наличие которых позволяет выполнять до 90 процентов работ по управлению GPO с помощью сценариев. При этом также развертывается каталог, в котором содержится большое количество готовых примеров сценариев, реализующих многие типичные задачи администрирования. Здесь следует упомянуть еще одну функциональность, которую мы долго ждали, а именно, возможность полученя результирующиго набора политик — Resultant Set of Policies (RSoP). RSoP позволяет моделировать и тестировать поведение GPO. Используя RSoP можно настраивать различные параметры. Например, можно указать, какой контейнер следует обрабатывать, какие должны быть задействованы группы безопасности, нужно ли использовать какой-либо сайт, задействовать ли режим петли (loopback mode) и нужно ли применять фильтр Windows Management Instrumentation (WMI). В конечном итоге при работе с RSoP будет получен тот же результат, что и при использовании Group Policy Object Editor — вы сможете в масштабах всего дерева увидеть те настройки, которые будут применены к клиентам через данный GPO.

С помощью GPMC можно управлять как доменами Windows 2003, так и доменами Windows 2000. Но при этом сама консоль GPMC должна запускаться только на компьютерах с установленной Windows 2003 или Windows XP Professional Edition Service Pack 2 (SP1 или SP2), на которых также должны быть установлены Windows .NET Framework. В принципе эта программа может быть установлена на компьютер, не являющийся членом домена, но такой подход практически не применяется, поскольку установка GPMC на компьютер, входящий в состав домена обеспечивает более эффективное использование данного инструмента.

Работа с GPMC через сценарии

Когда мы будем рассматривать примеры конкретных сценариев, помните о том, что хотя объекты GPMC и позволяют выполнять из сценариев те операции, которые при использовании GPMC являются потенциально опасными, однако они не позволяют создавать GPO из сценариев. Для того чтобы создавать объекты GPO необходимо использовать Group Policy Object Editor, но не GPMC. При создании GPO его компоненты, относящиеся к пользователям и компьютерам, по умолчанию включены, и вы можете использовать GPMC для того чтобы отключить любой из них или оба сразу. Сценарий DisableAll.vbs, приведенный в Листинге 1, является простым примером того, как можно отключить оба этих компонента GPO в масштабах домена. В начале сценария вызывается функция VBScript CreateObject, посредством которой создается объект автоматизации GPMC. Данный объект ссылается на переменную gpm. Далее с помощью метода IGPM::GetDomain выполняется обработка для домена mydomain.mycorp.com.

Метод IGPM::GetDomain имеет три параметра. Первый из них определяет домен, второй параметр является дополнительным и позволяет задать имя требуемого контроллера домена (DC), а с помощью третьего параметра можно указать какой именно контролер домена используется: Windows 2003 или Windows 2000. В рассматриваемом примере второй параметр является пустым, а третий параметр имеет значение 0. Данная комбинация параметров предписывает сценарию подключиться к компьютеру, исполняющему роль мастера PDC. Вместо того чтобы жестко задавать в сценарии имя DC (который может оказаться недоступным при запуске сценария), предпочтительнее указать роль мастера PDC. При этом будет выполнена привязка к тому DC, который с наибольшей вероятностью доступен в любое время. В результате AD находит тот контроллер домена, который был выбран на роль эмулятора PDC (или тот DC, который был назначен администратором), таким образом выбирается один из компьютеров, реализующих роль мастера, чем обеспечивается эмуляция PDC для поддержки доменов NT предыдущих версий.

После того как сценарий выполнит операцию подключения к домену, вызывается метод IGPMDomain::GetGPO, который возвращает соответствующий объект GPO и его параметры. Для того чтобы идентифицировать требуемый GPO сценарий использует соответствующий данному объекту глобальный идентификатор GUID. Поскольку мы пытаемся автоматизировать процедуру отключения компонентов GPO, желательно знать, каким объектом мы собираемся манипулировать (вместо того чтобы внедрять в сценарий соответствующие процедуры поиска необходимого GUID). короче говоря, проблема состоит в том, чтобы выяснить, к какому именно GUID нужно обращаться. К счастью один из примеров сценариев, имеющихся в GPMC, а именно listallgpos.wsf, позволяет получить имена и GUID всех объектов GPO в домене. Таким образом, после того как сценарий подключается к интересующему GPO, он обращается к свойству IGPMGPO::IsUserEnabled и определяет, активен ли пользовательский компонент данного объекта. Если да, то в этом случае для отключения данного компонента используется метод IGPMGPO::SetUserEnabled путем передачи значения FALSE. Затем аналогичным образом сценарий выполняет проверку и отключение компонента GPO, относящегося к компьютерам. Если требуется отключить только пользовательский или только компьютерный компонент GPO, то следует соответствующим образом отредактировать текст сценария Листинга 1. Также можно модифицировать сценарий для включения определенного компонента. Для этого можно отредактировать основные строки, например, так:

If Not gpmGPO.IsUserEnabled Then
gpmGPO.SetUserEnabled TRUE
End If

Связывание GPO со структурными компонентами дерева AD

Как отмечалось выше, GPO будет применяться только тогда, когда они привязаны к соответствующим локальным компьютерам, сайтам, доменам или OU. Для того чтобы привязать GPO к дереву AD, необходимо указать тот структурный компонент (location), которым мы собираемся управлять — в терминах GPMC это называют областью управления (scope of management (SOM)). Так как в Windows 2003 и Windows 2000 политики GPO применяются в соответствии с последовательностью их следования, то, при необходимости, можно привязывать GPO к SOM, учитывая порядок следования. Например, мы можем назначить GPO 4 позициям из 7. Затем, если по данной позиции уже существует связь с другим объектом GPO, данный метод устанавливает новую связь, размещая ее первой в списке, при этом существующая связь и все следующие за ней перемещаются в списке связей на одну строку вниз.

Допустим, нам нужно привязать какой-либо GPO к некоторому OU в домене, при этом и GPO, и OU нам известны. На Листинге 2 показан пример того, как можно привязать GPO к OU. Здесь, как и в примере Листинга 1, сценарий в начале получает описатели домена и GPO. Затем при помощи метода IGPMDomain::GetSOM находится объект SOM. Для того чтобы связать GPO с определенным OU, сценарий должен передать данному OU полностью полное имя домена (Fully Qualified Domain Name, FQDN). После того как сценарий выполнил подключение к необходимому SOM, можно привязать к этому SOM соответствующий объект GPO. Для этого используется метод IGPMSOM::CreateGPOLink. Первый параметр этого метода указывает в списке GPO позицию той политики, которая должна быть применена к данному SOM. Второй параметр представляет собой полученный ранее описатель GPO.

В примере Листинга 2 в качестве первого параметра метода используется значение -1, что указывает на то, что данный GPO должен быть добавлен в конец перечня GPO, используемого Windows 2003 и Windows 2000 для определения порядка применения политик. Учтите, что при добавлении GPO в определенную позицию списка следует быть аккуратным, поскольку если указанное число превышает количество строк в текущем списке GPO, то это приводит к сбою работы метода. Поэтому я рекомендую проверять количество элементов в списке. Для этого сначала используется метод IGPMSOM::GetGPOLink, возвращающий объект GPOLinksCollection, а затем, обратившись к свойству IGPMGPOLinksCollection::Count данного объекта, можно определить количество элементов в списке GPO.

Для того чтобы привязать GPO ко всему домену, а не к отдельному OU, используется вызов метода IGPMDomain::GetSOM с пустой строкой:

Set gpmSOM = gpmDomain.GetSOM ("")

Привязка политик к сайтам реализуется так же просто, как и в случае доменов. На Листинге 3 показан измененный вариант сценария Листинга 2, предназначенный для связывания GPO с сайтами. В данном сценарии, как и в примере Листинга 2, сначала находится описатель домена, для того чтобы можно было сформировать связь с заданным GPO. Однако далее, для получения доступа к значениям ключевых констант, сценарий использует совершенно новый интерфейс, называемый IGPM::GetConstants. В результате в сценарии не требуется использовать строки Const для объявления той или иной константы GPMC, поскольку мы можем получать эти константы динамически, в ходе выполнения сценария. Если в дальнейшем Microsoft решит изменить значения некоторых из этих констант, то использование метода IGPM::GetConstants гарантирует некоторую степень унификации для наших сценариев. После этого вызывается метод IGPM::GetSitesContainer, возвращающий описатель объекта GPMSitesContainer, что дает сценарию возможность установить соединение с конкретным сайтом. Данный метод имеет четыре параметра. Первый из них это полное имя DNS корневого домена леса, в котором находится интересующий нас сайт. В качестве второго параметра используется пустая строка, что указывает на то, что никакой конкретный домен не выбран. В результате сценарий будет использовать имя главного контроллера (PDC) корневого домена леса. Если необходимо указать какой-то конкретный домен, тогда следует использовать DNS-имя этого домена. В качестве третьего параметра также используется пустая строка, предписывающая методу использовать корневой PDC леса, вместо того, чтобы выполнять поиск NetBIOS- или DNS-имени заданного контроллера домена. В качестве четвертого параметра передается константа IGPMConstants::UseAnyDC, что предписывает сценарию использовать в качестве DC владельца роли мастера PDC. Если в третьем параметре указывается конкретный DC, тогда четвертому параметру следует присвоить значение 0. Далее сценарий находит описатель SOM для соответствующего сайта, для чего используется метод IGPMSitesContainer::GetSite. При этом методу передается единственный параметр — имя сайта. Последний шаг — привязка GPO к сайту — реализуется так же, как это делалось в сценарии в Листинге 2. Однако в данном случае эта процедура является несколько более затяжной, поскольку здесь выполняется подключение как к объекту GPMDomain для того чтобы получить описатель GPO, так и к объекту GPMSitesContainer для выполнения процедуры связывания.

Что дальше?

В данной статье мы коснулись лишь основ тех возможностей, которые открывает нам GPMC. В принципе, аналогичным образом можно автоматизировать большое количество процедур, связанных с манипуляциями с объектами GPO. Здесь мы рассмотрели сценарии, предназначенные для отключения GPO и привязки GPO к OU, доменам и сайтам, но помимо них в GPMC имеется значительное количество примеров сценариев для решения различных задач администрирования, которые могут послужить вам хорошей отправной точкой.

Листинг 1. DisableAll.vbs

Const GUID = "INSERT GPO GUID HERE"
Const DOMAIN = "mydomain.mycorp.com"
Dim gpm, gpmDomain, gpmGPO
Set gpm = CreateObject("GPMGMT.GPM")
Set gpmDomain = gpm.GetDomain (DOMAIN, "", 0)
Set gpmGPO = gpmDomain.GetGPO (GUID)
If gpmGPO.IsUserEnabled Then
	gpmGPO.SetUserEnabled FALSE
End If
If gpmGPO.IsComputerEnabled Then
	gpmGPO.SetComputerEnabled FALSE
End If

Листинг 2. LinkGPOToOU.vbs

Const GUID = "INSERT GPO GUID HERE"
Const DOMAIN = "mydomain.mycorp.com"
Const OU = "ou=Finance,dc=mydomain,dc=mycorp,dc=com"
Dim gpm, gpmDomain, gpmGPO, gpmSOM, gpmGPOLink
Set gpm = CreateObject("GPMGMT.GPM")
Set gpmDomain = gpm.GetDomain (DOMAIN, "", 0)
Set gpmGPO = gpmDomain.GetGPO (GUID)
Set gpmSOM = gpmDomain.GetSOM (OU)
Set gpmGPOLink = gpmSOM.CreateGPOLink(-1, gpmGPO)

Листинг 3. LinkGPOToSite.vbs

Const SITENAME = "Name-of-the-site-to-connect-to"
Const GUID = "INSERT GPO GUID HERE"
Const DOMAIN = "mydomain.mycorp.com"
Const FOREST_ROOT_DOMAIN = "mycorp.com"
Dim gpm, gpmDomain, gpmGPO, gpmConstants
Dim gpmSites, gpmSOM, gpmGPOLink
Set gpm = CreateObject("GPMGMT.GPM")
Set gpmDomain = gpm.GetDomain (DOMAIN, "", 0)
Set gpmGPO = gpmDomain.GetGPO (GUID)
Set gpmConstants = gpm.GetConstants
Set gpmSites = gpm.GetSitesContainer(FOREST_ROOT_DOMAIN,"","",gpmConstants.UseAnyDC)
Set gpmSOM = gpmSites.GetSite (SITENAME)
Set gpmGPOLink = gpmSOM.CreateGPOLink(-1, gpmGPO)

Источник

Шаблон:Нет ссылок
Шаблон:Переработать
Шаблон:Rq
Групповая политика — это набор правил или настроек, в соответствии с которыми производится настройка рабочей среды приёма/передачи (Windows, X-unix и другие операционные системы с поддержкой сети). Групповые политики создаются в домене и реплицируются в рамках домена. Объект групповой политики (Шаблон:Lang-en) состоит из двух физически раздельных составляющих: контейнера групповой политики (Шаблон:Lang-en) и шаблона групповой политики (Шаблон:Lang-en). Эти два компонента содержат в себе все данные о параметрах рабочей среды, которая включается в состав объекта групповой политики. Продуманное применение объектов GPO к объектам каталога Active Directory позволяет создавать эффективную и легко управляемую компьютерную рабочую среду на базе ОС Windows. Политики применяются сверху вниз по иерархии каталога Active Directory.

Создание групповых политик[]

По умолчанию в иерархии каталога Active Directory создаются две групповые политики: Default Domain Policy (политика домена по умолчанию) и Default Domain Controller’s Policy (политика контроллера домена по умолчанию). Первая из них назначается домену, а вторая — контейнеру, в состав которого входит контроллер домена. Если вы хотите создать свой собственный объект GPO, вы должны обладать необходимыми полномочиями. По умолчанию правом создания новых GPO обладают группы Enterprise Administrators (Администратор предприятия) и Domain Administrators (Администраторы домена).

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

Работая с групповыми политиками, следует учитывать, что:

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

Разрешение конфликта двух политик[]

Представьте, что некоторый параметр (например, logon banner — графическая заставка при подключении) определен как в политике Р3, так и в политике P1. При этом значение параметра, заданное в политике Р3, отличается от значения, заданного в политике Р1. Какое значение будет присвоено параметру в результате применения обеих этих политик? В подобной ситуации параметру объекта присваивается значение, извлеченное из GPO, который находится к объекту ближе всего. Таким образом, в рассмотренной ситуации параметру logon banner будет присвоено значение, извлеченное из политики Р1.

Наследование политик[]

Представьте, что политика Р3 содержит в себе значение параметра logon banner, в то время как политика Р1 не определяет этого параметра. В этом случае, если в отношении объекта применяются обе эти политики, рассматриваемому параметру объекта будет присвоено значение из политики Р3. Однако для контейнера SA не определено ни одной политики. Все же параметру logon banner этого контейнера будет присвоено значение из политики Р3. Мало того, в отношении этого контейнера будут в полной мере применены политики Р3 и Р1, так как контейнер SA унаследует эти политики от своих родителей.

Применение нескольких политик в отношении одного контейнера[]

Представьте, что политики Р4 и Р5, в которых определяются значения самых разнообразных параметров, применены в отношении контейнера Acct. В разделе конфигурации компьютера политики Р4 членам глобальной группы Accounting (бухгалтерия) разрешается локально подключаться к любому компьютеру в контейнере Acct, а также во всех подконтейнерах этого контейнера. А в разделе конфигурации компьютера политики Р5 права группе Accounting (бухгалтерия) не назначаются. В списке политик, отображаемом на странице Group Policy (Групповая политика) в окне свойств контроллера домена, политика Р5 располагается в самом верху списка — выше политики Р4.
Политики, указанные в этом списке, применяются к объекту в порядке снизу вверх. Другими словами, политики, расположенные внизу списка, применяются в первую очередь, после чего применяются политики, расположенные выше по списку. Таким образом, при обработке рассматриваемого набора политик в отношении контейнера Acct вначале будет применена политика Р4, а затем политика Р5. Следовательно, после обработки набора политик параметр прав на локальное подключение к системе будет содержать значение из политики Р5. Таким образом, члены глобальной группы Accounting (бухгалтерия) не будут обладать правом локального подключения к компьютерам контейнера Acct и его подконтейнеров. Чтобы изменить порядок обработки политик, следует воспользоваться кнопками Up (Вверх) и Down (Вниз) в правом нижнем углу вкладки Group Policy (Групповая политика).

Windows 2000 позволяет блокировать применение некоторых разделов объекта GPO. Если политика применяется в отношении контейнера не полностью, а только частично, общее время подключения пользователя к системе уменьшается. Чем меньшее количество параметров GPO следует применить в отношении того или иного объекта, тем быстрее выполняется обработка соответствующей политики. Отключение обработки некоторых разделов политики можно выполнить отдельно для каждого из объектов GPO. Для этого следует выполнить следующие действия:

Откройте оснастку Active Directory — Users and Computers (Active Directory — пользователи и компьютеры). Наведите указатель на интересующий вас контейнер, откройте окно свойств этого контейнера и перейдите на вкладку Group Policy (Групповая политика).
Выберите объект GPO, который вы намерены модифицировать.
Щелкните на кнопке Properties (Свойства).
Здесь вы можете блокировать применение в отношении контейнера параметров политики, относящихся к конфигурации компьютера или к конфигурации пользователя.
После того как вы указали, применение какого из разделов GPO должно быть блокировано, на экране появится сообщение о том, что значения параметров, модифицированных благодаря данной политике, будут восстановлены в изначальное состояние. Например, если блокировать применение параметров GPO, относящихся к конфигурации пользователя, то конфигурация всех пользователей, в отношении которых действует данная политика, будет восстановлена в состояние, в котором она была до применения данной политики. В отличие от Windows 2000, операционная система NT 4.0 выполняла очистку политик некорректно. В связи с этим в NT 4.0 даже после отмены политики параметры объектов сохраняли значения, присвоенные им в процессе применения отмененной политики.

Блокирование применения одного из разделов политики настраивается для конкретного объекта GPO и действует в отношении всех контейнеров, для которых назначен этот GPO.

Блокирование наследования политики[]

Windows 2000 позволяет блокировать наследование политики от родительского объекта. Например, если вы хотите, чтобы в отношении контейнера IT и всех его подконтейнеров действовали только политики, определенные на уровне IT, на странице Group Policy (Групповая политика) свойств объекта IT установите флажок Block Policy Inheritance (блокировать наследование политики). При этом политики Р1 и Р3 не будут применяться в отношении контейнеров IT Workstations и IT Servers. Блокирование наследования политик нельзя отключить для какой-либо одной политики. Если для какого-либо контейнера включено блокирование наследования политик, в отношении этого контейнера и всех его подконтейнеров перестают действовать абсолютно все политики, назначенные на более высоких уровнях иерархии каталога Active Directory.
Этот параметр может быть настроен отдельно для конкретного объекта GPO и действует в отношении всех контейнеров, для которых назначен этот GPO. Если для объекта GPO установлен флажок No Override (не отменять), значения параметров из соответствующей политики всегда будут обладать большим приоритетом при возникновении конфликтов политик вне зависимости от того, на каком уровне иерархии расположены контейнеры, к которым применяется данный GPO. Например, если вы откроете окно свойств домена shinyapple.msft и установите флажок No Override (не отменять) для политики Р1, объекты, расположенные ниже по иерархии Active Directory, всегда будут настроены в соответствии со значениями, заданными в политике Р1. При возникновении конфликта политик значениям из Р1 будет отдано предпочтение. Хорошим примером ситуации, в которой может потребоваться использование данной возможности, является применение параметров безопасности. Если для какого-либо контейнера включено блокирование наследования политик, политика, обладающая свойством No Override (не отменять), все равно будет применена, так как параметр No Override (не отменять) обладает большим приоритетом.

Фильтрация политик[]

Фильтрация применяемых политик на основе членства объектов в группах безопасности является ещё одним методом изменения обычного порядка применения политик в отношении объектов Active Directory. Фильтрация осуществляется при помощи списков ACL (Access Control List). Каждому объекту GPO ставится в соответствие список ACL. Информация из списка ACL объекта GPO анализируется системой безопасности вне зависимости от того, к какому из контейнеров применяется данный GPO. Политика применяется в отношении объекта только в том случае, если объект обладает в отношении соответствующего GPO разрешениями Read (Чтение) и Apply Group Policy (применение групповой политики). Если объект (пользователь или группа) не обладает разрешением Apply Group Policy (применение групповой политики), политика группы в его отношении не применяется.

Отладка процесса обработки политик и профилей[]

Чтобы задокументировать в журнале последовательность, в которой применяются политики и профили, следует при помощи редактора реестра добавить в ключ HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsNTCurrentVersionWinlogon значение UserEnvDebugLevel типа REG_DWORD, которое должно быть равно 0x10002. После этого перезапустите компьютер. Журнал применения политик и профилей будет записан в файл %SystemRoot%DebugUsermodeUserenv.log.
Помимо объектов GPO, существующих в каталоге Active Directory, в каждой системе Windows 2000 существует также локальная политика (local policy). Локальная политика определяет параметры, в соответствии с которыми настраивается рабочая станция. Система применяет политики в определенном порядке. Сначала применяется локальная политика (Local policy), затем политика узла (Site policy), затем доменная политика (Domain policy) и, наконец, политика контейнера OU (Organizational Unit policy). Порядок применения политик часто обозначают последовательностью символов (L, S, D, OU). Если локальная политика конфликтует с политикой узла, домена или контейнера OU, она всегда проигрывает. Другими словами, в процессе применения политик локальная политика обладает наименьшим приоритетом.
Все параметры, за исключением сценариев подключения/начала работы системы и отключения/завершения работы системы, а также установки программного обеспечения (либо назначенного, либо опубликованного), обновляются каждые 90 минут с переменным смещением плюс-минус 30 минут. Обновление осуществляется по инициативе механизма обновления групповых политик, работающего на стороне клиента, который следит за тем, когда клиент последний раз выполнял обновление. В начале процесса обновления порядковые номера версий всех действующих политик сравниваются с локальными номерами версий. Если локальный и удаленный номера версий не совпадают, заново применяется вся политика. В противном случае никакого обновления не происходит. Обновление политик, действующих в отношении контроллеров доменов, выполняется каждые пять минут.

Клиенты, которые могут использовать групповую политику[]

В процессе перехода на использование Windows 2000 в вашей сети наверняка будут присутствовать компьютеры, оснащенные более ранними версиями Windows. Чтобы эффективно управлять такой сетью, важно понимать, в отношении каких компьютеров будет действовать групповая политика. Далее перечисляются операционные системы, в отношении которых действует групповая политика.

Windows 2000 & 2003 Server. Компьютеры, оснащенные операционной системой Windows 2000 Server, могут быть либо обычными членами домена Active Directory, либо контроллерами домена. Групповая политика в полной мере применяется к обоим разновидностям серверов.
Windows 2000 & XP Professional. Групповая политика в полной мере применяется в отношении клиентских компьютеров, оснащенных Windows 2000 Professional.
Windows NT 4.0 Workstation и Server. В отношении таких компьютеров можно применить только системные политики в стиле NT 4.0. Для создания таких политик используется редактор poledit.exe. При помощи poledit.exe администратор может создавать файлы .adm. Windows NT 4.0 не поддерживает Active Directory и не использует объектов локальной политики, поэтому в отношении компьютеров, оснащенных этой операционной системой, групповая политика не применяется.
Windows 95 и Windows 98. Для создания системной политики в операционных системах Windows 98 и Windows 95 используется специальный редактор системной политики. Получившийся в результате редактирования файл с расширением .pol следует скопировать в каталог SysVol. Редакторы системной политики, входящие в комплект Windows 2000 и Windows NT, не совместимы с Windows 98 и Windows 95. Групповая политика Windows 2000 в отношении таких компьютеров не применяется.
Windows NT 3.51, Windows 3.1 и DOS. Групповая политика не применяется.

Сценарии подключения и отключения[]

Операционная система Windows NT позволяет назначить каждому пользователю сценарий, содержащий команды, которые необходимо выполнить при подключении данного пользователя к системе. Обычно сценарии подключения используются для начальной настройки пользовательского рабочего окружения. Помимо сценариев подключения, Windows 2000 поддерживает также сценарии отключения. Мало того, в новой операционной системе для каждого компьютера можно назначить сценарии начала и завершения работы системы. Система исполнения сценариев Windows Scripting Host (WSH) поддерживает исполнение сценариев, написанных на таких языках, как Visual Basic или Jscript, позволяющих напрямую обращаться к функциям Windows API. Рассмотрим некоторые возможности, связанные с использованием сценариев в среде Windows 2000.

Сценарии, определенные в рамках пользовательского объекта[]

Такие сценарии поддерживаются в точности так же, как это было в Windows NT 4.0, и существуют в основном для обеспечения совместимости с Windows ранних версий. Клиенты Windows 2000 и Windows NT 4.0 пытаются обнаружить такие сценарии в общей папке Netlogon сервера. Если обнаружить сценарий не удалось, поиск производится в каталоге %SystemRoot%system32RepllmportScripts (расположение сценариев, используемое в NT 4.0). Общая папка Netlogon располагается в каталоге SysVol (sysvolимя.доменаscripts) и автоматически реплицируется службой FRS. Репликация каталога сценариев операционной системы NT 4.0 должна быть настроена вручную.

Сценарии, определенные в рамках групповой политики[]

Эти сценарии применяются в отношении контейнеров OU. Иными словами, чтобы назначить пользователю сценарий подключения или отключения, следует сделать пользователя членом контейнера OU, для которого определена политика, в рамках которой назначен сценарий подключения или отключения. Этот метод является более гибким.
Если вы переводите свою сеть на использование Windows 2000, вы также должны учитывать некоторые другие особенности, связанные со сценариями. Во многих сетях наряду с машинами Windows 2000 используются компьютеры, оснащенные более ранними версиями Windows, по этой причине рекомендуется выполнять обновление сервера, содержащего общую папку NETLOGON, в последнюю очередь. Это связано с тем, что служба репликации, используемая в Windows 2000 (FRS), не совместима со службами репликации NT. Таким образом, обновляя сеть, вы должны быть уверены в том, что абсолютно все клиенты имеют возможность доступа к папке Netlogon и сценариям подключения вне зависимости от того, какую операционную систему они используют.
Следует также учитывать, что в Windows NT сценарии подключения работают в контексте безопасности пользователя. В Windows 2000 это справедливо лишь отчасти. В Windows 2000 сценарии, имеющие отношение к пользователю (подключения к системе и отключения от системы), также выполняются в контексте безопасности пользователя, в то время как сценарии, имеющие отношение к компьютеру (начала работы системы и завершения работы системы), выполняются в контексте безопасности LocalSystem.

Делегирование прав на администрирование групповых политик[]

Возможность управления объектами GPO можно делегировать другим ответственным лицам. Делегирование осуществляется при помощи списков ACL. Списки ACL объекта GPO позволяют назначить в отношении этого объекта разрешения на модификацию этого GPO или на назначение GPO в отношении некоторого контейнера. Таким образом, можно запретить создание неавторизированных объектов GPO. Например, создание и модификацию GPO можно доверить группе администраторов домена, в то время как назначение этих GPO могут осуществлять администраторы отдельных контейнеров OU. Администратор контейнера OU может выбрать наиболее подходящий объект GPO и применить этот GPO в отношении любого из подконтрольных ему OU. Однако при этом он не сможет изменить содержимое этого GPO или создать новый GPO.

Управление пользовательскими документами и кэшированием на стороне клиента[]

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

Application data
Desktop (Рабочий стол)
My Documents (Мои документы)
My Pictures (Мои рисунки)
Start Menu (Главное меню).

Механизм перенаправления пользовательских папок является частью технологии IntelliMirror, цель которой — обеспечить доступ к рабочим файлам и конфигурационной информации вне зависимости от того, какую рабочую станцию пользователь использует для работы. Как следствие, технология Intellimirror обеспечивает сохранность пользовательских файлов и конфигурационных данных в случае, если рабочая станция пользователя выходит из строя.
Перенаправление каталогов настраивается в разделе User Configuration (конфигурация пользователя) Windows Settings (параметры Windows) Folder Redirection (перенаправление папок) объекта групповой политики. В этом разделе отображаются все ранее перечисленные папки. Чтобы перенаправить одну из этих папок в новое место, правой кнопкой мыши щелкните на её имени и в появившемся меню выберите пункт Properties (Свойства).

На вкладке Target (Цель) вы можете выбрать один из трех вариантов перенаправления пользовательской папки.

No administrative policy specified (административная политика не назначена).
Basic (базовый). Перенаправляет папку в новое место вне зависимости от того, к какой группе принадлежит пользователь. Новое место должно быть указано с использованием формата UNC. При указании нового места можно использовать такие переменные, как %username%. Таким образом, для разных пользователей папка может быть перенаправлена в разные каталоги, однако все эти каталоги должны располагаться в одной и той же сетевой папке общего доступа.
Advanced (усложненный). Для разных групп пользователей можно указать разные местоположения папки. Для разных групп можно указать различные UNC-имена. Соответствующие папки могут располагаться на разных серверах.

Ссылки[]

Раздел групповой политики на Microsoft TechNet
Group Policy Management Console — бесплатная программа от Microsoft для управления групповой политикой.

Компоненты Microsoft Windows
Основные	Aero • ClearType • Диспетчер рабочего стола • DirectX • Панель задач (Пуск • Область уведомлений) • Проводник (Пространство имён • Специальные папки • Ассоциации файлов) • Windows Search (Smart folders • iFilters) • GDI • WIM • SMB • .NET Framework • XPS • Active Scripting (WSH • VBScript • JScript) • COM (OLE • DCOM • ActiveX • Структурированное хранилище • Сервер транзакций) • Теневая копия • WDDM • UAA • Консоль Win32
Службы управления	Архивация и восстановление • COMMAND.COM • cmd.exe • Средство переноса данных • Просмотр событий • Установщик • netsh.exe • PowerShell • Отчёты о проблемах • rundll32.exe • Программа подготовки системы (Sysprep) • Настройка системы (MSConfig) • Проверка системных файлов • Индекс производительности • Центр обновления • Восстановление системы • Дефрагментация диска • Диспетчер задач • Диспетчер устройств • Консоль управления • Очистка диска • Панель управления (элементы)
Приложения	Контакты • DVD Maker • Факсы и сканирование • Internet Explorer • Журнал • Экранная лупа • Media Center • Проигрыватель Windows Media • Программа совместной работы • Центр устройств Windows Mobile • Центр мобильности • Экранный диктор • Paint • Редактор личных символов • Удалённый помощник • Распознавание речи • WordPad • Блокнот • Боковая панель • Звукозапись • Календарь • Калькулятор • Ножницы • Почта • Таблица символов • Исторические: Movie Maker • NetMeeting • Outlook Express • Диспетчер программ • Диспетчер файлов • Фотоальбом • Windows To Go
Игры	Chess Titans • Mahjong Titans • Purble Place • Пасьянсы (Косынка • Паук • Солитер) • Сапёр • Пинбол • Червы
Ядро ОС	Ntoskrnl.exe • Слой аппаратных абстракций (hal.dll) • Бездействие системы • svchost.exe • Реестр • Службы • Диспетчер управления сервисами • DLL (формат модулей) • PE • NTLDR • Диспетчер загрузки • Программа входа в систему (winlogon.exe) • Консоль восстановления • Windows RE • Windows PE • Защита ядра от изменений
Службы	Autorun.inf • Фоновая интеллектуальная служба передачи • Файловая система стандартного журналирования • Отчёты об ошибках • Планировщик классов мультимедиа • Теневая копия • Планировщик задач • Беспроводная настройка
Файловые системы	ReFS • NTFS (Жёсткая ссылка • Точка соединения • Точка монтирования • Точка повторной обработки • Символьная ссылка • TxF • EFS) • WinFS • FAT • exFAT • CDFS • UDF • DFS • IFS
Сервер	Active Directory • Службы развёртывания • Служба репликации файлов • DNS • Домены • Перенаправление папок • Hyper-V • IIS • Media Services • MSMQ • Защита доступа к сети (NAP) • Службы печати для UNIX • Удалённое разностное сжатие • Службы удаленной установки • Служба управления правами • Перемещаемые профили пользователей • SharePoint • Диспетчер системных ресурсов • Удаленный рабочий стол • WSUS • Групповая политика • Координатор распределённых транзакций
Архитектура	NT • Диспетчер объектов • Пакеты запроса ввода/вывода • Диспетчер транзакций ядра • Диспетчер логических дисков • Диспетчер учетных записей безопасности • Защита ресурсов • lsass.exe • csrss.exe • smss.exe • spoolsv.exe • Запуск
Безопасность	BitLocker • Защитник • Предотвращение выполнения данных • Обязательный контроль целостности • Защищённый канал данных • UAC • UIPI • Брандмауэр • Центр обеспечения безопасности • Защита файлов
Совместимость	Подсистема UNIX (Interix) • Виртуальная машина DOS • Windows on Windows • WOW64

Источник