Групповые политики.


07.07.2017

Знакомство с Windows Server 2016. Групповые политики.

Как по-простому сказать, что такое "Групповые политики"? Давайте начнём с того зачем оно вообще нужно. И самый простой пример, который приходит на ум это - как сделать чтобы у определённой группы пользователей организации автоматически проходило обновление windows или же подключался сетевой диск. Это масштабный инструмент для управления поведением компьютеров и учётных записей! Если отойти от абстракций, то дело мы тут имеем с "Объектами групповых политик" или "GPO". Которые в свою очередь применяются на "подразделения" или "OU". Каждый объект групповых политик состоит из двух разделов - настройка поведения компьютера и настройка поведения учётной записи. И соответственно часть про компьютер влияют только на поведение системы и начинает действовать сразу после загрузки операционной системы, а часть настроек учётной записи начинает действовать после авторизации и влияет только на параметры пользователя. То есть если мы пристыкуем (прилинкуем) объект групповой политики, в котором настроены параметры для компьютера, к подразделению в котором только пользователи, то эффекта не будет. Перейдём к практике.

Запустим машину DC и в диспетчере сервера зайдём в "Средства" - "Управление групповой политикой"

Давайте создадим наш первый объект групповой политики. Жмём правой кнопкой по разделу "Объекты групповой политики" и выбираем "Создать".

Мы создадим политику обновления windows. Назовём её "win update".

Теперь давайте отредактируем наш объект групповой политики. Жмём по нему правой кнопкой и выбираем "Изменить". И нам открывается "редактор управления групповыми политиками"

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

Далее мы идём - В разделе "Конфигурация компьютера" - "Политики" - "Административные шаблоны" - "Компоненты Windows"

Затем в "Компонентах Windows" - "Центр обновления Windows"

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

Рассмотрим три основных переключателя в этом диалоге.
"Не задано" - Использование автоматического обновления не задано, но при этом Администратор машины может настроить автоматическое обновление через панель управления.
"Включено" - и тут мы можем выбрать разрешающее действие:
- уведомлять о загрузке и установке
- автоматическая загрузка с уведомлением об установке
- автоматическая загрузка и установка
- Разрешить администратору выбирать параметры

"Отключено" - Это полная блокировка обновления Windows, даже для локального администратора. Оставим блокировку обновлений в этом объекте и нажмём "OK"

Далее просто закрываем диалог и обратим внимание на раздел "Параметры" нашего объекта групповой политики "win update". Здесь мы можем видеть обзор всех изменений данной политики:

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

Давайте применим нашу групповую политику. Откроем раздел "Пользователи и компьютеры" - перейдём в созданное нами ранее подразделение "mrstudio" - в нём зайдём в подразделение "Computers" - видим только один компьютер "Gateway". Но вот так пока в нашем тестовом стенде - только один компьютер.

Теперь вернёмся в управление групповой политикой - здесь мы можем видеть то самое подразделение "mrstudio" так же, как и в разделе "Пользователи и компьютеры".

Как применить наш объект групповой политики "win update" к подразделению "mrstudio"? Мы можем:
- Просто перетащить левой кнопкой политику на подразделение (или OU). И согласиться связать выбранный объект политики с этим подразделением.

- Мы можем через контекстное меню подразделения выбрать пункт "Связать существующий объект групповой политики" и далее выбрать соответствующую политику.

И теперь можно наблюдать ярлык от нашей политики прямо в самом подразделении:

Теперь у нас все компьютеры, которые мы включили в подразделение "mrstudio" остались без обновления, подчёркиваю, что только компьютеры, на пользователей данная политика не распространится. Давайте это проверим. Перейдём на машину "Gateway". Так как разработчики Microsoft убрали классическое приложение Центр обновлений Windows из панели управления. То мы пойдём в Меню Пуск - Параметры - Обновление и безопасность - пункт «Центр обновления Windows». И мы тут видим не очень понятную картину, нет явного указания что Windows не будет обновляться.

Давайте попробуем на другой машине с Windows 7. Для начала введём систему в домен:
- Проверим сработал ли DHCP-сервер, раздал ли он адрес нашему новому компьютеру. И в результате я наблюдаю что мой DHCP-сервер на виртуальном "Gateway" не работает. Заходим на машину "Gateway" в оснастке "DHCP" наблюдаем красные стрелочки, говорящие о том что DHCP не работает.

Причину нужно выяснить, потому как без работающего DHCP сеть наша не функциональна, можно конечно вручную прописать адрес на тестируемом клиенте с Windows 7 и ввести его в домен, но у нас нарисовалась проблема и её надо решить.
Причиной может стать то что наша машина Gateway где крутиться DHCP-сервер не видит контроллер домена. Проверим пинг:

Пинг есть. Давайте просто кликнем по разделу DHCP в панели мониторинга. И тут мы видим, что служба DHCP не авторизована для запуска:

Вернёмся в настройку DHCP. Выделяем самый верхний пункт в дереве "DHCP"

Справа находим пункт "Дополнительные действия"

