Почему не применяется групповая политика к компьютеру или OU?
В этой обзорной статье я постараюсь разобрать типовые причины, из-за которых та или иная групповая политика может не применяться к подразделению (OU) или конкретному компьютеру / пользователю. Я думаю эта статья будет полезна как новичкам, так и профессионалам групповых политик AD для понимания принципов работы и архитектуры GPO. В первую очередь в статье я расскажу о возможных проблемах применения GPO, связанные с настройками самих политик на уровне домена, а не о траблшутинге применения GPO на клиентах. Практически все настройки, описанные в статье, выполняются в консоли редактора доменных групповых политик — Group Policy Management Console (GPMC.msc).
Область действия (scope) GPO
Если некой параметр политики не применятся на клиенте, проверьте область действия (scope) групповой политики. Если вы настраиваете параметр в секции Конфигурация компьютера (Computer Configuration), значит ваша групповая политика должна быть привязана к OU с компьютерами. Соответственно, если настраиваемый параметр относится к Конфигурация пользователя (User configuration).
Также проверьте, что объект, к которому вы пытаетесь применить политику находится в нужном OU с компьютерами или пользователями. Можно воспользоваться поиском по домену. OU, в котором находится объект содержится на вкладке Object в консоли ADUC.
Т.е целевой объект должен находится в OU, на который назначена политика (или во вложенном контейнере).
Фильтр безопасности GPO
Проверьте значение фильтра безопасности политики (Security Filtering). По-умолчанию на всех новых объектах GPO в домене присутствуют разрешения для группы «Authenticated Users«. Эта группа включает в себя всех пользователей и компьютеры домена. Это означает, что данная политика будет применяться на всех пользователях и ПК, которые попадают в область ее действия.
Если вы используете нестандартные фильтры безопасности политик, проверьте, что для целевых групп нет явного запрета на применение GPO (Deny).
WMI фильтры GPO
В групповых политиках можно использовать специальные WMI фильтры. Это позволяет применить политику к компьютерам на основании некоторого WMI запроса. Например, мы можете создать WMI фильтр GPO для применения политики только к компьютерам с определенной версией Windows, к ПК в определенной IP подсети, только к ноутбукам и т.д.
При использовании WMI фильтров групповых политик вам нужно проверить корректность WMI запроса, который выбирает только те системы, которые вам нужны и не исключаются ваши целевые компьютеры. Вы можете протестировать WMI фильтр на компьютерах через PowerShell
Если запрос возвращает любые данные, значит WMI фильтр применится к этому компьютеру.
Статус групповой политики
Проверьте статус групповой политики, перейдя в консоли GPMC.msc в свойствах политики на вкладку Details. Обратите внимание на значение в поле GPO Status.
Как вы видите, доступно 4 варианта:
Делегирование GPO
На вкладке политики Delegation указаны разрешения, настроенные для данной групповой политики. Здесь можно увидеть каким группам даны права на изменения настроек GPO, а также на разрешение или запрет применения политики. Вы можете предоставить права на управление GPO из этой консоли или с помощью мастера делегирования в ADUC. Кроме того, наличие строки доступа для Enterprise Domain Controllers определяет возможность репликации данной политики между контроллерами домена Active Directory (это нужно иметь в виду при наличии проблем с репликацией политики между DC). Обратите внимание, что права на вкладке Delegation соответствуют NTFS правам, назначенным на каталог политики в папке SYSVOL
Наследование групповых политик
Наследование это одна из основных концепции групповых политик. Политики верхнего уровня по-умолчанию применяются ко всем вложенным объектам в иерархии домена. Однако, администратор может заблокировать применение всех наследованных политик на определенный OU. Для этого в консоли GPMC нужно щелкнуть ПКМ по OU и выбрать пункт меню Block inheritance.
Организационные подразделения с отключенным наследованием политик в консоли отображаются с синим восклицательным знаком.
Если политика не применяются на клиенте, проверьте, не находится ли он в OU с отключенным наследованием.
Имейте в виду, что доменные политики, для которых включено свойства “Enforced”, применяются даже на OU с отключённым наследованием (наследованные политики, которые применяются к контейнеру доступны на вкладке Group Policy Inheritance).
Область действия и порядок применения групповых политик (LSDOU)
Чтобы запомнить особенности порядка применения групповых политик в домене, нужно запомнить аббревиатуру LSDOU. Это аббревиатура позволяет запомнить порядок применения GPO:
Последние политики имеют наивысший приоритет. Т.е. если вы включили некий параметр Windows на уровне политики домена, но на целевом OU данный параметр отключается другой политикой – это означает, что нужный параметр в результате будет отключен на клиенте (выиграет ближайшая политика к объекту в иерархии AD).
При использовании параметра Forced у GPO выигрывает та, политика находится выше в иерархии домена (например, при включении Forced у политики Default Domain Policy, она выигрывает у всех других GPO).
Кроме того, администратор может изменить порядок обработки политик (Link Order) в консоли GPMC. Для этого нужно выбрать OU и перейти на вкладку Linked Group Policy Objects. В списке содержаться список GPO, которые применяются к данной OU с указанием приоритета. Политики обрабатываются в обратном порядке (снизу-вверх). Это означает что политика с Link Order 1 выполнится последней. Вы можете изменить приоритет GPO с помощью стрелок в левом столбце, передвинув ее выше или ниже в списке.
GPO Link Enabled
У каждого объекта GPO, который привязан к организационному контейнеру AD вы можете включить или отключить связь (применение политики). Для этого нужно включить или отключить опцию Связь включена (Link Enabled) в меню политики. Если связь для политики отключена, ее иконка становится бледной. При отключении связи политика перестает применяться к клиентам, но ссылка на объект GPO не удаляется из иерархии. Вы можете активировать данную связь в любой момент.
Замыкание групповой политики
У этой политики есть два возможных значение:
Диагностика применения GPO на стороне клиента
Также можете познакомиться со статей, описывающей принципы диагностики при слишком долгом применении политик на клиентах.
В заключении хочется сказать, что следует держать структуру групповых политик как можно более простым и не создавать лишние политик без необходимости. Используйте единую схему именование политик, имя GPO должно давать однозначное понимание того, для чего она нужна.
Групповые политики (GPO) Active Directory: разбираемся почему это важно и как ими управлять в GPOAdmin
Групповая политика — важный элемент любой среды Microsoft Active Directory (AD). Её основная цель — дать ИТ-администраторам возможность централизованно управлять пользователями и компьютерами в домене. Групповая политика, в свою очередь, состоит из набора политик, называемых объектами групповой политики (GPO). У Microsoft реализованы тысячи разных политик и настроек, в которых можно утонуть и потом не всплыть. Все они подробно описаны в справочной таблице.
В этой статье мы расскажем о работах по настройке групповых политик и удобном инструменте для упрощения управления ими — Quest GPOAdmin. Подробности под катом.
Как устроены групповые политики
При создании домена AD автоматически создаются два объекта групповой политики:
Политика домена по умолчанию устанавливает базовые параметры для всех пользователей и компьютеров в домене в трех плоскостях: политика паролей, политика блокировки учетных записей и политика Kerberos.
Политика контроллеров домена по умолчанию устанавливает базовые параметры безопасности и аудита для всех контроллеров домена в рамках домена.
Для вступления настроек в силу, объект групповой политики необходимо применить (связать) с одним или несколькими контейнерами Active Directory: сайт, домен или подразделение (OU). Например, можно использовать групповую политику, чтобы потребовать от всех пользователей в определённом домене использовать более сложные пароли или запретить использование съемных носителей на всех компьютерах только в финансовом подразделении данного домена.
Объект групповой политики не действует, пока не будет связан с контейнером Active Directory, например, сайтом, доменом или подразделением. Любой объект групповой политики может быть связан с несколькими контейнерами, и, наоборот, с конкретным контейнером может быть связано несколько объектов групповой политики. Кроме того, контейнеры наследуют объекты групповой политики, например, объект групповой политики, связанный с подразделением, применяется ко всем пользователям и компьютерам в его дочерних подразделениях. Аналогичным образом, объект групповой политики, применяемый к OU, применяется не только ко всем пользователям и компьютерам в этом OU, но и наследуется всем пользователям и компьютерам в дочерних OU.
Настройки различных объектов групповой политики могут перекрываться или конфликтовать. По умолчанию объекты групповой политики обрабатываются в следующем порядке (причем созданные позднее имеют приоритет над созданными ранее):
Изменение последовательности GPO. Объект групповой политики, созданный позднее, обрабатывается последним и имеет наивысший приоритет, перезаписывая настройки в созданных ранее объектах. Это работает в случае возникновения конфликтов.
Блокирование наследования. По умолчанию дочерние объекты наследуют все объекты групповой политики от родительского, но вы можете заблокировать это наследование.
Принудительное игнорирование связи GPO. По умолчанию параметры родительских политик перезаписываются любыми конфликтующими политиками дочерних объектов. Вы можете переопределить это поведение.
Отключение связей GPO. По умолчанию, обработка включена для всех связей GPO. Вы можете предотвратить применение объекта групповой политики для конкретного контейнера, отключив связь с объектом групповой политики этого контейнера.
Иногда сложно понять, какие политики фактически применяются к конкретному пользователю или компьютеру, определить т.н. результирующий набор политик (Resultant Set of Policy, RSoP). Microsoft предлагает утилиту командной строки GPResult, который умеет генерировать отчет RSoP.
Для управления групповыми политиками Microsoft предоставляет консоль управления групповыми политиками (GPMC). Используя этот бесплатный редактор групповой политики, ИТ-администраторы могут создавать, копировать, импортировать, создавать резервные копии и восстанавливать объекты групповой политики, а также составлять отчеты по ним. Microsoft также предлагает целый набор интерфейсов GPMC, которые можно использовать для программного доступа ко многим операциям, поддерживаемым консолью.
По умолчанию любой член группы администраторов домена может создавать объекты групповой политики и управлять ими. Кроме того, существует глобальная группа под названием «Владельцы-создатели групповых политик»; его члены могут создавать объекты групповой политики, но они могут изменять только созданные ими политики, если им специально не предоставлены разрешения на редактирование других объектов групповой политики.
В этой же консоли можно делегировать вспомогательным ИТ-администраторам разрешения для различных действий: создание, редактирование и создание связей для определенных объектов групповой политики. Делегирование — ценный инструмент; например, можно предоставить группе, ответственной за управление Microsoft Office, возможность редактировать объекты групповой политики, используемые для управления настройками Office на рабочем столе пользователей.
Управление групповой политикой и делегирование
Делегирование— та вещь, которая быстро выходит из-под контроля. Права делегируются то так то эдак и, в конце концов, не те люди могут получить не те права.
Ценность групповой политики заключается в ее силе. Одним махом вы можете применить политики в домене или подразделении, которые значительно укрепят безопасность или улучшат производительность бизнеса. Или наоборот.
Но этой властью также можно злоупотребить, намеренно или случайно. Одно неправильное изменение объекта групповой политики может привести к нарушению безопасности. Взломщик или злонамеренный администратор могут легко изменить объекты групповой политики, чтобы, например:
Почему встроенные инструменты работы с GPO недостаточно удобны
К сожалению, встроенные инструменты не всегда позволяют в удобном формате поддерживать безопасность и контроль групповой политики. Изменения, внесенные в объекты групповой политики, по умолчанию вступают в силу, как только окно закрывается — отсутствует кнопка «Применить», которая могла бы дать администраторам шанс остановиться, одуматься и выявить ошибки, прежде чем организация подвергнется атаке.
Из-за того, что разрешения безопасности основаны на объектах групповой политики, любой администратор домена может изменять любой параметр безопасности объекта групповой политики. И даже параметры, которые должны препятствовать злонамеренным действиям этого человека. Например, администратор может отключить объект групповой политики, который отвечает за разрешение входа в систему на определенном сервере, на котором размещены конфиденциальные данные. Ну, а дальше скопировать часть или весь ценный контент на свой компьютер и продать в даркнете.
Но самое ужасное во всей этой истории с безопасностью GPO — изменения настроек не отслеживаются в собственных журналах безопасности, нет предупреждений, следовательно, невозможно отслеживать такие нарушения, даже если использовать SIEM-систему.
Как обезопасить GPO (объекты групповой политики)
Лучший способ минимизировать риск неправильной настройки объектов групповой политики — это создать многоуровневую структуру безопасности, которая дополняет собственные инструменты. Для надёжной защиты групповой политики нужны решения, которые позволят:
В интерфейсе можно выбрать избыточные или конфликтующие параметры групповой политики и объединить их в один объект групповой политики или создать новый.
Откат. Можно легко откатиться к предыдущим версиям объектов групповой политики и устранить негативные последствия.
Настраиваемый воркфлоу. В интерфейсе GPOADmin можно заранее определить автоматические действия для различных сценариев.
Политики защищенных настроек. Определите список параметров, по которым проверяются разрешенные настройки для политик.
Управление объектами. В интерфейсе легко определить, кто отвечает за управление определенными политиками.
Подтверждение по электронной почте. Утверждать или отклонять запросы на изменение объекта групповой политики можно прямо из письма в почте.
Пользовательские шаблоны писем. Для определенных ролей шаблоны писем можно кастомизировать.
Синхронизация GPO. Доступна возможность синхронизации настроек между несколькими GPO.
Сравнение GPO. Обеспечьте целостность настроек GPO и снизьте риск нарушения политики.
С GPOAdmin можно навести порядок в работе десятка администраторов, которые могут намеренно или случайно вносить неправильные изменения в объекты групповой политики. Теперь о каждом изменении будут знать все.
Мы готовы провести для вас демонстрацию или развернуть решение в вашей инфраструктуре, чтобы вы могли убедиться в ценности GPOAdmin для вашей организации. Решение, действительно, поможет уберечься от фатальных ошибок и навести порядок в домене. Свяжитесь с нами удобным для вас способом.
Применение групповых политик (часть 1)
Групповые политики являются одним из наиболее мощных инструментов управления пользователями и компьютерами в домене Active Directory. Однако, как и любой сложный инструмент, они требуют четкого понимания принципов своей работы и тщательного планирования. Без этого применение групповых политик может выдать не совсем тот результат, который требуется.
Вот собственно о них, основных принципах, и пойдет речь в этой статье. И начнем мы с самого основного — области действия.
Область действия групповых политик
Все групповые политики имеют свою область действия (scope), которая определяет границы влияния политики. Области действия групповых политик условно можно разделить на четыре типа.
Локальные групповые политики
Групповые политики, применяемые к локальному компьютеру, или локальные групповые политики. Эти политики настраиваются в оснастке «Редактор локальных групповых политик» и применяются только к тому компьютеру, на котором они были настроены. Они не имеют механизма централизованного развертывания и управления и, по сути, не являются групповыми политиками.
Групповые политики доменов
Объекты групповых политик, применяемые к домену Active Directory (AD) и оказывающие влияние на все объекты, имеющие отношение к данному домену. Поскольку в рамках домена работает механизм наследования, то все политики, назначенные на домен, последовательно применяются и ко всем нижестоящим контейнерам.
Групповые политики подразделения
Политики, применяемые к подразделению (OU) и оказывающие влияние на все содержимое данного OU и дочерних OU (при их наличии).
Групповые политики сайтов
Напомню, что в отличие от доменов, которые представляют из себя логическую структуру организации, сайты в AD используются для представления ее физической структуры. Границы сайта определяются одной или несколькими IP-подсетями, которые объединены высокоскоростными каналами связи. В один сайт может входить несколько доменов и наоборот, один домен может содержать несколько сайтов.
Объекты групповой политики, примененные к сайту AD, оказывают влияние на все содержимое этого сайта. Следовательно, групповая политика, связанная с сайтом, применяется ко всем пользователям и компьютерам сайта независимо от того, к какому домену они принадлежат.
Порядок применения групповых политик
Порядок применения групповых политик напрямую зависит от их области действия. Первыми применяются локальные политики, затем политики, назначенные на сайт, затем отрабатывают доменные политики и затем политики, назначенные на OU.
Так в нашем примере (на рисунке ниже) сначала отработает локальная политика (условно назовем ее GPO0), затем политика сайта GPO1, затем политика домена GPO2, ну а затем применятся политики, назначенные на OU. При этом политики применяются в соответствии с иерархией — сначала политика GPO3, назначенная на вышестоящее OU, затем нижестоящие политики GPO4 и GPO5.
Если на одну OU назначено несколько GPO, то они обрабатываются в том порядке, в котором были назначены. Например, к подразделению TechSupport относятся GPO4 и GPO5, которые обрабатываются согласно порядку назначения (Link Order).
Политики обрабатываются в обратном порядке (снизу вверх), т.е. политика с номером 1 отработает последней. При необходимости этот порядок можно изменить, выделив политику и передвинув ее вверх или вниз с помощью соответствующих стрелок.
Приоритет групповых политик
Приоритет GPO напрямую зависит от порядка их применения — чем позднее применяется политика, тем выше ее приоритет. При этом нижестоящие политики могут переопределять вышестоящие — например локальная политика GPO0 будет переопределена доменной политикой сайта GPO1, доменая политика GPO2 — политикой GPO3, а политика вышестоящего GPO3 — нижестоящими политиками GPO4 и GPO5.
Для большей наглядности проведем эксперимент. Для проверки действия политик будем заходить на рабочую станцию WKS1 под учетной записью пользователя Kirill, находящегося в OU TechSupport.
На рабочей станции WKS1 открываем редактор локальных групповых политик (gpedit.msc) и переходим в раздел Конфигурация пользователя\Административные шаблоны\Рабочий стол\Рабочий стол (User Configuration\Administrative Template\Desktop\Desktop).
Откроем политику Фоновые рисунки рабочего стола (Desktop Wallpaper) и укажем использовать в качестве обоев изображение local.png.
Затем перелогиниваемся и проверяем, что политика отработала и обои изменены.
Следующим шагом будет настройка доменной политики. Для этого в оснастке «Group Policy Management» выбираем политику GPO2 и открываем ее для редактирования.
Находим политику, отвечающую за смену обоев и устанавливаем в качестве рисунка рабочего стола изображение domain.png.
Дополнительно переходим в раздел выше и включаем политику «Remove Recycle Bin icon from desktop», удаляющую корзину с рабочего стола.
Еще раз заходим на WKS1 и удостоверяемся в том, что обои рабочего стола изменены и корзины не видно. Это значит, что доменные политики успешно применились и переопределили настройки, задаваемые локальными политиками.
Ну и в качестве завершаюшего шага открываем на редактирование политику GPO4 и устанавливаем политику «Remove Recycle Bin icon from desktop» в положение Disabled.
А также меняем рисунок рабочего стола на изображение с именем ou.png.
Теперь, зайдя на WKS1 мы видим, что обои опять изменены и на рабочий стол вернулась корзина. Из этого следует, что доменная политика GPO2 переопределена политикой GPO4, назначенной на OU.
Отключение наследования
Как я уже говорил, на все политики в домене распространяется наследование, т.е. политики, назначенные на родительский контейнер (домен или OU), последовательно применяются ко всем дочерним контейнерам. Это поведение по умолчанию, но при необходимости его можно изменить, отключив наследование для отдельно взятого OU.
Отключение наследования производится достаточно просто, надо только в оснастке «Group Policy Management» выбрать нужное OU, кликнуть на нем правой клавишей мыши и в контекстном меню отметить пункт «Block Inheritance». После этого для данного OU и его дочерних OU (при их наличии) отменяется воздействие всех вышестоящих политик.
Примечание. Политика Default Domain Policy содержит настройки, определяющие политику паролей и учетных записей в домене. Эти настройки не могут быть заблокированы.
В нашем примере отменим наследование для OU TechSupport, чтобы на него воздействовали только те политики, которые назначены непосредственно на данное OU.
Форсирование применения групповых политик
Форсирование применения групповых политик применяется тогда, когда данная политика должна отработать независимо от остальных политик. Если политика форсирована, то, вне зависимости от своей области действия она получает наивысший приоритет. Это значит, что ее настройки не могут быть переопределены нижестоящими политиками, а также на нее не действует отмена наследования.
Чтобы форсировать политику, надо выбрать ее в оснастке управления групповыми политиками, кликнуть на ней правой клавишей мыши и в контекстном меню отметить пункт «Enforced». Для примера форсируем политику GPO2, назначенную на домен.
Затем зайдем на WKS1 еще раз и увидим знакомую картину. Как видите, политика GPO2 отработала не смотря на блокировку наследования и перебила настройки нижестоящей политики GPO4.
Для одной статьи информации, я думаю, достаточно. А в следующей части разговор пойдет об особенностях применения групповых политик к пользователям и компьютерам.
