Еще два интерфейса Active Directory Scripting Interfaces, которые необходимо знать специалистам по AD.

В первой части статьи я рассказал о том, что при создании сценария для Active Directory (AD) для выполнения 80% задач из более 50 программных интерфейсов Active Directory Scripting Interfaces (ADSI) необходимо использовать только 3. В частности, рассматривался один из трех основных интерфейсов IADsOpenDSObject. Напомню, что интерфейс IADsOpenDSObject содержит метод OpenDSObject, который применяется для аутентификации при соединении с AD. В первой части также была описана терминология AD, ADSI и составных имен (DN). Во второй части я расскажу о двух оставшихся интерфейсах — IADs и IADsContainer.

Ключи к сценарию

Прежде чем подробно рассматривать интерфейсы IADs и IADsContainer, надо сказать несколько слов о той роли, которую они играют. Даже простые задачи при написании сценариев ADSI невозможно решить без использования хотя бы одного из этих интерфейсов. Свойства и методы, которые обеспечивают IADs и IADsContainer, используются для создания, удаления и изменения почти каждого объекта AD. Поэтому тем, кто хочет заниматься написанием ADSI-сценариев, рекомендую запомнить эти два интерфейса. Они включают только полдюжины свойств интерфейсов и с десяток методов, поэтому задача не так сложна, как может показаться на первый взгляд.

Интерфейс IADs

Интерфейс IADs реализуется всеми объектами AD одинаково. Он содержит шесть свойств и семь методов. Шесть свойств IADs, которые перечислены в Таблице 1, дают нам важную информацию об объекте.

Рассмотрим несколько сценариев, в которых будут использоваться свойства IADs. Допустим, требуется использовать ADSI-поставщика OLEDB/ADO и запрос к AD, а затем модифицировать объекты, возвращенные в результатах запроса. Однако записи набора, который возвращает ADSI-поставщик OLEDB/ADO, являются записями только для чтения, поэтому необходимо осуществлять привязку к каждому объекту из результатов запроса, чтобы иметь возможность модифицировать данный объект. Чтобы это сделать, необходимо иметь действительный ADsPath для выполнения операции связывания. Так как каждый объект предоставляет свой ADsPath через интерфейс IADs, можно идентифицировать ADsPath как одно из значений, возвращаемых в результатах запроса. Такой метод рекомендуется применять всякий раз при запросе AD.

Можно использовать свойство Class для определения схемы класса объекта (например, компьютер, организационная единица (OU), группа, пользователь), которая применяется для операций фильтрации. Допустим, при обработке списка вложенных групп можно использовать свойство Class внутри цикла, чтобы отследить момент, когда вместо группы появляется пользователь, и соответственно отреагировать.

Глобальный уникальный идентификатор (GUID) — это единственное свойство объекта, которое никогда не изменяется. Свойство GUID используется для привязки к объекту способом, который не зависит от его перемещения и переименования. Свойство Name — это относительное составное имя (RDN); оно представляет собой первичное имя объекта и уникально идентифицирует объект в текущем контейнере. Можно использовать свойства Parent вместе со свойствами ADsPath и Schema, работая с двоичным информационным деревом Directory Information Tree (DIT).

Листинг 1. Свойства схемы через IADs.

Свойство Schema нужно применять для создания ссылки на схему класса объекта для определения обязательных и дополнительных свойств этого объекта, как показано в Листинге 1. После связывания с целевым объектом я вывожу значения шести свойств IADs (см. Листинг 1, метка A). Меткой B в Листинге 1 я пометил путь, с помощью которого свойство Schema объекта обеспечивает связывание с классом схемы объекта. В ответ я получил ссылку на описание пользовательского класса схемы, базирующегося на типе объекта, который отражен в первой строке Листинга 1. Получив ссылку, я отразил содержимое атрибутов must-Contain и mayContain пользовательского класса. На Экране 1 показана часть результатов исполнения Листинга 1.

Экран 1. Частичный вывод на консоль из Листинга 1.

Семь методов IADs, показанных в Таблице 2, обеспечивают механизмы, которые используются для добавления, изменения и удаления данных объекта. Хотя методы IADs просты в применении, некоторые сценарии бывают весьма коварны. Но прежде, чем я расскажу о них, необходимо понять, что такое кэш свойств ADSI.

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

Кэш свойств является адресным пространством объекта, которое ADSI выделяет в тот момент, когда происходит связывание с объектом. Однако сначала кэш пуст. Методы IADs используются для инициализации и взаимодействия со значениями в локальном кэше свойств и нижележащей базой каталога, как показано на Рисунке 1.

