Во многих книгах и статьях, посвященных схеме Active Directory, — даже в тех, что подготовлены специалистами Microsoft, — утверждается, будто удаление классов или атрибутов из схемы AD недопустимо. Это создает проблемы для администраторов AD, поскольку в подобных условиях тестировать новые расширения схемы сложно, а удаление ненужных расширений и вовсе оказывается невозможным. Допустим, требуется проверить процесс расширения схемы в тестовом лесу. Понятно, что в случае возникновения ошибки в ходе испытаний процедуру потребуется повторить. Но удаление расширений не допускается, и остается только вновь формировать лес. Или другая ситуация: добавляется расширение в имеющийся лес, но оно оказывается неправильным. Взять бы и попросту удалить это расширение — но нет, такая возможность не предусмотрена.

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

Небольшое вступление

Схема AD определяет порядок, в соответствии с которым служба каталога AD представляет и структурирует данные. Знать основы функционирования схемы должен каждый администратор. Более полное представление о схеме можно получить, прочитав статьи «Diving into the AD Schema» September 2001, http://www.winnetmag.com, InstantDoc ID 21839, и «Extending the AD Schema» November 2001, http://www.winnetmag.com, InstantDoc ID 22540.

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

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

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

Так, удаление класса при сохранении его объектов может привести к рассогласованию данных или к возникновению ситуации, когда существуют объекты класса, не имеющего определения. Конечно, реализованная в службе AD распределенная архитектура репликации — вещь полезная, но она осложняет осуществление надежного процесса удаления расширений схемы. Администратор не может гарантировать, что данный объект не использует тот или иной класс или атрибут, до тех пор пока объект не будет удален. А ведь после удаления класса или атрибута с контроллера домена (domain controller, DC) какое-то время уходит на то, чтобы оповещение об удалении поступило на другие контроллеры доменов. И за это время одно из приложений вполне может создать на не извещенном об удалении контроллере домена объект на основе данного класса или с использованием данного атрибута.

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

Зачем удалять расширения схемы

Может возникнуть вопрос: а зачем тогда вообще ставить вопрос об удалении элементов схемы — ведь их можно просто сделать недоступными? Назовем две основные причины. Удаление элементов схемы может потребоваться, во-первых, для тестирования новых расширений схемы, а во-вторых, для удаления неиспользуемых классов и атрибутов.

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

Есть и третья причина, побуждающая ставить вопрос об удалении элементов схемы AD: так можно избавляться от расширений, созданных приложениями, которые уже выведены из эксплуатации. На очень многих предприятиях по разным причинам одни приложения устанавливаются, а другие ликвидируются. Почти наверняка прикладная программа, для которой ранее расширили схему, когда-нибудь будет выведена из эксплуатации. Удаление элементов схемы позволяет устранить все следы существования этой программы, сохранившиеся в среде AD. Со временем число «осиротевших» классов и атрибутов будет только расти, так что необходимость избавления схемы от балласта станет еще более очевидной.

