Делегирование прав или как предоставить пользователю определённые права
 

Хочу пользователю в AD в ходящему в группу domain users дать права на установку программ, ввод компьютера в домен а также право на удалённый рабочий стол.
Делаю так управление групповой политикой=> выбираю OU в которой находится данный пользователь => вкладка делегирование. Далее выбираю пользователя и разрешение для этого контейнера и всех дочерних контейнеров. Далее жму дополнительно (управление групповой политикой) выбираю нужного пользователя по умолчанию у него стоит галочка особые разрешения, нужно ли в этом окне давать ещё какие либо разрешения?
И ещё в этом окне жму дополнительно там есть вкладка Разрешения. Выбираю своего пользователя жму изменить а дальше какие выбрать разрешения?

очень хреновая идея. оттветтье объективно на вопрос "зачем?"
По умолчанию, любой пользователь домена может в него добавить до 10 компьютеров включительно. После превышения этого значения пользователь получит предупреждение «Your computer could not be joined to the domain. You have exceeded the maximum number of computer accounts you are allowed to create in this domain. Contact your system administrator to have this limit reset or increased» после попытки добавить компьютер в домен. Компьютер, конечно же, в домен не добавится.

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

виноват. подумалось, что права выдаются всем пользователям сети.

Ты лучше подскажи как правильно сделать задуманное ?
Буду очень благодарен а то в google что то не нашёл нужной информации.

Как понял можно через OU правой кнопкой и в мастере делегирования выбрать нужное. Но что нужное мне а что нет, непонятно.
К примеру создание,удаление и управление учётными записями inetOrgPerson что это такое?
Может лучше создать особую задачу для делегирования и там выбрать разрешения?

vaistor, прошу прощение

Хотелось бы сделать несколько уточнений вашего вопроса. Правильно ли я понял?

У вас есть рабочие станции пользователей (компьютеры), на которых установлен Lotus и пользователь с правами Domain Users, который администрирует Lotus. Так?
Вам необходимо предоставить этому пользователю административные привилегии для установки программ, а также ввода рабочей станции в домен и удаленный рабочий стол на рабочие станции. Так я вас понял?

Если так то
Делегирование прав в AD не решит этой проблемы, так как это операция позволяет данному пользователю лишь управлять объектами AD в том Подразделении (OU), к которому вы предоставили ему права.
Для того чтобы пользователь смог выполнять функции по переустановке программ на рабочих станциях пользователей ему необходимо предоставить права Локального Администратора на эти компьютеры. Это можно решить двумя способами: 1) Вручную добавить пользователя в группу Локальных Администраторов на каждой рабочей станции. или 2) создать групповую политику, привязать её к подразделению (OU) Active Directory, в котором размещены учетные записи рабочих станций, и соответственно настроить в этой групповой политики политику "Группы с ограниченным доступом" (Restricted Groups). Этим также можно воспользоваться для добавление пользователя в группу "Пользователи удаленного рабочего стола".

Если я что-то не так понял прошу пояснить.

Чтобы пользователь мог вводить в домен больше десяти компьютеров, выполните рекомендации из статьи:

Ratibor79 Можно по подробнее?
Как я понял захожу в объекты групповой политики=> создаю новую политику далее конфигурация компьютера => политики => конфигурация windows=>параметры безопасности=> локальные политики=>назначения прав пользователя?

vaistor

конфигурация компьютера => политики => конфигурация windows=>параметры безопасности=>Группы с ограниченным доступом
Правой кнопкой мыши => Добавить группу.
Выбираем группу (заранее созданную), куда входит пользователь, которому необходимы права Локального администратора на клиентских компьютерах.
В появившемся окне в секцию "Эта группа входит в:" (или This Group is Member) жмем добавить и пишем Администраторы (или Administrators). Снова Добавить и пишем Пользователи удаленного стола (или Remote Decktop Users). Всё
Перезагружаем клиентские компьютеры или применяем команду ipconfig /force на клиентских компьютерах.

Сделал так в OU users куда входит пользователь, создал там же группу глобальная тип группы безопасность.
Пользователю указал что он в этой группе.
Указал эту группу в группе с ограниченным доступом. Дальше эта группа входит: добавил administrators и remote desctop users.
И члены этой группы: туда добавил пользователя.
Применил политику к OU users.
gpupdate /force и перезагрузка не помогла у пользователя не появились разрешения на установку удаление программ.

vaistor

А вот этого не нужно было делать
Давай так
1. Добавить группу - выбираем группу, в которую входит пользователь, кому предоставляются права локального администратора (тип ввода должен быть - Domain\Group)
2. Только в секции "эта группа входит" - добавляем Administrators (если английская) и/или Администраторы (если русская) или и то и другое по очереди, если используются клиентские компьютеры обоих языков. Тип ввода такой (Group - без указания домена или имени компьютера). Это важно!
Эти действия позволят добавить твою группу в группы локальных администраторов на клиентских компьютерах.
По поводу remote desctop users - я погорячился, так как у членов группы администраторы и так есть права на удоленый доступ.
3. Ну теперь gpupdate /force или перезагрузка клиентского ПК

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

Пробуй.

vaistor, вот здесь наглядно http://www.frickelsoft.net/blog/?p=13
Посмотри

Спасибо сейчас посмотрю.

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

On Error Resume Next
Set ws = WScript.CreateObject ( "WScript.Shell" )
compname = ws.ExpandEnvironmentStrings ( "%COMPUTERNAME%" )
Set adGrp = GetObject ( "WinNT://" & compname & "/Администраторы,group" )
adGrp.Add ( "WinNT://domen/User Admins,group" )
Set adGrp = GetObject ( "WinNT://" & compname & "/Administrators,group" )
adGrp.Add ( "WinNT://domen/User Admins,group" )

Не получается делегировать права на управление пользовательскими аккаунтами.

Исходные данные:
Есть домен domain1.ru
В нем контроллер домена dc1.domain1.ru под управлением ОС Windows Server 2008 R2 (пока единственный)
Создана OU UserAccounts, в которой будут находиться все учетные записи пользователей домена
Есть группа UserAccountsAdms, членами которой будут некоторые пользователи домена, не обладающие правами Администратор домена и т.п.

Хочется:
Дать возможность членам группы UserAccountsAdms администрировать учетные записи пользователей, расположенные в OU
UserAccounts

Воспользовавшись мастером делегирования (Правой кнопкой на OU UserAccounts - Delegate Control - Next - Add - UserAccountsAdms - даем права Create, Delete and Manage user accounts) получаем что ПОКА члены группы UserAccountsAdms могут создать/редактировать/отключить/удалить учетную запись вновь созданного пользователя User1.
Но через какое-то время (5-15 минут) эта возможность пропадает.
Смотрю права на OU UserAccounts - UserAccountsAdms имеет все необходимые разрешения
Смотрю права на пользователя User1 - UserAccountsAdms там УЖЕ нет

Подскажите, пжл, в какую сторону смотреть.
Спасибо!

Если User1 — привилегированный пользователь, администрировать подобным образом его не получится. (Т.е., получится, но не стоит.) Система распознаёт его в качестве привилегированного и не даёт разрешения не-администраторам.

нет, User1 - это обычный рядовой пользователь домена.

Решение найдено
В моем случае у пользователей атрибут adminCount был установален в 1 (почему то).
Соответственно, AdminSDHolder отрабатывал и выданные разрешения пропадали.
Очень помогла http://support.microsoft.com/default...b;EN-US;817433

Он до этого побывал в одной из административной групп, а система не зачищает атрибут adminCount после удаления из группы.

1. атрибут adminCount был выставлен в 0 :)
2. не было его ни в какой привилегированной группе на 200%

Вот написал, что решение найдено, ан нет... Не выходит каменный цветок.
Скрипт, который приведен в http://support.microsoft.com/default...b;EN-US;817433 отработал. По результатам его работы adminCount=0 у User1, наследование включилось, UserAccountsAdms имеет все необходимые разрешения ...
И все равно в течение часа все слетает :(. И adminCount=1 у User1.
Проверил членство User1 в группах - никуда, кроме Domain Users он не входит.
Получается, что Domain Users привилегированная группа... :wow:
Хотя MS утверждает, что защищаемые группы в Windows Server 2008 R2 это:
Account Operators,
Administrator,
Administrators,
Backup Operators,
Domain Admins,
Domain Controllers,
Enterprise Admins,
Krbgt,
Print Operators,
Read-only Domain Controllers,
Replicator,
Schema Admins,
Server Operators

Что еще проверить?

Тогда не скажу.

Копаю дальше...
Решил посмотреть, какие группы привилегированные
Выполняю
get-adgroup -ldapfilter "(objectcategory=group) (admincount=1)"
и в результате прочего получаю
...
DistinguishedName : CN=Domain Users,CN=Users,DC=domain1,DC=ru
GroupCategory : Security
GroupScope : Global
Name : Domain Users
ObjectClass : group
ObjectGUID : 79f8eb80-4b2c-4f33-8eea-a756c4762eb8
SamAccountName : Domain Users
SID : S-1-5-21-3276496243-159508281-4038852760-513
...
Разве так должно быть?

Пока решение такое
1. Проверяем какие группы защищены AdminSDHolder
открываем PowerShell и выполняем
В результатах должны быть только следующие группы:
Account Operators,
Administrator,
Administrators,
Backup Operators,
Domain Admins,
Domain Controllers,
Enterprise Admins,
Krbgt,
Print Operators,
Read-only Domain Controllers,
Replicator,
Schema Admins,
Server Operators
2. Если Domain Users в защищенных группах, то сбрасываем admincount в ноль у группы
3. Проверяем какие пользователи защищены AdminSDHolder
В PowerShell и выполняем
4. Если там есть обычные пользователи, то сбрасываем в 0 admincount у всех пользователей. Руками или скриптом.
5. Проверяем, что наследование разрешений у пользователей включено
6. Проверяем, атрибут dsHeuristics. (Выполнить adsiedit - Configuration - Services - Windows NT - Directory Service - Properties). Для вывода всех операторов из под защиты ввести 000000000100000f. У меня был <not set>.
7. Принудительно запускаем SDProp (или ждем 1 час): LDP - Bind, Browse - Modify - Edit Entry Attribute=FixUpInheritance, Values=Yes - Run