
- •Планирование топологии сайта
- •Планирование леса
- •Планирование доверия
- •Планирование подразделения
- •Планирование домена и подразделения
- •Планирование репликации
- •Планирование сайта главного офиса
- •Планирование промежуточного сайта
- •Планирование контроллера домена
- •8.2. Причины делегирования администрирования
- •Делегирование администрирования лесов, деревьев и подразделений
- •Определение видимости объектов в Active Directory
- •Планирование изменения структуры
- •Средства преобразования Active Directory
- •Планирование тестовой лаборатории
- •Планирование архивации и восстановления
- •Планирование логической структуры домена
- •Моральная подготовка
- •Забудьте о Windows 2000
- •Комитет по планированию структуры домена
- •Управление доменами
- •Управление внесением изменений
- •Анализ предприятия
- •Рабочие среды предприятия
- •Внешняя среда
- •Внутренняя среда
- •Дополнительная среда
- •Работа с организационными диаграммами
- •Административное моделирование
- •Централизованное администрирование
- •Децентрализованное администрирование
- •Хорошо, плохо, неразумно
- •Логическая структура домена: блок-схема
- •Функции корневого домена
- •Домены второго уровня
- •Управление отдельными департаментами
- •Уменьшение задержки передачи данных по сети и снижение негативного эффекта от проведения репликации
- •Использование моделей децентрализованного администрирования
- •Управление автономными отделами
- •Применение различных политик доменов
- •Обеспечение требований безопасности
8.2. Причины делегирования администрирования
Причина |
Описание |
Организационная структура |
Необходимость обеспечения возможности независимого функционирования организации |
Правовые требования |
Необходимость обеспечения возможности ограничения доступа к секретной информации |
Операционные требования |
Необходимость обеспечения возможности создания уникальных ограничений конфигурации, доступности и безопасности |
Делегируемая административная ответственность может быть разделена на две категории: управление службами (service management) и управление данными (data management). Управление службами — это ответственность за доставку служб каталога, а управление данными — ответственность за содержимое каталога. Администратор служб отвечает за управление службой каталога, а администратор данных — за управление содержимым каталога.
Делегирование администрирования лесов, деревьев и подразделений
Для делегирования администрирования в лесах, деревьях и подразделениях используются структуры. Выбор той или иной структуры зависит от конкретных целей делегирования. Прежде чем перейти к чтению следующего материала, убедитесь в том, что вы хорошо поняли смысл предыдущего раздела, "Делегирование администрирования".
Администратор леса является членом группы Domain Admins (Администраторы домена) и имеет контроль над группами Enterprise Admins (Администраторы предприятия) и Schema Admins (Администраторы схемы). Это по умолчанию дает возможность администратору леса полностью контролировать все настройки леса. Поскольку "хозяин" леса управляет всеми контроллерами доменов, он является администратором служб. Члены группы Domain Admins имеют право управлять контроллерами домена, поэтому они также являются администраторами служб. Доступ к объектам подразделений регламентируется таблицей управления доступом; следовательно, пользователи и группы, имеющие контроль над объектами подразделений, являются администраторами данных.
Реализация безопасности объектов
Каждый объект Active Directory, например файл или запись реестра, имеет идентификатор безопасности. Таким образом, безопасность ресурсов каталога обеспечивается аналогично безопасности файлов. Фактически присвоение идентификатора безопасности означает предоставление прав на запись и/или чтение всего объекта, группы свойств объекта или же отдельного свойства обьекта. Благодаря идентификаторам безопасности администраторы получают средство контроля за процедурами обновления объектов каталога и пользователями, поддерживающими и обновляющими эти объекты.
Простое и многоуровневое наследование
Объекты Active Directory автоматически наследуют разрешения контейнера, в котором они находятся, а также разрешения родительского контейнера. Такая форма наследования используется по умолчанию, что существенно облегчает задачу администрирования объектов.
Разрешения распространяются вниз по иерархии от объектов-родителей к объектам-потомкам (если они существуют). Например, если создать подразделение Marketing (Маркетинг) и предоставить группе Marketing Admins (Администраторы подразделения Marketing) разрешения на полный доступ к объектам этого подразделения, то все дочерние подразделения унаследуют эти разрешения, в результате чего члены группы Marketing Admins будут иметь полный доступ и к объектам дочерних подразделений.
При необходимости, наследование дочерним объектом разрешений родительского объекта можно запретить.