Расширение схемы AD

Служба Active Directory операционной системы Windows 2000 открывает перед администратором множество различных возможностей управления данными. Опубликованная ранее статья "Займемся схемами AD" знакомит читателей со схемой AD. Она помогает составить представление о довольно сложном наборе реализованных в этой схеме понятий и отношений: речь идет об объектах classSchema и attrubuteSchema (и связанных с ними атрибутах), а также о взаимоотношениях между абстрактными, вспомогательными и структурными классами и атрибутами. Теперь, после знакомства с этой статьей, читатели, образно говоря, готовы покинуть мелководье и приступить к исследованию морских глубин, то есть вплотную заняться проблемой расширения схемы.

Однако для начала нужно ответить на вопрос: "А действительно ли расширение схемы необходимо?" Кроме того, следует продумать, как эта операция отразится на лесе AD. Не забывайте, что в среде Windows 2000 удаление расширений AD невозможно. Поэтому необходимо четко уяснить присущие схеме ограничения и требования, а перед тем, как приступить к реализации схемы в рабочей среде, тщательно проверить расширение. Сначала нужно создать объект расширения в тестовой среде, и лишь убедившись, что все сделано правильно, можно перенести новый объект в службу AD корпоративной сети.

Расширять или не расширять?

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

Публиковать следует только те данные, которые представляют интерес для всех звеньев сети. AD не подходит для хранения данных, к которым обращается лишь один сервер или один пользователь.

Избегайте публикации часто меняющихся данных. В системе Windows 2000 предусмотрено распределение и регулярное тиражирование каталога, и если данные устаревают еще до того, как AD растиражирует их по всему предприятию, значит, этой информации не место в хранилище AD. Судя по опыту, публиковать данные стоит лишь в том случае, если их "жизненный цикл" более чем в два раза превышает задержку (запаздывание) тиражирования службы AD, т.е. время, за которое эта служба тиражирует обновленную информацию (или изменения в информации) в масштабах всего предприятия. Задержку тиражирования в сети можно измерить с помощью таких инструментов, как DirectoryAnalyzer компании NetPro.

Учтите и такой показатель, как ширина полосы пропускания, необходимая для тиражирования данных; обычно он зависит от того, насколько часто изменяется информация, и от размеров объекта данных. Так, администратор, вероятно, не станет хранить в AD фотографии сотрудников, если эти снимки сделаны с высоким разрешением и с использованием 16 млн. цветов.

В тех случаях, когда без хранения каких-либо данных в каталоге AD все-таки не обойтись, а объект чрезвычайно велик или часто изменяется, можно уменьшить нагрузку на каналы связи и сэкономить дисковое пространство накопителей, сохраняя в каталоге не саму информацию, а ссылку на нее. Информацию можно хранить в базе данных Microsoft SQL Server и публиковать связывающую строку соединения ODBC (с оператором SQL SELECT) как выделенный атрибут в AD. Можно избрать и другой способ: хранить данные на Web-сервере и публиковать указатель URL, отсылающий пользователей к этой информации. Разумеется, оснащенные средствами AD приложения должны при этом корректно интерпретировать указатель.

Если вы все-таки пришли к выводу, что новые данные следует хранить в каталоге AD, настройте существующую схему так, чтобы она соответствовала реальным потребностям. Возможно, если модифицировать существующий класс, удастся обойтись без создания нового класса. Администратор должен четко понимать как общие положения, на которых строится схема, так и конкретные потребности своей организации. Получить ясное представление о схеме позволяет статья "Займемся схемами AD". Полезно также изучить обзор службы AD, размещенный в сети Microsoft Development Network - MSDN по адресу http://msdn.microsoft.com/certification/schema/default.asp.

Обратной дороги нет

Приняв решение о расширении схемы, нужно помнить о том, что во всем лесу AD существует только одна схема. Windows 2000 осуществляет глобальное тиражирование контекста именования схемы (Schema naming context, NC), поэтому любое изменение этого контекста будет затрагивать весь лес.

