Gpo Windows server 2008 r2 настройка

Управление групповыми политиками Active Directory (AD GPO)

В статье описана краткая информация о групповых политиках Active Directory и пример работы с ними на виртуальном сервере с операционной системой Windows Server.

Что такое групповые политики и зачем они нужны?

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

Групповые политики позволяют настраивать параметры для определенного набора пользователей или компьютеров внутри домена Active Directory. Также позволяют указать политики в одном месте для группы и применить к целевому набору пользователей.

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

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

Компоненты GPO

Существует два компонента групповых политик — серверный компонент и клиентский, т.е. данная структура относится к архитектуре “клиент-сервер”.

Серверный компонент — оснастка Microsoft Management Console (MMC), которая используется для указания настроек групповой политики.

MMC может быть использована для создания политик для контроля и управления административными шаблонами и настройками безопасности (скрипты, установка ПО и прочее).

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

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

Для администрирования GPO используют Group Policy Management Console (GPMC) и Group Policy Management Editor.

Сценарии использования Active Directory GPO:

• Централизованная настройка пакета программ Microsoft Office.
• Централизованная настройка управлением питанием компьютеров.
• Настройка веб-браузеров и принтеров.
• Установка и обновление ПО.
• Применение определенных правил в зависимости от местоположения пользователя.
• Централизованные настройки безопасности.
• Перенаправление каталогов в пределах домена.
• Настройка прав доступа к приложениям и системным программам.

Оснастка Управление групповыми политиками

После установки роли Active Directory Domain Service (AD DS) на контроллер домена на сервере появится оснастка Group Policy Management. Для того, чтобы ее открыть нажмите комбинацию клавиш Win+R и в открывшемся окне введите:

gpmc.msc

Нажмите OK.

Если оснастку не удается открыть, то возможно по определенным причинам она не установлена. Установить ее можно через стандартное меню Add roles and features в диспетчере сервера, выбрав компонент Group Policy Management.

Оснастка выглядит следующим образом:

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

Для создания объекта групповой политики перейдите во вкладку Forest ->Domains -> ->Group Policy Objects. С помощью правой кнопки мыши откройте меню и выберете New.

В открывшемся окне в поле Name введите удобное для вас имя групповой политики.

После этого вы увидите созданный объект в списке.

Теперь необходимо настроить созданный объект под конкретные задачи. в качестве примера удалим ссылку Games из меню Start. Для это с помощью правой кнопки мыши откройте меню объекта и выберете пункт Edit.

В редакторе групповых политик перейдите по иерархии User Configuration ->Policies ->Administrative Templates ->Start Menu and Taskbar. Найдите опцию Remove Games link from Start Menu и в контекстном меню выберете пункт Edit.

В открывшемся окне отметьте Enable

Источник: https://1cloud.ru/help/windows/gruppovye-politiki-active-directory

Windows Server 2008 R2: Оптимизация работы в филиалах

С филиалами всегда непросто. Обычно в них нет ИТ-специалистов, поэтому в филиалах сложнее управлять и обеспечивать безопасность среды.

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

В Windows Server 2008 R2 есть несколько функций, которые позволяют решить проблему производительность и безопасности в среде филиалов.

BranchCache

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

Для нормальной работы BranchCache необходимо, чтобы все рабочие станции в филиале работали под управлением Windows 7. Все файловые и веб-серверы в головном офисе должны работать под управлением Windows Server 2008 R2.

BranchCache может работать в одном из двух возможных режимов. Выбор режима в основном определяется размером филиала. Если в филиале менее 50 пользователей, сервер BranchCache не нужен.

В этом случае BranchCache может работать в режиме распределенного кеша.

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

Другой режим BranchCache больше подходит для крупных филиалов и называется режимом размещенного кеша (Hosted Cache Mode).

В этом режиме BranchCache размещается на выделенной машине с Windows Server 2008 R2.

По умолчанию в Windows Server 2008 R2 функциональность BranchCache отключена.

Чтобы включить BranchCache, откройте Server Manager на своем сервере BranchCache, щелкните контейнер Features, а затем — ссылку Add Features.

В списке доступных функций выберите BranchCache (рис. 1), после чего последовательно щелкните Next, Install и Close.

