Windows 2003 упрощает задачу
Расширение схемы Active Directory (AD) добавляет класс или атрибут к базовой схеме (то есть версии схемы, поставляемой вместе с Windows Server 2003 или Windows 2000 Server). Расширение схемы Windows 2000 всегда требовало тщательного планирования, так как разработчики Microsoft не предусмотрели никакого метода удаления объекта из схемы. В статье «Удаляем расширения схемы AD», опубликованной в Windows & .NET Magazine/RE № 1 за 2003 год, описан способ удаления объектов схемы, но этот метод официально не поддерживается и его применение требует осторожности. Данное ограничение часто мешает использовать AD на предприятиях для хранения деловой информации.
Однако в Windows 2000 можно сделать определенные классы и атрибуты недоступными. А в Windows 2003 существует еще более удобный способ отключить определение расширения таким образом, что расширение как будто исчезает из AD; затем элементы недоступного расширения (например, атрибут lDAPDisplayName, объектный идентификатор Object Identifier, OID) можно задействовать повторно. Деактивизация расширения схемы AD требует такой же осторожности и планирования, как и его создание. Необходимо учитывать различные факторы, в том числе причину отключения расширения, его первоначальную структуру и реализацию, версию AD (Windows 2003 или Windows 2000) и режим (функциональный уровень), в котором работает AD. В Windows 2003 функциональный уровень домена и леса определяет доступные функции AD. Функциональный уровень зависит от операционной системы контроллеров домена — DC. Настроить функциональный уровень леса Windows 2003 можно только в том случае, если все DC леса работают с Windows 2003. Этот уровень обеспечивает доступ к наиболее ценным возможностям AD. Более подробную информацию о функциональных уровнях можно найти в статье Microsoft «HOW TO: Raise Domain and Forest Functional Levels in Windows Server 2003,» http://support.microsoft.com/?kbid=322692. После того как будут учтены все возможные последствия и осложнения, связанные с отключением расширения, эту задачу можно выполнить с помощью ADSI Edit, оснастки Active Directory Schema (schmmgmt.dll) консоли управления Microsoft Management Console (MMC), файла Data Interchange Format (LDIF) протокола Lightweight Directory Access Protocol (LDAP) или сценария.
Приступая к чтению данной статьи, необходимо понимать, как работает схема AD. Более подробно о терминологии, механизмах и процессе создания расширений схемы рассказано в статьях «Расширение схемы AD,» (http://www.osp.ru/win2000/worknt/3nt06.htm) и «Займемся схемами AD,» (http://www.osp.ru/win2000/worknt/90nt03.htm), опубликованных на нашем сайте.
Анализ существующего расширения
Во-первых, приступая к деактивизации расширения схемы, необходимо четко представлять себе, зачем это делается. Как правило, администратор руководствуется одним из трех возможных соображений, изложенных во врезке «Зачем отключать?». От причин, вызвавших отключение схемы, зависит сложность задачи и, следовательно, объем планирования.
Во-вторых, необходимо понимать структуру и особенности реализации расширения, которое предполагается отключить. В первую очередь следует обратить внимание на различные ссылки объектов classSchema и attributeSchema. Поскольку в определениях объектов classSchema и attributeSchema содержатся ссылки друг на друга (то есть набор атрибутов всегда связан с конкретным классом), необходимо разорвать связи между объектами, прежде чем деактивизировать определения объекта расширения схемы.
В третьих, следует внимательно проанализировать информацию, используемую для построения схемы. Если планируется воссоздать обновленную версию расширения, то нужно помнить о том, что в зависимости от операционной системы и режима работы AD часть информации невозможно повторно задействовать даже после деактивизации исходного расширения. Имеется несколько атрибутов classSchema, которые часто применяются при построении нового объекта classSchema (то есть нового класса) и могут оказаться недоступными для повторного использования. Это же справедливо для атрибутов, используемых при создании нового объекта attributeSchema (то есть нового атрибута) и также иногда недоступных для повторного применения.
Существует несколько инструментов для исследования расширений схемы и сбора информации. Помимо ADSI Edit, оснастки Active Directory Schema и LDP (в комплекте Support Tools Windows 2003), можно использовать программу Schema Documentation от Microsoft, которая предоставляется по адресу http://msdn.microsoft.com/library/en-us/dnactdir/html/schemadoc.asp. Эта малоизвестная программа совместима с серверами Windows 2003 и Windows 2000. Она считывает расширение схемы и сохраняет его в файле .xml; затем расширение можно просмотреть в любом редакторе XML.
Правила и ограничения
В зависимости от версии и режима AD, на отключаемые типы объектов AD накладываются различные ограничения. Независимо от версии и режима AD, действительны следующие условия.
- Microsoft не поддерживает удаление объектов classSchema или attributeSchema, которые были добавлены в контекст именования схемы.
- Нельзя отключить объекты classSchema категории 1 или объект attributeSchema. (Более подробную информацию о категориях объектов схемы можно найти в статье «Займемся схемами AD».)
- Нельзя отключить объект attributeSchema, который составляет часть активного объекта classSchema.
- Можно отключить объект classSchema или attributeSchema, присвоив его атрибуту IsDefunct значение True.
- Если атрибуту IsDefunct объекта classSchema или attributeSchema присвоено значение True, то создать новый экземпляр этого объекта нельзя. Однако существующие экземпляры объекта остаются нетронутыми. Отключенный объект attributeSchema для существующих экземпляров невидим.
Другие ограничения в среде Windows 2000
Некоторые ограничения в средах Windows 2000 существуют независимо от того, какой режим применяется в организации — однородный или смешанный. Поэтому для деактивизации объекта необходимо учесть следующие факторы.
- Для повторного использования атрибута lDAPDisplayName или атрибута, который выбран для деактивизации, нужно изменить атрибут lDAPDisplayName прежде, чем атрибуту IsDefunct будет присвоено значение True. Кроме того, изменять атрибут lDAPDisplayName можно только на определяемых пользователем объектах схемы, которые относятся к категории 2.
- Даже если можно повторно задействовать атрибут lDAPDisplayName, следует иметь в виду, что нельзя повторно использовать OID объекта. Это досадное ограничение причиняет неудобства, если необходимо воссоздать стандартное расширение схемы, например определенное в Request for Comments (RFC) группы Internet Engineering Task Force (IETF). Поскольку номер OID воссозданного расширения должен отличаться от номера исходного расширения, воссозданное расширение, конечно, не отражает OID стандартного расширения, как определено в документе RFC. Однако большинство приложений обращаются к классам и атрибутам по их имени lDAPDisplayName, и разночтения не вызовут проблем, за исключением тех случаев, когда требуется обеспечить строгое соответствие документу RFC или совместимое со службой каталога приложение обращается к классам и атрибутам по OID. Перед отключением я рекомендую связаться с поставщиком или разработчиком расширений, в которых используется такой метод обращения к классам и атрибутам.
- Повторно задействовать атрибут cn нельзя, так как невозможно переименовать объект схемы. Поэтому, чтобы воссоздать расширение схемы, classSchema и attributeSchema должны использовать иной cn. Полезный прием при построении объектов схемы — добавить к концу имени порядковый номер (например, cn=DF-HR-Badge-Number-01). Совместимые со службой каталога приложения используют lDAPDisplayName вместо атрибута cn, в результате открывается возможность воссоздать объект схемы на базе соглашения о контексте именования cn, что особенно полезно в тестовой среде.
Новые возможности Windows 2003
Если служба AD работает на функциональном уровне леса Windows Server 2003, то она обеспечивает следующие возможности деактивизации расширений схемы.
- Повторное использование атрибута lDAPDisplayName при условии, что предварительно отключен объект classSchema или attributeSchema, который задействует этот lDAPDisplayName (то есть атрибуту IsDefunct объекта присвоено значение True). Не обязательно предварительно изменять lDAPDisplayName, как в Windows 2000. Остальные условия для деактивизации объекта схемы в Windows 2000 действительны и в Windows 2003.
- Точно так же можно повторно использовать OID, при условии что предварительно отключен объект classSchema или attributeSchema с таким же OID (IsDefunct имеет значение True). И вновь остальные условия для деактивизации объекта схемы в Windows 2000 действительны и для Windows 2003.
* Cn можно повторно задействовать при условии, что сначала будет переименован объект classSchema или attributeSchema, который использует такой же cn. Кроме того, можно переименовать объекты cn схемы. В этом контексте не обязательно добавлять к имени порядковый номер, если требуется многократно воссоздавать расширение.
Деактивизация расширения
Отключить расширение схемы вручную можно с помощью ADSI Edit или оснастки Active Directory Schema, но, чтобы продемонстрировать последовательность действий, я создал сценарий под названием DeactivateMyCompanyUserAttributes.vbs (его можно загрузить на нашем сайте InstantDoc ID 41666). Данный сценарий деактивизирует тестовое расширение, которое добавляет вспомогательный объект classSchema с именем dF-HR-EmployeeBadge с факультативным объектом attributeSchema (dF-HR-BadgeNumber) к структурному классу user (экран 1). Более подробно об этом тестовом расширении и процессе его создания рассказано в статье «Расширение схемы AD». В сценарии предполагается, что AD работает на функциональном уровне леса Windows Server 2003. Сценарий необходимо запускать на компьютере — мастере схемы. Этот сценарий можно изменить для работы в конкретной среде или использовать ADSI Edit и выполнить необходимые операции в том же порядке, что и в сценарии.
Исходный текст в листинге 1 объявляет константы, которые определяют отключаемые объекты classSchema и attributeSchema. Затем производится деактивизация с помощью базовых операций Active Directory Service Interfaces (ADSI). В листинге 2 показано, как считывается путь схемы. В листинге 3 из атрибута auxiliaryClass структурного класса user удаляется вспомогательный класс classSchema. В листинге 4 показано, как удалить объект attributeSchema из атрибута mayContain вспомогательного класса classSchema. Следует обратить внимание, что в рассматриваемом примере данный этап необязателен: можно было просто деактивизировать вспомогательный класс classSchema, не удаляя объект attributeSchema из объекта classSchema. Однако я разделил эти два объекта схемы, чтобы продемонстрировать процесс, который позволяет деактивизировать атрибут, но продолжать использовать вспомогательный класс (например, для другого набора атрибутов). Поэтому можно отключить объект classSchema, содержащий активные объекты attributeSchema, но нельзя деактивизировать объект attributeSchema, который является частью активного объекта classSchema. В такой ситуации необходимо удалить объект attributeSchema из вспомогательного класса.
В листинге 5 показано, как переименовать вспомогательный класс classSchema, присвоив ему уникальное имя. Имя состоит из текущей даты и времени в переменной strDateTime, инициализированной в начале листинга 5. Уникальное имя может пригодиться, только если требуется воссоздать расширение схемы, а затем деактивизировать это новое расширение. Это редко случается в производственных средах, но типично для лабораторий, в которых испытываются различные версии одного расширения схемы.
В листинге 6 показано, как деактивизировать вспомогательный класс classSchema. Исходный текст листинга 7 удаляет объект attributeSchema из индексов AD и каталогов Global Catalog (GC).
Исходный текст в листинге 8присваивает объекту attributeSchema уникальное имя (полученное с помощью переменной strDateTime). В листинге 9 объект attributeSchema деактивизируется. Исходный текст листинга 10 обновляет кэш схемы, чтобы изменения вступили в силу. Нужно иметь в виду, что должна быть выполнена репликация данных с DC мастера схемы на все другие контроллеры леса.
К деактивизации готов!
На функциональном уровне леса Windows Server 2003 исключается большинство ограничений, ранее накладывавшихся на изменения в схеме AD. Однако эффективное удаление объектов classSchema и attributeSchema, добавленных в контекст именования схемы, по-прежнему остается сложной задачей и производителем не поддерживается. Как и создание расширений схемы, их отключение требует продуманного планирования.
Зачем отключать?
Существуют три основные причины для деактивизации расширения схемы Active Directory (AD). Каждой ситуации соответствует определенный уровень сложности.
Во-первых, расширение можно отключить просто потому, что оно более не требуется. Этот случай — самый простой, так как в будущем классы и атрибуты нетрудно активизировать повторно.
Во-вторых, расширение схемы можно деактивизировать потому, что оно не отвечает требованиям приложения и нужно обновить некоторые классы и атрибуты, определенные исходным расширением. Сложность этой задачи зависит от типа необходимых изменений, так как определенные ограничения налагаются на информацию, которую можно использовать для создания и модернизации объекта classSchema или attributeSchema, как объясняется в тексте основной статьи.
В-третьих, иногда приходится отключать неудачно спроектированное расширение схемы, и в таком случае, вероятно, придется восстановить некоторые классы и атрибуты, определенные в первоначальном расширении. Эта ситуация — самая сложная из трех, так как в зависимости от версии AD (Windows Server 2003 или Windows 2000 Server) и функционального уровня леса (например, смешанный Windows 2003 и Windows 2000; все DC Windows 2003) не всегда удается повторно задействовать часть информации (например, Object Identifier — OID, lDAPDisplayName), которая использовалась при создании расширения. Некоторые особенности Windows 2003, такие как возможность деактивизировать расширение схемы, требуют, чтобы все серверы внутри леса работали в определенном режиме. Механизм Behavior Version Management системы Windows 2003 определяет поведение AD в зависимости от версии и функционального уровня домена или леса AD.
Алан Лессо (alain.lissoir@hp.com)- член группы Technology Leadership Group, входящей в состав подразделения HP Consulting and Integration. Автор книг Understanding WMI Scripting и Leveraging WMI Scripting (Digital Press).