Я пытаюсь дать пользователю "второстепенные" права администратора для настройки учетных записей пользователей в нашей AD.
У нас есть Windows Server 2012, и у меня уже есть группа AD "Local Admin", которую я использую, чтобы дать некоторым пользователям права на вход на каждую рабочую станцию, установку программного обеспечения ...
На данный момент у нас есть только стандартная папка «users» в нашей AD, которая содержит всех пользователей, но я не могу делегировать права здесь, потому что это не OU.
Какой здесь лучший вариант. Я думаю, мне нужно переместить пользователей в разные папки, у кого-нибудь есть совет или лучшие идеи?
Если ваша организация собирается серьезно относиться к безопасности Active Directory, вам нужна модель управления доступом на основе ролей (RBAC). Есть много способов сделать это, в том числе использовать стороннее решение для управления идентификацией. По моему опыту, сторонние решения только меняют проблему и добавляют сложности. Вместо этого я обнаружил, что очень хорошо работает:
1) Не используйте контейнер «Пользователи» по умолчанию для делегирования доступа. Создание OU упростит вам жизнь, когда дело доходит до делегирования детального доступа и применения групповой политики. Разделите подразделения верхнего уровня по уровням администрирования. Все, что может быть использовано для взлома контроллеров домена, относится к уровню 0, корпоративные службы - к уровню 1, а ваши пользовательские рабочие станции - к уровню 2. Вы также должны реализовать политику для предотвращения входа учетных записей администраторов более высокого уровня на компьютеры более низкого уровня, поскольку это может подвергнуть их атаке с кражей учетных данных. Это означает, что вам потребуется несколько учетных записей домена для некоторых администраторов, в зависимости от их роли. Например, человеку, нанятому для управления лесом AD, потребуются отдельные учетные записи для администратора предприятия, администратора домена, администратора сервера уровня 0, администратора сервера уровня 1 и администратора рабочей станции уровня 2. Кому-то, нанятому в службу поддержки, потребуются только администратор подразделения Tier-2 и администратор рабочей станции Tier-2. Учетная запись администратора OU используется для создания / удаления / изменения объектов AD для их области / отдела, а учетная запись администратора рабочей станции используется для удаленного администрирования рабочих станций для их области / отдела. Вам необходимо разделить эти роли, чтобы компрометация меньшей роли (администратор рабочей станции) не могла скомпрометировать более высокую роль (администратор подразделения). Это также означает, что теперь вам необходимо внедрить рабочие станции с привилегированным доступом (PAW) для администраторов с более высокой ролью. Мы уже развлекаемся?
2) Установите стандартизированную структуру OU, которая обеспечивает соблюдение принципала с наименьшими привилегиями. Вы должны решить, будет ли эта модель основываться на местоположении, отделе или немного обоим. Для уровня 2 мне нравится использовать и то, и другое, где подразделение первого уровня основано на местоположении, а затем подразделения в этом месте имеют подразделения ниже этого. Это позволяет местной службе поддержки делегировать права на все объекты в их расположении, а каждому отделу со своим собственным ИТ-персоналом можно делегировать права только на свои объекты. Подразделения уровня 0 и уровня 1 могут быть основаны на группах, выполняющих службы. Все зависит от того, что лучше всего подходит для ваших организационных нужд.
3) Каждое создаваемое вами подразделение должно содержать стандартный набор вложенных подразделений, групп безопасности, списков контроля доступа и групповой политики. Причина этого в том, что вы можете легко создать сценарий создания OU / Group / ACL / GPO, и он всегда будет вести себя одинаково каждый раз. Стандартизация - ключ к сохранению вашего рассудка, поверьте мне в этом. Если позже вы решите что-то изменить в будущем, измените это для всех структур OU и обновите процесс создания. Я предпочитаю иметь эти стандартные OU:
ACL для каждого стандартного OU будут использоваться для ограничения доступа на создание / удаление пользователя / компьютера / группы и чтения / записи всех свойств для стандартной группы администраторов OU, связанной со структурой OU. Заполните группы пользователями, которым нужна эта роль. Я настоятельно не рекомендую включать группы в какие-либо стандартные группы администраторов, если это не является абсолютно необходимым. Вы можете быстро потерять контроль над своими администраторами, если вложение групп выйдет из-под контроля. Я предпочитаю размещать группы администраторов OU в Admin OU на уровне выше, чтобы пользователи службы поддержки могли назначать администраторов OU отдела. Делайте то, что работает для вашей организации, но сохраняйте последовательность.
Вот несколько хороших источников информации по этой теме: