Одна из важнейших функций AD - делегирование административных полномочий объектов каталога группам конкретных пользователей - требует знания системы безопасности AD и тонкостей управления полномочиями в AD. Также необходимо изучить работу редактора AD ACL Editor, мастера делегирования полномочий Delegation of Control Wizard и понять, с какими "подводными камнями" придется столкнуться при формировании стратегии делегирования полномочий AD.

ОСНОВНЫЕ ПОНЯТИЯ И ОПРЕДЕЛЕНИЯ AD

AD состоит из объектов и их атрибутов. Например, объект "пользователь" имеет такие атрибуты, как имя (First Name) и адрес (Address), а объект OU (ogranizational unit - организационная единица) - такие атрибуты, как описание (Description) и Address. В AD разрешается назначать полномочия целым объектам и отдельным атрибутам объектов. Более того, каждый класс объектов может иметь различный набор полномочий безопасности. Если приложение добавляет новый класс объектов или атрибут, то для расширения схемы AD могут потребоваться дополнительные полномочия безопасности. Полномочия безопасности - это типы операций (например, чтение, запись, удаление), разрешенные для конкретного объекта. В AD имеется девятнадцать стандартных полномочий защиты, и класс объектов может располагать любым числом расширенных полномочий, специфических для данного класса. Например, право Create Site Link Objects (создание объектов связи узлов) допустимо и применимо только к классам объектов, относящимся к узлам.

Назначение полномочий объектам и их атрибутам - основа AD-делегирования. С помощью модели безопасности AD можно наделить пользователей правом изменять определенные объекты. Чтобы управлять делегированием полномочий в AD, необходимо освоить редактор Windows 2000 ACL Editor.

Каждый объект AD снабжен списком ACL, содержащим элементы контроля доступа (ACE). Элементы ACE состоят из прав или полномочий, назначенных объекту или атрибуту. ACL объекта AD хранится в атрибуте ntSecurityDescriptor. Обычно ntSecurityDescriptor нельзя увидеть с помощью обычных административных инструментов AD для просмотра объектов.

Для просмотра ACL-объектов можно использовать редактор ACL Editor. В некоторых документах обозначено различие между списком разграничительного управления доступом (discretionary ACL - DACL) и системным списком управления доступом (System ACL - SACL). В списках DACL можно указать лиц, имеющих доступ к объекту, и предоставляемый пользователям уровень доступа. В списке SACL перечислены пользователи, чье обращение к объектам вызовет событие аудита. AD позволяет задействовать списки SACL для проверки доступа к объекту.

Принимаемый по умолчанию ACL каждого класса объектов в схеме AD находится в атрибуте DefaultSecurityDescriptor объектного класса. Если новый объект AD не наследует полномочий от объекта-родителя или получает полномочия из другого источника, то ему будет назначен ACL на основе атрибута DefaultSecurityDescriptor.

Процедура задания списков ACL является более гибкой, чем процедура назначения полномочий файловой системы. Добавляя элемент ACE для конкретной группы пользователей к объекту AD, администратор решает, какие полномочия предоставить или аннулировать, а также определяет область действия этих полномочий. Полномочие может распространяться на целый объект или лишь на отдельные его атрибуты. Объект и атрибуты объекта могут иметь разные наборы полномочий. Например, назначая параметры безопасности OU, можно предоставить такие полномочия, как Create Printer Objects (создание объектов печати) и Delete Computer Objects (удаление объектов "компьютер"). Однако, защищая конкретные атрибуты OU, можно разрешить простой доступ для чтения или записи к каждому атрибуту. На Рисунке 1 показаны полномочия, такие как Read country Code (прочитать код страны), для объекта Finance OU.

