Сценарий
Active Directory имеет запланированный фоновый процесс, который называетсяSDPropкоторый периодически проверяет и применяет определенный дескриптор безопасности (разрешения) определенных групп (и их членов), которые AD считаетзащищенный. Устанавливаемые разрешения вытекают из тех, которые установлены наАдминистраторSDHolderобъект в нашей эре.
В рамках данного обсуждения мы сосредоточимся наАдминистраторы домена.
Цитировать:
... Если разрешения для любой из защищенных учетных записей и групп не соответствуют разрешениям для объекта AdminSDHolder, разрешения для защищенных учетных записей и групп сбрасываются в соответствии с разрешениями для объекта AdminSDHolder домена.
Дальше,Операторы счетовиметь по умолчанию разрешения на управление всеми объектами пользователей/компьютеров/групп в домене,за исключением любой из защищенных групп/членов, благодаря этому процессу SDProp.
В данном случае попытка изменить учетную запись администратора домена с помощью оператора учетной записи приводит кдоступ запрещеношибка.
Проблемы
Первая проблема:
Хотя они не могутизменитьэти защищенные учетные записи, согласно вышеуказанному процессу,Операторы счетовМОЖЕТ, однако, удалите их! Это не должно быть возможным, согласно моему пониманию этого механизма защиты.
При просмотре разрешений учетной записи администратора домена, Account Operators нигде не перечислены. Кроме того, запуск эффективной проверки доступа для AO показывает, что у него есть толькоразрешения на чтение/свойства. Все разрешения на запись и удаление запрещены.. Это ожидаемо.
Похоже, что возможность удалить защищенную учетную запись вытекает из ACL в OU, содержащем ее, в соответствии с чем группа операторов учетных записей имеет правоСоздание и удаление пользовательских объектовсправа (только этот объект), в пределах этого OU.
В данном случае, если я отредактирую эту запись ACE и удалю право на удаление, то проблема, указанная выше, исчезнет, и администратор домена больше не сможет удалить администратора домена.
Второй выпуск
Как отмечено выше, эффективные разрешения, похоже, скрывают тот факт, что AO может удалить объект. Я действительно этого не понимаю.
Вопросы, требующие ответа
Почему разрешение на OU переопределяет разрешения, установленные для защищенной учетной записи adminSDHolder? Вся цель этого процесса — ПРЕДОТВРАТИТЬ применение любых конкретных делегированных разрешений откуда-либо к защищенным учетным записям, чтобызащищатьих.
Почему на вкладке «Эффективный доступ» не отображается должным образом, что у меня есть возможность удалить эту учетную запись в соответствии с разрешениями организационного подразделения?
решение1
Действующие разрешения, похоже, скрывают тот факт, что AO может удалить объект. Я действительно этого не понимаю.
Мне понравилось этоБезопасная идентификациятак много постов на эту тему, что я решил сослаться и процитировать соответствующие части, которые имеют отношение конкретно к вашему вопросу.
Я думаю, это хороший вопрос, на который многие люди захотят узнать, является ли использование операторов учетных записей стандартной практикой в их среде домена AD. Я, конечно, никогда не пытался удалить учетную запись члена AD с правами администратора домена с помощью оператора учетных записей, но в прошлом я поддерживал среды, в которых использовались операторы учетных записей, а я был администратором домена.
Теперь, если мы посмотрим на имеющиеся у нас варианты удаления объектов в Active Directory, вы, возможно, заметили, что существует три различных типа удаления:
- Удалить (удалить маску доступа)
- Удалить ребенка (маска доступа ADS_RIGHT_DS_DELETE_CHILD)
- Удалить поддерево (маска доступа ADS_RIGHT_DS_DELETE_TREE)
И вот тут начинается самое интересное. При выполнении действия удаления система проверяет дескриптор безопасности как для объекта, так и для его родительского объекта, прежде чем разрешить или запретить удаление.
ACE, который явно запрещает пользователю доступ Delete, не имеет эффекта, если у пользователя есть доступ Delete Child к родительскому объекту. Аналогично, ACE, который запрещает доступ Delete Child к родительскому объекту, может быть переопределен, если доступ DELETE разрешен к самому объекту.
Источник: Контроль доступа и удаление объектов
Примеры удаления и удаления дочернего элемента:
Пример первый:
У моего пользователя-администратора Тони нет доступа ACE: Allow Delete к пользователю Domain Admin с именем Hank. Тони все равно может удалить учетную запись, если у него есть ACE: Allow Delete Child User к родительскому OU.
Пример два:
Если на Хэнке установлен явный доступ ACE: Deny Delete, Тони все равно сможет удалить учетную запись, если у него есть доступ ACE: Allow Delete Child User на родительском OU.
А если мы обратим это так: Тони окажется в ACE: Deny Delete Child User в родительском OU, он все равно сможет удалить его, если у него есть Explicit Allow Delete в ACE для объекта пользователя.
Итак, мы видим, что
AdminSDHolder Security Descriptorна самом деле не во всех сценариях защищает администраторов или вложенные группы.. Если вы посмотрите на изображение эффективных разрешений, у Тони не было прав на удаление пользователя. Но у него есть ACE: Allow Delete Child User в родительском OU, и он сможет удалить Хэнка, который является членом группы администраторов домена.Права по умолчанию
Теперь, когда мы обсудили права доступа на удаление, было бы неплохо подумать о том, у кого эти полномочия по умолчанию имеются в Active Directory?Помимо очевидных, таких как администраторы, администраторы домена, администраторы предприятия, у нас, конечно, есть также известные Группа операторов счетов.
Операторы учетных записей имеют по умолчанию явный Полный контроль над объектами User, Computer, Group и InetOrgPerson. У них нет такого явного доступа, предоставленного в дескрипторе безопасности AdminSDHolder, но у них есть явный Создать/Удалить дочернего пользователя, группу, компьютер и InetOrgPerson в организационных единицах.Если родительское подразделение для администраторов домена не имеет явного запрета на удаление дочерних пользователей, АО сможет удалять пользователей администраторов домена.
(Если вы готовы к этой задаче, его можно удалить из атрибута defaultSecurityDescriptor класса объекта, определенного в схеме)
Другой подход — это нацеливание на вложенность групп: если у пользователей есть членство в DA через вложенность групп, просто удалите эту группу, и они больше не будут DA.
Вот несколько причин, по которым я хочу выделить административное подразделение в качестве корневого подразделения, чтобы минимизировать риски ошибочного делегирования.
Поддерживающие ресурсы
решение2
Я думаю, что ваше заблуждение исходит из предположения, что поскольку Domain Admins — защищенная группа, то все ее члены также защищены. Что не так. Следовательно, AdminSDHolder не применяется к этим учетным записям.
В документации это нигде не указано явно, но также не указано, что члены группы Domain Admins считаются защищенными. Также не указано, что Account Operators не могут удалять членов группы Domain Admins
Использованная литература: