Групповая политика: правда или вымысел?
Введение
Я знаю, что я гик! Я думаю, что вы тоже, потому что вы читаете эту статью, основываясь на заголовке! Это нормально… поскольку есть группа из нас, которые просто любят групповую политику. Верно… люблю групповую политику. На самом деле у меня есть группа друзей (да, я буду считать их друзьями!), которые любят групповую политику так же сильно, как и я. Все они являются MVP в своей области и являются одними из самых замечательных коллег и друзей, которых я знаю. Они помогают мне, я помогаю им, и мы пытаемся сделать групповую политику увлекательной и пытаемся помочь каждой корпорации понять, как лучше использовать групповую политику. Итак, на протяжении многих лет я слышал и видел удивительные вещи, которые говорили и неправильно понимали о групповой политике. Вот простой список утверждений и комментариев относительно правды о каждом из них.
Заявление: все изменения реестра через татуировки групповой политики
Правда: вымысел
Комментарии: Есть четыре пути реестра, которые нестабильны, чтобы преодолеть эту концепцию татуирования реестра с помощью групповой политики. У всех четырех есть ключ «Политики» в пути. Есть два для HKLM и два для HKCU. Идея заключается в том, что когда объект групповой политики настраивает запись реестра, которая также может быть записана по одному из этих четырех путей, этот параметр дублируется в исходном пути, а также в специальном пути «Политики». Если оба существуют, путь управления политиками. Если существует только оригинал, из-за того, что запись реестра не была настроена с помощью групповой политики или объект групповой политики больше не применяется, что приводит к удалению записи пути политик, исходная настройка снова вступает в силу.
Утверждение: если пользователь изменяет запись реестра, настроенную объектом групповой политики, объект групповой политики при следующем обновлении изменит запись реестра обратно на то, на что настроен объект групповой политики.
Правда: вымысел
Комментарии: Групповая политика — это довольно упрощенная технология. Каждая модификация объекта групповой политики обновляет номер версии объекта групповой политики, который также сохраняется на целевом компьютере во время обновления. Таким образом, если пользователь целевого компьютера изменяет реестр, номер версии объекта групповой политики не изменяется, поэтому при обновлении номер версии объекта групповой политики не изменяется, поэтому обновления не происходят. Этого можно избежать с помощью команды gpupdate /force, которая игнорирует номера версий объекта групповой политики и применяет все параметры во всех объектах групповой политики, которые применяются к компьютеру, на котором вы запускаете команду.
Заявление: расширение групповой политики, такое как предпочтения групповой политики или PowerBroker от BeyondTrust (первоначальный производитель предпочтений групповой политики), может быть установлено и контролироваться администратором подразделения.
Правда: Факт
Комментарии: Расширения групповой политики проще, чем кто-либо может себе представить. Расширение групповой политики состоит из двух компонентов. Во-первых, это обновление для GPMC и редактора групповой политики, которое позволяет администратору «видеть» параметр в редакторе для настройки. Для этого требуются только права локального администратора на рабочем столе или сервере, где используется консоль управления групповыми политиками. Во-вторых, на каждом целевом компьютере должно быть установлено клиентское расширение (CSE), к которому будет применяться «новый» параметр расширения групповой политики. Это можно сделать вручную или с помощью политики программного обеспечения групповой политики, которая опять же не требует ничего, кроме возможности редактировать объект групповой политики и связывать его с OU компьютеров.
Заявление: Использование RSOP.msc может дать ложное представление о том, каковы на самом деле настройки компьютера.
Правда: Факт
Комментарий: RSOP.msc расшифровывается как результирующий набор политик. Этот инструмент показывает ТОЛЬКО параметры, которые развертываются на целевом компьютере из объекта групповой политики в Active Directory. Это означает, что параметры локальной политики и все параметры компьютера (через графический интерфейс или приложение) не отображаются в результатах RSOP. Отображаются только параметры, развернутые из объекта групповой политики, связанного с доменом, подразделением или сайтом. Таким образом, если у вас есть параметр, который вы настроили в образе рабочего стола или через приложение, этот параметр не будет отображаться с помощью RSOP.msc. Если параметр является параметром безопасности, я настоятельно рекомендую использовать secpol.msc, который покажет «фактические параметры компьютера», независимо от того, откуда был взят этот параметр.
Заявление: Если у меня есть контроллеры домена Windows Server 2008 и/или Server 2008 R2, я могу иметь несколько политик паролей с использованием объектов групповой политики, связанных с подразделениями.
Правда: вымысел
Комментарий. Если вы используете объекты групповой политики для настройки политик учетных записей (которые включают в себя параметры политики паролей), у вас может быть только одна политика паролей для каждого домена. Набор параметров политики паролей по умолчанию настраивается в политике домена по умолчанию, которая связана с доменным узлом вашего домена. Любой объект групповой политики, который вы связываете с OU, никогда не повлияет на учетные записи пользователей домена. Вместо этого эти объекты групповой политики и содержащиеся в них параметры политики паролей будут влиять только на локальные учетные записи пользователей, хранящиеся в локальном SAM компьютеров, расположенных в OU. Используя групповую политику, единственный способ применить политику паролей для учетных записей пользователей домена — это объект групповой политики, связанный с узлом домена. Теперь в Windows Server 2008 и 2008 R2 есть новая функция политики паролей, называемая детальными политиками паролей. Эти параметры не настраиваются с помощью групповой политики! Вместо этого эти параметры настраиваются с помощью ADSIEdit! Эти политики паролей позволяют использовать несколько политик паролей в одном домене, но для их настройки необходимо создать дополнительные объекты AD. Они также контролируются списком управления доступом к безопасности, связанным с созданным объектом AD, что означает, что политика паролей будет основана на группе, а не на ассоциации OU.
Резюме
Я знаю, что это включает только несколько концепций групповой политики, но это общие проблемы, с которыми, как я вижу, сталкиваются администраторы групповой политики и AD. Единственное, о чем всегда следует помнить при работе с групповой политикой, — это тестировать, тестировать еще раз, а затем тестировать эти результаты. То, что технология «выглядит» так, как будто она работает так, как вы хотите, не означает, что она действительно работает. С моей точки зрения, чем проще вы реализуете свою групповую политику, тем лучше. Держитесь подальше от таких настроек, как принудительное применение, блокировка наследования и фильтрация безопасности. Эти параметры могут вызвать проблемы с устранением неполадок, которые являются более сложными, чем большинство администраторов хотят решить. Попробуйте связать общие параметры групповой политики Microsoft и объекты групповой политики, в которых они настроены, с подразделениями. С доменом должно быть связано очень мало объектов групповой политики, если только у вас нет сторонних расширений групповой политики, таких как BeyondTrust PowerBroker, которые могут обрабатывать объекты групповой политики, связанные так высоко в структуре AD. Я также настоятельно рекомендую вам держаться подальше от технологий, которые утверждают, что они основаны на «групповой политике», но не использовать встроенную службу групповой политики и общие технологии групповой политики Microsoft. Эти технологии могут вызывать странное поведение и проблемы, выходящие за рамки того, что вам нужно и чем вы хотите управлять.