Comments 13
При использовании Merge — при появлении конфликтных параметров — выигрывает последняя политика?
З.Ы. Картинка слабо подходит под «слияние» -) Скорее под «взаимное уничтожение» :)
З.Ы. Картинка слабо подходит под «слияние» -) Скорее под «взаимное уничтожение» :)
Простите, но то, что вы описали, это бред.
Видно, что вы сами не до конца понимаете, как работает 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, да ещё и в группу для фильтрации добавлены и пользователи и компьютеры — это явный бред, который происходит от непонимания того, как это всё работает.
Видно, что вы сами не до конца понимаете, как работает 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, да ещё и в группу для фильтрации добавлены и пользователи и компьютеры — это явный бред, который происходит от непонимания того, как это всё работает.
Роман. Не буду вас переубеждать, просто предложу попробовать сделать то, что я описал.
Разница между тем что вы предлагаете и тем, что описал в одной, но весьма существенной детали:
В вашем варианте «политика ограничения» будет действовать на ВСЕХ пользователей, которые заходят на этот терминальный сервер. А это, согласитесь, неудобно (админам например все эти ограничения будут только мешать). В моем варианте «политика ограничения» будет действовать только на тех пользователей, кто входит в указанную группу. Админам (которые в эту группу не входят), соответственно, никаких препятствий для работы не будет.
Я не претендую на «переписывание библии Group Policy», мало того, если строго руководствоваться документацией — то это ТАК работать не должно (вы все правильно описали с точки зрения теории). Но факт — вещь упрямая. Попробуйте и увидите разницу. (Замечу, что по не очень понятным мне причинам, отмена политики, которая использует Loopback Processing происходит просто (достаточно gpupdate /force) а вот чтобы применить ее — требуется перезагрузка сервера. Учитывайте это в своих тестах, если захотите их провести)
Разница между тем что вы предлагаете и тем, что описал в одной, но весьма существенной детали:
В вашем варианте «политика ограничения» будет действовать на ВСЕХ пользователей, которые заходят на этот терминальный сервер. А это, согласитесь, неудобно (админам например все эти ограничения будут только мешать). В моем варианте «политика ограничения» будет действовать только на тех пользователей, кто входит в указанную группу. Админам (которые в эту группу не входят), соответственно, никаких препятствий для работы не будет.
Я не претендую на «переписывание библии Group Policy», мало того, если строго руководствоваться документацией — то это ТАК работать не должно (вы все правильно описали с точки зрения теории). Но факт — вещь упрямая. Попробуйте и увидите разницу. (Замечу, что по не очень понятным мне причинам, отмена политики, которая использует Loopback Processing происходит просто (достаточно gpupdate /force) а вот чтобы применить ее — требуется перезагрузка сервера. Учитывайте это в своих тестах, если захотите их провести)
> В вашем варианте «политика ограничения» будет действовать на ВСЕХ
> пользователей, которые заходят на этот терминальный сервер.
Представьте себе, в вашем варианте тоже. Тот факт, что вы в Security Filtering компьютерной политики, прилинкованной к OU с терминальными серверами, добавили (через группу) пользователей не меняет ровным счётом ничего. Если эти пользователи находятся за пределами OU, к которому прилинкована эта политика, то security filtering по этим юзерам вообще ни на что влиять не будет. Фильтр фильтрует объекты безопасности, к которым будет применяться политика, только внутри этого контейнера с терминальными серверами, к которому прилинкована политика.
> пользователей, которые заходят на этот терминальный сервер.
Представьте себе, в вашем варианте тоже. Тот факт, что вы в Security Filtering компьютерной политики, прилинкованной к OU с терминальными серверами, добавили (через группу) пользователей не меняет ровным счётом ничего. Если эти пользователи находятся за пределами OU, к которому прилинкована эта политика, то security filtering по этим юзерам вообще ни на что влиять не будет. Фильтр фильтрует объекты безопасности, к которым будет применяться политика, только внутри этого контейнера с терминальными серверами, к которому прилинкована политика.
Подскажите, как правильно организовать применение различных политик для различных групп пользователей на одном терминальном сервере? Грубо говоря:
Grp1=Pol1
Grp2=Pol2
Grp3=Pol3
В моем случае необходимо давать не один набор минимальных прав, а несколько разных наборов.
Grp1=Pol1
Grp2=Pol2
Grp3=Pol3
В моем случае необходимо давать не один набор минимальных прав, а несколько разных наборов.
Сделайте как описано в посте.
В Security Filter каждой политики добавьте соответствующую группу и сам терминальный сервер.
Не забудьте включить Loopback Processing Mode.
В Security Filter каждой политики добавьте соответствующую группу и сам терминальный сервер.
Не забудьте включить Loopback Processing Mode.
У меня Вариант 2 — все серверы в одной OU. Выше написано что «Фильтр фильтрует объекты безопасности, к которым будет применяться политика, только внутри этого контейнера с терминальными серверами, к которому прилинкована политика.»
Предполагаю, что при назначении фильтра для Pol1,2,3 он отработает только в части терминальных серверов (они входят в эту OU), но будет проигнорирован раздел групп, т.к. группы находятся в другой OU.
Предполагаю, что при назначении фильтра для Pol1,2,3 он отработает только в части терминальных серверов (они входят в эту OU), но будет проигнорирован раздел групп, т.к. группы находятся в другой OU.
> А это, согласитесь, неудобно (админам например все эти ограничения будут только мешать).
Да это всем, на самом деле, будет мешать.
Я сторонник того, чтобы через «User Group Policy Loopback processing mode» добавлять только всем полезные и удобные настройки, а не те, которые что-то ухудшают и зарезают. Зарезать права нужно ограничением прав доступа к объектам, а не групповыми политиками и визуальными финтифлюшками.
А что касается ограничений для админов, то они обходятся тем, что на пользовательскую политику, назначенную для админов где-то выше (например, на уровне домена), ставится Enforced. Таким образом User Configuration админской политики будет важнее, чем назначенные настройки через Loopback processing mode компьютерной политики.
Да это всем, на самом деле, будет мешать.
Я сторонник того, чтобы через «User Group Policy Loopback processing mode» добавлять только всем полезные и удобные настройки, а не те, которые что-то ухудшают и зарезают. Зарезать права нужно ограничением прав доступа к объектам, а не групповыми политиками и визуальными финтифлюшками.
А что касается ограничений для админов, то они обходятся тем, что на пользовательскую политику, назначенную для админов где-то выше (например, на уровне домена), ставится Enforced. Таким образом User Configuration админской политики будет важнее, чем назначенные настройки через Loopback processing mode компьютерной политики.
почему нельзя использовать фильтр wmi? и там, например указать
(или что душе угодно) я что-то не понимаю?
Select * From Win32_Networkadapter Where SystemName = "SUPERSERVER"???(или что душе угодно) я что-то не понимаю?
Есть вот такое решение:
http://it-padla.livejournal.com/22449.html
Нелогично, но работает.
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 имеет режим замыкания, то и все остальные пользовательские политики, привязанные к этому контейнеру будут применяться!
Т.е., нужно сделать одну политику с включенным режимом замыкания и общими для всех терминальных пользователей настройками, а затем сделать еще несколько политик с выключенным режимом замыкания и с фильтром применения групповой политики для нужной группы пользователей.
Если попытаться просто поставить фильтр по группам пользователей, то политики вообще применяться не будут. — по ходу что-то не так делает. У нас все работает.
Пользователи заходя на терминальные сервера получают те политики, которые им должны применяться, в зависимости от членства в группах.
И все нормально работает.
Пользователи заходя на терминальные сервера получают те политики, которые им должны применяться, в зависимости от членства в группах.
И все нормально работает.
Sign up to leave a comment.
Опытные мелочи-7, или «Слияния и поглощения в Group Policy»