Права на папку в домене

Предоставление прав доступа на папку

Коллеги, добрый день.

Столкнулся с проблемой в предоставлении доступа к сетевой папке. Задача следующая: есть сетевая папка с множеством папок и подпапок и кучей файлов внутри каждой. Необходимо предоставить доступ пользователям определенной группы так, что бы получить доступ к файлу можно было только по полному пути (например \сервер123test.txt), а если через проводник то содержание каталога не отображалось или вообще не было доступа к каталогу.

Вот что сделал: на папку \сервер1, на остальные наследуется.

1. Группе 123, дал права «Тип:Разрешить, Применяется к «Только для файлов», Разрешения «Полный доступ» »
2. Группе 123, дал права «Тип:Запретить, Применяется к «Только для этой папки», Разрешения «Запретить все» кроме «Чтение разрешений»»
3. Группе 123, дал права «Тип:Разрешить, Применяется к «Только для этой папки», Разрешения «Чтение разрешений» «

Что не получается, если вместо группы ставить пользователя (Например: USER), то работает как надо, а вот с группой не получается. Все дело происходит в домене, где USER простой «пользователь домена», а группа123 это глобальная группа безопасности, тоже без особых прав.

Подскажите, что ещё упускаю из вида?

Предоставление прав локального админа на ПК домена
Имеется парк компьютеров введенных в домен. Необходимо предоставить права локального.

Предоставление права доступа только на чтение
Здравствуйте, подскажите как можно предоставить доступ только на чтение пользователю в Win Server.

Предоставление доступа к расшаренной папке из другой подсети
В windows server 2008 есть 2 адаптера, подключенные к разным сетям. Как сделать что бы был доступ к.

Предоставление прав пользователям программно
С помощью методов GetPermissions и SetPermissions можно получать и предоставлять права.

Скрин группы из оснастки. Скрин, что пользователь в группе. Скрин NTFS с группой. Перезайти пользователем и проверить.

Так или иначе, чтоб разрешить только папку «3», Вам нужно убирать доступ в папке сервер или 1, откуда у Вас производиться первая настройка NTFS с унаследованием. По я думаю, по умолчанию у Вас стоит «все», потому и есть доступ.

Вам по хорошему надо сделать несколько групп.

С корня дать чтение ну или еще и запись на группу All_Read, а вот пользователю в группе Group_123 дать на папку 3 полный доступ или какой нужен и убрать унаследование.

Наследование выключено.
Все приложенные скрины для одной и той же сетевой папки, но в одном случаи пользователь и все работает, в другом группа и не работает.
Про разрешения писал выше, их три так как:
1. Группе test_201, дал права «Тип:Разрешить, Применяется к «Только для файлов», Разрешения «Полный доступ» » — разрешает делать все что угодно с файлами.
2. Группе test_201, дал права «Тип:Запретить, Применяется к «Только для этой папки», Разрешения «Запретить все» кроме «Чтение разрешений»» — запрещает смотреть папки кроме предоставленных разрешений.
3. Группе test_201, дал права «Тип:Разрешить, Применяется к «Только для этой папки», Разрешения «Чтение разрешений» » — разрешает читать только разрешения предоставленные папкам.

Добавлено через 21 минуту
Добавил группу «Пользователей домена». если данной группу дать разрешения Применяется к «Только для этой папки» — то доступ не появляется, а вот если дать доступ к Применяется к «Папке, подпапкам и файлам» то происходит попытка открыть нужный файл, но выскакивает ошибка «Отсутсвуют разрешенеия на открытие этого файла» Но как я понимаю это происходит из за наложения прав, так как пользователь 15725 так же входит и в «Пользователи домена».

Права на папку в домене

По сути-Вы путаете (или смешиваете) права «на сетевой доступ» и права «файловой системы».

в том что «Разрешения» — это права на уровне сети, а «Безопасность» — это на уровне файловой системы конкретного компьютера. это разные права и настраиваются они отдельно.

он прекрасно понял суть вопроса и направил вас именно туда — куда следовало, читайте внимательнее раздел: Создание разделяемого ресурса. по указанной выше ссылке.

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

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Здесь не принципиально ХП оно или 2003 и права локальные или из АД.

Принципиально-Вы даете права на сетевой доступ а удивляетесь, что доменный пользователь имеет право на запись в файловой системе.

Думаю что в локальную группу пользоватнелей данного компа(как минимум) вллючена доменная группа «пользователи домена».

Если трудно просмотреть начало предложенной темы,то пройдите на закладке вашей папки на вкладку- Безопасность-дополнительно-действующие разрешения. Там все понятно ? И обратите внимание на столбец -«унаследовано от».

корректно — на вкладке «Безопасность». на уровне сети вы можете задать только 3 общих варианта разрешений: полный доступ, чтение, изменение. хотите более детально — настраиваете на уровне файловой системы.

а вообще, в рабочей сети шарами лучше не пользоваться. хотите нормально сделать — подымите ftp и там настройте все.

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Valery12, Отличный ответ!
wwladimir, в принципе, Вы тоже были правы.
Вот теперь понятно, что права «Создание каталогов и файлов» по умолчанию установлены группе локальных пользователей. О том, что в эту группу входит группа «Пользователи домена» я не знал.

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Возник еще один вопрос по теме, чтобы не плодить новых тем, решил задать его здесь.

Ситуация следующая. Для примера, на диске С: имеются вложенные каталоги «Level_1», «Level_2»:

Необходимо настроить разрешения файловой системы пользователю таким образом, чтобы внутри каталога «Level_1» было «Чтение и выполнение», т.е. пользователь не может удалить каталог «Level_2» и не может создать новых. А внутри каталога «Level_2» у этого пользователя разрешено «Изменение».

Я в свойствах каталога «Level_1» добавил пользователю разрешение «Изменение» — применять к «Только для подпапок и файлов».
По факту получилось, пользователь не может создавать новые каталоги и файлы в каталоге «Level_1», но УДАЛЯТЬ каталог «Level_2» может. Хотя, в действующих разрешениях каталога «Level_1» нет разрешений на удаление.

Прошу более опытных коллег объяснить, почему удаляется каталог «Level_2».

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Господа моё почтение. Вынужден поднять эту тему, так как своими силами понять логику майкрософта не в силах.
Исходные данные.
1. Домен на 2008r8.
2. Администраторы домена входят в группу локальных админов, пользователи домена — в группу локальных пользователей (всё как задумали в мс).
3. Пользователь adm1 входит в группу доменных админов. Пользователь user1 — в группу доменных пользователей.
4. «Верхний каталог» fld (владелец — администраторы домена, не наследует сверху) имеет разрешения:
— создатель-владелец: полный доступ для подпапок и файла;
— система: полный доступ для папки, подпапок и файлов;
— пользователи домена: траверс папок, содержание папки, чтение атрибутов, создание папок только для этой папки;
— администраторы домена: полный доступ для папки, подпапок и файлов;
6. «Пользовательский каталог» usrfld (владелец — user1). Права унаследованы от каталога fld с той лишь разницей, что в ACL появилась запись для user1 на полный доступ (как я понимаю заменила запись для пользователей домена). Но она тоже имеет пометку о наследовании от fld.

Проблемы.
1. При такой конфигурации администратор домена ad1 не может зайти в каталог usrfld. Ему предлагается получить прямые разрешения на каталог. Если это сделать, то доступ мы получаем, но тогда возникает закономерный вопрос: почему по группе администраторы домена не пускает?
2. Опять же права на каталог usrfld просматриваются только через нажатия на доп. кнопки и, естественно, распространить права на все вложенные каталоги и файлы не разрешается.
3. Если отдать «верхний каталог» fld в общий доступ (администраторы домена — полный доступ, пользователи домена — изменение), то зайти в него под adm1 получится только после того, как adm1 будет помещён в группу «пользователи домена». Вот как это всё понимать?

Права на папку в домене

В предыдущей статье мы связывали файловый сервер Samba с доменом FreeIPA. Мы развернули и настроили доступ на общие файловые ресурсы с авторизацией пользователей как из домена FreeIPA, так и из доверенного домена Active Directory. Теперь нам нужно создать структуру общего файлового каталога и разграничить доступ на каждую папку в соответствии с правилами, принятыми в организации. Работы будут проводиться на сервере с установленной ОС Rosa Cobalt (он же CentOS7, он же RedHat 7).

Вводные данные.

