Задний план
Я создаю службу, позволяющую персоналу службы поддержки включать свои учетные записи пожарного вызова в нерабочее время (то есть, если ночью возникает проблема, и мы не можем связаться с кем-то с правами администратора, другой член группы поддержки может включить свои личные учетная запись firecall в AD, которая ранее была настроена с правами администратора). Эта служба также регистрирует причину изменения, предупреждает ключевых людей и множество других битов, чтобы гарантировать, что это изменение доступа проверено / чтобы мы могли гарантировать, что эти временные права администратора используются надлежащим образом.
Для этого мне нужна учетная запись службы, под которой работает моя служба, чтобы иметь разрешения для включения пользователей в активный каталог. В идеале я бы хотел заблокировать это, чтобы учетная запись службы могла только включать / отключать пользователей в определенной группе безопасности AD.
Вопрос
Как вы предоставляете доступ к учетной записи, чтобы включить / отключить пользователей, которые являются членами определенной группы безопасности в AD?
Резервный вопрос
Если это невозможно сделать группой безопасности, есть ли подходящая альтернатива? т.е. может ли это быть выполнено подразделением, или было бы лучше написать сценарий, чтобы перебрать всех членов группы безопасности и обновить разрешения для самих объектов (учетные записи пожарного вызова)?
Заранее спасибо.
Дополнительные теги
(У меня еще нет доступа для создания новых тегов здесь, поэтому приведенный ниже список поможет с поиском по ключевым словам, пока он не будет помечен и этот бит не будет отредактирован / удален) DSACLS, DSACLS.EXE, FIRECALL, ACCOUNT, SECURITY-GROUP
Разрешение на изменение свойств объектов Active Directory (AD) контролируется списками управления доступом (ACL). Списки ACL применяются к объектам явно (без наследования) или неявно путем наследования от контейнера (OU или объекта-контейнера), в котором находится объект.
Делегирование управления атрибутами пользователю или группе (вы почти всегда должны делегировать разрешения группам, в стороне) - это не что иное, как изменение разрешений для объектов контейнера (чаще всего) или отдельных объектов, не являющихся контейнером (например, учетных записей пользователей и учетных записей компьютеров- - хотя технически они являются контейнерные объекты).
ACL не применяется к объектам на основе членства в группе безопасности объектов, что, по вашему мнению, и является тем, что вы ищете.
Лучше всего организовать учетные записи пользователей, над которыми вы хотите передать управление, в OU и делегировать управление этим OU. Если это невозможно, то вы застряли в изменении списков ACL для каждой учетной записи пользователя индивидуально.
Большинство сторонних программ для управления идентификацией и доступом могут обрабатывать этот тип управления доступом, выполняя запрос от имени пользователя, обычно с использованием учетных данных администратора домена (но они всегда могут быть заблокированы в дальнейшем).
К сожалению, сама Windows не может этого сделать: членство в группе в AD на самом деле просто указано в списке участников группы ( member атрибут группы, используемый для генерации memberOf сконструированный атрибут) и не имеет структурного значения в каталоге (напомним, что AD - это в основном просто LDAP). В отличие от этого, разрешения в AD определены структурно, так что вы можете дать учетным записям определенные разрешения для поддеревьев (например, домена, подразделения или отдельного пользователя) в соответствии с иерархией, которую не определяют группы. Структура основана на доменах и OU, как и любое другое дерево LDAP. Если что-то не отображается в DN (отличительном имени) пользователя, это не может использоваться для управления разрешениями каталога.
Делегация. Вам необходимо делегировать разрешение на запись атрибуту userAccountControl для объекта.
Это делегирование может применяться к членам группы безопасности.