Делегирование доступа в AD

Наложение административных разрешений на объекты AD упрощает управление крупными инфраструктурами AD

Делегирование административных полномочий Active Directory (AD) позволяет передать обязанности по управлению инфраструктурой Windows AD какой-либо административной учетной записи или группе. Без делегирования прав AD невозможно распределить полномочия по управлению большим числом объектов AD (пользователей, компьютеров, принтеров, сайтов, доменов и т.д.) среди нескольких администраторов. Хороший пример успешного делегирования полномочий AD — предоставление специалистам службы технической поддержки прав, достаточных для изменения паролей пользовательских учетных записей AD, но не более того. Делегирование полномочий AD позволяет децентрализовать административные задачи и, как следствие, повысить эффективность управления, сократить затраты и улучшить общую управляемость крупных ИТ-инфраструктур.

Значение OU

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

OU представляет собой контейнер объектов AD, используемый в первую очередь для иерархической организации объектов AD и делегирования полномочий управления этими объектами различным администраторам.
OU не являются субъектами безопасности. У них нет SID, поэтому их нельзя использовать в списках управления доступом (ACL). Кроме того, OU отличается от группы тем, что OU нельзя делегировать административные задачи. Параметры авторизации для объектов OU можно назначать через списки ACL.
Объект может находиться только в одной OU, хотя иерархически он может иметь несколько родительских OU.
OU привязана к единственному домену. Она не может распространяться на несколько доменов.

Экран 1. Иерархия OU.

На экране 1 показана структура OU, охватывающая несколько географических районов. Организационные единицы верхнего уровня отражают континенты и города инфраструктуры: Европа — OU верхнего уровня, под ней находятся организационные единицы для Брюсселя (BRO), Дублина (DBO), Амстердама (AMS) и Лондона (LON). OU каждого города разделена на дочерние по типам администрируемых объектов: администраторам, пользователям, машинам и принтерам. Отличительное имя (distinguished name — DN) отражает уровень вложения OU. Например, объект fileserver в структуре OU (экран 1) может иметь следующее DN: CN=FileServer1, OU=Member Servers, OU=Machines, OU=BRO, OU=EU, DC=hp, DC=com.

Организация административного делегирования

Делегировать административные полномочия удобно с помощью мастера Delegation of Control компании Microsoft. На экране 2 показан заключительный экран мастера, на котором приведена сводка переданных полномочий. Мастер доступен на уровнях сайта, домена и OU из оснасток Active Directory Users and Computers и Active Directory Sites and Services консоли Microsoft Management Console (MMC). С помощью мастера Delegation of Control администратор может выбрать заранее определенный набор задач делегирования, перечисленных в таблице 1. Можно создать специализированные задачи, которые более точно отражают потребности конкретной организации, если сформулировать задачу в мастере Delegation of Control, или описать ее заранее, а затем передать мастеру.

Экран 2. Мастер Delegation of Control

Чтобы передать заранее сформулированную задачу мастеру Delegation of Control, необходимо изменить файл настройки delegwiz.inf. На экране 3 показан фрагмент этого файла, находящегося в каталоге %windir%/inf. Синтаксис, который необходимо использовать при настройке списка задачи, разъясняется в статье Microsoft «How to customize the task list in the Delegation Wizard,» http://support.microsoft.com/?kbid=308404.

Экран 3. Файл настройки Delegwiz.inf.

Администраторы, хорошо владеющие ACL-редактором объектов AD и моделью авторизации AD, могут обойтись без мастера Delegation of Control и назначать делегирование напрямую через ACL-редактор сайта, OU или любого другого объекта. Всем остальным настоятельно рекомендуется пользоваться мастером Delegation of Control.

Консоль Group Policy Management Console (GPMC) — инструмент управления AD из Windows Server 2003 — удобна для делегирования административных полномочий над объектами Group Policy Objects (GPO). В интерфейсе GPMC предусмотрена специальная вкладка Delegation (экран 4) для каждого GPO. GPMC можно загрузить бесплатно с Web-узла Microsoft.

Экран 4. Вкладка делегирования в GPMC.

С помощью мастера Delegation of Control можно добавлять разрешения, но не отменять их. Отдельные административные разрешения AD можно без труда удалить из редактора ACL или с использованием инструмента командной строки dsacls.exe. Если нужно отменить делегирование административных разрешений AD, назначенных учетной записи на дочерние объекты при делегировании на уровне родительского OU, то можно воспользоваться инструментом командной строки dsrevoke.exe, который облегчает и автоматизирует удаление разрешений в иерархических структурах объектов. Инструмент можно загрузить с сайта Microsoft.