Перед нами стоит задача: создать структуру общего файлового каталога и разграничить доступ к каталогам в соответствии с принятыми правилами. У нас уже установлен сервер FreeIPA, поэтому все пользователи и группы будем брать из базы FreeIPA.

Будем разворачивать следующую структуру:

• FS_share — общая точка входа на файловом сервере, содержащая папкаи подразделений организации.
• Unit1 — папка первого подразделения
• Unit2 — папка второго подразделения.

1. Все пользователи организации должны видеть структуру каталога.
2. Пользователи первого подразделения должны работать в каталоге Unit1, но не иметь доступ к каталогу второго подразделения.
3. Пользователи второго подразделения должны работать в каталоге Unit2, но не иметь доступ к каталогу первого подразделения.
4. Администраторы файлового сервера должны иметь доступ ко всем каталогам файлового сервера.

Добавляем группы в каталоге FreeIPA.

Для организации доступа к папкам по вышеописанному сценарию нам необходимо в домене FreeIPA создать четыре группы:

1. fs-users — группа, члены которой имеют доступ к корневому каталогу файлового ресурса. В нее добавим встроенную группу ipausers и ранее созданную внешнюю группу, в которую входят пользователи доверенного домена Active Directory. Т.е. доступ на просмотр корневого каталога файлового ресурса будут иметь все пользователи домена FreeIPA и пользователи доверенного домена Active Directory.
2. unit1 — группа, в которую входят учетные записи первого подразделения.
3. unit2 — группа, в которую входят учетные записи пользователей второго подразделения.
4. fs-admins — группа, в которую входят учетные записи администраторов файлового сервера. Т.е. эти пользователи будут иметь полный доступ во все подкаталоги общего файлового ресурса, а также смогут добавлять или удалять объекты (папки) в корневом общего файлового ресурса.

Конфигурация Samba.

Открываем файл /etc/samba/smb.conf и вносим изменения в раздел, описывающий общие ресурсы. Рздел global сейчас не рассматриваем, т.к. мы его уже настроили на предыдущем шаге.

Немного расшифруем директивы:

• Директива force create mode = 0110 необходима для того, чтобы дополнтельно выставить на вновь создаваемые файлы executable бит для владельца и группы, который не выставляется директивой create mask. Директива force create mode действует по принципу ИЛИ с основной маской доступа, и выставляет бит в том случае, если он не выставлен директивой create mask.
• Директива force group = +группа запрещает доступ к папкам всем, кто не входит в эту подгруппу. Текущий пользователь, обращающийся к общему ресурсу имеет только первичное значение по умолчанию группы, назначенное на эту группу. Это позволяет администратору решать, что только пользователи, которые уже находятся в специфической группе, создадут файлы с монопольным использованием группы, установленным на эту группу. Это дает более тонкую степень детализации назначения монопольного использования. Кроме того, это определяет имя группы UNIX, которое будет назначено как первичная группа по умолчанию для всех пользователей, соединяющихся с этим сервисом.
  Это полезно для того, чтобы совместно использовать файлы, гарантируя, что весь доступ к файлам этого сервиса будет использовать названную группу для проверки их разрешений. Таким образом, назначая разрешения для этой группы к файлам и каталогам в пределах этого сервиса администратор Samba может ограничить или позволить совместно использовать эти файлы.
• Директива browsable = no вообще скрывает подпапки из прямой видимости извне. Поэтому, когда вы просматриваете сетевое окружение с других компьютеров, вы увидите только папку FS_Share .
• valid users — список пользователей, которым разрешен доступ к сервису. Имена, начинающиеся с ‘ @ ’, ‘ + ’ и ‘ & ’ интерпретируются согласно некоторым правилам и не действительны в имени пользователя.
  Если значения параметра не определено, то все пользователи могут подключаться. Если имя пользователя находится одновременно и в этом списке и в списке invalid users list тогда, доступ для него к сервису будет запрещен. Потоком servicename заменяют для %S . Для секции [homes] полезно использование %S для подстановки имени пользователя.