Из семи методов IADs только GetInfo, GetInfoEx и SetInfo непосредственно взаимодействуют с базовым каталогом. Get, GetEx, Put и PutEx взаимодействуют только со значениями в кэше свойств, с одним исключением, о котором чуть позже. Процесс, используемый в работе с данными объекта и кэшем свойств, зависит от конкретной задачи. Например, при создании объекта и инициализации его свойств необходимо использовать следующие методы и функции.

  1. Функцию GetObject VBScript — для связывания с целевым контейнером, который будет содержать новый объект (сетевой трафик).
  2. Метод Create IADsContainer — для создания нового объекта в локальном кэше свойств (нет сетевого трафика).
  3. Метод Put или PutEx IADs или оба вместе - для установки новых обязательных и дополнительных свойств объекта в локальном кэше свойств (нет сетевого трафика).
  4. Метод IADs SetInfo - для фиксации (записи) нового объекта или соответствующих свойств в кэше свойств в базе службы каталога (сетевой трафик).

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

  1. Использовать функцию GetObject VBScript для связывания с целевым объектом (сетевой трафик).
  2. Использовать методы GetInfo или GetInfoEx IADs для извлечения свойств объекта из базы службы каталога, чтобы наполнить (инициализировать) локальный кэш свойств (сетевой трафик).
  3. Использовать методы Get или GetEx IADs или оба вместе для чтения свойств в локальном кэше свойств (нет сетевого трафика).
  4. Использовать методы Put или Put-Ex IADs или оба вместе для модификации свойств в локальном кэше свойств (нет сетевого трафика).
  5. Использовать метод IADs SetInfo для фиксации (записи) модифицированных свойств в кэше свойств в базе службы каталога (сетевой трафик).
  6. Использовать методы GetInfo или GetInfoEx IADs для реинициализации локального кэша свойств, чтобы отразить изменения, которые были сделаны на пятом шаге (сетевой трафик).

Теперь применим приобретенные знания для изменения версии сценария easyadsi.vbs, о котором шла речь в первой части статьи. Я использую код Листинга 2 как основу для дальнейшего обсуждения. Мы не будем проходить по сценарию построчно. Я объясню каждый метод IADs, затем приведу пример метода в Листинге 2. Однако я не показываю все доступные методы IADs, поскольку Листинг 2 можно использовать на практике, а некоторые методы IADs применяются редко.

GetInfo. Метод GetInfo извлекает свойства объекта из AD и загружает значения свойства в локальный кэш свойств, инициализируя его. Метод GetInfo загружает в кэш только те свойства, которые содержат значения.

В Листинге 2 метод GetInfo не используется по двум причинам. Во-первых, я создал новый объект пользователя (см. Листинг 2, метка А), поэтому не могу вызвать GetInfo для объекта, которого еще не существует. И хотя я обновил несколько свойств в метке B Листинга 2, я не затрагивал предыдущие значения свойств. Не нужно инициализировать кэш с существующими значениями, если планируется перезаписать значения (если только не требуется по какой-либо причине сохранить старые значения, к примеру, для фиксации изменений в управлении).

Использовать GetInfo в Листинге 2 нужно только в том случае, если требуется проверить новые значения, установленные в метке B. Чтобы это сделать, нужно вызвать GetInfo после вызова SetInfo и обновить значения в кэше. Если вызвать GetInfo перед SetInfo (и после Put-предложений), GetInfo перезапишет кэшированные значения (которые использовали Put и PutEx для модификации) оригинальными или старыми значениями из базы каталога, и изменения не сохранятся.

Хотя использование GetInfo — неплохой метод обновления кэша, он не считается самым эффективным. Например, я обновил три свойства в метке B Листинга 2. Вызов GetInfo после метки B извлекает все значения для более 50 свойств в метке A Листинга 2. Вместо GetInfo лучше применить GetInfoEx.

GetInfoEx. Метод GetInfoEx также инициализирует локальный кэш свойств, извлекая свойства объекта из AD и загружая значения свойства в кэш. Однако GetInfoEx загружает только свойства, перечисленные в массиве свойств, который является первым параметром GetInfoEx. Следовательно, метод GetInfoEx более эффективен для восстановления обновленных значений. Однако, как и в случае с GetInfo, перед вызовом GetInfoEx с именем обновленного свойства следует вызывать SetInfo.

Для проверки существующего значения метод GetInfoEx также более эффективен. Например, если нужно проверить значение одного свойства в AD, лучше использовать GetInfoEx. Вместо того чтобы выполнять явный вызов GetInfo или использовать Get для неявного вызова GetInfo, следует передать GetInfoEx массив, содержащий один элемент, который идентифицирует подлежащее проверке свойство.

