none
Запрет на изменение состава группы RRS feed

  • Вопрос

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

    Исходные данные:

    1) Есть домен AD Windows 2008R2

    2) Есть сервера под управлением Windows 2003 - 2008R2 входящие в этот домен.

    3) На этих серверах есть локальная группа Administrators. В состав данной группы входят Domain Admins (стандартно)

    4) На некоторые сервера в группу Administrators добавляются рядовые пользователи домена (разработчики).

     

    Задача: Как запретить этим пользователям (разработчикам), входящим в группу Administrators изменять состав данной группы? Т.е. они должны быть Администраторами на данном сервере, но изменять состав группы Administrators они не должны.

    Выручайте.

     

    23 ноября 2010 г. 7:52

Ответы

  • к сожалению, никак - администратор есть администратор... единственное, что вы можете - это через политику Restricted Groups жёстко назначить состав группы: он будет устанавливаться жёстко при каждом применении политики

    23 ноября 2010 г. 8:47
  • Жаль. Серверов много. Разработчиков ещё больше. Для каждого сервера писать свою политику Restricted Groups - на первый взгляд жестоко.
    зачем для каждого? сделайте по одной на каждый класс серверов - неужели на всех серверах разные админы?
    23 ноября 2010 г. 9:11

Все ответы

  • к сожалению, никак - администратор есть администратор... единственное, что вы можете - это через политику Restricted Groups жёстко назначить состав группы: он будет устанавливаться жёстко при каждом применении политики

    23 ноября 2010 г. 8:47
  • Жаль. Серверов много. Разработчиков ещё больше. Для каждого сервера писать свою политику Restricted Groups - на первый взгляд жестоко.
    23 ноября 2010 г. 9:01
  • Жаль. Серверов много. Разработчиков ещё больше. Для каждого сервера писать свою политику Restricted Groups - на первый взгляд жестоко.
    зачем для каждого? сделайте по одной на каждый класс серверов - неужели на всех серверах разные админы?
    23 ноября 2010 г. 9:11
  • Да, есть и такое, просто серверов очень много.

    Например на сервера 1С - нужен административный доступ 1Сникам. На другие их пускать нельзя. Для серверов обслуживающих ERP систему - нужен доступ тем кто занимает ERP, соответственно их никак нельзя пускать на сервера 1С :) Ну и так далее... 

     

    Добавил позже:

    Простите, не увидел в вашей фразе словосочетание "класс серверов". Это хорошая идея. Попробую. Спасибо!

    25 ноября 2010 г. 5:13
  • 1. Есть встречное предложение - проанализировать необходимость наличия привилегий. Сколько я работал с 1С и 1С-поддержкой, никогда не было никаких задач, которые требовали бы от поддержки 1С наличия привилегий Администратора (!) целого сервера. Никогда.

    Так действительно ли это нужно?

     

    2. Да, и Restricted Groups вам не помогут. Эта политика не запрещает администраторам изменять членство в группах, она лишь восстанавливает членство через определённые промежутки времени. То есть, я могу создать своего дополнительного администратора, затем залогонить его каким-нибудь процессом, а дальше политика пусть делает что хочет - пока я не выполню логофф этого администратора или не закрою все его процессы, его токен будет работоспособным хоть до конца света в 2012 году. Да даже если токен будет аннулирован раньше, свою задачу выполнить я успею.

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

     


    MCITP: Enterprise Administrator; MCT; Microsoft Security Trusted Advisor

    25 ноября 2010 г. 16:39