• write list — параметр определяет список пользователей имеющих доступ к сервису на чтение/запись. Если соединяющийся пользователь находится в этом списке тогда, он получит доступ на запись независимо от того установлен ли параметр read only (только чтение). Список может содержать названия группы, используется синтаксис @group . Заметьте что если пользователи одновременно находятся в списке только для чтения и в списке на чтение запись они получат доступ и на запись.
• guest ok — если этот параметр задан в yes на общем ресурсе, то для подключения к ресурсу не требуется пароль. По умолчанию установлен в » No «
• create mask — устанавливает права для вновь создаваемых файлов
• directory mask — устанавливает права для вновь создаваемых папок

Права в подпапки Unit1 и Unit2 наследуются от вышестоящей папки ( FS_Share )/ Их задавать в соответствующих разделах не нужно. Более того, если их явно указать в этих разделах, то они игнорируются.

Создаем структуру файлового ресурса и раздаем права.

Для начала необходимо создать структуру папок в корневом каталоге, соответствующую той, которая описана в файле /etc/samba/smb.conf .

Затем назначаем владельцев папок и назначаем права доступа:

• По умолчанию владельцем владельцем корневой папки share является пользователь root . Оставляем этот параметр без изменения.
• Владельцами папок Unit1 и Unit2 делаем соответствующие группы пользователей.
• Права 2770, выставленные на папки Unit1 и Unit2 гарантируют, что все файлы и подпапки, находящиеся в них, будут всегда создаваться с соответствующими подгруппами этих родительских папок, что предоставляет пользователям подгрупп полный доступ к любым документам и подпапкам, даже если они созданы другими пользователями.

В итоге в данной конфигурации мы полностью решили поставленную перед нами задачу.

Права на папку в домене

Поставил домен, а права раздать не могу, задолбался окончательно.
Создал на сервере папку FILMS, открыл общий доступ к ней. В разрешениях добавил группу «Пользователи домена» поставил для нее птицу на чтение. На вкладке «Безопасность» добавил группу «Пользователи домена» и поставил птицы на:
— чтение и выполнение
— список содержимого папки
— чтение
На этом с папкой FILMS все.
Далее создаю внутри нее папку BACKUP, в которую разрешен полный доступ пользователю домена test. На вкладке «Безопасность» для этой папки выставляю абсолютно все птицы для пользователя test. Для проверки захожу в Дополнительно-Действующие разрешения. Еще раз убеждаюсь, что пользователю test разрешено абсолютно все. Регистрируюсь в домене под test-ом, пытаюсь создать папку либо файл — «Не удается создать папку. Отказано в доступе».
Подскажите, плиз, что я делаю не так?

← →
Правильный$Вася ( 2008-09-10 12:08 ) [1]

проверь наследование прав на папки
в нт действует не аддитивная, а отъемлемая политика

← →
brother © ( 2008-09-10 12:18 ) [2]

> test

ты локального пользователя с доменным не путаешь?

← →
*Pavel ( 2008-09-10 13:22 ) [3]

Что касается наследования — я поснимал птицы на опциях:
«Разрешить наследование разрешений от родительского объекта к этому объекту и его дочерним объектам, добавляя их к разрешениям, явно заданным в этом окне»
причем как для корневой папки FILMS так и для ее подпапки BACKUP.

В Дополнительных параметрах безопасности для папки BACKUP:
Элементы разрешений:
Тип: Разрешить
Имя: Test (test@greta.local)
Разрешение: полный доступ
Унаследовано от:
Применять к: Для этой папки, ее подпапок и файлов

Локального пользователя с доменным я не путаю:
Создан в Active Directory->пользователи и компьютеры-> домен Greta.local->Zavod->Otdel_1->Otdel_1_1-> (user test)

← →
brother © ( 2008-09-10 13:34 ) [4]

напиши полный путо до папки BACKUP.

← →
brother © ( 2008-09-10 13:36 ) [5]

> Регистрируюсь в домене

каким образом?

← →
Something ( 2008-09-10 13:40 ) [6]

пользователь test заходит в ресурс как \servernamebackup или \servernamefilmsbackup? второй вариант не пройдет, разрешения на шару имеют приоритет над ntfs правами

← →
*Pavel ( 2008-09-10 14:07 ) [7]

У пользователей сетевой диск подключается в профиле (в сценарии входа) следующим образом:

Set objShell = WScript.CreateObject(«WScript.Shell»)

» Применение:
» strFunctionResult = mapNetworkDrive (DLetter, SharePath)
» SharePath=»\R039.PFR.RUОбщие ресурсыБазы данных КонсультантПлюс» » Сетевой путь к диску
» DLetter=»V:» » Буква диска