Можно установить и область изменения полномочий безопасности. Например, на Рисунке 1 показан раскрывающийся список Apply onto, из которого можно выбрать тип объекта, связанного с элементом ACE. Элемент ACE может применяться только к данному OU, ко всем объектам данного OU (в том числе другим OU, группам и пользователям) или отдельным типам объектов внутри OU (например, компьютерам и пользователям). Если не проявить осмотрительности, на этом уровне управления безопасностью AD можно легко запутаться в паутине полномочий.

НАСЛЕДОВАНИЕ

Используемая в AD модель наследования сходна с применяемой в файловой системе NTFS 5.0 (NTFS5) Windows 2000. Если разрешить наследование, то вновь создаваемые объекты унаследуют полномочия от объектов-родителей. Если полномочия определены для всего домена (то есть на доменном уровне AD), и в домене была создана новая OU, то организационная единица наследует полномочия, определенные на доменном уровне. С помощью наследования можно определить, кому разрешается выполнять различные операции в рамках инфраструктуры AD по мере ее расширения. С помощью редактора ACL Editor не составляет труда выяснить, какие элементы ACE унаследованы от объекта-родителя. Унаследованные ACE выделены серым цветом, и их нельзя изменить, не отключив механизм наследования.

Отключить наследование можно со стороны объекта-потомка или объекта-родителя. Чтобы сделать это, откройте ACL Editor на объекте AD, затем снимите флажок Allow inheritable permissions from parent to propagate to this object ("Разрешить передачу наследуемых полномочий от родителя данному объекту"). После щелчка на кнопке OK появляется диалоговое окно Security. Если решено, что объект не должен наследовать полномочий из родительского домена, то имеющиеся унаследованные полномочия можно скопировать или удалить. Если выбрана операция Copy, то все существующие унаследованные элементы ACE для объекта копируются на объект; и так как эти полномочия более не считаются унаследованными, то впоследствии их можно изменить. Если выбрана операция Remove, то все унаследованные элементы ACE удаляются из объекта, и остаются лишь специально отмеченные элементы ACE.

Для управления полномочиями, переходящими от родительских объектов к дочерним, откройте окно Properties для ACE родительского объекта. В этом диалоговом окне есть флажок Apply these permissions to objects and/or containers within this container only ("Применить данные полномочия к объектам и/или контейнерам только внутри данного контейнера"). Если отметить этот флажок, то ACE будет назначен лишь объектам или контейнерам, входящим в текущий контейнер, и не перейдет нижележащим контейнерам.

Предположим, что организационная единица Finance содержит единицу (sub-OU) Accounting OU. Необходимо делегировать полномочия по созданию и удалению объектов "компьютер" в Finance OU административной группе Finance Admins, но не предоставлять членам этой группы таких же прав в Accounting OU. В соответствии с обычными правилами наследования, элемент ACE, определенный для Finance OU, будет присвоен и Accounting OU. Чтобы изменить обычный порядок наследования, следует создать соответствующий ACE для Finance OU, выбрать пункт Computer Objects в раскрывающемся списке Apply onto и отметить флажок Apply these permissions to objects and/or containers within this container only. В результате группа Finance Admins будет иметь права только в отношении объектов "компьютер" в Finance OU.

РЕДАКТОР ACL EDITOR

Редактору ACL Editor свойственны некоторые своеобразные особенности, а интерфейс AD ACL Editor для Windows 2000 - не самый дружественный среди программ управления.

Чтобы открыть ACL Editor из меню оснастки Active Directory Users and Computers консоли управления Microsoft Management Console (MMC), следует выбрать пункт View\Advanced Features. Затем нужно щелкнуть правой кнопкой мыши на объекте, выбрать пункт Properties из контекстного меню и щелкнуть на закладке Security, показанной на Рисунке 2 . После того, как ACL Editor будет открыт, выясняется, что нельзя выполнить горизонтальную прокрутку имен групп безопасности или имен пользователей, показанных в верхнем подокне. Имя, которое не умещается в окне, невозможно прокрутить вправо, чтобы увидеть его окончание. Это ограничение предстоит обойти.