Рис. 1.Включение функциональности BranchCache

Настройка сервера BranchCache

Процедура настройки BranchCache зависит от типа кешируемого контента. BranchCache может кешировать данные файлового сервера, интрасетевого сервера или сервера приложения BITS. Так как чаще всего BranchCache используют для кеширования данных файлового сервера, я расскажу о настройке именно этого варианта.

Сначала на файловых серверах надо включить службу роли BranchCache for Network Files.

Это можно сделать на любом файловом сервере под управлением Windows Server 2008 R2, на котором расположены данные, которые надо кешировать.

Рис. 2. На файловых серверах надо включить службу роли BranchCache for Network Files

Затем надо сконфигурировать сервер BranchCache средствами групповых политик. При наличии только одного сервера BranchCache это можно сделать в локальной политике безопасности этого сервера.

Откройте редактор групповых политик Group Policy Editor и в дереве консоли перейдите к узлу Computer Configuration/Policies/Administrative Templates/Network/Lanman Server. Дважды щелкните политику Hash Publication for BranchCache и включите его, выбрав Enabled.

Нужно выбрать политику «Allow Hash Publications for All File Shares» (Разрешить публикацию хеша для всех общих папок ) или «Allow Hash Publication for File Shares with Windows BranchCache Support» (Разрешить публикацию хеша только для общих папок, для которых включена служба BranchCache) (рис. 3). Выполнив выбор, щелкните ОК.

Рис. 3. Надо разрешить публикацию хешей на общих папках

Надо сразу же настроить на сервере BranchCache пространство на жестком диске, выделяемое для хранения кешируемого контента. По умолчанию BranchCache занимает 5% диска. Желательно увеличить это значение, особенно если это выделенный сервер.

Настройка выделенного пространства на диске предусматривает изменение реестра, поэтому перед этой операцией рекомендуется сделать полную резервную копию системы.

Любые ошибки при изменении реестра могут привести к полной неработоспособности Windows.

Откройте редактор реестра и перейдите к разделу HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters.

Дважды щелкните параметр HashStorageLimitPercent. Укажите, какую долю (в процентах) диска надо выделить под кешируемые данные (рис. 4).

Если параметр HashStorageLimitPercent не существует, его надо создать.

Последнее, что нужно сделать при настройке BranchCache, — включить поддержку BranchCache на общих папках с файлами. Для этого щелкните общую папку и выберите Properties.

На странице свойств папки перейдите к вкладке Sharing и щелкните кнопку Advanced Sharing, а затем — кнопку Caching.

Установите флажки «Only the Files and Programs that Users Specify Are Available Offline» (Только указанные пользователем файлы и программы доступны в автономном режиме) и «Enable BranchCache» (Включить BranchCache) (рис. 5), после чего щелкните OK.

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

Конфигурирование клиентов BranchCache

После включения на сервере функциональности BranchCache, нужно настроить клиентов филиала. Лучше всего для этого использовать групповую политику компьютеров филиала.

В редакторе групповой политики откройте групповые политики, которые управляют параметрами безопасности филиала. В дереве политик перейдите к узлу Computer Configuration/Policies/Administrative Templates/Network/BranchCache.

Здесь есть несколько политик, относящихся к BranchCache. Дважды щелкните параметр Turn on BranchCache, выберите Enabled и щелкните OK. Затем дважды щелкните «Turn on BranchCache — Hosted Cache Mode» выберите Enabled и щелкните OK.

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

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

В некоторых сетях для нормальной работы BranchCache также потребуется задать правило брандмауэра. В режиме размещенного кеша нужно настроить доступ клиентов на прием HTTP-трафика с сервера BranchCache.

ReКонтроллеры доменов только для чтения

Контроллеры доменов только для чтения (RODC) предоставляют дополнительные средства для поддержки конечных пользователей филиала.

Во всех версиях Windows Server, начиная с Windows 2000 Server, использовалась доменная модель со многими хозяевами.

Это означает, что изменения Active Directory можно записывать на любом контроллере домена — далее изменения автоматически реплицируются на все контроллеры данного домена.

