Групповая политика — это набор правил, в соответствии с которыми производится настройка рабочей среды относительно локальных политик, по умолчанию. Групповые политики в реализации Active Directory — это часть интегрированного решения. Альтернативной реализацией Active Directory под Linux/Unix является проект Samba. Поддержка применения групповых политик в конкретных дистрибутивных решениях, в целом, не является частью проекта Samba. В данной статье представлен общий обзор данного инструмента в контексте интеграции применения групповых политик в решениях ALT.
- 1 Механизмы назначения и кеширования
- 1.1 Развёртывание клиентских средств применения групповых политик
- 1.1.1 Конфигурирование в командной строке
- 1.1.2 Конфигурирование с помощью Alterator
- 2.1 Состав локальной политики
- 3.1 Коды ошибок
Механизмы назначения и кеширования
В дистрибутивах ALT для применения групповых политик на данный момент предлагается использовать инструмент gpupdate. Инструмент рассчитан на работу на машине, введённой в домен Samba. Среди применяемых настроек присутствуют:
Настройка AD GP: Как установить 1С на все ПК домена
| Настройка браузера Firefox | Стабильная | Возможно установить при использовании ADMX файлов Mozilla Firefox (пакет admx-firefox , https://github.com/mozilla/policy-templates/releases) |
| Настройка браузера Chromium | Стабильная | Возможно установить при использовании ADMX файлов Google Chrome (пакет admx-chromium , https://dl.google.com/dl/edgedl/chrome/policy/policy_templates.zip) |
| Настройка «Яндекс.Браузера» | Стабильная | Возможно установить при использовании ADMX файлов Yandex (пакет admx-yandex-browser , https://yandex.ru/support/browser-corporate/deployment/deployment.html) |
| Запрет на подключение внешних носителей данных | Стабильная | Стандартные средства RSAT |
| Включение или выключение различных служб (сервисов systemd) | Стабильная | Возможно установить при использовании ADMX файлов ALT (пакет admx-basealt , https://github.com/altlinux/admx-basealt) |
| Управление control framework | Стабильная | Возможно установить при использовании ADMX файлов ALT (пакет admx-basealt , https://github.com/altlinux/admx-basealt) |
| Управление Gsettings | Стабильная | Возможно установить при использовании ADMX файлов ALT (пакет admx-basealt , https://github.com/altlinux/admx-basealt) |
| Управление настройками службы Polkit | Возможно установить при использовании ADMX файлов ALT (пакет admx-basealt , https://github.com/altlinux/admx-basealt) | |
| Генерация ярлыков запуска программ | Стабильная | Стандартные средства RSAT, GPUI. С некоторыми ограничениями. Также можно делать ярлыки типа URL и делать, например, URI-ссылки smb:// для открытия Samba shares. |
| Подключение сетевых дисков | Экспериментальная | Стандартные средства RSAT, GPUI |
| Управление каталогами | Стабильная | Стандартные средства RSAT, GPUI |
| Управление INI-файлами | Экспериментальная | Стандартные средства RSAT, GPUI |
| Управление общими каталогами | Экспериментальная | Стандартные средства RSAT, GPUI |
| Управление файлами | Экспериментальная | Стандартные средства RSAT, GPUI |
| Управление переменными среды | Стабильная | Стандартные средства RSAT, GPUI |
| Управление logon-скриптами | Экспериментальная | Стандартные средства RSAT, GPUI |
| Установка программного обеспечения | Экспериментальная | Возможно установить при использовании ADMX файлов ALT (пакет admx-basealt , https://github.com/altlinux/admx-basealt) |
| Установка пароля для локального пользователя root | Не реализовано | |
| Политика замыкания | Возможно установить при использовании ADMX файлов от Microsoft (пакет admx-msi-setup ) | |
| Периодичность запроса конфигураций | Стандартные средства RSAT, GPUI | |
| Указание прокси-сервера | Стандартные средства RSAT, GPUI |
IT 101. GPO Групповые политики, Установка ПО через ГПО, и настройка системы
Оценить полный набор возможностей могут администраторы инфраструктур на базе Active Directory скачав файлы ADMX из репозитория: https://github.com/altlinuxteam/admx-basealt и загрузив их в оснастку RSAT. Модули (настройки), помеченные как экспериментальные, необходимо включать вручную через ADMX файлы ALT в разделе GPUpdate.
Процесс применения настроек:
- настройки для машины реплицируются при запуске компьютера и далее обновляются раз в час;
- настройки для пользователя реплицируются при входе пользователя в систему и далее обновляются раз в час.
Развёртывание клиентских средств применения групповых политик
На текущий момент для включения инструмента групповых политик на клиентах AD необходимо установить пакеты из репозитория:
- oddjob-gpupdate
- gpupdate
Установка ПО производится командами:
# apt-get update # apt-get install gpupdate
Конфигурирование в командной строке
Включение работы групповых политик и выбор шаблона локальной политики (local policy) выполняется командой gpupdate-setup от пользователя с правами администратора:
# gpupdate-setup enable workstation
Для применения настроек следует перезагрузить рабочую машину.
Примеры, работы с командой gpupdate-setup :
-
показать текущий статус групповой политики:
# gpupdate-setup enabled
# gpupdate-setup active-policy workstation
# gpupdate-setup list server ad-domain-controller workstation
# gpupdate-setup write enable server server
Конфигурирование с помощью Alterator
Включить работу групповых политик и выбрать профиль локальной политики по умолчанию можно также с помощью GUI в ЦУС. Должны быть установлены пакеты alterator-auth и alterator-gpupdate :
# apt-get install alterator-auth alterator-gpupdate
Конфигурирование групповых политик с помощью Alterator возможно как при вводе машины в домен AD, так и на уже включённой в домен рабочей станции.
Для включения групповых политик при вводе машины в домен, следует в модуле ЦУС «Аутентификация» отметить пункт «Включить групповые политики»:
Если рабочая станция уже находится в домене, конфигурирование групповых политик с помощью Alterator возможно с помощью модуля «Групповые политики» из пакета alterator-gpupdate :
Функционал модуля «Групповые политики» пока ограничен включением/выключением политики и выбором шаблона локальной политики — Сервер, Рабочая станция или Контроллер домена:
Конфигурирование gpupdate
По умолчанию, нет необходимости конфигурировать gpupdate.
Однако, в файле /etc/gpupdate/gpupdate.ini можно указать в явном виде следующие опции:
в разделе [gpoa]
backend = выбор способа получения настроек
local-policy = профиль локальной политики, который будет применен сразу после загрузки ОС.
в разделе [samba]
dc = контроллер домена, с которого нужно обновлять групповые политики
В следующем примере указан пустой профиль локальной политики. Это бывает необходимо для тестирования групповых политик, чтобы они не наслаивались на локальные политики:
[gpoa] backend = samba local-policy = /usr/share/local-policy/default [samba] dc = dc0.domain.alt
Периодичность запуска групповых политик
Примечание: Данный раздел актуален для gpupdate , начиная с версии 0.9.11.2-alt1.
У машины и пользователя собственные таймеры процесса gpupdate.
Для мониторинга и контроля времени выполнения службы gpupdate.service используются системный таймер gpupdate.timer и пользовательский таймер gpupdate-user.timer. Для управления периодом запуска групповых политик достаточно изменить параметр соответствующего таймера systemd (по умолчанию период запуска составляет 1 час).
Изменить периодичность запуска системного таймера можно в /lib/systemd/system/gpupdate.timer . По умолчанию таймер gpupdate.timer запустится после загрузки ОС, а затем будет запускаться каждый час во время работы системы. Просмотреть статус системного таймера:
# systemctl status gpupdate.timer
Изменить периодичность запуска пользовательского таймера можно в /usr/lib/systemd/user/gpupdate-user.timer . По умолчанию таймер gpupdate-user.timer запустится после входа пользователя в систему, а затем будет запускаться каждый час пока активен сеанс соответствующего пользователя. Просмотреть статус пользовательского таймера:
$ systemctl —user status gpupdate-user.timer
Примечание: Чтобы изменения, внесённые в файл /usr/lib/systemd/user/gpupdate-user.timer , вступили в силу следует выполнить команду:
$ systemctl —user daemon-reload
Управлять периодичностью запуска gpupdate можно также через групповые политики (см. Периодичность запроса конфигураций).
Установка административных шаблонов и инструментов администрирования ГП
Для задания конфигурации необходимо установить административные шаблоны (ADMX-файлы).
Подробнее о инструменте удалённого управления базой данных конфигурации: ADMC.
Подробнее о инструменте редактирования настроек клиентской конфигурации: GPUI.
Internals
Групповые политики кэшируются в файле /var/cache/gpupdate/registry.sqlite (можно просматривать его командой sqlite3 ).
Состав локальной политики
Для клиента также существует понятие локальной политики. Настройки локальной политики находятся в каталоге /usr/share/local-policy/ . Данные настройки по умолчанию поставляются пакетом local-policy . Администраторы инфраструктур имеют возможность поставлять собственный пакет с локальной политикой и развёртывать её единообразно на всех клиентах. Формат шаблонов локальных политик представляет из себя архивный формат политик Samba с дополнительными модификациями. Локальную политику рекомендуется править только опытным администраторам. Состав локальной политики может меняться или адаптироваться системным администратором.
| Включение oddjobd.service | Необходимо для обеспечения возможности запуска gpupdate для пользователя с правами администратора. |
| Включение gpupdate.service | Необходимо для регулярного обновления настроек машины. |
| Включение sshd.service | Необходимо для обеспечения возможности удалённого администрирования. |
| Включение аутентификации с помощью GSSAPI для sshd | Необходимо для аутентификации в домене при доступе через SSH. |
| Ограничение аутентификации для sshd по группам wheel и remote | Необходимо для ограничения доступа при доступе через SSH для всех пользователей домена (только при наличии соответствующей привилегии). |
| Открытие порта 22 | Необходимо для обеспечения возможности подключения SSH на машинах при старте Firewall applier. |
Troubleshooting
В случае неописанных ошибок и «развала» отладочного вывода один из простых подходов к решению проблемы — удалить файл «реестра» /var/cache/gpupdate/registry.sqlite и запустить gpoa заново для перегенерации файла и вызова «применялки настроек».
Для диагностики механизмов применения групповых политик на клиенте можно выполнить команды:
-
получить и применить настройки для текущей машины:
# gpoa —loglevel 0
# gpoa —loglevel 0 ivanov
Коды ошибок
Сообщения, сопутствующие кодам ошибок, могут изменяться (переводиться, исправляться), но сам код уникален для определённой части программы, что позволяет однозначно идентифицировать проблему.
| E00001 | Недостаточно прав для запуска программы gpupdate . | Необходимо повысить уровень привилегий. Может помочь запуск программы от имени администратора. |
| E00002 | Программа gpupdate не будет запущена из-за предыдущих ошибок. | |
| E00003 | Ошибка работы бэкэнда, которая привела к досрочному прекращению обработки групповых политик. Этот код характеризует серьёзные ошибки, которые обрабатываются на самом высоком уровне. | Возможно, это баг в коде и необходимо отправить багрепорт в багтрекер проекта. |
| E00004 | Ошибка во время работы фронтенда. | Высокоуровневая ошибка при инициализации фронтенда или во время работы appliers. С большой вероятностью может оказаться багом в коде. |
| E00005 | Не получилось запустить применялку политик для обновления групповых политик компьютера. | Проверьте, что машина всё ещё в домене, демон oddjobd доступен через D-Bus и у пользователя достаточно прав для запуска ПО. |
| E00006 | Не получилось запустить применялку политик для обновления групповых политик пользователя. | Проверьте, что машина всё ещё в домене, демон oddjobd доступен через D-Bus и у пользователя достаточно прав для запуска ПО. |
| E00007 | Невозможно инициализировать бэкэнд Samba в силу неполадок компонентов, связанных с Samba. | Необходимо проверить инсталляцию Samba на машине, убедиться, что машина введена в домен и домен доступен. |
| E00008 | Невозможно инициализировать бэкэнд no-domain для выполнения процедуры бутстрапа групповых политик. | Возможно, было произведено вмешательство в локальную политику или произошёл misconfiguration. Необходимо проверить целостность пакета local-policy и настройки домена в Alterator. |
| E00009 | Произошла ошибка при попытке запуска adp | Необходимо обратиться к руководству по устранению неполадок проекта ADP. |
| E00010 | Произошёл сбой при попытке получить имя домена Active Directory | Необходимо проверить работу доменной службы имён (DNS), а также доступность доменного LDAP. Для доступа к LDAP необходим работоспособный Kerberos, так что стоит проверить и его конфигурацию. |
| E00011 | Во время работы applier с пониженным уровнем привилегий произошла неполадка. | Возможно, что в используемой групповой политике заданы параметры, для установки которых требуются права администратора. Это необходимо проверить и исправить объект групповой политики соответственно. |
| E00012 | Высокоуровневая ошибка инициализации бэкэнда. | Необходимо проверить наличие условий для запуска бэкэнда. В случае с Samba — удостовериться, что машина введена в домен. |
| E00013 | У пользователя, запустившего программу, недостаточно прав для обновления настроек машины. | Запустите программу с правами администратора. |
| E00014 | Не прошла проверка наличия билета Kerberos. Билет Kerberos нужен для доступа к сервисам домена. | Проверьте конфигурацию Kerberos в файле /etc/krb5.conf . Попробуйте получить билет Kerberos вручную. |
| E00015 | Запрос на получение имени домена Active Directory через LDAP не прошёл. | Проверьте возможность получения Kerberos ticket для машины. Проверьте работу DNS и возможность обратиться к доменному LDAP. |
| E00016 | Утилита wbinfo не отдаёт SID для пользователя, для которого выполняется обновление групповых политик. | Проверьте целостность программы wbinfo. Проверьте, что машина введена в домен. |
| E00017 | Невозможно получить список групповых политик для репликации на используемое имя пользователя. | Удостоверьтесь, что пользователь, для которого происходит попытка получить список групповых политик, существует в домене. Также необходимо удостовериться, что проблема не вызвана misconfiguration домена. |
| E00018 | Не получилось прочитать содержимое настройки XDG_DESKTOP_DIR. | Удостоверьтесь, что XDG в системе сконфигурирован корректно и пользователь, для которого вычитывается настройка, существует. |
| E00019 | Произошла ошибка во время работы applier для пользователя. | Необходимо удостовериться, что это не misconfiguration в используемой GPO. Возможен баг. В таком случае необходимо оставить bug report на страничке проекта. |
| E00020 | Произошла ошибка во время работы applier для пользователя с пониженными привилегиями. | Необходимо удостовериться, что это не misconfiguration в используемой GPO. Возможен баг. В таком случае необходимо оставить bug report на страничке проекта. |
| E00021 | Не был получен ответ от D-Bus при попытке запустить GPOA для текущего пользователя. | Удостоверьтесь, что D-Bus работает корректно и демон oddjobd запущен. Удостоверьтесь, что у текущего пользователя достаточно прав для обращения к D-Bus. |
| E00022 | Не был получен ответ от D-Bus при попытке запустить GPOA для машины. | Удостоверьтесь, что D-Bus работает корректно и демон oddjobd запущен. |
| E00023 | Не был получен ответ от D-Bus при попытке запустить GPOA для пользователя. | Удостоверьтесь, что D-Bus работает корректно и демон oddjobd запущен. Удостоверьтесь, что у текущего пользователя достаточно прав для обращения к D-Bus. |
| E00024 | Ошибка во время работы машинного applier. | Проверьте настройки applier вручную, чтобы убедиться, что соответствующая часть ОС не поломана. |
| E00025 | Ошибка во время инициализации пользовательского applier. | Проверьте, что машина является частью домена и контроллер домена доступен. Удостоверьтесь, что пользователь существует. Проверьте, что соответствующая часть ОС не поломана. |
Страницы проектов
Источник: www.altlinux.org
MS-Direction
Опишем процесс настройки конкретных пользователей и групп для добавления компьютеров в домен Active Directory.
И так, запустим редактор управления групповыми политиками. Создадим новую политику GPO, для этого щелкнем правой кнопкой мыши на папке Объекты групповой политики и выберем Создать.
Введем название новой политики: Добавление рабочих станций в домен
Откроем политику на редактирование и перейдем Конфигурация компьютераПолитикиКонфигурация WindowsПараметры безопасностиЛокальные политикиНазначение прав пользователя
Откроем политику Добавление рабочих станций к домену
Поставим галку Определить следующие параметры политикиДобавить пользователя или группуОбзорВведем имя группы или пользователяОк
Источник: nookiez84.blogspot.com
Групповые политики в доменах AD
В предыдущей статье [1] я говорил об управлении пользователями в среде Active Directory. Cлужба каталогов облегчает работу IT-подразделения по администрированию информационных ресурсов предприятия. Технологии Intellimirror и CCM (Change and Configuration Management – управление изменениями и конфигурациями) позволяют управлять рабочими местами, используя перемещаемые профили и перенаправление каталогов, автономные папки и распространение программ. Многие из этих задач легко выполняются при помощи групповых политик, обеспечивая при этом централизованное управление, а также гибкий механизм настройки и отладки. Групповые политики позволяют:
- назначать сценарии запуска, входа и выхода;
- распространять программное обеспечение в сети при помощи публикации или назначения;
- однозначно определять набор настроек безопасности для удаленных машин;
- определять политики паролей для пользователей домена;
- конфигурировать параметры Internet Explorer (даже несмотря на всю его «дырявость», по разным источникам от 60 до 80% пользователей во всем мире используют для просмотра веб-страниц именно этот браузер);
- настраивать перенаправление определенных папок из профиля пользователя;
- накладывать ограничения на рабочий стол;
- определять настройки таких категорий, как автономные папки, дисковые квоты и др., не исключением являются настройки самих групповых политик.
Все настройки администратор может сделать при помощи редактора системного реестра, но интуитивно понятный интерфейс редактора объектов групповой политики во многом упрощает эту задачу.
Структура объектов групповой политики и их место в службе каталогов
Объект групповой политики (GPO, Group Policy Object) состоит из двух частей: конфигурация компьютера (Computer Configuration) и конфигурация пользователя (User Configuration) (см. рис. 1). Он является контейнером для групп политик, применяемых соответственно к машинам и пользователям сети.
Рисунок 1. Редактор групповых политик gpedit.msc
В «Конфигурации компьютера» администратор может настроить параметры безопасности, политики паролей пользователей, параметры аудита, использование групп с ограниченным доступом (Restricted Groups), параметры реестра и так далее.
В разделе «Конфигурация пользователя» настраиваются параметры рабочего окружения пользователя (настройки рабочего стола, вид и ограничения для панели задач и меню «Пуск»), перенаправление папок, а также параметры Internet Explorer. Каждый объект GPO создается с помощью редактора групповых политик (Group Policy Object Editor). Запустить его можно из вкладки Group Policy свойств контейнера.
Как уже говорилось, GPO содержит в себе два узла, в которых определяются специфичные для компьютеров и пользователей настройки. Однако бывает, что существуют идентичные настройки для компьютеров и пользователей. Как система «разруливает» их применение, будет рассказано далее.
Каждая политика в объекте GPO может быть сконфигурирована и нет. В первом случае она воздействует на объект и может быть в состоянии включено/отключено, а также принимать значения с указанием дополнительных параметров. Во втором – политика на объект не воздействует.
Объекты групповых политик хранятся двумя частями: контейнер групповой политики (GPC, Group Policy Container) и шаблон групповой политики (GPT, Group Policy Template). Контейнер хранится непосредственно в службе каталогов и содержит информацию о свойствах, версии, статусе и список компонентов. Шаблоны GPT находятся в каталоге WindowsSYSVOLsysvolDomain_NamePoliciesGUID (см. рис. 2), где GUID – глобальный уникальный идентификатор объекта GPO. В этой папке содержатся административные шаблоны (ADM – файлы), настройки безопасности, информация о доступных приложениях и имена сценариев с командными строками.
Рисунок 2. Папка, содержащая шаблоны групповых политик на контроллере домена
Локальные политики рабочей станции
Каждая рабочая станция под управлением операционных систем семейства Windows 2000 имеет свои локальные политики, и администратор домена имеет возможность редактировать их. Они схожи с групповыми политиками домена, но применяются для всех локальных пользователей компьютера без исключения. Также невозможно настроить ряд установок, таких, например, как перенаправление каталогов и установка приложений. Несмотря на это, структура объекта локальных групповых политик такая же, как и GPO домена. Размещается он в папке Windowssystem32GroupPolicy.
При помощи команды gpedit.msc вы можете редактировать локальные политики рабочей станции. Синтаксис строки для запуска gpedit.msc для просмотра локальной политики удаленной машины будет выглядеть следующим образом:
Gpedit.msc /gpcomputer: Имя_Компьютера
Однако стоить заметить, что вы не сможете посмотреть локальные настройки безопасности удаленной машины (видимо, Microsoft сделала это из-за соображений безопасности).
Групповые политики по умолчанию
После создания первого контроллера домена формируются политики по умолчанию: Default Domain Controller Policy (привязывается к контейнеру Domain Controllers, применяется исключительно для контроллеров домена и содержит настройки безопасности) и Default Domain Policy (политика безопасности для домена, привязывается к контейнеру домена и распространяется на весь домен). Вы легко их можете заменить своими политиками, либо использовать в сочетании с другими. Еще один нюанс, который стоит отметить – если вы попытаетесь открыть Default Domain Controller Policy из меню «Администрирование», вам будут доступны только настройки безопасности. Полностью увидеть и изменить все настройки этого GPO можно из оснастки Active Directory – Users and Computers (DSA.MSC) в свойствах контейнера Domain Controllers.
Создание объектов GPO
Несмотря на название, GPO не имеют ничего общего с группами. Объекты групповых политик могут быть связаны с контейнерами сайта, домена и OU (организационной единицы). Таким образом, для создания объекта GPO мы можем воспользоваться консолями Active Directory – Users and Computers или Active Directory Sites and Services, все зависит от того, для какого контейнера мы создаем GPO. Итак, запускаем DSA.MSC либо DSSITE.MSC.
Далее заходим в свойства контейнера и открываем вкладку «Групповая политика» (Group Policy), как это показано на рис. 3. Здесь мы можем создать или изменить GPO, а также добавить и привязать к объекту уже существующий GPO. В этих настройках можно удалить как ссылку на GPO, и тогда пропадет всего лишь привязка GPO к контейнеру, так и сам объект групповой политики.
Рисунок 3. Открытие редактора групповых политик в DSA.MSC
В параметрах (Options) устанавливается, разрешено ли перекрытие для этого объекта. При включенной опции «Не перекрывать» (No Override) другие политики не могут наложить свои настройки на установки данной. Если включена опция «Отключить» (Disabled), это значит, что GPO не будет применяться на этом уровне (к этому контейнеру). При установленном флажке «Блокировать наследование политики» (Block Inheritance) политики верхних уровней иерархии службы каталогов применяться не будут. Однако, если для политики более высокого уровня включена опция «No Override», блокировать наследование не удастся.
В свойствах групповых политик можно увидеть дату создания, последнего изменения объекта GPO, его версию, GUID (Globally Unique Identifier, глобальный уникальный идентификатор) и домен, в котором располагается объект GPO. Здесь же есть возможность отключить настройки конфигурации компьютера или пользователя.
На вкладке «Связи» (Links) можно посмотреть, с какими объектами службы каталогов GPO имеет связь. В настройках безопасности указывается, каким группам пользователей предоставляются права на чтение политики, изменение, применение и т. д. Напомню, что связывание и наследование объектов GPO происходит на уровне контейнеров. Но администратор может явно указать, будет ли той или иной группе пользователей, принадлежащих какому-либо контейнеру, разрешено чтение и применение групповых политик из объекта GPO, связанного с этим контейнером. Таким образом, при использовании ACL (Access Control List, список контроля доступа), определяются области действия политики на основе групп. На вкладке «Фильтр WMI» (WMI Filter) вы можете выбрать, будет ли применяться к объекту политик фильтр WMI (Windows Management Instrumentation), и если да, то какой.
При создании объект групповой политики привязывается к контейнеру, для которого вы его создали. Этот GPO будет храниться в Active Directory и может быть применен к другим контейнерам – сайтам, доменам и организационным единицам. Одновременно с этим вы можете удалить привязку GPO к контейнеру, не удаляя сам объект GPO. Групповые политики данного GPO к этому контейнеру применяться не будут, но сам объект все еще будет существовать в службе каталогов. Таким образом, может возникнуть ситуация, когда какой-либо объект групповой политики не будет связан ни с одним контейнером, но он все еще будет существовать в службе каталогов, и вы в любой момент сможете привязать его к сайту, домену или OU.
Каждый контейнер может иметь связь с несколькими GPO, которые будут отображены в списке на вкладке «Групповая политики». И, чем выше политика, тем выше ее приоритетность. Выигрывающей является самая верхняя в списке политика. Изменить приоритетность вы можете, передвигая объекты вверх-вниз и меняя тем самым очередность.
Важно понимать, что применение параметров при воздействии многих политик происходит снизу вверх, и, если политика в объекте GPO не сконфигурирована, она не будет воздействовать на параметр. Таким образом, для параметра будет установлено значение, определенное самым верхним в списке объектом GPO, в котором политика сконфигурирована.
Порядок применения групповых политик
При загрузке компьютер получает от контроллера домена своего сайта список групповых политик в том порядке, в котором он должен их применить. Аналогично при входе пользователя в систему происходит запрос групповых политик, определенных для контейнера, которому этот пользователь принадлежит, и дальнейшее их применение. Далее в процессе работы групповые политики обновляются в фоновом режиме каждые X минут, где X – величина, лежащая в интервале 60-120 минут. Эту величину можно изменить при помощи групповых политик, но не рекомендуется делать ее очень маленькой, потому что это повлечет за собой затраты системных ресурсов из-за постоянного обращения к контроллеру домена. Для контроллеров домена групповые политики обновляются каждые 5 минут.
За обработку групповых политик на компьютерах клиентов отвечает набор динамических библиотек – клиентских расширений групповых политик. И, к слову говоря, если на локальной машине не будет файла scecli.dll (на компьютерах часто можно видеть событие с источником SceCli и описанием «Политика безопасности в объектах групповой политики успешно применена»), то групповые политики на нем и вовсе выполняться не будут.
Применение групповых политик пользователя и компьютера в системах Windows NT 5 происходит по-разному. В таблице показано, как это происходит в различных системах по умолчанию. Попросту говоря, в системе Windows XP политики применяются после того, как пользователь уже видит экран входа в систему. При входе в систему он сразу же видит рабочий стол, не дожидаясь применения всех политик. Для повышения безопасности такое поведение можно изменить с помощью параметра Computer Configuration/Administrative Templates/System/Logon/Always wait for the network at computer startup and logon.
Применение групповых политик пользователя и компьютера в системах Windows NT 5
Источник: samag.ru