Мало того, расширения схемы необратимы. Добавив новый объект classSchema или attributeSchema, вы уже не сможете его удалить. Иногда это ограничение можно обойти, отключив некоторые классы и атрибуты, но отключить атрибут активного класса невозможно; наконец, не предусмотрено отключение или переименование классов или атрибутов категории 1 (Category 1). К этой категории относятся объекты, которые являются частью базового дерева данных о каталоге - Base Directory Information Tree, или DIT. Более подробная информация о категориях объектов схемы содержится в статье "Займемся схемами AD".

Впрочем, некоторые изменения в активные объекты схемы вносить все-таки можно. Допускается добавление нового класса атрибуту possSuperiors объектов classSchema категории 1 или категории 2. Разрешается добавление нового атрибута атрибуту mayContain объектов classSchema категории 1 или категории 2. Можно добавить новый вспомогательный класс атрибуту auxiliaryClass объектов classSchema категорий 1 или 2. Можно, наконец, изменить атрибут lDAPDisplayName объекта classSchema или attributeSchema категории 2. Изменение имени, используемого протоколом Lightweight Directory Access Protocol (LDAP) позволяет всего лишь нейтрализовать ошибку, но не забыть о ней навсегда.

Добавлять или удалять атрибуты, присвоенные атрибуту mustContain какого-либо объекта, ни напрямую, с помощью вспомогательного класса, ни через механизм наследования атрибутов родительского класса (суперкласса) не разрешается. Многие компоненты системы Windows 2000 зависят от объектов категории 1, поэтому модификация таких атрибутов этих объектов, как rangeLower, rangeUpper, attributeSecurityGuid, defaultObjectCategory, objectCategory или lDAPDisplayName не допускается.

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

Начнем с того, что опытный менеджер схемы не притронется к рабочей системе до тех пор, пока вдоволь не поэкспериментирует в специально организованной тестовой среде. Выделите особую тестовую систему, на которой можно деинсталлировать и вновь устанавливать систему Windows 2000, не оказывая влияния на лес компании. Пусть на этом испытательном полигоне на один лес приходится один контроллер домена (domain controller, DC). Затем можно понизить роль контроллера домена, чтобы удалить внесенные в схему изменения, и создать DC, чтобы построить вновь базовую схему AD.

В процессе подготовки позаботьтесь о том, чтобы применяемая учетная запись пользователя была включена в список администраторов схемы (Schema Admins group). Кроме того, придется выяснить, какой из контроллеров доменов корпоративной сети Windows 2000 играет роль мастера схемы.

Понятно, что в тестовой среде с одним контроллером домена такой машиной и будет этот самый контроллер. Но когда вы будете готовы вносить изменения в схему корпоративной среды, у вас должен быть доступ к компьютеру - мастеру схемы, поскольку придется модифицировать реестр этой системы для того, чтобы переключить контекст именования схемы в режим чтения/записи. Для модификации реестра откройте редактор реестра, перейдите к разделу HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\NTDS\Parameters и присвойте параметру Schema Update Allowed (типа REG_DWORD) значение 1.

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

Получаем идентификатор объекта

Еще одно предварительное условие при создании расширения состоит в том, что для него нужно получить идентификатор объекта (Object Identifier, OID). Как я объяснял в статье "Займемся схемами AD", каждый класс и атрибут AD представляет собой уникальный объект, который должен обладать уникальным идентификатором OID, формируемым диспетчером схемы на основе базовых идентификаторов OID. Новый OID будет храниться в атрибуте attributeID нового объекта.

Получить два базовых идентификатора OID - один для объектов classSchema, а другой для объектов attributeSchema - можно с помощью инструмента Oidgen (oidgen.exe) из комплекта Microsoft Windows 2000 Server Resource Kit. С помощью Oidgen вы выполните задачу быстрее, чем если бы следовали методике, рекомендованной Международной организацией по стандартизации International Organization for Standardization, ISO. Но в этом случае идентификаторы OID будут явно «родом из Microsoft», так что для получения базовых OID вы, возможно, предпочтете вариант ISO. Выполните программу один раз, затем назначьте идентификаторы OID на основе сгенерированных образцов. На Рисунке 1 показан примерный результат однократного выполнения программы Oidgen. Если взять за основу представленные на рисунке базовые OID, идентификатор для первого объекта attributeSchema может выглядеть так:

1.2.840.113556.1.4.7000.233
  .28688.28684.8.450094.294295
  .2081771.1774679.1

а OID для первого объекта classSchema может выглядеть так:

1.2.840.113556.1.5.7000
  .111.28688.28684.8
  .331888.572581.472599
  .1295831.1

Чтобы зарегистрировать вновь созданные базовые идентификаторы OID в Microsoft, нужно написать по адресу oids@microsoft.com. Упомяните в письме название компании, имя ответственного за контакты лица, адрес электронной почты, а также базовые номера OID для классов и атрибутов.

Теперь пришло время присвоить новому объекту расширения уникальное имя. Приложения, участвующие в программе Windows Logo, должны строиться в соответствии с определенными правилами именования объектов схемы. Рекомендую соблюдать эти правила в целях согласованности, даже если ваша компания и не участвует в данной программе. Соглашения по именованию схемы касаются двух атрибутов объектов: атрибута "основное имя" (common name, cn) и атрибута "имя по протоколу LDAP" (lDAPDisplayName).

Атрибут cn нового объекта имеет следующую форму:

название_фирмыуникальное_имя_объекта

(company_nameunique_object_name). Префикс, или первый маркер (token) - это название фирмы, имя домена в Internet, сокращение или другой идентификатор компании. Это название можно писать через дефис - для того, например, чтобы указать приложение или название отдела, который будет использовать данное расширение. Второй маркер - это дефис. Третий маркер является описательным; это уникальное имя создаваемого класса или атрибута.

Предположим, что вы являетесь менеджером схемы компании DogFood, и ее домен в Internet называется df.com. Отдел кадров компании (human resources, HR) планирует развернуть новое глобальное AD-совместимое приложение учета пропусков служащих. Чтобы реализовать этот план, необходимо создать новый объект схемы AD для хранения номера пропуска каждого сотрудника. В данной ситуации атрибуту cn логично дать имя DF-HR-Badge-Number. В первом маркере (т.е. DF-HR) сочетается доменное имя компании и название группы, к которой относится новый объект. Третий маркер (Badge-Number) наглядным и уникальным образом идентифицирует целевое назначение объекта.

При формировании атрибута lDAPDisplayName проследите, чтобы первая буква его атрибута cn была строчной. Затем проверьте первую букву после каждого дефиса - эти буквы должны быть прописными - и удалите все дефисы, следующие после второго дефиса (который является маркером). В итоге атрибут lDAPDisplayName созданного для компании DogFood нового объекта badge-number будет иметь следующий вид: dF-HR-BadgeNumber.