Однако нельзя напрямую обновить копию базы данных Active Directory на RODC. Обновления можно записывать только на доступные для записи контроллеры доменов. Эти обновления затем реплицируются на все остальные контроллеры данного домена, в том числе на контроллеры RODC.

Есть две причины преимущества использования RODC в филиале. Первая причина — доступность. Контроллер домена выполняет проверку подлинности запросов на вход в домен.

Если в локальном филиале нет контроллера домена, пользователи филиала должны проходить проверку подлинности на контроллере домена в главном офисе.

Разместив контроллер в филиале, можно избежать такой ситуации. При отказе WAN-канала пользователи все равно смогут проходить проверку подлинности.

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

Часто машину с контроллером домена размещают в слабо защищенном шкафу и практически не обслуживают.

Так как база данных доступна только для чтения, не нужно беспокоиться о том, что кто-то получит физический доступ к контроллеру домена и попытается изменить данные Active Directory, распространив их по все сети. База данных обновляется только тогда, когда на RODC реплицируются обновления с других, полноценных и уполномоченных контроллеров домена.

Еще одна возможность обеспечения безопасности средствами RODC — хранение неполной версии базы данных Active Directory. В базе данных Active Directory обычно хранятся учетные данные все учетных записей пользователей и компьютеров в домене.

Однако по умолчанию RODC не хранят никаких учетных данных пользователей или компьютеров.

Когда пользователь проходит проверку подлинности, решение о том, кешировать ли пользовательский пароль на RODC, принимается на основе политики репликации паролей на RODC.

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

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

Развертывание RODC

Перед развертыванием RODC надо обеспечить, чтобы функциональный уровень леса Active Directory был не ниже Windows Server 2003. Также нужно использовать ADPREP (ADPREP /ForestPrep), чтобы подготовить лес Active Directory, а также домен для размещения RODC (команда ADPREP/DomainPrep /gpprep).

Если домен обслуживается контроллерами под управлением Windows Server 2003, надо выполнить команду ADPREP с параметром /rodcprep.

Не забудьте также до развертывания RODC, что в среде должен быть как минимум один доступный для записи контроллер домена под управлением Windows Server 2008 или 2008 R2.

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

Кешированием учетных записей на RODC управляет политика Password Replication Policy. В сущности это список, который определяет пользователей и группы, учетные данные которых подлежат репликации наRODC. При построении списка вы можете разрешать или запрещать репликацию пароля пользователя или группы.

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

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

Помните, что при противоречии в политиках у запрещений приоритет всегда выше.

Управлять политикой Password Replication Policy можно средствами консоли Active Directory Users and Computers.

Разверните узел контроллера домена, щелкните правой кнопкой значок своего RODC и выберите Properties. Откроется окно свойств RODC.

Параметры политики Password Replication Policy находятся на одноименной вкладке (рис. 7).

Рис. 7. Управление репликацией учетных данных пользователей

Перегрузка WAN-канала может стать серьезной проблемой в филиалах, но развертывание BranchCache и локальных RODC-контроллеров позволяет значительно разгрузить WAN-канал, обеспечив при этом повышение безопасности. Все это позволит значительно повысить удобство работы ваших пользователей в филиалах.

Источник: http://www.interface.ru/home.asp?artId=29316

Обновление Active Directory с Windows Server 2008 R2 до версии Windows Server 2012

В этой статье мы поговорим о процедуре обновления домена с версии Windows Server 2008 R2 до Windows Server 2012 с последующим понижением роли старого контроллера домена до рядового сервера AD.

Итак, что имеется:

• Домен Active Directory как минимум с одним контроллером домена на Windows Server 2008 R2
• Уровень леса и домена AD должен быть как минимум Windows Server 2003
• Дополнительный рядовой сервер домена с Windows Server 2012 , который в дальнейшем станет контроллером домена (как включить сервер в домен подробно описано в статье Как включить Windows 8 в домен).
• Учетная запись с правами администратора домена, схемы и леса.

Прежде чем добавлять новый контроллер домена на Windows 2012 необходимо обновить схему домена и леса. Классически подготовка и повышение уровня домена осуществлялась вручную с помощью утилиты Adprep.exe.

В документации новой серверной платформы от Microsoft указано, что при повышении первого сервера с Windows Server 2012 до уровня контроллера домена, повышение уровня домена происходит автоматически при установке роли AD DS на первый сервер Windows 2012 в домене.

Так что, теоретически, для подготовки домена ничего делать не нужно.

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

Обновление схемы AD до Windows Server 2012 с помощью adprep

Для обновления схемы нам понадобится утилита adprep.exe, взять которую можно в каталоге \support\adprep\ на диске с дистрибутивом Windows Server 2012.

Данная утилита бывает только 64-разрадной (утилиты adprep32.

exe больше не существует), соответственно, запустить ее можно будет только на 64 разрядном контроллере домена.

adprep /forestprep

Версия схемы Active Directory в Windows Server 2012 — 56.

Далее обновим схему домена:

adprep /domainprep

Далее осталось дожидаться окончания репликации изменений в схеме по всему лесу и проверить существующие контроллеры домена на наличие ошибок. Если все прошло хорошо – продолжаем. Пришла пора развернуть контроллер домена на Windows Server 2012.

Установка контроллер домена на Windows Server 2012

Первой интересной новостью является тот факт, что знакомой администраторам утилиты DCPROMO, позволяющей добавить или удалить контроллер домена в AD больше не существует. При ее запуске появляется окно, в котором сообщается, что мастер установки Active Directory Domain Services перемещен в консоль Server Manager.

Что ж, откроем консоль Server Manager и установим роль Active Directory Domain Services (Внимание! Установка роли автоматически не означает тот факт, что сервер стал контроллером домена, роль нужно сначала настроить)

Затем нужно указать, что данный контроллер домена будет добавлен в уже существующий домен (Add a domain controller to an existing domain), указать имя домен и учетную запись из-под которой будет проводится операция.

Затем укажите, что данный контроллер домена будет содержать роли GC (Global Catalog) и DNS сервера. Также укажите пароль восстановления DSRM (Directory Services Restore Mode) и, если необходимо имя сайта, к которому будет относиться данный контроллер домена.

В разделе “Paths” указываются пути к базе Active Directory (NTDS), файлам логов и каталогу SYSVOL.

По окончании работы мастера установки роли AD DS, сервер нужно перезагрузить. После перезагрузки  вы получаете новый контроллер домена с ОС Windows Server 2012.

Удаление старого контроллера домена на Windows Server 2008 R2

Прежде, чем понизить роль старого контроллера домена с Windows Server 2008 R2 до рядового сервера, нужно перенести все FSMO роли на новый контроллер домена .

Процедура переноса ролей FSMO с одного контролера домена на другой нами уже рассматривалась,  подробнее с ней можно познакомится в статье Передача ролей FSMO в Active Directory. Процедуру можно осуществить через графический GUI (проще) или из командной строки с помощью утилиты ntdsutil

После передачи роли FSMO PDC Emulator, необходимо настроить синхронизацию времени на новом контроллере домена с внешним сервером (с которым время синхронизировалось ранее).

Подробно процедура настройки синхронизации времени на PDC описана в статье: Синхронизация времени с внешним NTP сервером в Windows 2008 R2 .

Формат команды примерно такой (ntp_server_adress – адрес NTP сервера):

w32tm /config /manualpeerlist:ntp_server_adress /syncfromflags:manual /reliable:yes /update

После того, как все роли FSMO перенесены на новый DC Windows Server 2012, убедитесь, что домен работает корректно: проверьте прохождение репликации AD, журналы DNS и AD на наличие ошибки. Не забудьте в настройках сетевой карты на новом сервере в качестве предпочтительного DNS сервера указать собственный адрес.

Если все прошло корректно, можно понизить роль старого контроллера домена 2008 R2  до рядового сервера домена.

Это можно сделать, запустив на нем мастер DCPROMO, и указать, что данный сервер  более не является контроллером домена.

Источник: http://winitpro.ru/index.php/2012/12/13/obnovlenie-active-directory-s-windows-server-2008-r2-do-versii-windows-server-2012/

Создание и настройка групповых политик в Windows Server 2008 R2