Еще одна ситуация, в которой требуется GetInfoEx, связана с тем, что вызовы ADSI не загружают рабочие атрибуты (например, стандартное canonicalName) в кэш. Необходимо использовать GetInfoEx в запросе рабочего атрибута перед его прочтением, как, например, в коде, показанном на Рисунке 2. В противном случае система выдает сообщение об ошибке: «The Active Directory property cannot be found in the cache.»

Рисунок 2. Кэш свойств ADSI.

Get и GetEx. Get и GetEx обеспечивают похожие функции, так как оба считывают заданные значения из локального кэша свойств. Эти методы также запускают неявный вызов GetInfo, когда кэш свойств не инициализирован. Следовательно, GetInfoEx можно использовать для уменьшения сетевого трафика, если нужно только извлекать подмножества значений. После того как кэш свойств инициализирован явным или неявным образом, использовать Get или GetEx для обновления кэша нельзя.

Get возвращает однозначные свойства как скалярные переменные и многозначные свойства как переменные массивы. Метод GetEx возвращает все значения свойств как переменные массивы, поэтому он возвращает однозначное свойство в одноэлементном массиве.

Метод Get более эффективен в том случае, если известно, какое из двух целевых свойств является однозначным или многозначным. Однако Get может подвести, когда значение неизвестно, а кроме того, придется проверить тип результата Get и убедиться, что тип данных определен правильно. В противном случае сценарий будет выдавать ошибку при исполнении, если оперировать скаляром как массивом или наоборот. Еще больше запутывает дело то, что Get возвращает многозначный атрибут, содержащий единственное значение, как скалярную переменную, а не как одноэлементный массив. Метод GetEx использовать немного проще, поскольку можно применить один и тот же принцип для работы с любыми данными свойства. Тип результата проверять не нужно, так как GetEx возвращает все данные в массиве.

Код в Листинге 2 не вызывает Get или GetEx потому, что в возможностях этих методов нет необходимости в силу особенностей сценария, и сам сценарий не производит вывод на консоль или в файл. Если мне нужно отобразить значения свойства, я должен вставить соответствующее предложение вывода, придерживающееся такого же синтаксиса «объект.метод_свойства» (object.propertymet-hod), который использовался для установки значений свойства в метке A Листинга 2. Код на Рисунке 2 представляет собой пример синтаксиса object.propertymethod, который используется совместно с предложением Wscript.Echo.

Put и PutEx. Метод Put применяется для записи однозначных свойств в кэш свойств, а PutEx — для добавления, модификации, замены и очищения многозначных свойств в кэше свойств. Put и PutEx записывают и модифицируют значения только в кэше свойств. Для записи изменений из кэша в AD необходимо ввести SetInfo. Хотя Put можно использовать для модификации многозначных свойств, этот метод не позволяет управлять свойствами имеющихся данных. Put будет вслепую заменять все существующие многозначные данные так же, как он заменял однозначные свойства. Используйте метод PutEx в ситуациях, когда необходимо сохранить существующие данные в многозначном свойстве.

Как показано в Таблице 2, PutEx использует управляющий код для передачи типа выполняемого обновления. По ADS_PROPERTY_APPEND добавляется новое значение в то время, как существующие значения сохра-няются. ADS_PROPERTY_DELETE удаляет определенное значение и оставляет другие значения нетронутыми. Подобно Put, ADS_PROPERTY_UPDATE заменяет все существующие значения новыми, а ADS_PROPERTY_CLEAR удаляет все значения, очищая свойство.

Метка B Листинга 2 указывает на пример использования Put и PutEx. В случае с PutEx я добавил новое значение атрибуту otherHomePhone (замечу, что управлять порядком величин в многозначных свойствах нельзя).

SetInfo. Метод SetInfo записывает новые или модифицирует существующие значения свойства из кэша в AD. Метод SetInfo всегда вызывается явно; когда кэш свойств не инициализирован, SetInfo никогда не активизируется неявным образом, как это происходит в случае с Get или GetEx, вызывающими GetInfo. Любые изменения значений свойства, сделанные Put или PutEx, теряются при вызове GetInfo или, может быть, перед вызовом SetInfo. Можно использовать один вызов SetInfo для внесения целого ряда изменений, но необходимо понимать, что SetInfo — это бескомпромиссная операция типа «все или ничего». Т. е. SetInfo записывает все изменения, сделанные до вызова SetInfo, в базу каталога или не вносит изменений, если происходит ошибка (например, при нарушении требований системы безопасности).

