Использование заданий, ролей и областей для администрирования AD

Возможность децентрализовать администрирование сети предприятия высоко ценится ИТ-специалистами. Наделив сотрудников правом выполнять административные задачи, можно снизить общую стоимость владения (Total Cost of Ownership — TCO) информационной инфраструктурой. Для децентрализации администрирования в сетях Windows используются разнообразные методы и технологии. Например, делегировать управление в Active Directory (AD) можно с помощью мастера Active Directory Delegation of Control Wizard и редактора ACL Editor. Мастер Delegation of Control Wizard можно настроить на реализацию конкретного плана. В данной статье сначала будет рассматриваться процесс делегирования в целом, а затем более подробно — процедура настройки мастера.

Задание, роль, область

Прежде чем приступить к совершенствованию административной модели, необходимо проанализировать производственные процессы и кадровые ресурсы предприятия. Только после изучения различных факторов, влияющих на администрирование сети предприятия, можно приступать к реализации модели. В крупных организациях со сложной иерархией наиболее уместен нисходящий подход, который я называю «задание, роль, область» (Task, Role, Scope). Этот метод применим и на малых предприятиях.

Задание. На этапе задания необходимо составить список всех административных задач предприятия, независимо от того, кто и каким образом их выполняет. Чтобы не пропустить ни одного из аспектов деятельности организации, можно разделить задачи по категориям. Например, в табл. 1 приведены типичные административные категории и подзадачи.

Роль. После того как список административных задач предприятия составлен, можно переходить к ролям. На данном этапе идентичные задания группируются согласно обязанностям, назначаемым каждому уровню администрирования и поддержки. Например, на персонал службы поддержки возлагаются задачи изменения пользовательских паролей, разблокирования учетных записей и ввода новых пользователей в группы, а на роль более высокого уровня возлагается задача создания пользователей и групп в AD.

Область. На этапе «область» роли применяются к конкретным подразделениям предприятия. Например, роль службы поддержки уровня 1 может изменять пароли пользователей, разблокировать их и добавлять пользователей в группы. Но в крупной организации может существовать несколько региональных справочных служб. В этом случае каждый регион становится областью администрирования. Нередко области образуют естественную иерархию, где некоторые роли действуют в широкой (например, национальной, международной) области, а внутри этой области находятся роли, распределенные между малыми областями (например, районами, сайтами). Области применяются и на других этапах. Например, группа технического обслуживания уровня 2 может создавать и присоединять компьютеры к домену — но только клиентские компьютеры. Группа технического обслуживания уровня 3 отвечает за создание и присоединение серверов к домену. В этом случае различие между клиентами и серверами становится областью.

Эти три этапа могут стать составными частями процесса проектирования AD. Области определяют структуру организационной единицы (OU) экземпляра AD. Первое и самое важное правило проектирования организационной единицы AD заключается в том, что OU должна отражать административную модель, а не организационную диаграмму. Организационные единицы должны отражать естественную иерархию областей. Список заданий, которые следует делегировать другими средствами, например с помощью параметров Group Policy, списков управления доступом (ACL) и членства в группах, представлен во врезке «Когда делегирование технически не считается таковым».

Группы безопасности

После того как организована структура OU, которая поддерживает области администрирования, можно создать группы безопасности для каждой роли. В группах безопасности содержатся пользовательские учетные записи сотрудников, выполняющих конкретные роли. При распределении ролей между областями всегда следует определить и группы безопасности. Предположим, что группа технической поддержки уровня 2 — национальная, а служба технических консультаций уровня 1 — локальная. В этом случае необходимо сформировать несколько групп безопасности, представляющих службу технических консультаций уровня 1 в каждом подразделении.

В административной иерархии в группу безопасности, созданную для роли, нередко входят члены групп безопасности, организованных для ролей более высокого уровня. Например, в группу безопасности для справочной службы уровня 1 могут входить члены группы безопасности для службы технической поддержки уровня 2, чтобы ее администраторы могли сбрасывать пароли, разблокировать учетные записи и добавлять пользователей в группы.

