Опытные мелочи-7, или «Слияния и поглощения в Group Policy»

    image Продолжение «опытных мелочей». Предыдущие части: раз, два, три, четыре, пять, шесть.

    Сегодня мы поговорим об одном интересном параметре в Group Policy. Да, именно так. Один единственный параметр, который может облегчить вам жизнь (ну или усложнить ее, такое тоже возможно)


    Задача была поставлена очень просто:
    Требуется, чтобы определенные пользователей, входя на терминальный сервер, имели СуперМинимальный набор прав. Не могли изменять ничего на рабочем столе, не видели диски, могли запускать только заранее определенные приложения (1С, Консультант+, Word, Excel) и т.д. В тоже время все остальные, заходя на тот же терминальный сервер, должны получать полный набор прав. Ну и касаться это должно только данного конкретного терминального сервера, на рабочих станциях все пользователи примерно равны.

    Казалось бы чего проще — настраивай групповую политику и вперед, на танки. Однако, как в старом анекдоте, «Есть нюанс!». Если мы говорим про настройку пользовательского окружения (запрет на отображение дисков, настройку рабочего стола и т.п.), то эти параметры применяются к пользователям (логично!), и возникает вопрос: куда именно применять нашу политику.

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

    Если применять эту политику на OU в котором содержится терминальный сервер, то пользовательские параметры просто не применятся, т.к. они перечислены в категории User Configuration, и на сервер никакого влияния не окажут.

    И вот тут в бой вступает вышеупомянутый интересный параметр в Group Policy. Записывайте: Computer Configuration — Administrative Template — System -Group Policy — User Group Policy Loopback processing mode -Merge (или Replace)

    Делаем примерно так:
    • Создаем группу Pol_RestrictTerminalUsers и вносим в нее тех людей, которым нужно выставить заданные ограничения
    • Создаем политику RestrictTerminalUsers
    • Выставляем в политике все те пользовательские (!) ограничения, которые нам нужны
    • Выставляем описанный выше параметр в значение Enable-Merge
    • Применяем ее на OU, в котором содержится нужный нам терминальный сервер (логично, кстати, вынести его в отдельный OU, чтобы политика не влияла на соседние компьютеры)
    • В Security Filter этой политики убираем Authenticated Users и добавляем группу Pol_RestrictTerminalUsers, а также (!!) сам терминальный сервер
    • В результате, когда пользователь состоящий в группе Pol_RestrictTerminalUsers входит на данный терминальный сервер, к нему применяются не только обычные его пользовательские политики, но и наша новая политика RestrictTerminalUsers, причем ее пользовательские значения имеют приоритет над значениями из других политик.
    • Для пользователей, которые НЕ входят в эту группу, срабатывает Security Filter, и им никакие дополнительные настройки не применяются. Таким образом мы получаем следующее: при входе на терминал одним пользователям сеанс сконфигурирован одним образом, другим — другим, и управляется это все очень просто через группы в AD.
    • На своих рабочих станциях у пользователей остается все по прежнему.

    Что и требовалось. Ну и напоследок пара замечаний:
    1. Режим Merge «сливает» все пользовательские настройки, а режим Replace заменяет их. Мы обычно используем Merge, т.к. в предыдущих политиках могут быть параметры (например подключаемый диски, принтера и т.д.), которые не нужно менять. Подробнее про Replace и Merge можно почитать, например, вот тут
    2. При использовании Loopback processing в режиме Merge политика фактически отрабатывает дважды, учитывайте это, если используете Logon-скрипты. У меня, например, долго крышу сносило. Четко видно, что скрипт отрабатывает дважды, с перерывом в 0,5 -1 сек, а причину — не мог понять, пока не прочитал более подробно про Loopback processing.

    Продолжение следует
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 13

      0
      При использовании Merge — при появлении конфликтных параметров — выигрывает последняя политика?

      З.Ы. Картинка слабо подходит под «слияние» -) Скорее под «взаимное уничтожение» :)

        0
        Выигрывает политика из раздела User Configuration того GPO, который прилинкован к компьютерному объекту, на который логинится юзер.
        +3
        Простите, но то, что вы описали, это бред.
        Видно, что вы сами не до конца понимаете, как работает Loopback processing mode и Security Filtering.

        Когда GPO линкуется к какому-то OU, то по умолчанию политики из раздела Computer Configuration данной GPO применяются ко всем компьютерным объектам внутри этого OU (и его подконтейнеров), а политики из раздела User Configuration применяются ко всем пользовательским объектам внутри этого OU (и его подконтейнеров).

        Если вы прилинкуете GPO к OU, в котором лежат только компьютерные объекты, и в этом GPO укажете какие-то настройки в разделе User Configuration, то по умолчанию эти пользовательские настройки будут проигнорированы и никем не будут использоваться (т.к. я уже указал выше, что по умолчанию к компьютерным объектам применяются только настройки из Computer Configuration).

        Так вот, чтобы к пользователям, которые логинятся на какие-то машины, применялись пользовательские настройки (раздел User Configuration) из GPO, которая прилинкована к компьютерному объекту, и включается «User Group Policy Loopback processing mode».

        При этом в режиме Replace пользовательские настройки (User Configuration) из других GPO, назначенных на пользовательский объект, будут отменены и будут действовать только пользовательские настройки (User Configuration) из GPO, назначенного на компьютерный объект, куда логинится пользователь.
        А в режиме Merge эти настройки совместятся (ранее назначенные сохранятся, новые добавятся, конфликтующие перезапишутся). Т.е. частично у пользователя останутся настройки, назначенные на самого пользователя через другие GPO, плюс добавятся пользовательские настройки (User Configuration) из GPO, назначенного на компьбютер.

        Но нужно понимать, что хоть в этом случае меняются пользовательские настройки, но сам GPO назначается всё же на компьютерный объект. И при настройке линковки Security Filtering про это не нужно забывать.

        Если вы для GPO, прилинкованному к OU, настраиваете Security Filtering, тогда политики из этого GPO применяются не ко всем объектам внутри данного OU, а только к тем, которые указаны в фильтре безопасности прямо или косвенно (через группы).
        Чтобы данный GPO применился к какому-то объекту, этот объект:
        а) должен быть внутри OU, к которому прилинкован GPO;
        б) должен подпадать под указанный фильтр безопасности (с правами: read group policy + apply group policy).
        В Security Filter нет смысла включать объекты, которые не содержатся внутри OU, к которому вы линкуете GPO, — политики к таким объектам всё равно не применятся.

        А вы же в своём описании:
        1) Создаёте OU, переносите в него компьютерные объекты терминальных серверов.
        2) Создаёте GPO и линкуете его к этому OU.
        3) Для GPO указываете Security Filter, в который включаете не только терминальные серверы (которые находятся в этом OU), но ещё зачем-то и пользователей (которые находятся за пределами данного OU).

        Во-первых, нет смысла вообще делать Security Filtering, если вы и так терминальные серверы вынесли в отдельный OU. Просто линкуете GPO к этому OU с терминальными серверами (например: ou=terminal servers,ou=servers,dc=example,dc=org) без всякой фильтрации и всё.

        Во-вторых, если и не выносить терминальные серверы в отдельный OU, а оставить их, например, в контейнере со всеми прочими серверами (ou=servers,dc=example,dc=org), то тогда можно использовать Security Filtering, но только в этот фильтр нужно добавлять никак не пользователей, а только терминальные серверы, которые содержатся в прилинкованном OU. Например создать domain local security-группу с именем TerminalServers, в неё включить компьютерныеобъекты всех терминальных серверов, находящихся в контейнере Setrvers. И уже эту группу добавлять в Security Filtering, убирая оттуда Authenticated Users.

        Итого, как было правильно реализовать задуманное вами:

        Вариант 1 (с созданием отдельного OU для терминальных серверов).
        1. Создаёте отдельный подконтейнер для ТС: ou=terminal servers,ou=servers,dc=example,dc=org
        2. В этот контейнер перемещаете компьютерные объекты всех терминальных серверов.
        3. Создаёте GPO, например, TermSrv_Minimal_UserConf.
        4. В настройках GPO TermSrv_Minimal_UserConf:
        — в разделе User Configuration: задаёте нужные вам разрешения для пользователя.
        — в разделе Computer Configuration включаете «User Group Policy Loopback processing mode» в режим Merge (или Replace).
        5. Линкуете GPO TermSrv_Minimal_UserConf к OU, в котором находятся терм.серверы, т.е. к ou=terminal servers,ou=servers,dc=example,dc=org
        6. Настройки безопасности GPO оставляете по умолчанию, т.е. Authenticated Users: Read+apply group policy.

        Вариант 2 (без создания отдельного OU для терминальных серверов).
        1. Терминальные серверы лежат в одном OU с прочими компьюьерными объектами (например, в ou=servers,dc=example,dc=org).
        2. Создаёте доменную группу, например, TermServers (domain local, security), включаете в неё все терминальные серверы (комп. объекты).
        3. Создаёте GPO, например, TermSrv_Minimal_UserConf.
        4. В настройках GPO TermSrv_Minimal_UserConf:
        — в разделе User Configuration: задаёте нужные вам разрешения для пользователя.
        — в разделе Computer Configuration включаете «User Group Policy Loopback processing mode» в режим Merge (или Replace).
        5. Линкуете GPO TermSrv_Minimal_UserConf к OU, в котором находятся терм.серверы (и не только), т.е. к ou=servers,dc=example,dc=org
        6. Настраиваете для этого GPO Security Filtering: удаляете Authenticated User, добавляете созданную вами ранее группу TermServers (с правами по умолчанию: Read+apply group policy).

        Вот и всё. При этом:
        а) Если юзеры будут логиниться на свою рабочцю станцию и на какие-то прочие нетерминальные серверы (куда им разрешено), то к ним будут применяться пользовательские настройки из GPO, назначенных на их пользовательскую учётку (в частности из Default Domain Policy И прочих, созданных вами).
        б) Если юзеры будут логиниться на терминальные серверы, то к ним сначала, как обычно, будут применяться пользовательские настройки из GPO, назначенных на их пользовательскую учётку, а потом сразу же поверх них будут накатываться пользовательские настройки из GPO TermSrv_Minimal_UserConf, прилинкованного к контейнеру с терминальными серверами, путём полной замены (Replace) или дополнения с перезаписью конфликтных значений (Merge).

        Лепить непонятный винегрет, когда и отдельный OU и Security Filtering, да ещё и в группу для фильтрации добавлены и пользователи и компьютеры — это явный бред, который происходит от непонимания того, как это всё работает.
          0
          Роман. Не буду вас переубеждать, просто предложу попробовать сделать то, что я описал.

          Разница между тем что вы предлагаете и тем, что описал в одной, но весьма существенной детали:
          В вашем варианте «политика ограничения» будет действовать на ВСЕХ пользователей, которые заходят на этот терминальный сервер. А это, согласитесь, неудобно (админам например все эти ограничения будут только мешать). В моем варианте «политика ограничения» будет действовать только на тех пользователей, кто входит в указанную группу. Админам (которые в эту группу не входят), соответственно, никаких препятствий для работы не будет.

          Я не претендую на «переписывание библии Group Policy», мало того, если строго руководствоваться документацией — то это ТАК работать не должно (вы все правильно описали с точки зрения теории). Но факт — вещь упрямая. Попробуйте и увидите разницу. (Замечу, что по не очень понятным мне причинам, отмена политики, которая использует Loopback Processing происходит просто (достаточно gpupdate /force) а вот чтобы применить ее — требуется перезагрузка сервера. Учитывайте это в своих тестах, если захотите их провести)
            –1
            > В вашем варианте «политика ограничения» будет действовать на ВСЕХ
            > пользователей, которые заходят на этот терминальный сервер.

            Представьте себе, в вашем варианте тоже. Тот факт, что вы в Security Filtering компьютерной политики, прилинкованной к OU с терминальными серверами, добавили (через группу) пользователей не меняет ровным счётом ничего. Если эти пользователи находятся за пределами OU, к которому прилинкована эта политика, то security filtering по этим юзерам вообще ни на что влиять не будет. Фильтр фильтрует объекты безопасности, к которым будет применяться политика, только внутри этого контейнера с терминальными серверами, к которому прилинкована политика.
              +1
              Подскажите, как правильно организовать применение различных политик для различных групп пользователей на одном терминальном сервере? Грубо говоря:
              Grp1=Pol1
              Grp2=Pol2
              Grp3=Pol3
              В моем случае необходимо давать не один набор минимальных прав, а несколько разных наборов.
                0
                Сделайте как описано в посте.
                В Security Filter каждой политики добавьте соответствующую группу и сам терминальный сервер.
                Не забудьте включить Loopback Processing Mode.

                  0
                  У меня Вариант 2 — все серверы в одной OU. Выше написано что «Фильтр фильтрует объекты безопасности, к которым будет применяться политика, только внутри этого контейнера с терминальными серверами, к которому прилинкована политика.»
                  Предполагаю, что при назначении фильтра для Pol1,2,3 он отработает только в части терминальных серверов (они входят в эту OU), но будет проигнорирован раздел групп, т.к. группы находятся в другой OU.
                    0
                    Вы просто попробуйте. Все сработает как описано в статье.
                    Увидите сами.
              0
              > А это, согласитесь, неудобно (админам например все эти ограничения будут только мешать).

              Да это всем, на самом деле, будет мешать.
              Я сторонник того, чтобы через «User Group Policy Loopback processing mode» добавлять только всем полезные и удобные настройки, а не те, которые что-то ухудшают и зарезают. Зарезать права нужно ограничением прав доступа к объектам, а не групповыми политиками и визуальными финтифлюшками.

              А что касается ограничений для админов, то они обходятся тем, что на пользовательскую политику, назначенную для админов где-то выше (например, на уровне домена), ставится Enforced. Таким образом User Configuration админской политики будет важнее, чем назначенные настройки через Loopback processing mode компьютерной политики.
            0
            почему нельзя использовать фильтр wmi? и там, например указать
            Select * From Win32_Networkadapter Where SystemName = "SUPERSERVER"???
            (или что душе угодно) я что-то не понимаю?
              –1
              Есть вот такое решение:
              http://it-padla.livejournal.com/22449.html

              Нелогично, но работает.

              Настройка политик терминальных пользователей или особенность замыкания групповых политик

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

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

              Computer Configuration –> Policies –> Administrative Templates –> System –> Group Policy –> User Group Policy loopback processing mode

              И выбрать режим Replace.

              После этого нужно настроить все необходимые параметры в User Configuration разделе. Эту политику нужно привязать к OU в которой находятся терминальные севера. Обязательно следует дать право на чтение этой политики группе Authenticated Users и на чтение и применений для группы Domain Computers.

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

              Если попытаться просто поставить фильтр по группам пользователей, то политики вообще применяться не будут. Но, оказывается, есть хитрость. Если хотя бы одна политика на OU имеет режим замыкания, то и все остальные пользовательские политики, привязанные к этому контейнеру будут применяться!

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

                0
                Если попытаться просто поставить фильтр по группам пользователей, то политики вообще применяться не будут. — по ходу что-то не так делает. У нас все работает.
                Пользователи заходя на терминальные сервера получают те политики, которые им должны применяться, в зависимости от членства в группах.
                И все нормально работает.

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

              Самое читаемое