Как делать исключения в групповой политике?

Есть ли лучший способ сделать то, что мы пытаемся достичь?

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

Я не уверен, что я на 100% понимаю, чего вы на самом деле пытаетесь достичь, когда дело касается настроек перенаправления папок. Какова конечная цель бизнеса? Настроены ли эти специальные компьютеры для перенаправления папок так, чтобы пользователи могли свободно перемещаться между ними? Каково ожидаемое взаимодействие с пользователем при использовании на компьютере без перенаправления папок, примененного после того, как они использовали тот, который работает (и они не могут найти свои файлы)? Я не уверен, что вы полностью продумали эту часть.

Похоже, вы не хотите применять групповую политику к пользовательским объектам. Было бы любопытно узнать причину. «Перенаправление папок» применяется только при входе пользователей в систему определенный компьютеры немного нестандартны. Говоря в более общем плане, циклическая обработка групповой политики не является нормой, хотя я признаю, что использую ее довольно часто. Погружение в процессинг с обратной связью - смелый шаг с точки зрения обучения.

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

Это не означает, что нет компьютеров, на которых я мог бы использовать Loopback Processing для «исключения» из перенаправления папок (и что я мог бы принудительно включить только локальные профили), но это будет меньшинство и исключение, а не по умолчанию. (Например, киоски и специализированные однозадачные компьютеры.)

У меня также есть сценарии, в которых мне нужно освободить пользователей от перенаправления папок (подрядчиков, ориентированных на задачи пользователей и т. Д.), И, поскольку я применяю политику перенаправления папок почти исключительно к пользователям, это просто заканчивается либо иерархией подразделений, где «Нет папки Перенаправление », или фильтрация группы безопасности, чтобы исключить пользователей из перенаправления папок.

Большинство организаций хранят все рабочие станции в одном подразделении (как мы пытаемся это сделать) или же они разделяют его (как мы реализовали)?

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

Иерархия ваших подразделений должна быть спроектирована, во-первых, для делегирования административного управления объектами Active Directory. Часто бывает, что компании не имеют разграничения административного контроля над объектами клиентских компьютеров. Помните, я не говорю о «правах локального администратора» на компьютерах, а просто говорю об административном контроле над объектами компьютеров в AD.

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

Имеет ли смысл тот тип исключений, который мы хотим сделать? Брандмауэры работают нормально, поскольку они являются компьютерными политиками, но эта система выходит из строя, когда мы хотим применить пользовательские политики ко всем пользователям, которые входят в систему на этих ПК.

Ваше понимание Loopback Processing кажется правильным, основываясь на формулировке последнего предложения вашего абзаца по этому вопросу. Чтобы прояснить это: обработка петли жестяная банка работают нормально. Я довольно широко использую его на нескольких сайтах клиентов почти на всех их компьютерах.

То, что вы пытаетесь сделать с выборочным применением перенаправления папок, можно сделать, но я предупреждаю, что перенаправление папок не обязательно действует так же, как параметр, применяемый к реестру пользователя из административного шаблона. Не видя всех деталей вашего AD, мне трудно сказать, почему вы не видите ожидаемых результатов. В качестве примера: если у пользователя был настроен перемещаемый профиль пользователя, и он вошел в систему на компьютере с циклической обработкой таким образом, что перенаправление папок применялось к профилю этого пользователя, настройки перенаправления папок будут «придерживаться» его профиля и «следовать» за ними даже в компьютер, на котором не применялось перенаправление папок с помощью кольцевой обработки.

Существуют ли какие-либо инструменты, кроме GPRESULT / RSOP, которые подходят для устранения неполадок этого типа?

Безусловно, я считаю эти инструменты полезными. Иногда, если мне кажется, что у меня возникают проблемы с отдельным расширением на стороне клиента (CSE) групповой политики, я могу включить вывод отладки (либо с помощью GPSvcDebugLevel настройки в Windows 7 или UserEnvDebugLevel или RunDiagnosticLoggingGlobal настройки в Windows XP).

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

Алгоритм определения приложения групповой политики для данного объекта «Компьютер» или «Пользователь» (который я называю «субъектом») выглядит следующим образом:

• Начните с верхней части домена и найдите все связанные объекты групповой политики. Пока не беспокойтесь о группе безопасности или фильтрации WMI - просто найдите все связанные GPO в верхней части домена. Аннотируйте их в том порядке, в котором они связаны, в нижней части списка под названием «Невыполненные объекты групповой политики». Если вы обнаружите, что объект групповой политики связан с параметром «Принудительно» (или, в прежние времена, «Без переопределения»), добавьте его в конец второго списка под названием «Принудительные объекты групповой политики». скорее чем в списке «Невыполненные объекты групповой политики». Всегда добавляйте объекты групповой политики в списки в том порядке, в котором они связаны в каждом подразделении (порядок, в котором они связаны имеет значение).

• Переместитесь вниз по иерархии подразделений к подразделению, в котором находится субъект. В каждом подразделении найдите все связанные объекты групповой политики и добавьте их в один из своих списков («Не принудительные объекты групповой политики» или «Принудительные объекты групповой политики»), как вы это делали в верхней части домена. Если вы найдете подразделение с установленным параметром «Блокировать наследование», удалите все в своем списке «Не принудительно» перед добавлением объектов групповой политики, связанных с этим подразделением, в ваши списки. Однако «Блокировать наследование» не влияет на список «Принудительное».

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

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

Когда Loopback Processing включена в режиме «Replace», вы просто обрабатываете OU, в котором находится компьютер, на котором выполняется вход, как если бы он был местом входа пользователя в систему, и соответственно составляете списки GPO. Когда он находится в режиме «слияния», вы сначала создаете списки для пользователя в его собственном подразделении, затем снова начинаете в верхней части домена и, добавляя к уже созданным спискам, добавляете объекты групповой политики, которые связаны в верхней части домена. и движение вниз по каждой OU в иерархии к объекту-компьютеру.

Списки, которые вы составили после того, как дойдете до подразделения, в котором находится объект, являются списками объектов групповой политики, которые жестяная банка относятся к теме. Порядок, в котором они применяются, сначала идет сверху вниз в списке «Невыполненные объекты групповой политики», за которым следует список «Принудительные объекты групповой политики», как подробно описано ниже.

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

• Начав с первого объекта групповой политики в списке «Не принудительные объекты групповой политики», проверьте его разрешения и настройки фильтрации WMI, чтобы определить, можно ли его применить к субъекту. Когда вы рассчитываете RSoP для компьютера, учитывайте членство компьютера в группах, чтобы определить право на фильтрацию безопасности. При вычислении RSoP для пользователя учитывайте членство пользователя в группах. При вычислении RSoP пользователя в режиме обратной связи только членство пользователя в группе применяется к фильтру безопасности (то есть членство в группе компьютеров имеет Нет влияние на RSoP для пользователей, которые входят в систему, когда включена кольцевая обработка).

• Если объект групповой политики может быть применен на основе фильтрации группы безопасности и фильтрации WMI, отметьте применяемые параметры в новом списке под названием «Результирующий набор политик». (Очевидно, если вы создаете RSoP для компьютера, смотрите только на компьютерные части объектов групповой политики для настроек и пользовательские разделы для пользователей.)

• По мере продвижения вниз по списку объектов групповой политики, если нижележащий объект групповой политики изменяет параметр, который уже был помещен в список «Результирующий набор политик», вычеркните уже существующий параметр и замените его параметром из объекта групповой политики, расположенного ниже в списке. список. Вот как объекты групповой политики «перекрывают» друг друга - настройки просто применяются поверх уже примененных настроек. Ничего особенного.

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

• После того, как вы переместились через все записи «Не принудительные объекты групповой политики», проделайте то же самое со списком «Принудительные объекты групповой политики», начиная с верхней части списка и применяя настройки каждого объекта групповой политики в списке к одному и тому же «Результирующему набору». of Policy », к которому вы уже применили параметры« Non-Enforce GPOs ». Выполняя список «Принудительные объекты групповой политики» последним, вы делаете их настройки более «весомыми», чем «Принудительные объекты групповой политики». Нет ничего особенного в "Enforce" за кулисами. Этот параметр просто заставляет "принудительно" применять GPO позже в процессе.

