Делегирование полномочий в AD повышает производительность информационной инфраструктуры предприятия.
При правильном использовании возможностей делегирования полномочий в Windows 2000 Active Directory (AD) можно значительно увеличить производительность информационной системы предприятия и обеспечить его надежную защиту. Однако на этом пути могут встретиться серьезные препятствия: дело в том, что действия администраторов при внедрении модели делегирования полномочий не всегда соответствуют тем принципам, которые реализовали в AD разработчики Microsoft.

По мере формирования структуры модели делегирования необходимо перевести повседневные задачи и функции администраторов на особый язык прав доступа AD. Несмотря на то что администратор может хорошо знать, кто из ИТ-персонала какие задачи выполняет, как отразить эти задачи в терминах полномочий AD — не всегда понятно. Я предлагаю читателям несколько приемов делегирования, выходящих за рамки элементарного уровня и касающихся проблем, с которыми можно столкнуться на конкретном предприятии. Несколько примеров из реальной жизни помогут сформировать надежную модель делегирования полномочий в AD, в соответствии с требованиями среды.

Основы

На первый взгляд в модели делегирования полномочий в AD нет ничего сложного. Точно так же, как при назначении полномочий для работы с NTFS можно предоставить пользователям доступ лишь к части файловой системы, в AD можно создать записи управления доступом (ACE) и предоставить пользователям права (или лишить прав) доступа только к части каталога. В одном и том же контейнере можно связать правила с одними типами объектов (например, учетными записями компьютеров) и не связывать с другими. Можно также связать права с целым объектом, например, так, чтобы администратор полностью контролировал учетные записи пользователя. Но можно обеспечивать безопасность каждого атрибута объекта отдельно: допустим, разрешить администраторам менять телефонные номера пользователей, но не их пароли. Когда правила понятны, задача создания модели делегирования получает естественное решение. Нужно научиться предоставлять младшим администраторам полномочия по отношению к тем фрагментам леса AD, которые необходимы им для выполнения их задач — не больше и не меньше.

Прежде всего, в качестве азбуки делегирования полномочий в AD обсудим делегирование прав Account Options, в том числе права принудительной смены пароля. Затем я затрону вопросы делегирования прав на перемещение объектов за пределы и внутрь подразделений организации (филиалов) — на этом примере легко уяснить, как эффективно решать задачи, связанные с делегированием ограниченных прав. После обсуждения основных понятий я познакомлю читателей с процессом создания централизованной модели делегирования.

И, наконец, от контекста именования домена, применительно к которому до того момента будут обсуждаться задачи делегирования, я перейду к контексту именования конфигурации и расскажу о делегировании полномочий на уровне управления сайтами.

Делегирование права Account Options

Сначала необходимо запустить оснастку Active Directory Users and Computers консоли Microsoft Management Console (MMC), затем выбрать определенного пользователя и щелкнуть на вкладке Accounts. На экране появиться раздел Account options, содержащий список из 10 пунктов. Первые два пункта — это User must change password at next logon («Пользователь обязан сменить пароль при следующем подключении») и User cannot change password («Пользователь не имеет права менять пароль»). Остальные восемь пунктов объединены одним атрибутом с побитным маскированием под общим названием User Account Control. Несмотря на то что побитное маскирование представляет собой эффективный способ хранить много параметров на небольшом пространстве, что положительно сказывается на репликации и хранении данных, с точки зрения делегирования полномочий оно создает проблему. Атрибуты объектов являются элементарными составляющими делегирования в AD. Единичный атрибут не допускает дальнейшего деления. Поэтому все восемь свойств в составе атрибута User Account Control обрабатываются по принципу «все или ничего». Если предоставить сотрудникам службы технического сопровождения право User Account Control, это позволит им не только активизировать учетную запись пользователя, но и установить для этого пользователя неограниченное применение пароля. Администраторы вполне обоснованно возражают против того, чтобы сотрудники службы технической поддержки освобождались от обязанности периодически менять пароли в пользовательских учетных записях, поскольку пароли с неограниченным сроком действия повышают уровень риска для системы безопасности.

Многие администраторы ошибочно полагают, что право User Account Control покрывает также два первых свойства в списке Account options. Первое свойство — User must change password at next logon — является правом, которое администраторы часто делегируют сотрудникам службы технической поддержки одновременно с правом разблокировать учетные записи пользователя и менять пароли. Обладая этими правами, сотрудники службы технической поддержки могут помочь пользователям снова получить доступ к своим учетным записям после того, как те сами себя заблокировали в результате неумелой смены пароля. Принуждение пользователей к смене паролей при очередном подключении дает гарантию, что сотрудники службы технической поддержки не будут в дальнейшем знать пароли этих пользователей.

Я опишу процесс делегирования права принудительно вызывать изменение паролей (документацию по этой процедуре мне найти не удалось). Данный пример также иллюстрирует основы делегирования полномочий в AD для тех, кто вообще не знаком с процессом делегирования. Обычно решение задач делегирования осуществляется на вкладке Security оснастки Active Directory Users and Computers. По умолчанию вкладка Security скрыта в оснастке. Чтобы ее увидеть, нужно щелкнуть View, Advanced features.

Право вызывать смену пароля контролируется через параметр pwdLastSet. Но по умолчанию этот параметр на графический интерфейс Security не выводится. Список всех скрытых атрибутов содержится в файле dssec.dat, который расположен в каталоге system32. Для того чтобы сделать этот атрибут видимым, следует открыть файл, перейти к заголовку секции User, найти строку «pwdLastSet=7» и заменить 7 на 0, как показано на Экране 1. В окне Security показываются все атрибуты, значение которых отлично от 7. Пока файл dssec.dat открыт, можно заодно поменять значение параметра LockoutTime с 7 на 0. Атрибут LockoutTime, также скрытый по умолчанию, позволяет делегировать право разблокировать учетные записи. Далее следует либо отредактировать файл dssec.dat на каждом сервере и рабочей станции, которые подлежат администрированию, либо скопировать отредактированный файл на каждую машину.

Экран 1. Изменение pwdLastSet в dssec.dat.

Теперь необходимо вернуться к оснастке Active Directory Users and Computers и щелкнуть правой кнопкой мыши по OU, содержащей учетную запись пользователя, параметры которой будут администрировать сотрудники службы технической поддержки. Нужно перейти на вкладку Security, затем щелкнуть Advanced, New. В диалоговом окне следует ввести имя учетной записи пользователя или учетной записи группы, которым требуется назначить полномочия или выбрать имя из списка прокрутки. Далее нужно ввести имя службы технического сопровождения и нажать OK. Чтобы просмотреть список полномочий уровня объекта, следует щелкнуть по области Apply onto («Применить к») и выбрать User objects («Объекты»). Затем необходимо перейти на вкладку Properties и установить флажки Allow («Разрешено») для атрибутов Read pwdLastSet и Write pwdLastSet (см. Экран 2). Если эти атрибуты не видны, нужно перезапустить оснастку Active Directory Users and Computers. Также можно установить флажки Allow для атрибутов Read Lockout Time и Write Lockout Time, если необходимо предоставить такие права сотрудникам службы технического сопровождения. Те же шаги следует повторить для каждой организационной единицы OU, а управление ими поручить службе технической поддержки.

Экран 2. Назначение разрешений на принудительную смену пароля.

После внесения этих изменений, при открытии сотрудником службы технического сопровождения учетной записи пользователя в определенном подразделении все атрибуты, за исключением User must change password at next logon, будут затенены, как показано на Экране 3. Если нужно предоставить сотрудникам службы технического сопровождения возможность блокировать учетные записи пользователя и нет необходимости при этом делегировать им все права из набора User Account Control, на той же вкладке следует установить флажок Allow для атрибутов Read account Expires и Write account Expires. Несмотря на то что сотрудники службы технического сопровождения не смогут непосредственно отключать учетные записи пользователя, они достигнут того же результата, установив дату окончания действия учетной записи пользователя уже прошедшим числом.

Экран 3. Свойства учетной записи в OU.

Перемещаем объекты в другие OU

Одно из важных административных прав, подлежащих делегированию, — право перемещать объекты внутрь OU и за их пределы. Однако делегирование этого права без риска для систем безопасности требует творческого подхода. Для того чтобы в AD переместить объект за пределы организационной единицы, необходимо удалить полномочия. Перемещение объекта в организационное подразделение требует создания полномочий. Если администратор не имеет этих двух прав, переместить объект не удастся — попытки щелкнуть на объекте и выбрать Move в оснастке Active Directory Users and Computers ни к чему не приведут. AD устроена так, что администратор имеет возможность перемещать объекты, но может и удалять их, хотя даже с практической точки зрения операции создания и удаления отличаются от операций перемещения. Возможна ситуация, когда администратору удобно предоставить локальным администраторам право на перемещение какого-либо объекта (обратимая операция), но неудобно давать право на удаление объекта (необратимая операция). Очевидно, что это не элементарная задача.

Одним из простых методов делегирования является передача администратору уровня сайта AD права полного контроля в иерархии некоторого подразделения. Например, предположим, что в домене есть два филиала, сети которых образуют разные сайты: Нью-Йорк и Детройт. Администратору по имени Чип предоставлено право полного контроля над филиалом в Нью-Йорке, а Мария получает полный контроль над филиалом в Детройте. Администраторам часто приходится перемещать учетные записи пользователя и время от времени перемещать учетные записи компьютеров и групп в другие подразделения (например, если сотрудники переезжают или меняются их должности и обязанности служащих информационных подразделений). Мария имеет право полного контроля над своим филиалом, поэтому если Джек переезжает в Нью-Йорк, то для Марии не составляет труда переместить его учетную запись за пределы своего филиала в Детройте: как у администратора уровня сайта у нее есть право удалять объекты в своем подразделении. Однако у Марии нет прав на создание объектов в филиале Нью-Йорка, поэтому она не может перемещать объекты внутрь этого филиала. Если предоставить Марии право создавать объекты в Нью-Йоркском филиале (и во всех других подразделениях, куда могут переехать пользователи из Детройта), то все имеющиеся в географически ориентированной модели администрирования преимущества системы безопасности сойдут на нет.

В данном случае можно сформировать специальное организационное подразделение (назовем его «депо»), в рамках которого все администраторы уровня сайта имели бы права на создание и удаление объектов. Когда Джек переезжает в Нью-Йорк, Мария перемещает его учетную запись из своего филиала в депо. Затем она сообщает Чипу, что в его распоряжение переходит пользовательская учетная запись Джека, которая находится в депо и ожидает дальнейшего перемещения. После этого Чип перемещает учетную запись Джека из депо в Нью-Йоркский филиал.

Такое решение исключает незапланированное появление учетных записей. В филиале Чипа не появится ни одной лишней учетной записи до тех пор, пока он их туда не переместит. Администраторы уровня домена могут просматривать депо и проверять, нет ли там «зависших» пользователей. При необходимости можно создать в своей организации несколько различных депо. Администратору все равно придется предоставлять права на создание и удаление объектов в нескольких местах, но не так часто, как это пришлось бы делать, не создавая депо.

Формирование централизованной модели делегирования

Теперь, когда имеется базовая информация и один пример, рассмотрим, как можно задать модель делегирования в целом. То, что важна именно хорошо структурированная модель, обусловлено самим принципом делегирования. Предположим, что члены группы Domain Administrators могут делегировать право контроля над фрагментами каталога другим пользователям, не делая их при этом администраторами всего домена. Кроме того, пусть каждый, кто обладает правом Change permissions по отношению к какому-либо объекту, может передавать права на этот объект или лишать прав любого другого пользователя по своему усмотрению. Продолжим последний пример: вполне могло оказаться, что я доверяю Чипу управление Нью-Йоркским филиалом (т. е. предоставляю право создавать и удалять объекты, следить за членством в группах и т. п.), но не хотел бы, чтобы он расширял круг полномочий этого уровня, предоставляя аналогичные права кому-либо еще. Возможно также, что я лишу его права удалять какие бы то ни было полномочия, назначенные другим пользователям. Однако, обладая правом Change permissions в пределах Нью-Йоркского филиала, он сможет делать и то и другое. Например, предоставить секретарю почтовой службы право удалять учетные записи в филиале и лишить сотрудников центральной службы технической поддержки возможности восстанавливать пароли. Плохо продуманный подход к делегированию полномочий не обеспечит предприятию надежной среды, потому что обеспечение безопасности основано на централизованной и согласованной модели безопасности. Но если централизованная модель делегирования уже создана, еще остается возможность ограничить права администраторов уровня филиала на дальнейшее делегирование ими своих полномочий, чтобы не создавать беспорядка в модели.

Разработка модели делегирования начинается с назначения ролей (например, OU Manager, User Account Manager, Computer Account Manager). Затем каждой роли приписывается определенный набор полномочий, который должен быть предварительно задокументирован; его необходимо пересматривать по мере изменения требований. Эти роли нужно протестировать в лаборатории, затем развернуть на стадии формирования Нью-Йоркского филиала, например. Если роли работают там, то они будут работать везде.

Экран 4. Примерная структура OU со специальными локальными группами сайта.

При создании каждого филиала следует формировать подразделение с названием Admin OU (группа администраторов филиала). В подразделении Admin OU для каждой роли нужно создать в домене локальную группу с префиксом из кода сайта. В приведенном примере в Нью-Йоркском подразделении Admin OU я создал группы NY-OUMgr, NY-UsrMgr и NY-CompMgr. На Экране 4 изображены эти группы и структура моего гипотетического Нью-Йоркского филиала. Подобным группам следует назначить полномочия, заранее определенные для соответствующих ролей. Например, локальная доменная группа NY-OUMgr будет иметь следующие права в рамках всего Нью-Йоркского филиала: Read All Properties («Просматривать все свойства»), Write All Properties («Записывать все свойства»), Create All Child Objects («Создавать дочерние объекты») и Delete All Child Objects («Удалять дочерние объекты»), как показано на Экране 5. Ни одно из этих полномочий не позволяет никому из членов группы менять существующие полномочия. Если я помещу учетную запись Чипа в локальную доменную группу NY-OUMgr, то он получит почти полный контроль над объектами в данном филиале и сможет предоставлять другому пользователю любое из определенных прав, просто добавляя его учетную запись в соответствующую группу. Фактически можно было бы создать локальную доменную группу под названием NY-RoleMgr и предоставить ее членам только полномочия Read Members и Write Members по отношению к групповым объектам в Нью-Йоркской группе Admin OU. В любом случае никто из членов этих групп не сможет менять централизованно установленные полномочия.

Экран 5. Разрешения для роли OU Manager.

Если такой подход для предприятия приемлем, то можно перевести делегирование на еще более высокий уровень автоматизации. Специалисты некоторых предприятий пишут собственные программы, с помощью которых автоматически создаются OU и локальные доменные группы и назначаются полномочия. Программы независимых разработчиков также могут помочь в управлении организационными подразделениями и разрешениями (см. врезку «Инструменты для управления делегированием полномочий в AD»).

Делегирование на уровне сайта

До сих пор обсуждение делегирования полномочий ограничивалось видимой частью «айсберга» AD — контекстом именования домена. Контекст именования домена содержит пользователей, группы, учетные записи компьютеров и организационные подразделения OU. Однако AD имеет еще два не менее важных, но менее очевидных контекста — контекст именования конфигурации и контекст именования схемы. Как следует из названия, контекст именования конфигурации содержит информацию о конфигурации AD (например, информацию о конфигурации сайтов, репликации, маршрутизации). Контекст именования схемы содержит общую информацию об AD и список всех объектов, которые может содержать каталог.

Можно позаботиться о безопасности обоих контекстов, но я остановлюсь только на первом из них. Контекст конфигурации позволяет делегировать несколько функций, которые обычно резервируются за администраторами предприятия. Группа Enterprise Admins — это универсальная группа, которая прописана в корневом домене леса AD. Члены группы Enterprise Admins имеют полный набор прав в отношении леса, включая возможность добавлять и удалять домены и управлять доверительными отношениями. Несмотря на то что многие администраторы стремятся войти в эту мощную группу, правильная политика безопасности должна ограничивать членство в ней небольшим числом сотрудников. Тем не менее можно распространить на более широкий круг администраторов права на выполнение тех задач, которые обычно зарезервированы за группой Enterprise Admins. Среди этих задач — управление доверительными отношениями, создание дочерних доменов, установка дополнительных контроллеров домена (DC), выполнение авторизации сервера DHCP и сервера Microsoft Remote Installation Services (RIS-сервера). Эти полномочия присваиваются через настройку параметров безопасности в различных частях контейнера Configuration. Одной из типичных задач, которую, возможно, будут делегировать члены группы Enterprise Admins другим администраторам, является управление сайтом.

Чтобы делегировать полный набор полномочий на уровне управления сайтом, нужно создать группу под названием Enterprise Site Admins. Затем следует запустить оснастку Active Directory Sites and Services. Щелкнув правой кнопкой мыши на значке Sites на правой панели, нужно перейти на вкладку Security. Далее необходимо щелкнуть Add, выбрать группу Enterprise Site Admins и предоставить ей полный доступ, указывая Allow в ячейке Full Control. Каждый член этой группы будет иметь все права по управлению сайтом.

Переходя на один уровень ниже и настраивая безопасность определенного сайта, можно предоставить разрешения на полный доступ только к одному сайту. Хотя, возможно, понадобится еще назначить разрешения для контейнера Subnets (понятие «сайты» как раз предполагает, что они состоят из нескольких подсетей). Группе, которая будет управлять сайтом, нужно предоставить оба разрешения по отношению к контейнеру Subnets — Read («Читать») и Create All Child Objects («Создавать дочерние объекты»), а затем следует обеспечить встроенной группе CREATOR/OWNER полный доступ ко всем контейнерам Subnets. Теперь все члены группы могут формировать подсети и управлять теми подсетями, которые они создали.

Следует также помнить, что, имея полный доступ к сайтам, администраторы могут создавать объекты связи между сайтами (Inter-Site Transport objects). Такое действие оказывает сильное влияние на сеть. Каждый раз, когда создается новый объект связи, служба проверки целостности Knowledge Consistency Checker пересчитывает топологию репликации всего леса. Межсайтовые объекты связи воздействуют и на производительность глобальных сетей, т. е. снижают ее. Таким образом, подобные объекты должны создаваться только теми, кто хорошо понимает возможные последствия. Для того чтобы не давать членам группы Enterprise Site Admins возможности создавать эти объекты, следует наделить их разрешением Deny по отношению к праву Create Inter-Site Transport Container Objects.

Присущая AD возможность выборочного привязывания полномочий к отдельным типам объектов позволяет широко применять делегирование ограниченных прав. Предположим, что требуется назначить группе пользователей право управлять расписанием репликации во всех сайтах предприятия. Для того чтобы это сделать, можно создать группу под названием Site Replication Schedulers («Планировщики репликации между сайтами»). Для этого нужно щелкнуть правой кнопкой мыши на контейнере Sites в оснастке Active Directory Sites and Services, в контекстном меню выбрать Properties и перейти на вкладку Security. Щелкнув по вкладкам Advanced, Add, следует ввести имя группы — Site Replication Schedulers, и в поле Apply under («Область применения») выбрать Site Settings Objects («Объекты настройки сайта»). Теперь требуется щелкнуть мышью на вкладке Properties и установить флажки Allow для свойств Read schedule («Чтение расписаний») и Write schedule («Запись расписаний»), как показано на Экране 6. Два указанных разрешения дают этой группе возможность управлять расписанием репликации на уровне сайтов на всем предприятии.

Экран 6. Назначение разрешений Read schedule и Write schedule.

Во врезке «Углубленное изучение делегирования полномочий в AD» перечислено несколько источников, в которых более подробно рассматриваются вопросы делегирования полномочий в AD, но тема все равно пока остается малоизученной. Не следует поддаваться обманчивому впечатлению, что вы уже все можете делать сами. Тем, кто не любит ходить проторенными дорожками, рекомендую использовать следующие приемы.

  • Записывайте, записывайте, записывайте. AD - такая сложная и обширная вещь, что в процессе создания модели делегирования легко потерять нить. Кроме того, если вы найдете абсолютно правильную комбинацию полномочий для одной команды, то наверняка вам сразу захочется воспроизвести это решение в других филиалах. Существует много инструментов Microsoft и прочих компаний, позволяющих не только администрировать, но и документировать модель делегирования (см. врезку "Инструменты для управления делегированием полномочий в AD"), но проще использовать карандаш и бумагу или заполнять компьютерную форму.
  • Не стоит использовать для тестирования рабочие компьютеры. Проверка той комбинации полномочий, которая необходима для выполнения данной задачи, может плохо повлиять на производительность сети, особенно если это полномочия в контексте именования схемы или конфигурации. Для тестирования сценариев следует установить несколько машин в отдельном лесу.
  • Для назначения полномочий следует использовать локальные доменные группы. Может показаться, что проще назначать полномочия отдельным пользователям, но тогда, возможно, придется выполнять репликацию целого ряда полномочий, а сделать это согласованно и аккуратно нелегко. Если же назначить полномочия определенной группе и потребуется кому-либо еще предоставить точно такие же права, надо просто добавить этого человека в данную группу.
  • Для проверки используйте команду Runas. Не всегда легко сразу найти именно тот набор полномочий, который необходим для выполнения данной задачи, поэтому придется поэкспериментировать, прежде чем развертывать сценарии делегирования, отличные от описанных в этой статье. Команда Runas позволяет запускать программы в контексте другого пользователя. Обычно я открываю одну консоль MMC в контексте группы Enterprise Admins, в рамках которой могу менять полномочия, и запускаю еще одну консоль MMC в контексте тестовой учетной записи, к которой предоставляю доступ. Такой способ значительно быстрее, чем авторизованный вход и выход в качестве другого пользователя. Чтобы увидеть, какой эффект произвели сделанные изменения на административные возможности тестовой учетной записи, я использую переключатель Alt+Tab.

