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