none
Делегирование прав в AD RRS feed

  • Вопрос

  • Добрый день, коллеги.
    Нужна ваша консультация по наследованию прав в AD.


    Что имеем: AD с большим числом OU, отображающую организационную структуру фирмы, пользователи раскиданы в различных контейнерах. Есть выделенный системный аккаунт SpecUser.

    Что надо: Необходимо предоставить  акаунту SpecUser права на чтение всех свойств только некоторых пользователей, учетные записи которых лежат в различных местах AD.

    Что пробовал: создал группу Group1, в которую включил интересующих меня пользователей, и предоставил служебному акаунту SpecUser права на чтение всех свойств этой группы, в надежде, что удасться прочитать и свойства пользователей включенных в эту группу. Однако ничего не получилось.

    Подскажите, как это возможно реализовать?

    P.S. Все пользователи и группы в одном домене. Windows 2003 AD, native mode




    23 марта 2009 г. 7:45

Ответы

  • Kurepkin Nikolay,
    в вашей ситуации поможет следующее.

    добавьте в группу пользователей на которых необходимо дать права на чтение (для большей безопасности сделайте тип группы - распространение).

    и например использовать небольшой скрипт

    echo off

    for /f %%i in ('cmd /c "dsget group CN=users_read,CN=Users,DC=gex,dc=com -members"') do (
      dsacls %%i /G gex\needread:GR /I:T
    )


    в группу users_read добавляем пользователей.
    needread - этому пользователю выдаем права


    • Предложено в качестве ответа Gennady Efimov - ge][ 23 марта 2009 г. 15:50
    • Помечено в качестве ответа Kurepkin Nikolay 24 марта 2009 г. 11:08
    23 марта 2009 г. 15:39

Все ответы

  • Нужна  назначать права  чтения не на  группу (в которой пользователи), а  включать  группу(или другого пользователя)  в Security пользователя (что  хотим читать).

    Теперь по порядку. По умолчанию все пользователи могут читать свойства.  Domain.name.localhost-> Properties- > Security-> Authenticated Users -> Allow Read.

    Если убрать  хоть  одно свойство из  Properties, то  делегированный пользователь перестает видеть всю OU и листинг не возможен.
    К тому же, думаю снимать  рид права  - не стоит, ибо  пользователи не смогут нормально пользоваться  инфраструктурой АД.

    Как вариант создай  новую оснастку для  пользователя SpecUser в которой  будет минимум выбора. 
    23 марта 2009 г. 10:22
  • право на просмотр имеют все юзеры домена (если отдельно не ограничено). права можно делигировать на отдельные юниты.
    открываешь оснастку "Пользователи и компьютеры", правой кнопкой щелкаешь по нужному тебе юниту и выбираешь Делегирование прав.

    У меня параллельно вопрос, может кто знает: какие права нужно делигировать, чтобы пользователь мог переименовать комп в домене. но не давать ему операторские права? (чисто на переименование компа)

    VovaMozg
    23 марта 2009 г. 11:24
  •  Проще всего,  имхо, дать ему полный доступ на учетку компьютера в AD
    23 марта 2009 г. 11:38
    Отвечающий
  • Kurepkin Nikolay,
    группа имеет свойство member, которое содержит членов этой группы, это всего лишь ссылки.
    назначая права на группу они не распространяюца на ее членов. (если бы только пользователи не были дочерними объектами группы, но это уже другая история).



    23 марта 2009 г. 11:56
  • Спасибо всем откликнувшимся!

    Да, я знаю, что по умолчанию права на чтения всех свойств объектов в домене есть у всех авторизованных пользователей. Но, преднамеренно, по требованиям отдела по защите информации, эта возможность была ранее убрана. В целом никаких сложностей в работе мы не испытывали.
    В принципе, было бы возможно дать полный доступ акаунту SpecUsers на конкретные учетные записи, но во-первых это не удобно, во-вторых, состав этих пользователей(чьи свойства необходимо читать) периодически меняется.

    Вариант оснастки также не подходит, т.к. это необходимо не живому человеку, а софтине наших разработчиков.

    Gennady Efimov - ge][,
    А можно по-подробнее про историю с дочерними объектами группы? Может это наш вариант? :)



    Поэтому вопрос все еще в силе - как возможно эту задачу решить? :)

    P.S. VovaMozg,  а прав "Create Computer Object" и "Delete Computer Object" недостаточно для переименования компьютера в домене?
    23 марта 2009 г. 12:49
  • Kurepkin Nikolay,
    ну думаю врядли это может помочь и честно говоря это бессмысленно. потому как в качестве дочернего объекта может выступать любой контейнерный объект, н-р: OU, и собственно разницы нет.

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

    но лучше этого не делать.
    23 марта 2009 г. 14:42
  • Gennady Efimov - ge][ написал:

    Kurepkin Nikolay,
    ну думаю врядли это может помочь и честно говоря это бессмысленно. потому как в качестве дочернего объекта может выступать любой контейнерный объект, н-р: OU, и собственно разницы нет.

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

    но лучше этого не делать.


    Не говорите ерунды, членство в группе - всего лишь аттрибут самой группы.
    А про предков и потомков - почитайте внимательнее про LDAP
    23 марта 2009 г. 14:49
    Отвечающий
  • почему ерунда? это реально.. но бессмысленно...

    вы бы сами внимательно почитали.. и желательно все посты
    23 марта 2009 г. 14:55
  •  Ну нет у объекта группы дочерних элементов.
    А у автора возникла задача, с какой-то неведомой мне софтиной.
    23 марта 2009 г. 15:03
    Отвечающий

  • Gennady Efimov - ge][ написал:

    Kurepkin Nikolay,
    ну думаю врядли это может помочь и честно говоря это бессмысленно. потому как в качестве дочернего объекта может выступать любой контейнерный объект, н-р: OU, и собственно разницы нет.

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

    но лучше этого не делать.

    плохо читаете.. обратите внимание на выделенное.

    23 марта 2009 г. 15:07
  • Это неправда
    23 марта 2009 г. 15:09
    Отвечающий
  • vanchello написал:

    Это неправда


    :) вы правильно сказали.. нужно читать про LDAP.
    23 марта 2009 г. 15:37
  • Kurepkin Nikolay,
    в вашей ситуации поможет следующее.

    добавьте в группу пользователей на которых необходимо дать права на чтение (для большей безопасности сделайте тип группы - распространение).

    и например использовать небольшой скрипт

    echo off

    for /f %%i in ('cmd /c "dsget group CN=users_read,CN=Users,DC=gex,dc=com -members"') do (
      dsacls %%i /G gex\needread:GR /I:T
    )


    в группу users_read добавляем пользователей.
    needread - этому пользователю выдаем права


    • Предложено в качестве ответа Gennady Efimov - ge][ 23 марта 2009 г. 15:50
    • Помечено в качестве ответа Kurepkin Nikolay 24 марта 2009 г. 11:08
    23 марта 2009 г. 15:39
  • Спасибо за конслуьтацию, буду пробовать.
    Я так понимаю, что этот скрипт необходимо запускать каждый раз после изменения членства в этой группе?
    24 марта 2009 г. 11:08
  • да. и еще надо будет подумать о том как удалять права в случае удаления пользователя из группы.

    тут тоже скрипт подойдет. но другой.

    mcp, mcdba, mcsa, mcse, ccna
    24 марта 2009 г. 11:22