Для более полного отображения административного делегирования в AD можно построить специальный административный интерфейс, именуемый консолью задачи, taskpad, на уровне интерфейса администратора, которому были делегированы разрешения. Чтобы создать консоль задачи, следует открыть новую консоль MMC и добавить оснастку, затем щелкнуть правой кнопкой мыши в контейнере оснасток и выбрать пункт New Taskpad View. Мастер Taskpad View Wizard помогает пользователю создать консоль задачи. Специализированные консоли MMC и taskpad можно сохранять как обычные файлы и рассылать администраторам по электронной почте.

Примеры делегирования административных разрешений

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

Пример службы поддержки. Как отмечалось выше, административное делегирование AD полезно для службы технической поддержки. Как правило, организации делегируют ее сотрудникам следующие полномочия: возможность изменять пароли пользователей, устанавливать свойство учетной записи User must change password at next logon и разблокировать учетные записи, сбрасывая свойство Account is locked out.

Для делегирования перечисленных выше административных задач сотрудникам службы поддержки необходимо предоставить им следующие разрешения в OU, содержащем учетные записи пользователей.

Присвоить разрешению Reset Password for user objects значение Allow to grant permission to reset account passwords.
Присвоить разрешению Set the Write lockoutTime for user objects значение Allow to grant permission to unlock accounts.
Присвоить разрешению Write pwdLastSet for user objects значение Allow to grant permission to set the User must change password at next logon account property.
Присвоить разрешению Read AccountRestrictions for user objects значение Allow to grant permission to read all account options. Это позволяет сотрудникам службы технической поддержки определить активную учетную запись.

Чтобы отобразить атрибуты pwdLastSet и lockoutTime учетной записи user в расширенном виде редактора ACL на системах Windows 2000, требуется отредактировать файл конфигурации dssec.dat. Атрибутам lockoutTime и pwdLastSet необходимо присвоить значение 0 (по умолчанию выбирается значение 7). На экране 5 показано, как после установки pwdLastSet в значение 0 в файле dssec.dat разрешения Read pwdLastSet и Write pwdLastSet становятся видимыми в редакторе ACL.

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

Чтобы разрешить самостоятельное управление учетной записью, компания Microsoft ввела специальный субъект безопасности с именем Self. По умолчанию различные разрешения приписываются субъекту безопасности Self, и каждый пользователь получает возможность редактировать атрибуты своей учетной записи в AD. Чтобы изменить самоуправляемый атрибут, необходимо изменить стандартный дескриптор безопасности (т.е. выбираемые по умолчанию параметры авторизации) для класса объекта User в AD.

Экран 5. Атрибут pwdLastSet учетной записи пользователя

Назначить стандартный дескриптор безопасности классу объекта AD можно из диалогового окна свойств данного класса. Сделать это проще всего с помощью оснастки Active Directory Schema консоли MMC. Прежде чем запустить оснастку, необходимо зарегистрировать библиотеку schmmgmt.dll. Для этого требуется ввести следующую команду:

Regsvr32 schmmgmt.dll

Затем нужно открыть оснастку Active Directory Schema, отыскать объект User в контейнере Classes и открыть диалоговое окно Properties этого класса. Стандартный дескриптор безопасности можно изменить на вкладке Default Security (экран 6). В Windows 2000 эта вкладка называется просто Security, хотя такое название недостаточно точно отражает ее назначение.

Экран 6. Изменение стандартного дескриптора безопасности AD

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

Экран 7. Стандартные разрешения субъекта безопасности Self

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

Инструменты делегирования AD от независимых поставщиков

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

Административное делегирование в AD — мощный механизм, с помощью которого можно делегировать повседневные задачи управления AD. Для корректного и максимально эффективного делегирования необходимо доскональное знание модели авторизации AD. Но даже опытным администраторам не рекомендуется напрямую изменять разрешения объектов AD. Делать это лучше с помощью мастера AD Delegation of Control или инструмента делегирования от независимой компании.

Член Security Office компании HP. Специализируется на управлении идентификационными параметрами и безопасности в продуктах Microsoft. Автор книги Windows Server 2003 Security Infrastructures (издательство Digital Press). jan.declercq@hp.com