Делегируем права на перемещение учетных записей пользователей в Active Directory. Часть 1. Постановка задачи

 Вадим Андросов

Делегируем права на перемещение учетных записей пользователей в Active Directory
Часть 1. Постановка задачи

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

В этом цикле статей будет рассмотрено расширение стандартного механизма делегирования полномочий управления учетными записями пользователей на примере операционной системы Windows Server 2003. Данная надстройка будет удобна прежде всего для крупных организаций со сложной структурой и частыми миграциями персонала в пределах компании. Реализованный в операционной системе механизм делегирования полномочий неудобен в случаях, когда требуется перенести объект пользователя из одной организационной единицы в другую. Эта операция отражает перевод сотрудника в другой отдел. Для ее успешного осуществления требуется иметь право управления объектами типа «Пользователь» как в организационной единице-источнике, так и получателе.

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

Для начала определим базовый механизм реализации надстройки. К каждой организационной единице будет прикреплен специальный объект типа «Комната ожидания». Active Directory не содержит такого класса, поэтому его нужно будет предварительно создать. При переносе объекта пользователя он будет попадать не в целевую организационную единицу, а в эту «комнату».

Главная функция надстройки – управление переходами пользователей между отделами организации. Эта операция должна выполняться сотрудниками, занимающими определенную должность. Назовем ее «Менеджер по персоналу». Под словом менеджер в дальнейшем в статье будет подразумеваться именно это понятие, если явно не указано другое. Вполне возможна ситуация, когда на предприятии за миграцией персонала между подразделениями отвечает по нескольку человек в одном подразделении. Однако было принято решение несколько упростить задачу, чтобы не перегружать статью незначительными, но объемными тонкостями реализации.

Итак, если менеджер обладает достаточными правами как в исходной, так и целевой организационных единицах, он может просто перенести пользователя, не используя расширенный механизм надстройки. В противном случае он может только «вывести» пользователя из своего подразделения и поставить в комнату ожидания целевого.

Важно не превратить разрабатываемый механизм в дыру в системе безопасности. Перенос пользователя из одной организационной единицы в другую может выводить его из области действия одних глобальных политик безопасности и вводить в область других. Возможны еще более серьезные последствия, если используется надстройка, подобная описываемой в [1]. В этом случае смена подразделения может привести к переходу из одной группы безопасности в другую. Поэтому необходимо ввести следующее правило: в комнате ожидания не может находиться активных пользователей. Другими словами, объект частично перенесенного пользователя должен быть отключен (disabled). Это наиболее логичное решение: пока человек не прошел все формальности по переводу, он не может попадать под действие политик безопасности целевого отдела и пользоваться его информационными ресурсами. В то же время и из отдела источника он уже ушел, поэтому и доступа к нему иметь не должен.

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

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

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

Итак, для пользователей, находящихся в комнате ожидания, требуется ряд дополнительных атрибутов. Однако их добавление непосредственно в системный класс мне кажется нецелесообразным. Дело в том, что ожидание завершения операции переноса скорее исключительная, чем повседневная операция. Абсолютное большинство пользователей основную часть времени находятся в активном состоянии в конкретных отделах. Так что добавлять ряд атрибутов, потребность в которых возникает очень редко, во все объекты типа «Пользователь» нецелесообразно. Я решил использовать для этой цели специально созданный класс, объект которого будет содержать в себе переносимого пользователя и необходимые свойства. Время жизни этих объектов будет совпадать со временем пребывания пользователей в комнатах ожидания. Развивая аналогию с комнатой ожидания, назовем объекты с дополнительной информацией стульями (UserMoveChair). То есть объекты стулья – это контейнеры, содержащие объекты пользователей в период их переноса из одного подразделения в другое.