Меры предосторожности

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

  • Удаляйте только те объекты схемы, которые созданными объектами не используются. В среде AD, особенно в сетях с множеством контроллеров доменов, нет возможности гарантировать, что тот или иной класс или атрибут не применяется. Для формирования запросов к одному или нескольким контроллерам доменов администратор может воспользоваться таким средством, как Ldp (оно входит в набор Windows 2000 Support Tools kit). В большинстве случаев Ldp позволяет определить, используют ли объекты данный класс или атрибут. Программа не сможет выполнить эту задачу лишь в том случае, если некое приложение создало объект, использующий данный класс или атрибут, но сам объект еще не был реплицирован на контроллер домена, к которому направлен соответствующий запрос Ldp. В данной ситуации рекомендуется организовать форсированное тиражирование с помощью средств Replmon или Repadmin (они тоже входят в комплект Support Tools).
  • Не удаляйте объекты схемы из базовой схемы AD. В принципе это возможно, однако надо иметь в виду, что удаление стандартных классов или атрибутов может обернуться нарушениями в функционировании службы AD. При этом не исключено, что приложения (например, Microsoft Exchange 2000 Server) будут вести себя неожиданным образом. Разработчики Microsoft и многие поставщики программного обеспечения исходят из того, что стандартные элементы схемы AD будут всегда присутствовать в системе, и программные средства часто пытаются организовать как хранение данных, так и запросы на их получение с использованием существующих объектов схемы.
  • Операции по удалению проводите только в тестовых лесах, а также в лесах, выделенных для группы разработки. Процедура удаления объектов схемы пока еще исследована мало. Кроме того, учитывая, что Microsoft не дает санкции на эту операцию, не стоит предпринимать попытки удаления в имеющемся лесу, не проведя предварительно всесторонние испытания и не получив четкого представления о последствиях возможного нарушения целостности схемы.
  • После удаления ненужных объектов схемы сделайте недоступной функцию удаления элементов схемы. Всегда полезно отключать функцию модернизации, когда нет необходимости в изменении схемы. Точно так же следует признать удачной идею блокировать возможность удаления элементов схемы, когда не нужно удалять из нее объекты. Это позволит исключить возможность случайных изменений.
  • Необходимо помнить о том, что, если вследствие удаления класса или атрибута возникнет какая-либо проблема, специалисты Microsoft, возможно, не станут оказывать помощь, ибо удаление элементов схемы не документировано, и в программном обеспечении соответствующая возможность не предусмотрена. Мало того, представители Microsoft почти наверняка будут утверждать, что удаление элементов схемы попросту невозможно.

Удаление объектов схемы

Подготовка схемы к удалению не вызывает затруднений. Процесс состоит из двух этапов. Сначала нужно модифицировать список управления доступом (access control list, ACL) контейнера Schema (cn=Schema, cn=Configuration, ForestDN, где ForestDN — это составное имя — distinguished name, DN — леса). Таким образом, будет получено разрешение на удаление объектов-потомков. Далее нужно включить функцию модификации схемы.

Экран 1. Использование ADSI Edit.

Модификация списка управления доступом. Для внесения изменений в список управления доступом члены группы Schema Admins могут воспользоваться оснасткой ADSI Edit консоли Microsoft Management Console (MMC). По умолчанию члены групп Enterprise Admins и Domain Admins необходимыми правами на внесение изменений в контейнер Schema не наделяются.

В окне оснастки ADSI Edit следует добавить запись для контейнера Schema, который требуется редактировать в данном лесу (если, конечно, такой записи пока нет). Необходимо раскрыть запись для контейнера Schema и щелкнуть правой кнопкой мыши на папке с составным именем контейнера Schema, как показано на Экране 1. Затем следует щелкнуть на элементе Properties и на закладке Security и выбрать группу, членам которой нужно предоставить право удалять элементы схемы (например, Schema Admins). После этого в разделе Permissions требуется установить флажок Allow для пункта Delete All Child Objects, как показано на Экране 2.

Экран 2. Установка разрешений на удаление из схемы.

Теперь при щелчке на кнопке OK членам соответствующей группы будет предоставлено право на удаление элементов схемы. Для выполнения этой процедуры можно также использовать оснастку Schema консоли MMC. При необходимости процедуру можно даже автоматизировать с помощью утилиты Dsacl (поставляемой в комплекте Support Tools kit).

Включение функции обновления схемы. Любые модификации схемы, в том числе удаление ее объектов, могут осуществляться лишь на контроллерах доменов, наделенных ролью мастера схемы, и только после того, как в реестр данного контроллера домена будут внесены изменения, обеспечивающие функцию модификации схемы. Значение параметра Schema Update Allowed (типа REG_DWORD) из подраздела реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesNTDSParameters должно быть установлено равным 1. Для изменения этого значения можно воспользоваться редактором реестра или установить флажок Allow Schema Updates в оснастке Schema.