Чтобы выполнить назначенные задания, в частности сбросить пароли пользователей, следует назначить группе безопасности (роль) соответствующие разрешения (задание) в нужной организационной единице (область). Так, например, можно назначить справочной службе уровня 1 западного региона разрешение Allow:Reset Password (сброс паролей) для пользовательских объектов в организационной единице West Users. Тщательно проанализировав задания, роли и области, можно сформировать иерархию OU и вложенных групп безопасности, которые минимизируют число изменений списков ACL, вносимых в AD.

Делегирование в AD

Делегирование административных заданий в AD производится путем манипуляций со списками ACL объектов AD. Каждому заданию соответствует разрешение. Например, с заданием сброса пароля связано разрешение Reset Password, которое можно активизировать или блокировать (явно или по наследованию), точно так же как разрешения Read или Write для файла или папки.

Обращение к списку управления доступом объекта AD производится так же, как к ACL файла или папки. Сначала необходимо открыть оснастку Active Directory Users and Computers консоли управления Microsoft Management Console (MMC), перейти в меню View и выбрать пункт Advanced Features. Щелкнув правой кнопкой мыши на объекте AD и выбрав пункт Properties, можно вывести на экран вкладку Security, которая представляет собой интерфейс редактора ACL Editor.

Интерфейс ACL Editor состоит из нескольких уровней диалоговых окон. В первом диалоговом окне отображается базовая информация о шаблонах разрешений, назначенных конкретным субъектам безопасности (security principal), например пользователям, группам, компьютерам. Между интерфейсами административных инструментов Windows Server 2003 и Windows 2000 Server существуют небольшие различия. На экране 1 показан интерфейс Windows 2003. Например, в Windows 2003 для управления наследованием используется только диалоговое окно Advanced Security Settings, а в Windows 2000 доступ к флажку наследования можно получить как в диалоговом окне Security Settings, так и в Advanced Security Settings. Кроме того, если разрешения субъекта безопасности выходят за рамки стандартных шаблонов разрешений, приведенных в диалоговом окне, то в нижней части диалогового окна Windows 2000 появляется набранное мелким шрифтом предупреждение об отсутствии в окне некоторых из существующих разрешений. Пользователь может и не заметить эту информацию. В Windows 2003 появился дополнительный шаблон безопасности Special, который легче заметить при просмотре разрешений учетной записи. Однако шаблон Special размещается в нижней части списка разрешений, поэтому, чтобы увидеть его, придется прокрутить экран.

Экран 1. Интерфейс ACL Editor

Щелкнув на кнопке Advanced во вкладке Security, администратор переходит ко второму диалоговому окну. Между диалоговыми окнами Advanced Security Settings системы Windows 2003 и Access Control Settings системы Windows 2000 также существуют различия. В окне Advanced Security Settings системы Windows 2003 (см. экран 2) появился столбец Inherited From, с помощью которого можно определить, в какой точке дерева OU было применено конкретное разрешение. Еще одно полезное новшество Windows 2003 — кнопка Default, которая удаляет список ACL, заменяя его стандартным ACL, определенным в схеме для объекта. И наконец, из новой вкладки Effective Permissions можно проанализировать итоговые разрешения для конкретного субъекта безопасности.

При добавлении или редактировании в списке Permission entries на экране появляется диалоговое окно Permission Entry, которое относится к третьему уровню цепи диалоговых окон безопасности и содержит наиболее подробную информацию о разрешениях объекта и свойств. Окно Permission Entry при переходе от Windows 2000 к Windows 2003 существенно не изменилось.

Мастер делегирование управления

Знать о диалоговых окнах ACL Editor полезно, как и о функциональности вкладки Effective Permissions, но я не рекомендую использовать их для делегирования. Поскольку в этих диалоговых окнах приведена очень подробная информация, при манипуляциях с ними легко допустить ошибки, которые могут привести к катастрофическим последствиям.

Мастер Delegation of Control Wizard скрывает сложности изменений списков ACL. Для запуска мастера следует щелкнуть правой кнопкой мыши на крупном контейнере (например, сайте, домене, OU) и выбрать пункт Delegate Control. Другие объекты AD (например, пользователи, группы) не располагают функцией Delegate Control. Все объекты AD имеют списки ACL и поэтому поддерживают делегирование, но изменение ACL отдельных объектов-«листьев» AD связано с серьезным риском. Такие изменения могут выйти из-под контроля, их трудно документировать, анализировать и проводить диагностику. Я рекомендую задействовать контейнеры в качестве точек делегирования, а затем полагаться на механизм наследования для изменения ACL объектов внутри этих контейнеров. Microsoft рекомендует данный метод и отображает функцию Delegate Control лишь в нескольких крупных контейнерах.