Function checkNetworkMapping(strDriveLetter)
Set objNetwork = WScript.CreateObject(«WScript.Network»)
«WScript.Echo «Проверяем наличие подключенного сетевого диска »
CheckNetworkMapping = False
For Each strDrive In objNetwork.EnumNetworkDrives
If LCase(strDrive) = LCase(strDriveLetter) Then
checkNetworkMapping = True
Exit For
End If
Next
If checkNetworkMapping Then
» WScript.Echo «Сетевой диск найден»
Else
» WScript.Echo » Сетевой диск не найден»
End If
End Function

» Эта подпрограмма ассоциирует букву с сетевым каталогом
Function mapNetworkDrive(strDriveLetter, strNetShare)
Set objNetwork = WScript.CreateObject(«WScript.Network»)
on error resume next
err.clear
«WScript.Echo «Подключаем сетевой диск.»
objNetwork.MapNetworkDrive strDriveLetter, strNetShare, false
if err <> 0 then
«Подключение не удалось
«WScript.Echo «не могу ассоциировать » & driveletter & » с » & netshare
objNetwork.RemoveNetworkDrive strDriveLetter
objNetwork.MapNetworkDrive strDriveLetter, strNetShare, false
else
«WScript.Echo «ОК. »
end if
mapNetworkDrive = «ok»
End Function

Пользователь, у которого не подключается сетевой диск автоматом, заходит на ресурс как \xeon2duofilmsbackup. А как иначе? Если выбросить из пути films, т.е. оставить просто \xeon2duobackup — выдаст, что ресурс не найден. Ведь расшаренным ресурсом является только папка FILMS. Если расшарить BACKUP, то тогда, конечно, можно ходить напрямую \xeon2duobackup.

← →
Рамиль © ( 2008-09-10 14:26 ) [8]

> Создал на сервере папку FILMS, открыл общий доступ к ней.
> В разрешениях добавил группу «Пользователи домена» поставил
> для нее птицу на чтение

Поставь всем полный доступ.

← →
oldman © ( 2008-09-10 14:28 ) [9]

> На вкладке «Безопасность» добавил группу «Пользователи домена»
> и поставил птицы на:
> — чтение и выполнение
> — список содержимого папки
> — чтение
> На этом с папкой FILMS все.
> Далее создаю внутри нее папку BACKUP

Вот на содержимое подпапки backup и действуют права папки films.

← →
Anatoly Podgoretsky © ( 2008-09-10 14:42 ) [10]

> Something (10.09.2008 13:40:06) [6]

← →
*Pavel ( 2008-09-10 14:48 ) [11]

> Вот на содержимое подпапки backup и действуют права папки films.
Каким образом? Ведь в параметрах безопасности и для папки Backup и для папки Films запрещено наследование разрешений от родительских объектов к дочерним.

← →
*Pavel ( 2008-09-10 15:30 ) [12]

В общем разобрался я.
Разрешения, выданные при расшаривании расширить НТФС-разрешениями невозможно, а вот сузить-запросто. Получается, что при расшаривании папки пользователям домена надо выдавать полный доступ, а уже в правах НТФС его уменьшать до требуемой величины.

Делегирование административных полномочий в Active Directory

В этой статье мы рассмотрим особенности делегирования административных полномочий в домене Active Directory. Делегирование позволяет предоставить право на выполнение некоторых задач управления в AD обычным пользователям домена, не включая их в привилегированные доменные группы, такие как Domain Admins, Account Operators и т.д.. Например, с помощью делегирования вы можете предоставить определённой группе пользователей (допустим, Helpdesk) право на добавление пользователей в группы, заведение новых пользователей в AD и сброс пароля.

Особенности делегирования прав в AD

Для делегации полномочий в AD используется мастер Delegation of Control Wizard в графической оснастке Active Directory Users and Computers (DSA.msc).

Административные права в AD можно делегировать на довольно детальном уровне. Одной группе можно предоставить право на сброс пароля в OU, другой – на создание и удаление аккаунтов, третье на сброс пароля. Можно настроить наследование разрешений на вложенные OU. Вы можете делегировать полномочия на уровне:

1. Сайта AD;
2. Всего домена;
3. Конкретной OU в Active Directory.

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

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