Данное руководство представляет собой пошаговую инструкцию по созданию и настройке локальной групповой политики, а также групповых политик на уровне доменов и подразделений в Windows Server 2008 R2.

Групповые политики – это набор правил, обеспечивающих инфраструктуру, в которой администраторы локальных компьютеров и доменных служб Active Directory могут централизовано развертывать и управлять настройками пользователей и компьютеров в организации.

Все настройки учетных записей, операционной системы, аудита, системного реестра, параметров безопасности, установки программного обеспечения и прочие параметры развертываются и обновляются в рамках домена при помощи параметров объектов групповой политики GPO (Group Policy Object).

I. Область действия групповых политик

Все групповые политики имеют свою область действия (scope), которая определяет границы влияния политики. Области действия групповых политик условно можно разделить на четыре типа:

Локальные групповые политики

Групповые политики, применяемые к локальному компьютеру, или локальные групповые политики.

Эти политики настраиваются в оснастке «Редактор локальных групповых политик» и применяются только к тому компьютеру, на котором они были настроены.

Они не имеют механизма централизованного развертывания и управления и, по сути, не являются групповыми политиками.

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

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

Групповые политики подразделения

Политики, применяемые к подразделению (Organizational Unit policy, сокр. OU) и оказывающие влияние на все содержимое данного OU и дочерних OU (при их наличии).

Групповые политики сайтов

Сайты в AD используются для представления  физической структуры организации. Границы сайта определяются одной или несколькими IP-подсетями, которые объединены высокоскоростными каналами связи.

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

II. Порядок применения и приоритет групповых политик

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

Первыми применяются Локальные политики, затем Групповые политики сайтов, затем отрабатывают Доменные политики и затем OU политики.

Если на одну OU назначено несколько GPO, то они обрабатываются в том порядке, в котором были назначены (Link Order).

При этом нижестоящие политики могут переопределять вышестоящие — например Локальная политика будет переопределена Доменной политикой сайта, Доменная политика — политикой OU, а политика вышестоящего OU — нижестоящими политиками OU.

III. Создание локальной групповой политики

1. Для создания локальной групповой политики зайдите на рабочую станцию, нажмите Пуск, в поле поиска введите Выполнить, затем, в поисковой выдаче, выберите Выполнить (Рис.1).

Рис.1

.

2. В открывшемся окне введите в поле gpedit.msc, затем нажмите OK (Рис.2).

Рис.2

.

3. В открывшемся окне Вы увидите две основные категории параметров групповой политики — параметры конфигурации компьютера и параметры конфигурации пользователя.

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

Параметры конфигурации пользователя действуют только в отношении конкретно заданных пользователей (Рис.3).

Рис.3

.

4.

 Выберите: Конфигурация пользователя > Административные шаблоны >Рабочий стол >Active Desktop.

 В правой колонке выберите Фоновые рисунки рабочего стола и нажмите Изменить (меню вызывается через правую кнопку мыши) (Рис.4).

Рис.4

.

5.