Используя функцию Delegate Control из контейнера, администратор автоматически выбирает область делегирования. Мастеру требуется следующая информация.

?Пользователи или группы, которым предполагается передать управление. Чтобы указать получателя разрешений, администратор вводит субъектов безопасности, а именно административную группу, которая представляет эту роль. На экране 3 показан мастер, в котором вводятся субъекты безопасности.

* Тип управления, которое следует предоставить субъектам безопасности. Как показано на экране 4, в мастере используется термин «задание» (task). Пользователь может выбирать из списка заданий, определенных мастером как типовые, или сформировать специализированное задание. Определения типовых заданий в конкретной организации, как правило, отличаются от выбираемых по умолчанию. Но, как будет показано далее, мастер Delegation of Control Wizard может быть настроен на отображение типовых заданий конкретного предприятия.

Таким образом, даже мастер следует оптимальной процедуре — нисходящей реализации «задание, роль и область». После того как эти три компонента определены, мастер соответствующим образом изменяет ACL в контейнере.

Настройка интерфейсов делегирования

К сожалению, из-за ограниченного списка типовых заданий мастера Delegation of Control Wizard процедура делегирования излишне упрощается, и мастер становится бесполезным для реализации любого тщательно продуманного плана делегирования. Например, типичная административная задача — разблокирование учетных записей, пользователи которых забыли свои пароли. Другой пример — изменение пароля. Оптимальный метод изменения пользовательского пароля — потребовать, чтобы пользователь ввел новый пароль в ходе следующей процедуры регистрации. Этого нельзя сделать с помощью мастера Delegation of Control Wizard в Windows 2000 (однако данная задача выполнима в мастере Delegation of Control Wizard системы Windows 2003). Строгий контроль удаления объектов, в частности пользователей, групп и компьютеров, — еще одна распространенная задача, особенно в крупных организациях, так как удаление объекта приводит к потере его SID (security identifier — идентификатор безопасности). Типовая операция мастера обеспечивает создание, управление и удаление пользовательских объектов, но как быть, если требуется разделить эти задания?

Чтобы настроить операции, выполняемые мастером, можно изменить файл delegwiz.inf в скрытой папке \%windir%inf. В простой структуре файла delegwiz.inf каждое типовое задание определено шаблоном, содержащим дружественное пользователю имя и подробную информацию об изменениях списка ACL, которые должны быть сделаны мастером при делегировании. В начале файла delegwiz.inf находится раздел с именем DelegationTemplates. В следующем за ним параметре Templates перечислены шаблоны, сохраненные в данном файле. Чтобы добавить или удалить шаблон, необходимо ввести или изъять имя шаблона из этого списка.

В листинге 1 показан шаблон, который представляет собой часть стандартного файла delegwiz.inf. Исходный текст с меткой A в листинге 1 указывает, что шаблон будет применен при вызове мастера из домена, OU или объекта-контейнера. Исходный текст с меткой B содержит понятное пользователю описание задания. Исходный текст с меткой C указывает, что если задание выбрано в мастере Delegation of Control Wizard, то мастер изменит разрешения в контейнере-области и в пользовательском объекте. Шаблон разрешений существует для области и для пользовательских объектов. Шаблон разрешений области обеспечивает создание и удаление пользовательских объектов. Шаблон разрешений пользовательских объектов назначает полные разрешения (GA в листинге 1) всем свойствам пользовательских объектов.

Используя шаблоны листинга 2, можно реализовать два типовых задания, которых не хватает в мастере Microsoft. Список в параметре Templates раздела DelegationTemplates необходимо дополнить элементами templatecustom01 и templatecustom02. Требуется изменить delegwiz.inf на компьютере, который используется для администрирования AD. Чтобы сделать файл delegwiz.inf доступным для нескольких администраторов, его следует распространить соответствующим образом. При применении пакета исправлений или модернизации операционной системы этот файл может быть перезаписан, поэтому нужно обязательно сделать его резервную копию. После того как настройка мастера Delegation of Control Wizard будет завершена, легко делегировать управление без обращений к спискам ACL объектов AD и риска допустить ошибку.

Более подробную информацию о структуре delegwiz.inf можно найти в статье Microsoft «HOWTO: Customize the Task List in the Delegation Wizard» (http://support.microsoft.com/?kbid=308404). Сведения о конкретных именах свойств и объектов протокола LDAP и описателях разрешений приведены на сайте TechNet и в сети Microsoft Developer Network (MSDN).

Пропавшие разрешения

Досадный недостаток редактора ACL Editor как Windows 2003, так и Windows 2000 — невозможность увидеть все имеющиеся разрешения, их слишком много. Такое ограничение понятно, но что делать, если назначается разрешение, которое невозможно увидеть на экране? Изменив dssec.dat, текстовый файл в папке system32, можно выбрать разрешения, которые отображаются в ACL Editor. Файл dssec.dat разбит на разделы, каждый из которых представляет параметр. Значение параметра 7 означает, что разрешение скрыто, а при значении 8 (или полном отсутствии параметра) разрешение выводится на экран. В листинге 3 показан раздел [user] файла sampledssec.dat.

В разделе [user] параметру lockoutTime присвоено значение 7, поэтому он в ACL Editor не отображается. Данный параметр будет виден, если заменить значение на 0 (см. экран 5). Файл dssec.dat в системе Windows 2003 не содержит lockoutTime в разделе [user], поэтому параметр отображается в ACL Editor.

Экран 5. Выбор разрешений, которые следует выводить

Кроме того, файл dssec.dat определяет, какие параметры представлены в разделе специальных заданий мастера Delegation of Control Wizard. Как и в случае с delegwiz.inf, необходимо изменить dssec.dat на машине, с которой выполняется администрирование AD. Следует сделать резервную копию dssec.dat, чтобы файл не был изменен при применении пакетов исправления или модернизации операционной системы. Если delegwiz.inf был настроен таким образом, чтобы облегчить делегирование заданий, к которым нельзя получить доступ иными средствами, то назначаемые разрешения следует сделать видимыми с помощью dssec.dat. Например, если второй шаблон листинга 2 используется для операции Unlock locked user accounts (разблокирование учетных записей пользователей), то параметру lockoutTime в файле dssec.dat следует присвоить значение 0.

Исключение ошибок администратора

В результате тщательного планирования процесса делегирования и распространения специализированных файлов dssec.dat и delegwiz.inf, необходимых для реализации данной модели, можно построить более эффективную среду, надежно защищенную от ошибок пользователей. Если администратор намерен делегировать управление AD вручную, а роли организации группируют задания иным способом, нежели мастер Delegation of Control Wizard, то задачу можно значительно облегчить с помощью методов, описанных в данной статье.

Когда делегирование технически не считается таковым

Далеко не исчерпывающий список заданий в Таблице может стать отправной точкой для составления собственного списка. В список администратора конкретного предприятия, по-видимому, войдут следующие дополнительные административные задачи:

  • добавление и удаление контроллеров доменов (DC);
  • резервное копирование контроллеров доменов;
  • создание объектов групповой политики (Group Policy Object, GPO).
  • администрирование инфраструктуры безопасности домена (например, сертификатов PKI для протокола IPSec);
  • управление записями DNS;
  • развертывание, настройка конфигурации и поддержка компьютеров;
  • администрирование серверов с помощью Remote Desktop for Administration;
  • создание совместно используемых сетевых папок;
  • управление разрешениями доступа к файлам и папкам;
  • управление очередями принтеров.

Для делегирования этих и других подобных заданий используются параметры Group Policy, списки ACL для конкретных ресурсов (например, папок, зон DNS) или членство в соответствующих группах (например, членство в группах Server Operators, Power Users или Administrators дает возможность создавать разделяемые ресурсы). Для реализации этих заданий делегирование AD не используется, поэтому здесь мы их рассматривать не будем. Однако такие задания можно анализировать с помощью метода заданий, ролей и областей. Для реализации этой модели нужно лишь использовать метод, отличный от делегирования AD.

Дэн Холм (danh@intelliem.com) — директор по обучению в компании Intelliem, специализирующейся на обучении и консалтинге по корпоративным технологиям Windows и Active Directory