В окне Permissions показаны наборы стандартных полномочий, которые могут быть назначены выделенному объекту. Если выделена OU, то эти полномочия - Full Control (полный контроль), Read (чтение), Write (запись), Create all child objects (создание любых объектов-потомков) и Delete all child objects (удаление любых объектов-потомков). Если выделен домен, объект "пользователь" или объект "компьютер", то на экране появляется более длинный список других стандартных прав. Назначить базовые права доступа к объекту можно, не покидая первой страницы ACL Editor. Однако для более сложных операций нужно щелкнуть на кнопке Advanced, после чего появляется диалоговое окно Access Control Settings (Параметры управления доступом), показанное на Рисунке 3.

В этом диалоговом окне можно выполнить несколько операций. В частности, назначить аудит объекту AD. Эту функцию может принять на себя лицо, имеющее право присваивания владения объектов в AD, что позволит ему переустановить полномочия на объекте. Можно также просматривать и редактировать отдельные элементы ACE в списке ACL. Чтобы изменить ACE или установить полномочия на объекте или свойстве, следует выбрать элемент ACE в окне Permission Entries и щелкнуть на кнопке View/Edit.

При определенных обстоятельствах ACL Editor может выдать ошибочную информацию, что ACE не имеет назначенных полномочий. Если использовать функции Advanced для создания и редактирования ACE и установить комбинацию расширенных полномочий элемента ACE, отличную от стандартной, то при просмотре в ACL Editor список ACL будет выглядеть лишенным стандартных полномочий. Так получается потому, что ни одно из стандартных полномочий не отражает выбранных расширенных полномочий.

МАСТЕР ДЕЛЕГИРОВАНИЯ ПОЛНОМОЧИЙ ПО АДМИНИСТРИРОВАНИЮ ОБЪЕКТОВ

Делегировать полномочия по администрированию объектов AD с помощью ACL Editor сложно, поэтому компания Microsoft дополнила редактор ACL мастером Delegation of Control Wizard. Мастер проводит по этапам процедуры назначения пользователям и группам набора полномочий на объект AD. Чтобы воспользоваться мастером делегирования, следует открыть любую оснастку AD в MMC и щелкнуть правой кнопкой мыши на объекте-контейнере. Запустить мастер можно из результирующего меню, выбрав пункт Delegate Control. Мастер работает только с объектами-контейнерами (например, доменами, организационными единицами), которые могут содержать другие объекты-контейнеры и объекты-листья (то есть объекты, не имеющие потомков, такие как пользователи и группы). В меню, вызываемом щелчком правой кнопки мыши на объекте "пользователь", нет команды запуска мастера.

В диалоговом окне мастера, показанном на Рисунке 4, предусмотрено два режима назначения полномочий. В первом случае предлагается набор заранее определенных операций, таких как Create, delete and manage user accounts ("Создавать, удалять и управлять пользовательскими учетными записями"). Во втором случае можно специально настроить операцию, определив область ее действия и набор полномочий.

Функции мастера для построения элементов ACE нельзя назвать интуитивно понятными. Пусть требуется делегировать операцию Create, delete and manage user accounts для OU. С помощью мастера право выполнять эту операцию назначается двум группам пользователей, Finance Admins и EastCoast Admins. Четыре элемента ACE, генерируемые в этом случае, показаны в Таблице 1.

Мастер создает по два ACE для каждой группы пользователей. Он должен назначить группам Finance Admins и EastCoast Admins права создания, удаления и управления пользовательскими учетными записями в OU. Мастер создает два элемента ACE, область действия которых охватывает OU и все дочерние объекты OU. Каждый ACE дает группе пользователей полномочия Create User Object и Delete User Object. Кроме того, мастер генерирует два элемента ACE, область действия которых охватывает только объекты "пользователь". Каждый из этих ACE дает группе пользователей права полного контроля над объектами "пользователь".