Есть одно специальное исключение из алгоритма, описанного выше: компьютеры контроллеров домена распознают только параметры «Конфигурация компьютера / Параметры Windows / Параметры безопасности / Политики учетных записей», которые поступают из подразделений, связанных на верхнем уровне домена. Эти объекты групповой политики создают политику паролей и учетных записей для домена. (Эти настройки можно изменить с помощью Детализированные политики паролей, но это выходит за рамки данного обсуждения.) Любые параметры в разделе «Конфигурация компьютера / Параметры Windows / Параметры безопасности / Политики учетных записей» объектов групповой политики, связанных с подразделениями ниже верхнего уровня домена, игнорируются компьютерами контроллера домена.

Вот и все. Это алгоритм применения групповой политики. (В продукте он реализован несколько иначе, но этот метод функционально эквивалентен.) На самом деле в этом нет ничего особенного.

В течение нескольких лет я преподавал сертификационные классы по официальной учебной программе Microsoft в общественном колледже. Я обнаружил, что, как только ученики поймут этот алгоритм, «загорится свет» и возникло количество вопросов, которые я получил на тему «Почему эта политика не применяется?» упала почти до нуля.

Может ли кто-нибудь порекомендовать какие-либо видео / блоги / эксперты, чтобы узнать больше о передовых методах общей практики? Есть ли у Microsoft где-нибудь эта документация? Вроде бы трудно найти.

Что касается структуры Active Directory, документация, предназначенная для Windows 2000 Server и Windows Server 2003, по-прежнему полностью актуальна. Основные функциональные возможности и факторы, влияющие на проектные решения для структуры Active Directory, сегодня такие же, как и при выпуске AD.

Точно так же групповая политика кардинально не изменилась. Да, конкретный настройки на которую может влиять групповая политика, изменились, но правила, управляющие процессом приложения, остались прежними, хотя имена некоторых вещей были изменены (например, «Без переопределения» стало «Принудительно») и были добавлены функции (например, фильтрация WMI) . Все основные концепции остаются в силе.

Большая часть документации и справочных веб-сайтов по групповой политике, которые я видел, похоже, погрязла в недоумении: «Ой, черт возьми, взгляни на все эти захватывающие настройки, которые можно применить», и рассматривает изучение процесса приложения как некоторую запоздалую мысль, что вы просто используете моделирование GPMC обрабатывать. Для меня это обратное мышление. Как только вы поймете, как на самом деле применяются GPO, вы можете покопаться в настройках. (Узнайте, как завести машину первый прежде чем разобраться, как работают звуковая система и электрические стеклоподъемники. Конечно - складной верх яркий, но он не сработает, если вы не сможете завести машину.)

Вот некоторые ресурсы Microsoft, относящиеся к разработке Active Directory, которые я считаю разумными:

• Руководство по планированию и развертыванию групповой политики

• Проектирование инфраструктуры групповой политики

• Проектирование логической структуры Active Directory - Не имеет прямого отношения к групповой политике, но представляет собой хорошее обсуждение дизайна Active Directory.

• Проектирование работающих структур организационных единиц

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

При условии, что вы работаете с набором изолированных подразделений и «выбрасываемых» объектов пользователей и компьютеров, вы можете безнаказанно «играть» с групповой политикой в ​​своих производственных доменах (по крайней мере, для клиентских компьютеров - для серверов и, особенно, контроллеров домена, вам может быть лучше поиграть в тестовой среде). Вы можете смоделировать верхнюю часть домена с OU "Block Inheritance", если это необходимо, и построить всю смоделированную среду под ним. (Вам также нужно будет создать имитацию объекта Site, если вам нужно смоделировать групповую политику на уровне сайта ... однако вряд ли кто-нибудь, кроме меня, похоже, использует это.)

В сторону: Zow - после почти 5 лет использования Server Fault I Ну наконец то У меня есть время и возможность записать мою лекцию по обработке GPO в моем старом классе колледжа. Итак, давайте посмотрим здесь - я написал статью о подсетях IPv4 из моих старых конспектов лекций, я набрал 100 КБ и приближаюсь к этому «Легендарному» значку.

Моя миссия здесь почти завершена.