При функционировании надстройки потребуется косвенное управление большим количеством вспомогательных объектов (объекты типов «Комната ожидания» (UserMove WaitingRoom), «Стул ожидания» (User MoveChair), «Ссылка на стул ожидания» (UserMoveChairLink). Все эти объекты являются исключительно вспомогательными, и менеджеру по персоналу ничего не нужно знать о них, чтобы пользоваться надстройкой. Вся низкоуровневая работа ложится на сценарии. Однако эти сценарии будут выполняться от имени пользователей (руководителей отделов). Для эффективной работы менеджерам необходимо предоставить полный доступ ко всем вспомогательным объектам.

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

Я решил остановиться на более простом и эффективном решении. Вся работа со вспомогательными классами концентрируется на сервере. Рассмотрим основные преимущества подхода.

• Сценарии на стороне клиента выполняют только минимальный объем операций, сводящихся к подготовке и отправке команды серверу. Для выполнения всех действий необходимы только права управления объектами в одной организационной единице.
• Все операции по реальному перемещению пользователей выполняются на сервере с правами администратора, что позволяет избежать необходимости разработки сложной (а значит, более подверженной ошибкам) системы распределения прав к вспомогательным объектам.

На стороне клиента формируется команда (начать, подтвердить или отменить перемещение), которая сохраняется в виде объекта в организационной единице менеджера по персоналу. Серверная часть надстройки ожидает событий появления таких команд. Когда это происходит, команда выполняется, если прошла проверку на допустимость.

Для реализации этого механизма потребуется создать дополнительный класс команды. Пусть он называется UserMoveCommand. Установим необходимые атрибуты. Во-первых, понадобится собственно идентификатор команды. Вот список команд, необходимых для управления надстройкой (идентификатор будет принимать одно из этих значений).

• StartMove – начать перемещение пользователя.
• Accept – подтвердить перемещение пользователя. Завершает перевод сотрудника в целевой отдел.
• Deny – отказать пользователю в перемещении. Отказ в приеме сотрудника.
• RollBack – отмена операции перемещения. Сотрудник возвращается в исходный отдел.

Также потребуется атрибут для хранения идентификатора пользователя – объекта команды и того, кто команду создал (executor).

Рассмотренных атрибутов достаточно для команд подтверждения перевода пользователя (accept) и отмены операции (rollback), так как они завершают процесс перемещения. Команда отказа приема пользователя (deny) ставит перемещаемый объект в комнату ожидания исходного подразделения. Для нее потребуется дополнительное поле с комментарием, содержащим причину отказа.

Самой сложной является команда начала перемещения (StartMove). Во-первых, она должна содержать всю необходимую информацию для постановки объекта пользователя в очередь перемещения (комментарий, время, инициатор операции, пункт назначения, включена или отключена перемещаемая учетная запись). Во-вторых, команда начала перемещения должна быть контейнером, содержащим пользователя. То есть выносимый сотрудник будет отключаться и помещаться «внутрь» объекта команды, как бы исчезая из стандартных оснасток.

Рассмотрим результирующую схему классов, необходимую для реализации надстройки (см. рис. 1). Отметим, что к названиям всех реальных классов и их атрибутов будет добавлен префикс UserMove, чтобы избежать случайных совпадений имен с системными объектами.

Рисунок 1. Диаграмма классов

Итак, организационная единица (organizationalUnit) может содержать объекты классов комнаты ожидания (WaitingRoom) и команды (Command). Также, естественно, она может содержать и объекты пользователей, но на схеме этого не отражено, поскольку не относится к функциональности, добавляемой надстройкой. В комнате ожидания могут содержаться объекты классов стул (Chair) и ссылки на стулья ожидания исходящих пользователей (ChairLink).

В отдельный класс (Data) я решил сгруппировать атрибуты перемещаемых объектов: источник переноса (from), инициатора (who), времени начала движения (when) и комментарий (comment). Это исключительно вспомогательный класс, и создание его экземпляров не подразумевается. Введен он был для удобного манипулирования группой атрибутов. От него унаследован другой вспомогательный класс контейнера (Container), который также может содержать в себе объекты пользователей и имеет дополнительное свойство «отключен» (disabled). Это вызвано тем, что при помещении в контейнер учетная запись пользователя отключается и ее нужно вернуть в исходное состояние при извлечении.

Класс контейнера является родительским для двух «реальных» классов, объекты которых и используются надстройкой. Это классы команды начала перемещения (StartMoveCommand), который унаследован еще от класса команды, и стула ожидания. Также в отдельный класс выделена команда отказа приема пользователя в свое подразделение (DenyCommand), так как для его объектов требуется дополнительный атрибут комментария (comment), который содержит причину отказа.

Перейдем к непосредственной реализации необходимых классов.

Модификация схемы Active Directory

Для того чтобы начать изменять схему Active Directory, необходимо разблокировать эту возможность и установить необходимую оснастку Active Directory Schema. Этот процесс достаточно подробно описан в [2, 3], поэтому останавливаться на нем не буду.

Теперь будут рассмотрены необходимые изменения и дополнения в схеме Active Directory. Но перед тем, как перейти к процессу модификации схемы, хотелось бы остановиться на некоторых подробностях корректного выполнения этого процесса. Дело в том, что в процессе изменения схемы будут создаваться новые системные атрибуты и даже классы. Для всех этих объектов должен быть определен уникальный идентификатор X.500 OID (Object IDentifier или идентификатор объекта). Фактически это текстовая строка, состоящая из групп цифр, разделенных точками. Можно придумать что-то самостоятельно, но делать этого настоятельно не рекомендуется. Совпадение нового идентификатора с существующим в системе может привести ко всяческим сбоям. Microsoft рекомендует получать код с помощью специального сценария [4].

В результате его применения будет получена префиксная часть всех идентификаторов для пользовательских объектов и классов. Поступать рекомендуют следующим образом.

• Сгенерировать идентификатор с помощью сценария. Допустим, было получено значение 1.222.33 (на самом деле оно значительно длиннее).
• Дописать в конец точку и единицу или двойку для префиксов классов и атрибутов соответственно. То есть 1.222.33.1 для классов и 1.222.33.2 для атрибутов.
• Идентификаторы конкретных объектов получать путем добавления к имеющемуся префиксу еще одной группы с порядковым номером объекта. Например, если требуется создать два пользовательских класса, их идентификаторы могут быть 1.222.33.1.1 и 1.222.33.1.2.

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

Все классы Active Directory прямо или косвенно унаследованы от общего суперкласса Top. Он содержит ряд служебных настроек и атрибутов, поэтому классы надстройки будут также унаследованы от него.

Сначала необходимо создать все необходимые атрибуты (см. рис. 2), приведенные на диаграмме на рис. 1.

Рисунок 2. Атрибуты классов надстройки

Их назначение уже было рассмотрено выше. Практически все атрибуты, представляющие собой ссылки на объекты Active Directory, имеют строковый тип. За исключением признака отключения учетной записи пользователя (userMoveDisabled), который имеет логический тип, и времени начала операции переноса (userMoveWhen), тип – UTC Coded Time (Universal Time Coordinated, или универсальное скоординированное время, – можно считать временем по Гринвичу, за исключением того, что летом и зимой часы здесь не переводятся).

Далее с помощью той же оснастки создадим необходимые классы. Обратите внимание, что на диаграмме классов (рис. 1) есть случай множественного наследования. Класс StartMoveCommand является потомком как команды (UserMoveCommand), так и контейнера (UserMoveContainer). Однако множественное наследование в Active Directory не поддерживается. Вместо этого можно воспользоваться так называемыми вспомогательными (auxiliary) классами. Такие классы используются, когда требуется создать группу параметров, пригодную для повторного использования. То есть новый класс наследует все атрибуты дополнительного, но не его тип. В нашем случае на роль дополнительных классов подходят UserMoveData и UserMoveContainer. Таким образом, класс UserMOveStartMoveCommand наследует только класс Command, так как в дальнейшем все команды будут обрабатываться единообразно.

Рассмотрим несколько примеров создания классов. Сначала создадим вспомогательный класс UserMoveData. На первом этапе нужно ввести название класса и его уникальный идентификатор (см. рис. 3).

Рисунок 3. Создание нового класса. Шаг 1

Также указывается тип класса – «дополнительный». То есть уже на этапе создания мы указываем, что этот класс является только средством группировки атрибутов и не несет информации о типе. Далее нужно задать предварительно созданные атрибуты (см. рис. 4)

Рисунок 4. Создание нового класса. Шаг 2

Обратите внимание, что все атрибуты сделаны необязательными (optional). Это не вполне отвечает логике работы надстройки, однако использовать дополнительный класс с обязательными (mandatory) атрибутами у меня не получилось. В документации я объяснения так и не нашел. При попытке добавления класса с обязательными атрибутами в существующий возникает ошибка (см. рис. 5).

Рисунок 5. Ошибка при использовании дополнительного класса с обязательными атрибутами

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

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

Рисунок 6. Настройка связей класса

Итак, родительский класс был задан при создании. UserMoveContainer указан как дополнительный. В качестве допустимого контейнера (Possible superior) указаны организационные единицы (organizationalUnit). Это необходимо сделать, чтобы обеспечить возможность создания объектов-команд в организационных единицах. Кроме собственных классов, потребуются изменения для стандартного класса пользователя (user). Для него нужно добавить в качестве допустимого контейнера стул ожидания (UserMoveChair).

Теперь можно уточнить логику работы надстройки с учетом особенностей реализации схемы. Для начала будут рассмотрены этапы сценария переноса пользователя из отдела А в отдел Б.

• Начало операции. Начинает операцию менеджер по персоналу отдела А. Создается объект команды начала перемещения (UserMoveStartMoveCommand). Учетная запись отключается (состояние disabled), так как теперь он не является членом ни одного отдела и помещается внутрь команды. Поскольку команды не отображаются в стандартных оснастках (чтобы отображались, нужно установить флажок «Show objects of this class while browsing» в свойствах класса), объект пользователя как бы исчезает. Далее устанавливаются атрибуты объекта класса команды: целевая организационная единица (отдел Б), инициатор операции (менеджер по персоналу А), источник (отдел А), время начала операции и комментарий для менеджера по персоналу отдела Б (например, «Убедиться, что приказ о переводе уже подписан»). На этом клиентская часть инициации перемещения завершается. Сервер следит за появлением объектов команд в организационных единицах. При обнаружении команды начала перемещения создается объект класса MoveUserChair, куда и помещается пользователь. В конце объект пользователя, упакованный в MoveUserChair, помещается в комнату ожидания целевой организационной единицы Б.
• Ожидание. Далее для краткости я буду описывать работу надстройки в целом, не разделяя ее на клиентскую и серверную части. Помните лишь, что менеджер только создает объект команды, всю реальную работу по перемещению пользователя выполняет сервер. Пользователь находится в комнате ожидания. Менеджер по персоналу отдела А может отменить операцию, просматривая список инициированных им ожиданий. В этом случае объект пользователя разблокируется, удаляется из комнаты ожидания и возвращается в старый отдел. Также правом отмены операции обладает менеджер по персоналу отдела Б. Однако здесь поведение надстройки должно быть несколько иным. Пользователь должен в заблокированном виде попасть в комнату ожидания своего отдела А, так как окончательное решение теперь уже за менеджером по персоналу организационной единицы А. Ситуация, когда пользователь «зависает» между двумя отделами, вследствие того, что менеджеры по персоналу двух отделов отменяют переводы друг друга, является нештатной и может быть разрешена администраторами более высокого уровня.
• Завершение операции. Менеджер по персоналу отдела назначения Б подтверждает операцию перевода. Учетная запись пользователя разблокируется, удаляется из комнаты ожидания и попадает в отдел Б.

При описании сценария работы был обнаружен неудобный момент. Как менеджер по персоналу сможет получить сведения обо всех переводимых из его отдела пользователях. Дело в том, что они находятся в комнатах ожидания целевых подразделений. Информация об источнике операции имеется, но для построения списка «отправленных» пользователей потребуется обход всей иерархии подразделений, которая может быть достаточно большой. Поэтому для удобства реализации было решено добавить еще один дополнительный вспомогательный контейнер, прикрепленный к организационным единицам: «Исходящие пользователи». Новый класс контейнера создавать не потребуется – вполне подойдет и имеющийся MoveUserWaitingRoom. Только содержать он должен ссылки на пользователей, ожидающих перевода из этого отдела. Для этой цели лучше создать отдельный простой класс, содержащий единственный атрибут – путь к объекту ожидающего пользователя. Пусть он называется MoveUserChairLink, атрибут – MoveUserLink строкового типа.

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

Отдельные «комнаты» для входящих и исходящих пользователей я решил не создавать. Путаница не возникнет, так как разные операции представлены объектами разных типов.

Требования к пользовательскому интерфейсу

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

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

Рисунок 7. Назначение менеджера подразделения

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

Поскольку речь идет о делегировании некоторых административных полномочий, основным инструментом работы менеджеров по персоналу должна быть оснастка Active Directory Users and Computers. Требуется только добавить дополнительную функциональность для реализации основных функций надстройки.

Во-первых, необходима функция «Перевести в…». Активировать ее будет удобно из контекстного меню пользователя. Затем менеджер должен указать целевой отдел перевода и «отправить» туда пользователя. По замыслу операция является практически аналогичной стандартной «Move…», за исключением того, что не требует наличия у отправителя прав на запись в целевую организационную единицу.

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

Администраторы домена также должны иметь возможность пользоваться этими функциями, несмотря на то что они имеют возможность манипулирования объектами пользователей без очередей. Таким образом, они получают возможность просматривать имеющиеся очереди пользователей.

Возможна ситуация, когда пользователь не принимается ни одной стороной перевода. То есть менеджеры по персоналу пересылают его друг другу. В этом случае администратор должен иметь возможность извлечь объект пользователя из контейнеров ожидания (MoveUserChair и MoveUserWaitingRoom) и поместить в произвольный отдел.

Заключение

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

1. Андросов В. Синхронизация ACL и архитектуры структуры организации. Часть 1. // Системный администратор, №12, декабрь 2007 г. – С. 36-41.
2. Андросов В. Реализуем нестандартные правила управления доступом на основе архитектуры организации в Windows Server 2003. //Системный администратор», №10, октябрь 2007 г. – С. 48-58.
3. Чарли Рассел, Шарон Кроуфорд, Джейсон Джеренд. «Windows server 2003 + SP1 и R2. Справочник администратора». – М.: Издательство «ЭКОМ», 2006 г. – 1424 с.
4. http://go.microsoft.com/fwlink/?LinkId=100725.

Комментарии могут оставлять только зарегистрированные пользователи