Тем, кто хочет более подробно ознакомиться с соглашениями по именованию объектов схемы, я рекомендую прочесть правила именования MSDN для программы Certified for Windows Program, размещенные по адресу (http://msdn.microsoft.com/certification/namingrules.asp), или загрузить созданную в рамках той же программы документацию Server Specification (v 1.3), которую можно получить по адресу http://msdn.microsoft.com/certification/download.asp. Интересующие сведения содержатся в четвертой главе под заголовком "Active Directory". Если вы хотите иметь гарантии, что применяемый в организации префикс не будет использоваться другой фирмой, можете зарегистрировать его по адресу http://msdn.microsoft.com/certification/ad-registration.asp.

Решения, решения ...

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

Пропуск каждого сотрудника имеет уникальный номер, поэтому логично сделать новый объект атрибутом (иначе говоря, объектом dF-HR-BadgeNumber attributeSchema), который ассоциируется с классом user (т.е. с объектом user classSchema).

Следующее решение: новый атрибут должен быть обязательным или факультативным? Мы хотим, чтобы наш атрибут был ассоциирован с каждым новым экземпляром пользователя, а значит, он должен быть обязательным, ведь так? Нет, не угадали. Вот когда пришлось вспомнить об ограничениях, упомянутых мною в начале статьи. Атрибут mustContain определяет обязательные атрибуты ассоциированного с ним объекта. Но все дело в том, что модификация атрибута mustContain существующего объекта категории 1 не допускается, а класс user, являющийся частью базового дерева DIT, как раз и относится к объектам категории 1.

Кто-то из читателей скажет, что в этой ситуации логично было бы создать новый класс user, связать с ним новый атрибут (наделив его статусом "обязательный", чтобы затем при формировании новых экземпляров пользователей применять не стандартный класс user, а только что созданный). Однако все не так просто. Специалистами Microsoft разработано множество инструментальных средств, которые взаимодействуют именно со стандартным классом user и могут функционировать лишь в том случае, если служба AD обращается к этому классу (в качестве примера можно привести любые средства управления, поставляемые с Windows 2000). Следовательно, если вы откажетесь от этого класса, проект расширения схемы станет, образно говоря, предприятием по разработке средств управления для Windows 2000. Так что нам остается единственный вариант - оставить за атрибутом badge-number статус факультативного и ассоциировать его со стандартным классом user.

Теперь нужно решить, как именно реализовать эту связь. Преодолейте искушение ассоциировать атрибут "по наследованию". В этом случае атрибут будет ассоциироваться с каким-либо абстрактным классом, например, Top, Person или organizationalPerson. Это четко определенные классы X.500, и такое изменение нарушит совместимость определений данного класса с определениями X.500.

Ассоциировать атрибут с классом user можно и напрямую, но если со временем вы создадите множество атрибутов расширения, которые будут обслуживать целый ряд приложений, будет трудно понять, к чему относятся и какой цели служат подобным образом ассоциированные атрибуты. Так что лучший способ ассоциации нового атрибута с классом user - создать вспомогательный объект classSchema с именем dF-HR-EmployeeBadge и связать новый атрибут с этим вспомогательным классом. Как видно из Рисунка 2, впоследствии с помощью этого вспомогательного класса можно будет включить в класс user новый атрибут badge-number. Использование вспомогательных классов позволяет группировать атрибуты расширения в соответствии с приложениями или по их значению.

При создании нового вспомогательного класса последний может быть выведен из существующего класса, который в таком случае определяется как суперкласс. В нашем примере, однако, новый класс является всего-навсего средством для связывания нового атрибута с классом user, так что наделять (класс) dF-HR-EmployeeBadge атрибутами, заимствованными у какого-либо существующего класса, нет оснований. Иначе говоря, новый вспомогательный класс можно создавать без указания суперкласса.

Теперь нам ясно, что нужно делать - создать вспомогательный объект classSchema (dF-HR-EmployeeBadge) с факультативным объектом attributeSchema (dF-HR-BadgeNumber) и добавить этот новый класс к атрибуту auxiliaryClass класса user.

Определяем расширение

Прежде всего, необходимо создать объект attributeSchema с именем dF-HR-BadgeNumber. Характеристики данного атрибута нужно определять через другие ассоциированные атрибуты (возможно, это положение покажется не совсем четким; подробно суть вопроса излагается в статье "Займемся схемами AD", где, кстати говоря, приводится также и список обязательных и факультативных атрибутов). Итак, мы уже определили содержимое атрибута attributeID, где хранится идентификатор OID объекта, атрибут cn с основным именем объекта и атрибут lDAPDisplayName, где содержится имя объекта при отображении по протоколу LDAP. Если вернуться к нашему примеру с номерами пропусков сотрудников, другими важными атрибутами будут те, что определяют синтаксис нового объекта, диапазон, статус индексирования, тип значения (может ли объект принимать только одно или несколько значений), глобальный уникальный идентификатор (globally unique ID, GUID) и статус публикации в глобальном каталоге (Global Catalog, GC).

Атрибут attributeSyntax определяет синтаксис атрибута. Синтаксис определяется типом данных, которые вы собираетесь хранить в данном атрибуте (строка, число, и т.д.).

Атрибуты rangeLower и rangeUpper определяют диапазон между минимальным и максимальным размером атрибута (для атрибутов со строковым синтаксисом) или между минимальным и максимальным значением (для атрибутов с числовым синтаксисом). Атрибуты диапазона не фиксируют конкретных пороговых значений. Они определяют правила, соблюдение которых обеспечивается службой AD при установлении значения атрибута. Таким образом, менеджер схемы может с легкостью изменять правила, сокращая или увеличивая диапазон.

Атрибут searchFlags определяет статус индексации нового объекта attributeSchema. Если вы хотите, чтобы приложение выполняло такие операции поиска по протоколу LDAP, в которых ключевым словом является имя нового атрибута, новый атрибут для ускорения процесса поиска нужно проиндексировать. Однако имейте в виду, что на создание экземпляра объекта на основе класса с множеством проиндексированных атрибутов системе требуется больше времени. Поэтому индексировать новый атрибут имеет смысл лишь в том случае, если вы уверены, что операции поиска на его основе будут проводиться достаточно часто.

Атрибут isSingleValued определяет, может ли атрибут принимать только одно или несколько значений. Если взять в качестве примера объект badge-number (номер пропуска), созданный для компании DogFood, новый объект attributeSchema будет принимать лишь одно значение, поскольку каждый служащий имеет лишь один номер пропуска.

Атрибут schemaIDGUID указывает глобальный уникальный идентификатор объекта (GUID). Генерировать значение этого атрибута можно с помощью средства Uuidgen (uuidgen.exe) из комплекта Microsoft Platform Software Development Kit (SDK). Создавая идентификатор GUID вручную, можно обеспечить идентичность значения атрибута schemaIDGUID в различных лесах AD, что, соответственно, позволяет задействовать согласованные ссылки на объект. (Если вы не указать рассматриваемый атрибут, служба AD автоматически создаст идентификатор GUID для нового объекта. Но если вы создаете данный атрибут в различных лесах, его значение будет изменяться от леса к лесу).

Атрибут isMemberOfPartialAttributeSet определяет, будет ли новый объект attributeSchema реплицироваться в глобальном каталоге. Необходимость в публикации атрибута в глобальном каталоге возникает в тех случаях, когда требуется, чтобы этот атрибут был доступен по всему лесу (а не только в домене, в котором создается объект user).

В других же случаях вопрос о том, тиражировать ли атрибуты в глобальном каталоге, решается в зависимости от обстоятельств. Как и индексирование, публикация атрибутов в глобальном каталоге создает дополнительный трафик репликации. Кроме того, задавая атрибуту isMemberOfPartialAttributeSet значение publish the new object in the GC, менеджер схемы тем самым инициирует процесс полной синхронизации всех глобальных каталогов леса AD. И если все это происходит в огромном лесу с множеством глобальных каталогов, синхронизация выливается в интенсивный сетевой трафик репликации. Более подробная информация об этом явлении содержится в статье Microsoft "How to Modify Attributes That Replicate to the Global Catalog".

Теперь, когда мы собрали всю необходимую информацию для определения нового атрибута, самое время приступить к созданию расширения схемы в тестовой AD. Каким инструментом воспользоваться для решения этой задачи? Казалось бы, ответ напрашивается сам собой: модифицировать схему с помощью оснастки Active Directory Schema консоли Management Console (MMC), которая открывает доступ к диалоговому окну Create New Attribute. Но я не рекомендую этот способ. Во-первых, данное диалоговое окно отображает не все атрибуты из тех, которые, возможно, придется определять при создании расширения схемы (атрибута schemaIDGUID, к примеру, там нет). Далее, менеджеру приходится вручную вводить в оснастку идентификатор OID расширения, а при вводе большого количества цифр легко допустить ошибку. Но еще важнее то, что уже по завершении испытаний расширения на тестовой системе придется вновь вводить все эти данные в оснастке для корпоративной системы. А тут уже возникает опасность того, что вы допустите ошибку, которой удалось избежать в ходе испытаний.

Поэтому модифицировать схему на тестовой системе я рекомендую с помощью сценария. Впоследствии можно применить этот сценарий на производственных системах или просто перенести протестированное расширение в производственную систему AD с помощью входящего в комплект поставки Windows 2000 Server средства LDAP Data Interchange Format Data Exchange (Ldifde). Если же вы в любом случае хотите модифицировать схему при помощи оснастки, по крайней мере, не забывайте о потенциальных проблемах.

Работаем со сценарием

Для изменения тестовой схемы программным путем можно использовать разработанные в Microsoft интерфейсы ADSI (Active Directory Service Interfaces), которые представляют собой уровень абстракции модели COM, реализуемый поверх протокола LDAP. (Вопросы использования ADSI подробно освещаются в "белой книге" Microsoft "Active Directory Service Interfaces"). Интерфейсы ADSI совместимы с языками Visual Basic (VB) 6.0, VBScript, JScript и C.

В Листинге 1 приведены избранные фрагменты сценария на языке VBScript (createdogfoodschema.vbs), написанного мною при создании расширения для компании DogFood. Многоточие (...) означает, что в данном месте пропущено несколько строк. Другие образцы кода, а также дополнительная информация о расширении схемы содержится в руководстве Active Directory Programmers Guide из комплекта Platform SDK, представленном на Web-узле MSDN по адресу http://msdn.microsoft.com/library/default.asp?url=/library/psdk/adsi/glschemex_5py9.htm.

Как видно из Листинга 1, в сценарии, прежде всего, определяются константы, которые будут использоваться при формировании новых объектов attributeSchema и classSchema. Затем сценарий обращается к объекту RootDSE, чтобы определить местонахождение контекста именования схемы в данном лесу.

Далее сценарий устанавливает различные атрибуты, необходимые для создания нового объекта attributeSchema. Для превращения восьмиразрядной строки атрибута schemaIDGUID в бинарную восьмиразрядную строку (этот процесс необходим для определения атрибута schemaIDGUID), сценарий обращается к объекту WSHOcx, который инициализирует метод StringGUIDToBinaryGUID. Данный метод, который представляет собой COM-объект ActiveX, реализован в скрытых строках сценария. Объект WSHOcx включен в доступный через Internet файл 22540.zip, который можно получить на сайте оригинального журнала Windows 2000 Magazine.

Сформировав в контексте именования схемы новый атрибут badge-number, сценарий создает новый класс, который будет содержать данный атрибут. Процесс включает те же этапы, что и при создании атрибута, с той лишь разницей, что в этом случае для создания объекта classSchema сценарий инициализирует другой набор атрибутов. Идентификатор OID объекта определяется атрибутом governsId. Поскольку данный класс является вспомогательным классом, применяемым для включения в класс user нового атрибута, атрибут objectClassCategory присваивает ему категорию 3. Атрибуты lDAPDisplayName и schemaIDGUID содержат, соответственно, такие характеристики объекта вспомогательного класса, как имя при отображении по протоколу LDAP и глобальный уникальный идентификатор GUID.

Но вот вспомогательный класс создан. Теперь сценарий должен ассоциировать с новым классом новый атрибут. В метке A Листинга 1 показан код, выполняющий связывание атрибута mayContain.

Следующий этап работы сценария - обновление класса user так, чтобы он включал в себя новый вспомогательный класс. Отметим, что при этом сценарий должен рассматривать атрибут auxiliaryClass класса user как допускающий множество значений (multivalued), иначе все существующие вспомогательные классы, ассоциированные с классом user, будут удалены (так, сценарий может случайно удалить из класса user ассоциированные вспомогательные классы Microsoft Exchange 2000 Server). Метка B иллюстрирует код, выполняющий это определение.

Внесенные менеджером изменения вступают в силу не сразу, а по прошествии определенного времени. В целях обеспечения оптимальной производительности копия схемы AD хранится в памяти. Обновление этой копии происходит автоматически по истечении 5 минут с момента модификации схемы, однако менеджер может произвести немедленное обновление. Для выполнения этой операции сценарий обращается к функциональному атрибуту schemaUpdateNow объекта RootDSE.

Второй способ немедленного обновления предполагает обновление кэша с помощью оснастки Active Directory Schema. Существует и третья возможность: использовать Ldifde для загрузки файла LDIF, показанного в Листинге 2. Файл LDIF представляет собой всего-навсего ASCII-версию экспортированного содержимого каталога с бинарными значениями, закодированными по основанию 64. Тем, кто хочет получить более подробную информацию о программе Ldifde и о файлах LDIF, рекомендую обратиться к статье Microsoft "Using LDIFDE to Import/Export Directory Objects to the Active Directory".

Переносим расширение в производственную систему

После настройки расширения в тестовой среде его нужно воспроизвести в лесу AD корпоративной сети Windows 2000. При этом можно использовать созданный в лаборатории сценарий; достаточно просто учесть различия в параметрах тестовой и корпоративной среды. Можно избрать и другой путь: с помощью средства Ldifde создать файл LDIF, содержащий объекты расширения, экспортировать файл LDIF и импортировать его в реальный лес. Так, для того, чтобы создать файл dogfoodschema.ldf, показанный на Рисунке 3, введите следующие инструкции:

LDIFDE -f DogFoodSchema.ldf -d 
  "cn=Schema,cn=Configuration,
  dc=MyW2KRootDomain,dc=com"
  -r "(cn=df-HR*")

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