Кликаем по пункту Список авторизованных серверов

И наблюдаем что нет авторизованных серверов

Хорошо давайте авторизуем наш DHCP-сервер "Gateway.mrstudio.local" с адресом 192.168.1.1. и в результате нам сообщение что службе DHCP не удалось обратиться к Active Directory. И это при том что пинг до контроллера идёт.

И вот почитав внимательно ошибку снизошло озарение. Оказывается, DHCP-сервер не работал потому -что был в домене! После того как я вывел из домена машину Gateway, DHCP-сервер снова заработал.

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

Запускаем настройки сети и видим, что наш DHCP-сервер успешно раздал адрес "192.168.1.100" нашему клиенту. Есть правильный адрес DNS-сервера и значит мы можем вводить машину в домен.

Перезагружаем нашего клиента. Заходим под доменной учёткой "ermakova@mrstudio.local". Заходим в панель управления - Центр обновления Windows - и наблюдаем что политика не работает:

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

Вводим команду "gpupdate /force" и ждём успешного выполнения:

Заходим в панель управления и видим, что обновления по-прежнему доступны. Как же так? Давайте вернёмся к контроллеру домена и зайдём в оснастку "Active Directory - пользователи и компьютеры". И тут, как положено, наш "COMP1" успешно обосновался в контейнере "Computers" нашего домена "mrstudio.local".

Но, для начала - политика не применяется к простому контейнеру, за исключением, когда контейнер находится внутри подразделения. А ещё политику то мы применили к подразделению "mrstudio" а наш "COMP1" очевидно не в ней! Поэтому берём и тащим его в оюшку (OU –Organization Unit или Подразделение) "Computers" в оюшке "mrstudio", к которой у нас и применена политика "win update"

Перезагружаем наш "COMP1" или можно было вызвать "cmd" от администратора и выполнить команду "gpupdate /force". Заходим в панель управления и вот оно - сработало.

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

Кликнув левой кнопкой по подразделению в оснастке "Управление групповой политикой" мы можем посмотреть какие политики и с каким приоритетом будут действовать на данное подразделение. На данный момент есть только одна политика "win update" и имеет она приоритет "1".

Если бы тут было ещё одна политика, которая наоборот разрешает обновления, но с приоритетом "2", то действовала бы всё равно запрещающая политика так как у неё самый высокий приоритет -"1".

А теперь давайте проведём эксперимент - Оставим запрещающую политику для подразделения "mrstudio", а разрешающую политику привяжем к подразделению "Computers".

И при таком раскладе мы имеем разрешённые обновления, потому что приоритет наследования не в пользу подразделения которое выше, а наоборот в пользу подразделения на которое и применена политика - это видно из вкладки "Наследование групповой политикой":

Кстати, наследование политик от "родительских" подразделений можно заблокировать - достаточно просто нажать правой кнопкой по нужному подразделению и выбрать "Блокировать наследование":

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

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

На скриншоте выше мы видим что у подразделения "mrstudio" включено блокирование наследия (восклицательный знак в синем кружочке) но тем не менее на вкладке наследования мы видим что в приоритете политика "win update allow", которая привязана на верхнем уровне к самому домену "mrstudio.local" и это происходит потому что политика "win update allow" имеет статус "принудительной" ((enforced) значок жёлтого замочка в ярлыке политики).

Подробную информацию о политике можно найти на вкладке "Сведения", кликнув по политике либо по её ярлыку в подразделении. Тут же, в разделе "Состояние GPO" можно отключить функционал политики, распространяющийся либо на компьютер, либо на пользователя.

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

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

В самом низу - "Windows Management Interface Фильтр" или "Фильтр WMI". Его нужно предварительно создать в соответствующем разделе оснастки "управления групповой политикой"

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

Ну а теперь давайте попробуем настройки пользователя, т.е. не политики, а именно настройки - то есть то что пользователь может изменить. Создадим объект групповой политики, который будет создавать каталог "Expo" на диске "C:\".
Назовём политику "make expo".

Далее жмём правой кнопкой по политике - изменить - "Конфигурация пользователя" - "Настройка" - "Конфигурация Windows" - "Папки":

Создаём папку:

Прописываем путь "C:\Expo", Действие выбираем - "Создать". Далее во вкладке "Общие параметры" ставим чек на пунктах "Выполнять в контексте безопасности вошедшего пользователя" - это для того чтобы владельцем созданного каталога был сам пользователь, а не система, и "Применить один раз и не применять повторно" - это для того чтобы каталог не создавался заново при каждой авторизации.

Далее не забудем прилинковать политику к подразделению, в моём случае "mrstudio". Запускаем клиента, авторизуемся под доменным пользователем, и наблюдаем созданный политикой каталог "Expo".

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

Все применяемые политики на клиенте мы можем посмотреть, выполнив в консоли команду "gpresult /h gp_report.html". Давайте это сделаем:

Запускаем консоль, затем вводим команду "gpresult /h C:\Expo\gp_report.html". Команда создаст отчёт в созданном нами ранее каталоге "Expo".