В появившемся окне выберите пункт Включить, затем в поле Имя фонового рисунка введите путь к фоновому рисунку (прим.

Рис.5

.

6. После перезагрузки компьютера Вы увидите, что политика отработала и фон рабочего изменился (Рис.6).

Рис.6

.

IV. Создание и настройка групповой политики на уровне домена

1. Для создания групповой политики на уровне домена зайдите на сервер, выберите Пуск > Администрирование >Управление групповой политикой (Рис.7).

Рис.7

.

2. Выберите домен (прим. в данном руководстве это example.local), через правую кнопку мыши вызовите меню, в котором выберите Создать объект групповой политики в этом домене и связать его… (Рис.8).

Рис.8

.

3. В появившемся окне выберите, в соответствующем поле, имя новой групповой политики (прим. в данном руководстве это GPO-1), затем нажмите ОК (Рис.9).

Рис.9

.

4.

Выберите созданную групповую политику (прим. GPO-1), через правую кнопку мыши вызовите меню, в котором выберите Изменить (Рис.10).

Рис.10

.

5.

Выберите: Конфигурация пользователя >Политики >Административные шаблоны >Рабочий стол >Active Desktop. В правой колонке выберите Фоновые рисунки рабочего стола и нажмите Изменить (меню вызывается через правую кнопку мыши) (Рис.11).

Рис.11

.

6. В появившемся окне выберите пункт Включить, затем в поле Имя фонового рисунка введите путь к фоновому рисунку (прим.

в данном примере это C:\Yellow_Domain_GPO-1.jpg), после чего нажмите Применить и ОК.

Затем перезагрузите компьютер на котором ранее устанавливали локальную групповую политику (Рис.12).

Рис.12

.

7.

После перезагрузки компьютера Вы увидите, что групповая политика домена отработала и фон рабочего стола на компьютере изменился (прим.

на компьютере доменные политики успешно применились и переопределили настройки, задаваемые локальными политиками. Т.о.

установленный локальной политикой зеленый фон был переопределён и, в соответствии с доменной политикой, стал жёлтым) (Рис.13).

Рис.13

.

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

1. Для создания групповой политики на уровне подразделения (Organizational Unit policy, сокр. OU) зайдите на сервер, выберите Пуск > Администрирование >Управление групповой политикой (Рис.14).

Рис.14

.

2. Выберите домен (прим. в данном руководстве это example.local), через правую кнопку мыши вызовите меню, в котором выберите Создать подразделение (Рис.15).

Рис.15

.

3. В появившемся окне выберите, в соответствующем поле, имя нового подразделения (прим. в данном руководстве это OU-1), затем нажмите ОК (Рис.16).

Рис.16

.

4.

Выберите созданное подразделение (прим. OU-1), через правую кнопку мыши вызовите меню, в котором выберите Создать объект групповой политики в этом домене и связать его… (Рис.17).

Рис.17

.

5.

В появившемся окне выберите, в соответствующем поле, имя новой групповой политики (прим. в данном руководстве это GPO-2), затем нажмите ОК (Рис.18).

Рис.18

.

6. Выберите созданную групповую политику (прим. GPO-2), через правую кнопку мыши вызовите меню, в котором выберите Изменить (Рис.19).

Рис.19

.

7.

Выберите: Конфигурация пользователя >Политики >Административные шаблоны >Рабочий стол >Active Desktop. В правой колонке выберите Фоновые рисунки рабочего стола и нажмите Изменить (меню вызывается через правую кнопку мыши) (Рис.20).

Рис.20

.

8. В появившемся окне выберите пункт Включить, затем в поле Имя фонового рисунка введите путь к фоновому рисунку (прим.

в данном примере это Red_OU_OU-1_GPO-2.jpg), после чего нажмите Применить и ОК. Затем перезагрузите компьютер на котором ранее устанавливали локальную групповую политику (прим.

на этом же компьютере она была переопределена доменной групповой политикой) (Рис.21).

Рис.21

.

9. После перезагрузки компьютера Вы увидите, что доменная политика (GPO-1) переопределена политикой (GPO-2), назначенной на OU. (Т.о.

установленный локальной политикой зеленый фон был переопределён и, в соответствии с доменной политикой, стал жёлтым, после чего доменная политика была переопределена политикой OU и фон стал красным) (Рис.22).

Рис.22

.

VI. Наследование в групповых политиках

1. На все политики в домене распространяется наследование, т.е. политики, назначенные на родительский контейнер (домен или OU), последовательно применяются ко всем дочерним контейнерам.

 При необходимости это можно изменить, отключив наследование для отдельно взятого OU. Для этого необходимо перейти в управление групповой политикой (прим. Пуск > Администрирование > Управление групповой политикой), выбрать нужное OU (прим.

в данном руководстве это OU-1), кликнуть на нем правой клавишей мыши и в контекстном меню отметить пункт Блокировать наследование.

 После этого для данного OU и его дочерних OU (при их наличии) отменяется воздействие всех вышестоящих политик (Рис.23).

Рис.23

.

VII. Форсирование применения групповых политик

1. Форсирование применения групповых политик применяется тогда, когда данная политика должна отработать независимо от остальных политик.

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

 Чтобы форсировать политику, необходимо перейти в управление групповой политикой (прим. Пуск > Администрирование > Управление групповой политикой), выбрать нужную политику (прим.

в данном руководстве это GPO-1), кликнуть на ней правой клавишей мыши и в контекстном меню отметить пункт Принудительный (Рис.24).

Рис.24

.

 Надеемся, что данное руководство помогло Вам! 

.

Похожее

Источник: https://lyapidov.ru/creating-and-configuring-gpo-in-windows-server-2008-r2/

Применение групповых политик (часть 3)

Применение групповых политик (часть 3)

Обычно объекты групповой политики назначаются на контейнер (домен, сайт или OU) и применяются ко всем объектам в этом контейнере.

При грамотно организованной структуре домена этого вполне достаточно, однако иногда требуется дополнительно ограничить применение политик определенной группой объектов.

Для этого можно использовать два типа фильтров.

Фильтры безопасности

Фильтры безопасности позволяют ограничить применение политик определенной группой безопасности.

Для примера возьмем GPO2, с помощью которого производится централизованная настройка меню Пуск на рабочих станциях с Windows 8.1\Windows 10.

GPO2 назначен на OU Employees и применяется ко всем без исключения пользователям.

Теперь перейдем на вкладку «Scope», где в разделе «Security Filtering» указаны группы, к которым может быть применен данный GPO.

По умолчанию здесь указывается группа Authenticated Users.

Это означает, что политика может быть применена к любому пользователю или компьютеру, успешно прошедшему аутентификацию в домене.

На самом деле каждый GPO имеет свой список доступа, который можно увидеть на вкладке «Delegation».

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

Так в нашем примере политика может применяться только к группе Accounting.

WMI фильтры

Windows Management Instrumentation (WMI) — один из наиболее мощных инструментов для управления операционной системой Windows.

WMI содержит огромное количество классов, с помощью которых можно описать практически любые параметры пользователя и компьютера.

Посмотреть все имеющиеся классы WMI в виде списка можно с помощью PowerShell, выполнив команду:

Get-WmiObject -List

Для примера возьмем класс Win32_OperatingSystem, который отвечает за свойства операционной системы.

Предположим, что требуется отфильтровать все операционные системы кроме Windows 10.

Заходим на компьютер с установленной Window 10, открываем консоль PowerShell и выводим имя, версию и тип операционной системы с помощью команды:

Get-WmiObject -Class Win32_OperatingSystem | fl Name, Version, ProductType

Для фильтра используем версию и тип ОС. Версия одинакова для клиентских и серверных ОС и определяется так:

• Window Server 2016\Windows 10 — 10.0• Window Server 2012 R2\Windows 8.1 — 6.3• Window Server 2012\Windows 8 — 6.2• Window Server 2008 R2\Windows 7 — 6.1

• Window Server 2008\Windows Vista — 6.0

Тип продукта отвечает за назначение компьютера и может иметь 3 значения:

• 1 — рабочая станция;• 2 — контроллер домена;

• 3 — сервер.

В открывшемся окне даем фильтру имя и описание. Затем жмем кнопку «Add» и поле «Query» вводим WQL запрос, который и является основой WMI фильтра. Нам необходимо отобрать ОС версии 10.0 с типом 1, соответственно запрос будет выглядеть так:

SELECT * FROM Win32_OperatingSystem WHERE Version ″10.0%″ AND ProductType = ″1″

Примечание. Windows Query Language (WQL) — язык запросов WMI. Подробнее о нем можно узнать на MSDN.

Сохраняем получившийся фильтр.

Теперь осталось только назначить WMI фильтр на объект групповой политики, например на GPO3. Переходим к свойствам GPO, открываем вкладку «Scope» и в поле «WMI Filtering» выбираем из списка  нужный фильтр.

Анализ применения групповых политик

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

Для примера зайдем на компьютер wks2, на котором установлена ОС Windows 7, и проверим, сработал ли WMI фильтр.

Для этого открываем консоль cmd с правами администратора и выполняем команду gpresult /r, которая выводит суммарную информацию о групповых политиках, примененных к пользователю и  компьютеру.

Примечание. Утилита gpresult имеет множество настроек, посмотреть которые можно командой gpresult /?.

Также проверить действие GPO можно из оснастки «Group Policy Management», с помощью специального мастера. Для запуска мастера кликаем правой клавишей мыши на разделе «Group Policy Results» и в открывшемся меню выбираем пункт «Group Policy Results Wizard».

Указываем имя компьютера, для которого будет составлен отчет. Если требуется просмотреть только пользовательские настройки групповой политики, то настройки для компьютера можно не собирать. Для этого необходимо поставить галочку снизу (display user policy settings only).

Проверяем выбранные настройки, жмем «Next» и ждем, пока собираются данные и генерируется отчет.

Отчет содержит исчерпывающие данные об объектах групповых политик, примененных (или не примененных) к пользователю и компьютеру, а также об используемых фильтрах.

Для примера составим отчеты для двух разных пользователей и сравним их. Первым откроем отчет для пользователя Kirill и перейдем в раздел настроек пользователя. Как видите, к этому пользователю не применилась политика GPO2, поскольку у него нет прав на ее применение (Reason Denied — Inaсcessible).

А теперь откроем отчет для пользователя Oleg. Этот пользователь является членом группы Accounting, поэтому к нему политика была успешно применена. Это означает, что фильтр безопасности успешно отработал.

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

Источник: https://windowsnotes.ru/activedirectory/primenenie-gruppovyx-politik-chast-3/

Просто о сложном

14.04.2011

Dmitry Bulanov Групповые политики, Windows Server 2008/2008 R2

Введение

 Из моих статей, возможно, вы уже многое узнали о технологии групповой политики. Например, в статье «Управление групповыми политиками в организации. Часть 2» были подробно расписаны связи объектов групповой политики, а в статье «Управление групповыми политиками в организации.

Часть 3» было рассказано о приоритетах объектов GPO и о делегировании разрешений для объектов групповой политики.

Соответственно, вы помните, что приоритет объекта групповой политики определяет, какой параметр политики будет применен к клиенту, а именно то, что если вы создадите объекты групповой политики и привяжите их к сайту, домену и подразделениям, то эти объекты GPO будут наследоваться на подразделения более низкого уровня, где объект GPO с более высоким приоритетом, будет иметь привилегии над объектами групповой политики с более низким приоритетом. Другими словами, при запуске клиентского компьютера, клиент групповой политики анализирует размещение объекта компьютера или пользователя в Active Directory и применяет политики в следующем порядке: объекты GPO, связанные с сайтом, затем с доменом, после чего с родительским подразделением первого уровня, а потом с подразделением, где расположен объект пользователя или компьютера. Кумулятивным результатом такого применения объектов групповой политики называется наследование политики. Но ни в одной статье не было рассказано о таком важном свойстве, как блокирование наследования, о чем, собственно, и пойдет речь в данной небольшой статье.

Больше

Dmitry Bulanov Групповые политики, Предпочтения групповой политики, Windows 7, Windows Server 2008/2008 R2

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

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

Больше

13.03.2011

Dmitry Bulanov Групповые политики, Совет недели, Windows 7, Windows Server 2008/2008 R2

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

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

В предыдущих девяти советах недели было рассмотрено использование настраиваемого фона входа в систему, настройка экрана входа в систему пользователей, предопределение языковых стандартов, журналирование брандмауэра Windows в режиме повышенной безопасности, ограничения проводника Windows, настройка персонализации, настройка групповых политик, управление электропитанием, а также настройка удаления программ и компонентов Windows. Также хотелось бы отметить тот момент, что в предыдущих статьях было рассмотрено изменение 44 параметров групповой политики, расположенных в узле «Административные шаблоны», а также были вкратце рассмотрены некоторые параметры групповой политики брандмауэра Windows в режиме повышенной безопасности, которые можно найти в узле «Конфигурация Windows» родительского узла «Конфигурация компьютера». Пожалуй, единственный совет недели, который не полностью раскрыл все настройки параметров групповой политики по своей теме, был совет недели №8, где рассматривались параметры управления электропитанием. В этой статье были рассмотрены узлы «Параметры экрана и видео», а также «Параметры уведомления».

Больше

13.03.2011

Dmitry Bulanov Active Directory, Групповые политики, Планирование Active Directory, Windows Server 2008/2008 R2