Синтаксические соглашения object.pro-pertymethod. Синтаксис object.propertymethod — это соглашение, которое OLE-клиенты могут использовать вместо Get или Put. Синтаксис позволяет программистам на Visual Basic (VB) и VBScript использовать привычную нотацию dotMethodOrPro-pertyName. Синтаксис состоит из двух частей, отделенных точкой (.). Имя слева от точки является объектной ссылкой; имя справа от нее — это отображаемое имя атрибута, извлекаемого или записываемого в кэш, написанное по правилам Lightweight Directory Access Protocol (LDAP). Использование синтаксиса object.propertymethod в правой части оператора присваивания или выражении эквивалентно Get. Использование этого синтаксиса в левой стороне оператора присваивания эквивалентно Put. Требования к поведению синтаксиса object.propertymethod — те же самые, что и к Get и Put (т. е. те же типы возвращаемых Get результатов и ограничения на Put при обновлении многозначных свойств).

Я использовал object синтаксис .propertymethod в метке A Листинга 2 для установки исходных значений как для однозначных, так и многозначных свойств. В метке B Листинга 2 я задействовал Put и PutEx, поскольку обновил многозначное свойство под именем otherHomePhone.

Интерфейс IADsContainer

Интерфейс IADsContainer служит для управления жизненным циклом объектов AD. Контейнерные объекты создают иерархию и образуют организацию DIT. Каждый контейнерный объект в AD реализует IADs Container. IADsContainer имеет четыре свойства, которые перечислены в Таблице 3, и пять методов, указанных в Таблице 4.

Из четырех свойств IADsContainer два доступны через провайдера LDAP. Тем не менее можно использовать непосредственно и VBScript, вызвав только одно свойство: Filter. Имя говорит само за себя, свойство Filter позволяет применять фильтр к контейнеру и выбирать отдельные типы объекта. Например, при привязке к OU, когда нужно выбрать только группу объектов, входящих в OU, к OU применяется Group Filter, как показано на Рисунке 3.

Можно добавить в массив другие типы объектов, проводя фильтрацию по различным типам объектов. Например, Array («Group», «Computer») перечисляет все объекты типа Group и Computer. Кроме того, можно еще раз применить фильтр с другими типами объектов и получить совершенно другой перечень. Однако если используется свойство Filter для фильтрации объектов User, то в перечне появятся как объект User, так и Computer, потому что Computer является дочерним по отношению к User в иерархии классов AD. Чтобы избежать такой ситуации, можно применить фильтр для объектов Computer, запомнив список только объектов Computer. Далее создается второй список для фильтра по User, сравниваются два списка, и из списка пользователей удаляются позиции из списка компьютеров. Или же можно полностью заменить фильтр запросом ADO.

Другое свойство IADsContainer, применяемое к провайдеру LDAP, называется NewEnum. Однако непосредственно NewEnum не вызывается; предложение For Each из VBScript осуществляет просмотр контейнера и неявным образом вызывает NewEnum, как показано на Рисунке 3.

Из пяти методов IADsContainer к методам Create, Delete, GetObject и MoveHere нельзя получить доступ с помощью провайдера LDAP. Вместе все четыре метода обеспечивают первичные механизмы управления жизненным циклом объектов AD.

Create. Метод Create применяется для создания новых объектов AD (например, User, OU, Group, Com-puter, Site). Код, показанный меткой A в Листинге 2, осуществляет привязку к соответствующему контейнеру и вызывает Create для создания нового объекта. Некоторых общих ошибок при использовании метода Create можно избежать, если не пропускать установку новых обязательных свойств объекта перед вызовом SetInfo или не забывать указывать «key=» как часть относительного имени RDN объекта. Можно использовать сценарий, подобный приведенному в Листинге 1, для определения обязательных (must-Containe) и дополнительных (may-Containe) свойств объекта.

Система сама присваивает значения большинству обязательных свойств (например, objectClass, objectCategory, objectSid, ntSecurityDescriptor, instanceType). Из семи обязательных свойств пользователя, которые показаны на Экране 1, приходится иметь дело только с cn и sAMAccountName. Установка свойства cn происходит как часть вызова метода Create, а Put используется для установки sAMAc-countName. Обычно обязательные свойства, которые обрабатывает система, не инициализируются.

Delete. Метод Delete несложен (см Листинг 2 метка D). Сначала происходит привязка к родительскому контейнеру объекта, который нужно удалить. Далее вызывается метод Delete контейнера и идентифицируется целевой дочерний объект для удаления. Как и в случае с методом Create, требуется указание соответствующего «key=», как части имени RDN целевого объекта.