Удалять объекты схемы можно несколькими способами. Например, имеется возможность делать это напрямую, с помощью инструментов ADSI Edit или Ldp, как удаляются объекты любого другого типа. Однако нужно иметь в виду, что существуют ограничения, как по объектам, разрешенным к удалению, так и по порядку удаления. К примеру, не допускается удаление атрибута, если он определен как часть принадлежащего классу атрибута mayContain или mustContain; кроме того, нельзя удалить класс, если он определен в качестве части принадлежащего другому классу атрибута subClassOf.

Как это делается

Возможно, достоинства функции удаления элементов схемы ярче всего проявляются в процессе тестирования или разработки расширений схемы в тестовом лесу. Бывает, что для тестирования расширений администратору приходится расширять схему вновь и вновь. Для создания расширений схемы я рекомендую использовать файлы формата LDAP Data Interchange Format (LDIF). Формат описан в документе Request for Comments (RFC) 2849, который был подготовлен комитетом IETF (Internet Engineering Task Force). Файлы LDIF удобны для чтения и имеют оптимальный формат. Применяя файлы LDIF для модификации схемы, можно получить простое средство отслеживания изменений в схеме, которое удобно хранить и архивировать. В Листинге 1 представлен простой LDIF-файл с именем add.ldf. Файл создает новый вспомогательный класс (xyz-ITUser) и два атрибута (xyz-ITDeptName и xyz-ITBldg-Name). С помощью класса xyz-ITUser можно расширить класс user так, чтобы он содержал два новых атрибута. Этот подход широко используется для расширения существующих классов объектов, таких, как user.

Код в метках A и B Листинга 1 создает атрибуты xyz-ITBldgName и xyz-ITDeptName, соответственно. Строки в метке C Листинга 1 модифицируют кэш схемы. Подобная модификация кэша необходима для того, чтобы атрибуты xyz-ITBldgName и xyz-ITDeptName могли быть описаны в метке D Листинга 1 как часть класса xyz-ITUser. В оставшейся части файла модифицируется кэш схемы; таким образом, внесенные в новый класс изменения фиксируются незамедлительно.

Для импорта и экспорта файлов LDIF можно использовать утилиту Ldifde, которая устанавливается на любой машине Windows 2000. Для импорта расширений схемы, проделанных в Листинге 1, нужно ввести следующую команду:

ldifde -i -v -f add.ldf

Ключ -i включает режим импорта, ключ -v (verbose) обеспечивает расширенный вывод, а ключ -f указывает имя LDIF-файла, который надлежит импортировать. Чтобы провести аналогичный тест в условиях конкретной сети, следует заменить все выражения DC=xyz,DC=com в Листинге 1 составным именем леса, где будет проводиться испытание. Если утилита Ldifde выполняется в сети на не наделенном ролью мастера схемы контроллере домена, нужно будет использовать ключ -s для указания имени такого контроллера.

Теперь, когда имеется файл LDIF, обеспечивающий добавление расширений схемы, можно приступать к созданию еще одного файла LDIF — delete.ldf, — содержащего команды на удаление данных расширений. В Листинге 2 содержится код в формате LDIF, обеспечивающий удаление класса и атрибутов, созданных с помощью кода, представленного в Листинге 1. Вследствие ограничений на удаление, о которых говорилось ранее, прежде всего, следует удалять класс xyz-ITUser, описанный в метке A Листинга 2, и только после этого — атрибуты, описанные в метках B и C Листинга 2. Опять-таки можно использовать утилиту Ldifde для выполнения файла LDIF на контроллере домена и удалить указанные расширения схемы:

ldifde -i -v -f delete.ldf

Так же, как и в уже рассмотренном случае с Листингом 1, потребуется заменить все встречающиеся в Листинге 2 выражения DC=xyz,DC=com составным именем леса, в котором проводится тестирование.

Разумеется, операции по добавлению, модификации или удалению расширений схемы производятся не только с помощью файлов LDIF. Все эти действия можно выполнять вручную, используя утилиту ADSI Edit, или программным путем, с помощью Perl, VBScript и других языков.

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

Робби Ален — системный архитектор и программист в ИТ- департаменте Cisco Systems. Соавтор книги «Managing Enterprise Active Directory Services» (Addison-Wesley). С ним можно связаться по адресу: rallen@cisco.com.