ДЖЕФ БЕНЬОН — старший системный инженер в компании BindView, специализируется на проектировании и консультациях по вопросам миграции на Active Directory. С ним можно связаться по адресу jeff.bennion@bindview.com

Углубленное изучение делегирования полномочий в AD

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

  • Экзамен Microsoft MCSE #70-219, разработка инфраструктуры Microsoft Windows 2000 Directory Services, включает тему делегирования. Любое руководство по подготовке к этому экзамену предоставит основную информацию о делегировании полномочий в AD.
  • Статья в книге Элистер Дж. Лоу-Норис "Windows 2000 Active Directory" (из-во O'Reilly & Associates, 2000), посвященная делегированию полномочий.
  • В книге консалтинговой службы "Microsoft Building Enterprise Active Directory Services: Notes from the Field" (изд-во Microsoft Press, 2000) описаны типичные задачи делегирования в контексте именования конфигурации.
Статьи Microsoft по вопросам делегирования полномочий в AD

Инструменты для управления делегированием полномочий в AD

  • Оснастка Active Directory Users and Computers консоли Microsoft Management Console (MMC). Помимо использования в процессе администрирования стандартных учетных записей пользователей, групп и компьютеров при помощи этой оснастки можно обеспечивать безопасность AD. По умолчанию панель безопасности AD скрыта, но ее можно включить, щелкнув View, Advanced feature. После включения углубленных функций у каждого объекта появится вкладка Security, в которой устанавливаются полномочия. В этой оснастке также есть доступ к мастеру Delegation of Control Wizard, с помощью которого можно выполнить первоначальную настройку делегирования. Необходимо щелкнуть правой кнопкой мыши по OU, выбрать Delegate control, после чего мастер выполнит пошаговое назначение разрешений для данной OU. С помощью этого инструмента нельзя увидеть текущие разрешения или отменить ранее назначенные, поэтому вкладка Security, возможно, покажется более подходящей для повседневного администрирования полномочий.
  • Оснастка ADSI Edit консоли MMC. Этот инструмент из комплекта Windows 2000 Support Tools с установочного компакт-диска Windows 2000 открывает доступ ко всем свойствам всех объектов, а также позволяет подключаться ко всем контекстам именования и обеспечивать их безопасность. Кроме того, оснастка ADSI Edit делает доступной для всех объектов вкладку Security. В отличие от оснастки Active Directory Users and Computers, где некоторые атрибуты безопасности скрыты по умолчанию, оснастка ADSI Edit отображает все атрибуты безопасности.
  • Dsacls. Этот инструмент командной строки тоже устанавливается в составе Windows 2000 Support Tools. Dsacls помогает назначать разрешения на использование каталогов точно так же, как Cacls позволяет устанавливать разрешения из командной строки через файловую систему. Кроме того, Dsacls отображает все уже назначенные разрешения. Dsacls - гораздо более эффективное средство для составления полной картины о разрешениях для данной OU, чем вкладка Security оснастки Active Directory Users and Computers.
  • Acldiag. Подобно Dsacls (и будучи одним из элементов Windows 2000 Support Tools), этот инструмент командной строки позволяет просматривать и назначать разрешения в AD. Инструмент выполняет одну дополнительную функцию, с помощью которой можно узнать, какие задачи делегирования были назначены с помощью мастера Delegation of Control Wizard. Это полезная возможность, поскольку мастер Delegation of Control Wizard не предоставляет никакой информации о ранее назначенных задачах. При некоторых условиях Acldiag даже может исправлять те записи контроля доступа (ACE), которые отличаются от спецификаций в шаблонах задач.
  • Инструменты независимых разработчиков: Enterprise Directory Manager от компании Aelita, bv-Admin for Windows 2000 от BindView, FastLane ActiveRoles от Quest Software и Directory Security Administrator компании NetIQ.

назад