Представим, наша задача – предоставить группе HelpDesk право на сброс пароля и разблокировку аккаунтов пользователей в домене. Итак, создадим новую группу в AD с помощью PowerShell:

New-ADGroup «HelpDesk» -path ‘OU=Groups,OU=Moscow,DC=corp,dc=winitpro,DC=ru’ -GroupScope Global

Добавьте в группу нужных пользователей:

Add-AdGroupMember -Identity HelpDesk -Members ivanovaa, semenovvb

Запустите консоль Active Directory Users and Computers (ADUC), щелкните ПКМ по OU с пользователями (в нашем примере это ‘OU=Users,OU=Moscow,DC=corp,dc=winitpro,DC=ru’) и выберите пункт меню Delegate Control.

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

Выберите из списка один из преднастроенных наборов привилегий (Delegate the following common tasks):

• Create, delete, and manage user accounts;
• Reset user passwords and force password change at next logon;
• Read all user information;
• Create, delete and manage groups;
• Modify the membership of a group;
• Manage Group Policy links;
• Generate Resultant Set of Policy (Planning);
• Generate Resultant Set of Policy (Logging);
• Create, delete, and manage inetOrgPerson accounts;
• Reset inetOrgPerson passwords and force password change at next logon;
• Read all inetOrgPerson information.

Либо создайте собственное задание делегирования (Create a custom task to delegate). Я выберу второй вариант.

Выберите тип объектов AD, на которые нужно предоставить права. Т.к. нам нужно предоставить права на учетные записи пользователей, выберите пункт User Object. Если вы хотите предоставить право на создание и удаление пользователей в этом OU, выберите опции Create/Delete selected objects in this folder. В нашем примере мы не предоставляем таких полномочий.

В списке разрешений нужно выбрать те привилегий, которые вы хотите делегировать. В нашем примере мы выберем право на разблокировку (Read lockoutTime и Write lockoutTime) и сброс пароля (Reset password).

Нажмите Next и на последнем экране подтвердите назначение выбранных полномочий.

Теперь под учетной записью пользователя из группы HelpDesk попробуйте из PowerShell сбросить пароль пользователя из OU Users, например из PowerShell:

Set-ADAccountPassword petricdb -Reset -NewPassword (ConvertTo-SecureString -AsPlainText “PPPPa$$w0rd1” -Force -Verbose) –PassThru

Пароль должен сброситься успешно (если он соответствует доменной политике паролей).

Теперь попробуйте создать пользователя в данной OU с помомью командлета New-ADUser:

New-ADUser -Name kalininda -Path ‘OU=Users,OU=Moscow,OU=winitpro,OU=DC=ru’ -Enabled $true

Должна появится ошибка доступа, т.к. полномочий на создание учетных записей вы не делегировали.

Для контроля пользователям, которым вы делегированными привилегии, вы можете использовать журналы контроллеров домена. Например, вы можете отследить кто сбросил пароль пользователя в домене, узнать кто создал учетную запись пользователя в AD или отследить изменения в определённых группах AD.

Делегация полномочий на присоединение компьютеров в домен AD

По умолчанию любой пользователь домена может присоединить в домен 10 компьютеров. При добавлении в домен 11-го компьютера появляется сообщение об ошибке.

Вы можете изменить это ограничение на уровне всего домена, увеличив значение в атрибуте ms-DS-MachineAccountQuota (ссылка). Либо (гораздо правильнее и безопаснее), делегировав право на присоединение компьютеров к домену в определенной OU конкретной группе пользователей (helpdesk). Для этого нужно предоставить право создавать объекты типа (Computer objects). В мастере делегирования выберите Create selected objects in this folder.

А в секции Permissions выберите Create All Child Objects.

Отключаем делегирование прав в домене AD

Чтобы лишить группу делегированных ранее прав на OU, откройте свойства OU в консоли ADUC и перейдите на вкладку Security.

В списке разрешений найдите группу, который вы делегировали права и нажмите Remove. Список предоставленных полномочий можно посмотреть на вкладке Advanced. Как вы видите для группы HelpDesk разрешен сброс паролей.

Также со вкладки Security ->Advanced вы можете самостоятельно настроить делегирование полномочий, назначая нестандартные разрешений различным группам безопасности.