При создании элементов ACE мастер делает ряд предположений. Так, он "полагает", что группам пользователей следует назначить полномочия Create User Object и Delete User Object в текущем OU и всех дочерних OU, что может быть неверно. При этом мастер исходит из того, что группам пользователей требуется доступ только к объектам "пользователь", что также может быть неверно. Чтобы полностью контролировать работу мастера, нужно выбрать режим Create a custom task to delegate ("Подготовить специализированную задачу для делегирования") в начальном диалоговом окне мастера. В этом режиме можно пройти по всем этапам построения ACE.

Мастер делегирования не позволяет изменить ранее назначенные им полномочия. Он не сохраняет никакой информации о своих предыдущих действиях. Допустим, мастер был задействован для назначения группе Finance Admins права считывать и записывать все свойства объектов "пользователь" в Finance OU. Затем было решено, что члены группы Finance Admins должны читать и записывать только свойство "подразделение" пользователя. Если вновь запустить мастер, выбрав только эти полномочия, то мастер не изменит ACL. Это происходит потому, что мастер обращается к текущему ACL и обнаруживает, что права на чтение и запись свойства "подразделение" уже назначены; мастер не понимает, что полномочия следует ограничить только свойством "подразделение". Если бы мастер позволял назначать объектам негативные ACE, то можно было бы сначала запретить все свойства, за исключением свойства "подразделение", а потом предоставить права для свойства "подразделение". Однако лучший способ изменить полномочия после работы мастера - использовать редактор ACL Editor для непосредственного изменения ACE.

ПРОБЛЕМЫ И "ПОДВОДНЫЕ КАМНИ"

Делегирование полномочий AD - трудная задача, особенно если пользоваться инструментами, предоставленными для этой цели Microsoft. От мастера Delegation of Control Wizard мало пользы, если нужно делегировать управление администраторам. А сложности ACL Editor могут переполнить чашу терпения даже самого опытного из них. Устав преодолевать трудности управления списками AD ACL, многие компании разместят администраторов в группе Domain Admins, так как по умолчанию члены Domain Admins имеют полномочия во всем домене AD. Однако в результате такого решения делегирование полномочий AD теряет смысл.

Управление защитой AD - лишь одна из целей делегирования полномочий; вторая цель - безопасность ресурсов. Предоставление администратору прав полного контроля (Full Control) над объектом AD (например, сервером) не дает ему автоматического контроля над ресурсами сервера, потому что административные группы, кроме Domain Admins, не имеют явных полномочий на управление ресурсами сервера. Если административной группе нужно предоставить административный контроль над ресурсами сервера, то ее необходимо явно сделать членом локальной административной группы сервера. Или же можно использовать функцию централизованного назначения политик безопасности Group Policy. С помощью Group Policy можно определить круг лиц, имеющих доступ к физическим ресурсам, скрытым за назначенными полномочиями безопасности AD.

Полномочия на администрирование серверных объектов AD, назначенные с помощью ACL Editor, предоставляют административной группе возможность запускать и останавливать службы, управлять принтерами и создавать или удалять общие каталоги на сервере. В текущей версии Windows 2000 для выполнения этих задач необходимы отдельные процессы.

Делегирование административных прав в Windows 2000 связано с предоставлением полномочий для доступа не только к объектам AD, но и к ресурсам локальных машин, таким как файловая система, системные службы и локальная политика безопасности. Однако Windows 2000 не связывает эти задачи между собой, и безопасность AD устанавливается с помощью сложного редактора ACL Editor, а защита ресурсов - с применением Group Policy. Помимо перечисленных, в распоряжении администраторов имеется не очень много инструментов для работы со сложной моделью защиты AD.

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


Даррен Мар-Элиа - внештатный редактор журнала Windows NT Magazine. Специалист по архитектуре NT; занимается планированием развертывания сетей NT 4.0 и Windows 2000 в масштабах США. С автором можно связаться по адресу: dmarelia@earthlink.net.