Удаление объекта — действие необратимое. Но Delete не может удалить контейнеры, в которых хранятся объекты. Сначала необходимо рекурсивно удалить все дочерние объекты, затем, если требуется использовать метод Delete для удаления целого сегмента дерева каталога, также рекурсивно удалить вложенные контейнерные объекты. Если очевидно, что нужно отрезать целую ветвь дерева каталога, используется метод DeleteObject, предоставляемый интерфейсом IADs-De-leteOps, который обеспечивает удаление контейнера и всех его объектов.

GetObject. Метод GetObject из IADs-Container подобен функции GetObject из VBScript тем, что GetObject из IADs-Container создает ссылку на объект программирования ADSI. Различие между ними заключается в том, что метод GetObject из IADsContainer позволяет привязываться только к дочерним объектам в контейнере ADSI. Это объясняет, почему сигнатуры методов (т. е. списки параметров) двух методов с одним и тем же названием различны. Функции GetObject из VBScript предоставляется ADsPath, в то время как методу GetObject из IADsContainer требуется имя класса и RDN целевого объекта в текущем контейнере. Последний метод обеспечивает легкость просмотра контейнера и привязки к каждому дочернему объекту из списка.

MoveHere. MoveHere используется для переноса объекта из одного контейнера в другой, что происходит при перемещении между доменами или переименовании объекта. Из рассматриваемых четырех методов пользователи чаще всего совершают ошибки с MoveHere. Ошибкой является непонимание того, что MoveHere — это механизм, который используется для переименования объектов AD. Нельзя изменить обязательное свойство cn объекта или эквивалентное ему (например, ou в случае OU), чтобы переименовать объект AD, как это обычно делается при изменении других атрибутов. Нужно использовать MoveHere. Другая общая ошибка — это попытка создать ADsPath для перемещения или переименования объекта. Для решения этой задачи лучше использовать свойство IADs::ADs Path или переменные, пример показан в Листинге 2, метка С.

При использовании MoveHere всегда происходит привязка к целевому контейнеру, который может быть текущим родительским контейнером объекта. При перемещении объекта происходит привязка к целевому контейнеру; при переименовании объекта — к родительскому контейнеру объекта. Если объект и перемещается и переименовывается, осуществляется привязка к целевому контейнеру. После получения интерфейса целевого или родительского контейнера можно вызывать MoveHere. Первый параметр MoveHere — ADsPath объекта для перемещения или переименования — всегда один и тот же, он не зависит от типа операции. Второй параметр — это одно из двух возможных значений. При переименовании объекта вторым параметром является новое имя RDN объекта. Если объект не переименовывается, то вторым параметром будет текущее RDN объекта.

Дополнительные интерфейсы в ADSI

Хотя я рассказал только о трех базовых интерфейсах ADSI, несомненно, для решения различных административных задач используются и другие программные интерфейсы. Перечислим некоторые из них:

  • методы SetPassword и ChangePas-sword, которые интерфейс IADsUser предоставляет для управления паролями пользователей, как показано в Листинге 2, метка А;
  • метод Group, который интерфейс IADsUser предоставляет для перечисления групп, принадлежащих пользователю;
  • методы Members, IsMember, Add и Remove, которые предоставляет интерфейс IADsGroup для управления членством в группах;
  • интерфейсы системы защиты IADs-SecurityDescriptor, IADsAccessCont-rolList и IADsAccessControlEntry для управления безопасностью объектов AD.

Чтобы понять, какой интерфейс, отличный от IADs или IADsContainer, необходимо применить, нужно сделать следующее.

  1. Идентифицировать тип объекта, с которым вы работаете (например, объекты Computer, Group, User).
  2. Обратиться к документации по ADSI и выяснить, существует ли интерфейс для такого типа объекта. Названия интерфейсов начинаются с IADs, затем идет имя типа объекта (например, IADsComputer, IADsGro-up, IADsOU, IADsUser). Найти полный список интерфейсов можно в Microsoft Developer Network (MSDN) Online Library.
  3. Если интерфейс в ADSI существует, нужно оценить те свойства и методы, которые он предоставляет, чтобы найти подходящий метод или свойство.

(Окончание.)

БОБ УЭЛЛС - консультант по программному обеспечению; специализируется на вопросах проектирования и реализации инфраструктуры информационных систем, основанных на NT. Имеет сертификаты MCSE и MCT. С ним можно связаться по адресу: bobwells@win2000mag.com.