Дождитесь репликации

Одних упований на то, что перенесенная в производственную систему обновленная версия схемы будет так или иначе реплицирована по всему лесу, явно недостаточно; данный процесс следует проконтролировать, и это особенно важно в тех случаях, когда цель обновления - подготовка среды к установке приложения типа Exchange 2000. Дело в том, что инсталляцию программного обеспечения можно начинать лишь после того, как обновленные данные будут должным образом переданы на все контроллеры доменов. Чтобы удостовериться в завершении процедуры репликации, нужно с помощью оснастки Active Directory Schema установить соединение с удаленным контроллером домена и определить, присутствует ли данное расширение в контексте именования схемы. Кроме того, следует проверить, нет ли сообщений об ошибках репликации в журнале регистрации событий службы каталога (Directory Service, DS). Мониторинг репликации AD можно проводить с помощью таких изделий, как DirectoryAnalyzer.

Управляем новыми объектами

Как бы то ни было, на этапе успешного создания расширения наша работа не завершается. Менеджеру схемы необходима возможность управления введенными в схему новыми атрибутами и классами. Для решения этой задачи можно разработать Web-интерфейс или написать прикладную программу для клиентской стороны; можно, наконец, создать оснастку MMC. Однако надо иметь в виду, что в режиме по умолчанию стандартная оснастка MMC Active Directory Users and Computers не отображает атрибуты расширения. Сначала нужно расширить возможности консоли с помощью спецификаторов отображения (display specifiers). Эти спецификаторы представляют собой атрибуты, хранящиеся в контейнере cn=DisplaySpecifiers контекста именования конфигурации AD. Они содержат данные, касающиеся конкретного класса, и определяют, каким образом следует отображать упомянутые данные. Полное описание спецификаторов отображения и методов их использования выходит за рамки настоящей статьи, но читатели могут почерпнуть необходимые сведения в белой книге Microsoft "Active Directory Display Specifiers".

Обеспечиваем защиту расширения

По умолчанию каждому объекту classSchema присваивается дескриптор безопасности. Он защищает объекты, созданные на основе данного класса. Если требуется более избирательный контроль доступа к новым расширениям, можете определить новые права и присвоить их новому объекту - служба AD предоставляет такую возможность. В нашем примере с компанией DogFood можно, скажем, предоставить пользователям право считывать, но не изменять атрибут badge-number (номер пропуска). Эти права, именуемые расширенными правами (extended rights) и фиксируемые в контейнере cn=Extended-Rights контекста именования конфигурации, содержат сведения о нуждающихся в защите атрибутах и информацию о том, каким образом эта защита реализуется. Как и спецификаторы отображения, расширенные права не являются предметом данной статьи; информацию о создании и реализации этих прав можно найти в комплекте Platform SDK на Web-узле MSDN.

Семь раз отмерь…

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

Ален Лиссо - С ним можно связаться по адресу: alain.lissoir@compaq.com.