Мне нужно настроить два типа пользователей, которые могут администрировать пользователей и группы безопасности AD:
Я делаю это на основе функции управления делегированием. Идея состоит в том, чтобы не иметь единой точки доверия для создания пользователей и добавления их в группы безопасности, поэтому для этой операции потребуются как минимум 2 человека.
Все ясно с Тип 1 пользователей. Я только что настроил управление делегированием для учетной записи пользователя и сумел создать пользователей в пределах только установленного OU (то есть операторов) с этим.
С участием Тип 2 все стало сложнее, потому что, как я заметил, это не группа, связанная с пользователем, а фактически пользователь, связанный с группой. Я могу изменить членство в группе только для 1 OU (т.е. группы операторов), но я могу добавить ЛЮБОГО пользователя в группы внутри этого OU. Это означает, что пользователь, ответственный за изменение членства в группе, может добавить себя в любую из групп, что для меня неприемлемо, поскольку только пользователи, созданные Тип 1 пользователь может быть добавлен в группы безопасности, контролируемые Тип 2 пользователей.
Теоретически я вижу только правильное решение, как реализовать это ограничение на уровне группы безопасности или подразделения для изменения членства в группах для пользователей, которые не входят в разрешенное подразделение, однако я искал в Google и исследовал базу знаний Microsoft, но не смог найти какой-либо достаточной информации как это можно сделать.
Может быть, кто-нибудь знает, как это можно реализовать, или может подсказать, как еще я могу реализовать необходимую конфигурацию?
пользователь, ответственный за изменение членства в группе, может добавить себя в любую из групп
Конечно. Это сделано намеренно. Связанные отношения между группами и членами групп в Active Directory делают вперед ссылка из группы на пользователя с возможностью записи ( член атрибут), а обратная ссылка от пользователя к группе ( член атрибут) вычисляется внутренне и только для чтения. Вы не можете делегировать право редактировать атрибут memberOf пользователю. Подробнее о том, как это хранится в Блог Флориана.
Вывод для этого случая: членство в группе контролируется возможностью пользователя редактировать группа, а не целевой пользователь, которого нужно добавить в группу. Обычно это происходит потому, что группа «принадлежит» определенному человеку или группе внутри организации, поскольку она контролирует доступ к привилегированным ресурсам этой группы. Следовательно, эта группа, назначенная руководителем службы безопасности, должна иметь право по своему усмотрению определять, каким членам организации предоставляются разрешения, предоставленные группой. Это дискреционный политика контроля доступа.
Пункт обучения: Вы не можете делегировать управление группой таким образом, чтобы пользователь мог добавлять участников только из определенного подразделения.
Желаемая конечная цель описывает комбинацию обязательное и дискреционный политики контроля доступа:
Это невозможно при использовании механизмов делегирования Active Directory по умолчанию по причине, о которой я говорил вначале. Любая подходящая реализация этого должна быть нетехнической (то есть политикой) системой или отдельным субстратом, с помощью которого пользователь изменяет свое членство в группе:
Сообщите всем сотрудникам, что они должны добавлять в свои делегированные группы только членов из своих контролируемых подразделений. Настройте автоматические отчеты для отслеживания нарушений этой политики и либо автоматически исправляйте их (удалив нарушившего пользователя), либо отправляйте уведомление по электронной почте в соответствующие органы.
Не делегируйте право пользователям изменять членство в группах напрямую. Вместо этого используйте сторонний программный пакет (который вы можете разработать на заказ). Программному пакету делегировано управление на редактирование любой из управляемых групп. Он может проверить правильность выбора пользователя, которого нужно добавить (путем проверки OU на соответствие ACL и т. Д.), Прежде чем вносить изменения от имени пользователя.
Вы можете представить себе ситуацию, в которой вы перевернете логику - создайте две группы для каждого OU:
При создании ACL для ресурса вы добавляете группу OU с полным доступом и группу deny со всеми ACE, установленными на deny. Делегированные разрешения означают, что конечные пользователи могут отказать в доступе любому по своему выбору (из любого подразделения). Это не нарушает модель, потому что пользователям нужно позволять привилегии для получения доступа, и они доступны только из Группа OU которому вы не делегируете права на изменение.
Это не идеально по многим направлениям:
Я рекомендую вам сделать одно из следующего: