Schema master — Хозяин схемы Active Directory. Обновление схемы Active Directory

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

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

Active Directory допускает использование в рамках одной организации несколько контроллеров домена, построенных на базе разных версий ОС Windows. А именно на базе Windows Server 2000, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008. Поскольку данные версии выпускались в разные годы, и каждая новая версия несет больший функционал, чем предыдущая, понимание схемы у каждой операционной системы свое. Поэтому при добавлении нового контроллера на базе Windows Server 2008 в организацию, где существующие контроллеры построены на Windows Server 2003, вам приходилось запускать утилиту «Adprep ». Тем самым вы обновляли схему вашей организации до того уровня, с которым работает Windows Server 2008.

Процесс обновления схемы выполнялся до установки первого контроллера Windows Server 2008 и собственно сама процедура установки нового контроллера, могла и не выполняться. Если вы только начинаете работать с какой-то организацией Active Directory и не знаете, какие действия осуществлялись до вашего прихода, вам для понимания полноты структуры, будет нужно знать, на каком уровне работает Схема текущей организации.

Возможные версии схемы:

13 - Windows 2000 Server
30 - Windows Server 2003 RTM, Windows 2003 With Service Pack 1, Windows 2003 With Service Pack 2
31 - Windows Server 2003 R2
44 - Windows Server 2008 RTM

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

Посмотреть версию схемы можно несколькими способами, самым простым является способ с использованием утилиты «DSQuery». Для этого в командной строке необходимо ввести команду со следующими параметрами:

“dsquery * cn=schema,cn=configuration,dc=domainname,dc=local -scope base -attr objectVersion”

Естественно в части «dc=domainname,dc=local» вы должны подставить имя собственного домена. (Пример: dc=microsoft,dc=com )

Результатом ввода команды является получение атрибута «ObjectVersion », который и будет являться номером версии схемы:

Рис. 1 Получение версии схемы через утилиту «DSQuery».

Второй способ более длинный и подразумевает использование оснастки «ADSIEdit.msc» . Для просмотра версии схемы вам придется подключиться к разделу Active Directory схема.

"CN=Schema,CN=Configuration,DC=domain,DC=local "

И найти значение атрибута "objectVersion ".

Рис.2 Получение версии схемы через оснастку «ADSIEdit.msc ».

Зная версию схему, вы всегда можете с уверенностью сказать нужно ли схему обновлять и если нужно то, до какого уровня.

Следует отметить, что обновления схемы могу производиться программным обеспечением тесно интегрированным с Active Directory. Самый яркий пример Microsoft Exchange Server. И зачастую в организации, планирующей внедрение Exchange Server, необходимо выяснить, была ли осуществлена подготовка схемы? И если была, то какой версией Exchange Server. На текущий момент существуют три версии Exchange, работающие с Active Directory, но вариантов модификации схемы существует шесть. Понять была ли изменена Схема Active Directory Exchange сервером можно по атрибуту «rangeUpper», который принимает следующие значения:

4397 - Exchange Server 2000 RTM
4406 - Exchange Server 2000 With Service Pack 3
6870 - Exchange Server 2003 RTM
6936 - Exchange Server 2003 With Service Pack 3
10628 - Exchange Server 2007
11116 - Exchange 2007 With Service Pack 1

Как можно заметить обновление схемы происходит и при установке набора обновлений SP3 для Exchange Server 2000/2003 и SP1 для Exchange 2007.

Посмотреть значение атрибута «rangeUpper» можно через утилиту DSQuery:

"dsquery * CN=ms-Exch-Schema-Version-Pt,cn=schema,cn=configuration,dc=domainname,dc=local -scope base -attr rangeUpper"

Рис. 3 Получение атрибута «rangeUpper» через утилиту DSQuery.

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

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

Материал предоставлен ресурсом

FSMO-роль хозяин схемы (Schema master) является одной из двух ролей, функционирующих на уровне леса Active Directory. То есть во всем лесе AD необходимо иметь лишь одного хозяина схемы.

Основная статья по Active Directory — . Читайте также другие статьи по ролям хозяев операций — .

Если вам интересна тематика Windows Server, рекомендую обратиться к рубрике на моем блоге.

Schema master — Хозяин схемы Active Directory

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

Теория

Поскольку хозяин схемы — роль уровня леса, то в каждом конкретном лесе AD она существует всегда в единственном экземпляре . Другими словами существует только один контроллер домена, который имеет право вносить изменения/обновления в схему, тем не менее реплика схемы присутствует на каждом контроллере домена и при необходимости роль может быть захвачена принудительно любым DC, но об этом позже. На практике изменения схемы происходят крайне редко, например при установке сервера Exchange или других приложений, которые хранят некоторые свои данные (например объекты конфигурации) в AD.

Все-таки что такое схема AD ? Это прежде всего набор объектов и их атрибутов, которые используются для хранения данных. Мало кому это определение что-то объясняет, попробую рассказать более детально на примере. Что такое объект? Например объектами являются учетные записи пользователей или компьютеров. В данном случае в схеме AD находится класс user , который определяет все атрибуты объекта учетной записи пользователя:

Каждая учетная запись пользователя в домене будет иметь все эти атрибуты. Но значения атрибутов могут быть и не заданы. Можно проверить какие атрибуты и их значения имеет моя недавно созданная учетная запись администратора домена. Чтобы это сделать, необходимо зайти в консоль adsiedit.msc и открыть контекст именования по умолчанию. В иерархии находим объект пользователя и открываем его свойства:

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

Для интереса можно посмотреть атрибуты объекта сервера Exchange 2013, ведь Exchange вносит множество новых классов в схему:

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

Лучшие практики

Схема AD имеет принципиально важное значение для работоспособности Active Directory, а потому нуждается в соответствующем администрировании, хоть и о ней в большинстве случаев просто забывают. Ниже сформулированы лучшие практики администрирования схемы.

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

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

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

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

4) Без крайней на то необходимости не выполняйте изменения схемы вручную . Если это все же нужно сделать в любом случае, см. пункт 1.

От теории плавно переходим к практике.

Администрирование схемы

Прежде всего стоит сказать, что для управления схемой необходимо иметь как минимум права Администратора Схемы (Schema Admin) . Все остальные авторизованные пользователи имеют права только на чтение, хотя в принципе разрешения можно и изменить. Большинство задач администрирования выполняются в оснастке для управления схемой Active Directory, которая недоступная по умолчанию и чтобы её активировать, необходимо зарегистрировать библиотеку schmmgmt.dll . Для этого запускаем командную строку с правами администратора и выполняем:

Visual Basic

regsvr32 schmmgmt.dll

regsvr32 schmmgmt . dll

Получаем оповещение:

После этого в консоли MMC вы сможете найти оснастку Схема Active Directory . Выполнять команду необходимо на каждом контроллере домена, на котором планируется заниматься администрированием схемы.

Допустим у вас два контроллера домена и вы хотите перенести роль хозяина схемы с DC01 на DC02:

1. Открываем оснастку на DC01, правой кнопкой нажимаем на Схема Active Directory и выбираем Сменить контроллер домена Active Directory;
2. Далее выбираем контроллер домена, на который мы хотим перенести роль (у меня это DC02, по умолчанию всегда выбирается сервер-владелец роли). Подтверждаем предупреждение;
3. Снова правой кнопкой на Схема Active Directory, но уже выбираем Хозяин операций… ;
4. Нажимаем кнопку Сменить.

После этого необходимо подтвердить выбор и получить уведомление об успешном переносе роли.

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

С момента выпуска службы Active Directory в составе Windows 2000 корпорация Майкрософт предоставила пользователям определение базовой схемы для реализации Active Directory.

Выпуск Active Directory® также обозначил изменение процесса написания множества приложений и их реализации в Windows®. До этого такие приложения, как Microsoft® Exchange 5.5, создавались с собственной структурой каталога. После появления Active Directory множество приложений (корпорации Майкрософт и других компаний) начали использовать преимущество предоставляемой базовой структуры вместо создания собственной схемы с нуля.

Первоначально использовалась предоставляемая Active Directory базовая архитектура, которая затем при необходимости расширялась. В Microsoft Exchange 2000, например, служба Active Directory использовалась для реализации систем обмена сообщениями, тем самым определяя будущее архитектуры системы обмена сообщениями Microsoft.

Сегодня работа множества приложений, созданных для работы в среде Active Directory, основывается на ее базовой схеме, во многих приложениях также определяются необходимые собственные изменения схемы. Для этого, разумеется, необходима схема с возможностью расширения, что и будет рассмотрено в данной статье. Более того, поскольку многие приложения зависят от базовых определений в Active Directory, постоянная стабильность основной схемы является исключительно важной. Так как многие приложения должны совместно работать в одной службе Active Directory, изменения одного приложения не должны воздействовать на другие приложения.

Что такое схема?

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

В качестве стратегии множество организаций используют службы Active Directory облегченного доступа к каталогу (ADLDS) в Windows Server® 2008 (или режим Active Directory Application Mode (ADAM) в Windows Server 2003) как альтернативу для тестирования или прямой реализации пользовательских определений схемы вместо расширения схемы Active Directory.

Схема – это базовая структура, предоставляющая формат для службы каталога. Схема Active Directory определяет атрибуты и классы объектов, используемые в доменных службах Active Directory (ADDS). Основная схема содержит определения для множества хорошо известных классов (таких как user, computer и organizationalUnit) и атрибутов (например, telephoneNumber и objectSID). Объекты в определении основной схемы называются объектами категории 1, а добавляемые объекты называются объектами категории 2.

Схема Active Directory находится в контейнере, определенном по пути cn=Schema, cn=Configuration,dc=X, где X – пространство имен леса Active Directory. Имейте в виду, что лес Active Directory содержит только одну схему; внесение изменений в определение схемы в лесу влияет на все домены в этом лесу. На рис. 1 показано количество классов и атрибутов, добавленных к схеме Active Directory в различных версиях Windows Server.

Количество классов и атрибутов

Обновление схемы для различных версий Windows Server осуществляется с помощью служебной программы Adprep. При обновлении до Windows Server 2003 R2 версия схемы обновляется до 31, а при обновлении до Windows Server 2008 она обновляется до 44.

Номер версии можно узнать, проверив значение атрибута objectVersion по адресу cn=Schema,cn=Configuration,dc=X в Active Directory с помощью такого средства, как ADSIEdit. Обратите внимание, что некоторые приложения, например, Exchange Server, System Management Server (SMS) и другие приложения, зависящие от Active Directory, могут изменять схему в соответствии с требованиями приложения.

Базовые составляющие

Active Directory состоит из двух типов объектов: classSchema (кратко – class) и attributeSchema (кратко – attribute). Обычно расширение схемы Active Directory рассматривается, если для организации необходимо сохранение данных в определенных атрибутах, недоступных в существующей схеме. Атрибут в схеме Directory создается путем указания объекта attributeSchema в контейнере схемы и последующим определением необходимых свойств нового объекта.

Список свойств объектов attributeSchema и сведений о них приведен на веб-узле go.microsoft.com/fwlink/?LinkId=110445 . Как видите, для объектов attributeSchema можно определить большое количество свойств, некоторые из которых являются обязательными.

Помимо обычных атрибутов в схеме также присутствуют специальные атрибуты, называемые связанными и реализуемые по парам путем указания ссылок вперед и назад. В качестве примера рассмотрим членство в группах в Active Directory. Атрибут членства любой группы (например, группы ContosoEmployees с членом John Doe) – это ссылка вперед, а соответствующий атрибут memberOf объекта члена – это ссылка назад (чтобы при запросе атрибута memberOf члена John Doe вычислялось различающееся имя (DN) группы ContosoEmployees).

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

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

Все классы объектов в ADDS определяются объектом classSchema в контейнере схемы. Список атрибутов, наиболее важных для успешного определения объекта classSchema, приведен на веб-узле go.microsoft.com/fwlink/?LinkId=110445 .

Существует три типа классов, которые могут быть определены: структурные, абстрактные и вспомогательные. Тип класса определяется значением атрибута objectClassCategory. (В четвертую категорию, известную как 88, входят классы, определенные до стандартов X.500 1993 года. Этот тип классов указывается значением 0 в атрибуте objectClassCategory. Данный тип более не должен определяться.)

Получение и использование идентификаторов

Удостоверения всех объектов classSchema и attributeSchema в каталоге определяются с помощью обязательных идентификаторов объекта (OID), governsID – для объектов classSchema и attributeID для объектов attributeSchema. Это уникальные числовые значения, предоставленные определенными центрами для идентификации объектов. Нумерация ведется в соответствие с определением протокола LDAP (RFC 2251). Некоторые идентификаторы объектов в схеме Active Directory выпускаются международной организацией по стандартизации (ISO) и корпорацией Майкрософт. Идентификатор объекта в каталоге должен быть уникальным.

Идентификатор объекта – это строка чисел, например, 1.2.840.113556.1.y.z, как показано на рис. 2 . Таким образом, идентификатор объекта пользователя classSchema – 1.2.840.113556.1.5.9.

Идентификатор объекта пользователя

Значение	Значение	Описание
1	ISO	Определяет корневой центр.
2	ANSI	Обозначение группы, присвоенное ISO.
840	США	Код страны/региона, присвоенный организацией.
113556	Майкрософт	Обозначение организации, присвоенное страной/регионом.
1	Active Directory	Присвоено организацией (в данном случае Майкрософт).
Y	Тип объекта	Число, обозначающее различные типы объекта (категории), например, classSchema или attributeSchema. Например, 5 означает класс объекта.
Z	Объект	Число, обозначающее определенный объект в категории. Например, классу пользователя может быть присвоено число 9.

Когда организация собирается расширить схему, она обеспечивает уникальность идентификатора объекта путем получения собственного корневого номера OID, используемого для создания уникальных идентификаторов новых атрибутов и классов объектов организации. Корень идентификатора объекта может быть получено непосредственно от национального управления регистрации ISO (в США – американский национальный институт стандартов (ANSI)).

Процедуру и тарифы на услуги для получения корневого идентификатора объекта можно узнать на веб-узле ansi.org. В других регионах обратитесь в соответствующую организацию-участник ISO, список которых представлен по адресу iso.org/iso/about/iso_members.htm .

Ранее организации получали идентификатор объекта от корпорации Майкрософт путем отправки сообщения электронной почты по адресу [email protected] . Однако сейчас это приводит к получению автоматического ответа с предложением загрузить и выполнить сценарий VBScript с веб-узла go.microsoft.com/fwlink/?LinkId=110453 .

Идентификаторам объектов, выпущенных корпорацией Майкрософт, присваиваются номера числового пространства идентификаторов объектов Microsoft: 1.2.840.113556.1.8000.x, где x – уникальный номер, присвоенный организации. Организация может разделить эти идентификаторы для указания объектов. Так, можно использовать 1.2.840.113556.1.8000.x.1.y для новых объектов classSchema и 1.2.840.113556.1.8000.x.2.z для объектов attributeSchema (где x – уникальный номер организации, а y и z - номера, присвоенные определенным объектам classSchema и attributeSchema соответственно). Кроме того, в целях различения в именах этих объектов рекомендуется использовать уникальный префикс организации.

Определение связанных атрибутов

Значение attributeSyntax ссылки назад должно быть 2.5.5.1, что является синтаксисом Object (DS-DN). Обычно атрибуты ссылки назад добавляются к значению mayContain класса с наибольшей абстракцией. Это обеспечивает чтение атрибута ссылки назад из объектов любых классов, поскольку такие атрибуты не сохраняются в объекте, а вычисляются на основе значений ссылки вперед.

В Windows Server 2003 появилась функция, которую могут использовать организации для связывания двух объектов в схеме: автоматическое создание идентификаторов linkID. Эта функция обеспечивает автоматическое создание идентификатора linkID для нового связанного атрибута, если для linkID атрибута установлено значение 1.2.840.113556.1.2.50. Соответствующая ссылка назад создается путем установки для linkID значения attributeId или ldapDisplayName ссылки вперед. Кэш схемы должен быть перезагружен после создания ссылки вперед и до создания ссылки назад. В противном случае при создании ссылки назад не будут найден атрибут attributeId или ldapDisplayName. Кэш схемы перезагружается по запросу через несколько минут после изменения схемы или при перезагрузке контроллера домена.

Если служба Active Directory работатет на уровне Windows 2000, необходимо запросить идентификаторы linkID от корпорации Майкрософт, отправив сообщение электронной почты по адресу [email protected] . В автоматическом ответе будет следующая строка: "E-mails sent to [email protected] will be processed only if they are related to linkID registrations for legacy environments." (Сообщения электронной почты, отправленные по адресу [email protected] , будут обработаны только в том случае, если относятся к регистрации идентификаторов linkID для устаревших сред.). Для этого необходимо указать в сообщении электронной почты следующие сведения: название компании, имя контактного лица, адрес электронной почты, номер телефона, зарегистрированный префикс (при необходимости), зарегистрированный идентификатор объекта (при необходимости).

Можно приступать к расширению схемы

Предположим, вы решили расширить схему Active Directory. Решение может предполагать прекращение использования альтернативного каталога, реализованного с помощью служб ADLDS (или ADAM в Windows Server 2003), после подтверждения того, что он не будет соответствовать требованиям. Следующим этапом является определение новых объектов attributeSchema, которые необходимо добавить к схеме; при этом определяются все необходимые значения (такие как cn, ldapDisplayName и т.д.), указывающие эти новые объекты. При определении значений атрибутов для объекта также получен идентификатор объекта от корпорации Майкрософт или из другого источника. Указанные выше действия задокументированы в качестве бизнес-требований и технических спецификаций. Более того, реализована экспериментальная лабораторная среда, имитирующая работу Active Directory и готовая к тестированию.

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

После того, как организация решает приступить к осуществлению проекта, необходимо определить планы тестирования и реализации проекта. Можно расширить схему путем добавления новых объектов с помощью оснастки схемы Active Directory консоли управления Microsoft (MMC) или используя программные или полупрограммные способы (например, использование LDIFDE для импорта файлов LDIF; использование CSVDE для импорта файлов CSV; или использование сценариев для интерфейсов ADSI).

Независимо от выбранного метода эта функция должна быть выполнена на сервере, который имеет роль FSMO (Flexible Single Master Operations) хозяина схемы в лесе Active Directory или подключен к ней. Кроме того, учетной записи, используемой для обновления схемы, необходимы достаточные права администратора для выполнения обновления, поэтому ее необходимо включить в группу администраторов схемы. Наконец, необходимо разрешить обновление схемы для леса (по умолчанию отключено).

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

Добавление атрибутов

Для наших рассуждений предположим, что организации с названием Contoso необходимо добавить в службу Active Directory атрибут, определяющий размер обуви всех сотрудников. В лесу Active Directory два домена: contoso.com и employees.contoso.com. Необходимо, чтобы все объекты, созданные с помощью определения класса пользователя, также содержали этот новый атрибут.

Важно помнить, что изменение схемы влияет на оба домена, поскольку они находятся в одном лесе. Предположим, от корпорации Майкрософт получен идентификатор объекта 1.2.840.113556.8000.9999, который разделяется на 1.2.840.113556.8000.9999.1 для объекта classSchema и 1.2.840.113556.8000.9999.2 для attributeSchema компании Contoso. Теперь необходимо определить все значения атрибутов для этого нового объекта, как показано на рис. 3 .

Определение атрибута contosoEmpShoe

Атрибут	Значение	Примечания
Cn	contosoEmpShoe
lDAPDisplayName	contosoEmpShoe
adminDisplayName	contosoEmpShoe
attributeSyntax	2.5.5.12	Определяет строку в юникоде.
oMSyntax	64	Указывает строку в юникоде.
objectClass	top, attributeSchema
attributeID	1.2.840.113556.8000.9999.2.1	Определено организацией.
isSingleValued	TRUE	Сохраняется только одно значение размера обуви.
searchFlags	1	Анализ показывает необходимость индексирования этого атрибута. Примечание. Будет выполнен анализ нагрузки в лабораторной среде.
isMemberOfPartialAttributeSet	TRUE	Этот атрибут должен быть доступен в глобальном каталоге.

Кроме того, хотя атрибут contosoEmpShoe должен быть доступным для всех объектов, созданных в качестве объектов класса пользователя, не рекомендуется изменять определение класса пользователя по умолчанию. Вместо этого следует определить вспомогательный класс contosoUser, для атрибута mayContain которого установлено значение contosoEmpShoe, как показано на рис. 4 . После этого необходимо добавить к классу пользователя атрибуты, определенные для вспомогательного класса contosoUser.

Определение класса contosoUser

Теперь, когда выполнен анализ и определены значения, необходимо создать файл LDIF, который будет выглядеть примерно как код на рис. 5 . Можно скопировать код на рис. 5 в блокнот и сохранить файл под именем contosoUser.ldif (включен в материалы для загрузки по адресу technetmagazine.com).

Файл LDIF для расширения схемы

#Attribute definition for contosoEmpShoe dn: CN=contosoEmpShoe,CN=Schema,CN=Configuration,DC=X changetype: ntdsschemaadd objectClass: top objectClass: attributeSchema cn: contosoEmpShoe attributeID: 1.2.840.113556.1.8000.9999.2.1 attributeSyntax: 2.5.5.12 isSingleValued: TRUE adminDisplayName: contosoEmpShoe adminDescription: contosoEmpShoe oMSyntax: 64 searchFlags: 1 lDAPDisplayName: contosoEmpShoe systemOnly: FALSE dn: changetype: modify add: schemaUpdateNow schemaUpdateNow: 1 - # Classes dn: CN=contosoUser,CN=Schema,CN=Configuration,DC=X changetype: ntdsschemaadd objectClass: top objectClass: classSchema cn: contosoUser governsID: 1.2.840.113556.1.8000.9999.1.1 mayContain: contosoEmpShoe rDNAttID: cn adminDisplayName: contosoUser adminDescription: contosoUser objectClassCategory: 3 lDAPDisplayName: contosoUser name: contosoUser systemOnly: FALSE dn: changetype: modify add: schemaUpdateNow schemaUpdateNow: 1 - dn: CN=User,CN=Schema,CN=Configuration,DC=X changetype: ntdsschemamodify add: auxiliaryClass auxiliaryClass: contosoUser - dn: changetype: modify add: schemaUpdateNow schemaUpdateNow: 1

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

Ldifde –i –f \contosoUser.ldif –b -k –j. –c "CN=schema,CN=Configuration,DC=X" #schemaNamingContext

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

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

Для проверки изменений откройте оснастку «Active Directory – пользователи и компьютеры», подключитесь к домену employees.contoso.com, выберите организационное подразделение пользователей и создайте новую учетную запись пользователя с именем ContosoTestUser. Теперь откройте консоль adsiedit.msc и подключитесь к разделу домена dc=employees,dc=contoso,dc=com, разверните подразделение Users, правой кнопкой мыши щелкните ContosoTestUser, затем откройте страницу Properties (Свойства). Найдите атрибут contosoEmpShoe. Можно изменить этот атрибут, чтобы ввести значение. Также можно использовать служебную программу Ldp.exe для проверки и изменения атрибутов.

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

Конечно, сначала вы проделаете анализ, сходный с тем, который я упоминал в предыдущем примере. Однако сейчас пойдем дальше и создадим файлы LDIF (linkids1.ldif и linkids2.ldif), как показано на рис. 6 . Затем выполним следующую команду, чтобы импортировать файлы LDIF:

Файлы LDIF ссылок вперед и назад

#linkids1.ldif #Attribute definition for Forward Link Attribute dn: CN=ContosoShoeSizeTaker,CN=Schema,CN=Configuration,DC=X changetype: ntdsschemaadd objectClass: top objectClass: attributeSchema cn: ContosoShoeSizeTaker attributeID: 1.2.840.113556.1.8000.9999.2.2 LinkID: 1.2.840.113556.1.2.50 attributeSyntax: 2.5.5.1 isSingleValued: TRUE adminDisplayName: ContosoShoeSizeTaker adminDescription: ContosoShoeSizeTaker oMSyntax: 64 searchFlags: 1 lDAPDisplayName: ContosoShoeSizeTaker systemOnly: FALSE dn: changetype: modify add: schemaUpdateNow schemaUpdateNow: 1 - #Reload schema #linkids2.ldif #Attribute definition for Backward Link Attribute dn: CN=ContosoShoeSizesTakenByMe,CN=Schema,CN=Configuration,DC=X changetype: ntdsschemaadd objectClass: top objectClass: attributeSchema cn: ContosoShoeSizesTakenByMe attributeID: 1.2.840.113556.1.8000.9999.2.3 LinkID: 1.2.840.113556.8000.9999.2.2 attributeSyntax: 2.5.5.1 isSingleValued: FALSE adminDisplayName: ContosoShoeSizesTakenByMe adminDescription: ContosoShoeSizesTakenByMe oMSyntax: 64 searchFlags: 1 lDAPDisplayName: ContosoShoeSizesTakenByMe systemOnly: FALSE dn: changetype: modify add: schemaUpdateNow schemaUpdateNow: 1 - #Add ContosoShoeSizeTaker and ContosoShoeSizesTakenByMe Attribute as MayContain in #contosoUser class dn: CN= contosoUser,CN=Schema,CN=Configuration,DC=X changetype: ntdsschemamodify add: mayContain mayContain: ContosoShoeSizeTaker mayContain: ContosoShoeSizesTakenByMe dn: changetype: modify add: schemaUpdateNow schemaUpdateNow: 1 - #Add Backward Link Attribute as MayContain in Top dn: CN=Top,CN=Schema,CN=Configuration,DC=X changetype: ntdsschemamodify add: mayContain mayContain: ContosoShoeSizesTakenByMe dn: changetype: modify add: schemaUpdateNow schemaUpdateNow: 1 ldifde –i –f \linkedids.ldif –b -k –j. –c "CN=schema,CN=Configuration,DC=X" #schemaNamingContext

Теперь при создании объекта пользователя он также будет иметь атрибуты ContosoShoeSizeTaker и ContosoShoeSizesTakenByMe. При создании объекта пользователя, например, для Джона, атрибут ContosoShoeSizeTaker заполняется различающимся именем лица, измерившего размер обуви, – Фрэнка. Если теперь перейти к свойствам объекта пользователя Фрэнка и запросить атрибут ContosoShoeSizesTakenByMe, результат будет содержать различающееся имя Фрэнка и других лиц, чей размер обуви Фрэнк измерил. В завершение нашего случая руководство может вознаградить Фрэнка на основе количества различающихся имен, существующих в атрибуте ContosoShoeSizesTakenByMe его учетной записи пользователя.

Система сдержек и противовесов

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

Прежде всего, значение governsID для каждого класса должно быть уникальным в схеме. При определении объекта schemaClass все атрибуты, определенные в списках systemMayContain, mayContain, systemMustContain и mustContain, уже должны существовать. Одновременно с этим все классы, определенные в списках subClassOf, systemAuxiliaryClass, auxiliaryClass, systemPossSuperiors и possSuperiors, тоже уже должны существовать.

Кроме того, атрибут objectClassCategory всех классов в списках systemAuxiliaryClass и auxiliaryClass должен быть классом 88 или вспомогательным классом. Аналогично, атрибут objectClassCategory всех классов в списках systemPossSuperiors и possSuperiors должен быть определен как класс 88 или структурный класс.

При определении различных классов абстрактные классы могут быть порождены только от других абстрактных классов, вспомогательные классы не могут быть порождены от структурных, а структурные классы не могут быть порождены от вспомогательных классов. Кроме того, указанный в rDNAttID атрибут должен быть однозначным и иметь синтаксис в виде строки юникода.

Эти некоторые из правил, относящихся к объектам classSchema. Как насчет правил для объектов attributeSchema? Как и значение governsID для классов, значение attributeID должно быть уникальным. Кроме того, должно быть уникальным и значение mAPIID (если таковое имеется). Далее, если присутствуют rangeLower и rangeUpper, значение rangeLower должно быть меньше значения rangeUpper. Значения attributeSyntax и oMSyntax должны совпадать. Если синтаксис атрибута является объектным (oMSyntax =127), он должен иметь верный oMObjectClass. Идентификатор linkID, если таковой имеется, должен быть уникальным. Кроме того, ссылка назад должна иметь соответствующую ссылку вперед.

Что, если произошла ошибка?

После расширения схемы и добавления к ней новых объектов (классы и атрибуты) они не могут быть удалены. Однако классы и атрибуты могут быть деактивированы путем установки для атрибута isDefunct объекта схемы значения TRUE. Деактивация объектов схемы, которые входят в состав схемы по умолчанию, поставляемой вместе с Active Directory (объекты категории 1), невозможна. Деактивировать можно только объекты, добавленные к схеме по умолчанию, т.е. объекты категории 2, и только после проверки того, что класс не используется в списках subClassOf, auxiliaryClass или possSuperiors какого-либо существующего действующего класса.

При попытке отключения любого атрибута Active Directory проверяет, не используется ли он в списках mustContain и mayContain какого-либо существующего действующего класса. Отключенные объекты могут быть снова включены путем установки для атрибута isDefunct значения FALSE. Если Active Directory работает на уровне Windows Server 2003, можно повторно использовать значения ldapDisplayName, schemaIdGuid, OID и mapiID отключенных объектов.

Заключение.

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

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

07.04.2011 Брайан Десмонд

Так уж сложилось, что администраторы Active Directory (AD) и ИТ-менеджеры обычно опасаются расширять схему AD. В значительной степени страх порождает документация Microsoft времен Windows 2000, в которой расширение схемы представлено как сложная операция, требующая крайней осторожности. Однако при разумном планировании расширение схемы совершенно не связано с риском

Схема AD определяет структуру данных, сохраненных в каталоге. Изначально AD поддерживает много типов объектов (например, пользователи) и атрибутов (например, имя и фамилия). Если базовая схема AD плохо согласуется с данными, которые требуется хранить в каталоге, ее можно дополнить пользовательскими объектами и атрибутами.

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

Варианты хранения данных

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

Если данные не соответствуют этим критериям, но все же должны размещаться в каталоге LDAP, оптимален второй вариант. Службы каталогов AD Lightweight Directory Services (AD LDS, в прошлом ADAM) - автономная версия AD, которая может функционировать в качестве службы на сервере, члене домена (или контроллере домена - DC), и, подобно AD, обрабатывать запросы, направляемые к LDAP. Необходимость размещать контроллеры домена AD для проверки подлинности и поддержки приложений - не досадное ограничение, а возможность строго контролировать круг лиц, имеющих право читать данные, и направление репликации данных путем размещения экземпляров AD LDS в соответствующих местах.

Примитивы хранения данных

Ключевую роль для понимания схемы AD играют два термина: класс и атрибут. Все элементы AD, в том числе схема, определяются в рамках классов и атрибутов. Классы - это типы данных, которые требуется хранить. Например, пользователь (user) - класс в AD, как и компьютер (computer). Атрибуты - свойства классов. Класс «пользователь» имеет атрибут «имя» (givenName) и атрибут «фамилия» (sn). Класс «компьютер» имеет атрибут «операционная система». Схема AD определяется в терминах двух классов: classSchema для классов и attributeSchema для атрибутов.

Проводя аналогию с типичной базой данных, можно сравнить классы с таблицами в базе данных, а атрибуты - со столбцами внутри таблицы. Но имейте в виду, что структура базы данных AD Directory Information Tree (DIT) в действительности имеет существенные отличия.

Решая задачу сохранения данных нового типа в AD, необходимо продумать сопоставление данных классам и атрибутам. В наиболее типичных случаях достаточно добавить атрибут к существующему классу (например, пользователю или группе). Если требуется просто сохранить новый фрагмент данных об объекте существующего типа (таком, как пользователь), сначала постарайтесь найти подходящие атрибуты среди имеющихся в AD. Схема содержит тысячи атрибутов, большинство из которых не задействовано. Поэтому, например, чтобы сохранить сведения о почтовом адресе пользователя, можно применить атрибут physicalDeliveryOfficeName.

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

Но иногда возможен только подход на основе классов. В двух случаях удобнее добавить в схему новый класс, нежели использовать атрибуты. Первый из них: необходимость отслеживать новый тип данных в каталоге. Если, например, требуется отслеживать в AD автомобили компании, можно определить в схеме новый класс «автомобиль». Другой случай - сопоставление «один ко многим».

Идеальным примером может служить Microsoft Exchange Server 2010. Каждое мобильное устройство, синхронизированное с Exchange с помощью ActiveSync, сохраняется как экземпляр специального класса объектов msExchActiveSyncDevice в каталоге. Эти мобильные устройства хранятся как дочерние объекты пользователя, владельца устройства. Такая структура обеспечивает сопоставление большого числа атрибутов (для каждого устройства) одному пользователю.

Входные данные для расширения схемы

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

В первую очередь выберите имя класса или атрибута. Самая важная часть имени - префикс. Имена атрибутов и классов в схеме (и в схеме покупателя стороннего приложения) должны быть уникальны, поэтому добавление префикса обеспечит отсутствие конфликтов между идентификаторами атрибутов.

Обычно в качестве префикса применяется сокращенное название компании. Например, я использую bdcLLC в качестве префикса для атрибутов нашей компании Brian Desmond Consulting LLC. Для корпорации ABC можно использовать префикс abcCorp. Обязательно позаботьтесь об уникальности префикса, так как общего реестра префиксов не существует. Если у компании типичное или сокращенное название, придумайте, как придать ему уникальные черты.

После того как имя выбрано, нужно назначить атрибуту или классу идентификатор объекта Object Identifier (OID). Идентификаторы OID - дополнительный компонент, который должен быть глобально уникален. AD (более обобщенно, LDAP) - не единственная структура, в которой OID используется в качестве идентификатора, поэтому организация Internet Assigned Numbers Authority (IANA) назначает уникальные деревья OID по запросам компаний. Запрос номера Private Enterprise Number, который представляет собой часть дерева OID, уникальную для компании, бесплатно обслуживается примерно за 10 минут. Получить его нужно прежде, чем приступить к созданию пользовательских расширений схемы. Запросить номер Private Enterprise Number можно на сайте по адресу www.iana.org/cgi-bin/assignments.pl.

Получив номер Private Enterprise Number, можно создать практически неограниченное количество уникальных идентификаторов OID и упорядочить их. На рисунке показана структура дерева OID для номера Private Enterprise Number нашей компании. Идентификаторы OID строятся путем добавления ветвей к дереву, поэтому многие компании начинают с создания ветви AD Schema (1.3.6.1.4.1.35686.1 на рисунке), а затем под ней формируется ветвь классов и ветвь атрибутов. Под каждой из этих ветвей назначаются идентификаторы OID каждому новому атрибуту или классу. На рисунке показан OID (1.3.6.1.4.1.35686.1.2.1), выделенный пользовательскому атрибуту myCorpImportantAttr. Очень важно подготовить внутренний механизм отслеживания (например, электронную таблицу Excel или список SharePoint), обеспечивающий уникальность идентификаторов OID.

Рисунок. Иерархия OID

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

Оставшиеся два входных параметра специфичны для атрибутов и зависят от их типа. Чрезвычайно полезные связанные атрибуты используются для хранения ссылок между объектами в AD. Они хранятся как указатели в базе данных AD, поэтому ссылки своевременно обновляются в соответствии с местоположением объекта в лесу. Два типичных примера связанных атрибутов - членство в группах (member и memberOf) и отношение менеджер/сотрудник (manager/directReports). К связанным атрибутам применяются концепции ссылок вперед и обратных ссылок. Ссылка вперед - редактируемая часть связи между атрибутами. Например, в случае членства в группе атрибут member для группы представляет собой ссылку вперед; атрибут memberOf для пользователя - обратная ссылка. При редактировании членства в группе изменения вносятся в атрибут member (ссылка вперед), а не атрибут memberOf объекта-члена (обратная ссылка).

Чтобы определить связанные атрибуты в AD, необходимо определить два атрибута (ссылку вперед и обратную ссылку) и присоединить идентификатор ссылки (linkID) к каждому из этих атрибутов. Идентификаторы ссылки должны быть уникальными внутри леса, а поскольку идентификаторы ссылок необходимы и другим приложениям, требующим расширения схемы, их нужно сделать глобально уникальными. В прошлом компания Microsoft издавала идентификаторы ссылок для сторонних организаций, но начиная с Windows Server 2003 вместо этого в AD появился специальный указатель, позволяющий формировать уникальные идентификаторы ссылок при дополнении схемы, связанной парой атрибутов.

В AD предполагается, что идентификаторы ссылок являются последовательными числами. В частности, атрибут ссылки вперед - четное число, а следующее за ним число назначается атрибуту обратной ссылки. Например, для member и memberOf (членство в группе) идентификатор ссылки для member равен 4, а идентификатор ссылки для memberOf - 5. Если расширенная схема должна быть совместима с лесом Windows 2000, необходимо определять идентификаторы статических ссылок описанным способом. В противном случае следует использовать процесс автоматического формирования идентификаторов ссылок, реализованный в Windows Server 2003. Для использования автоматического процесса создания идентификаторов ссылок следуйте приведенным ниже рекомендациям, определяя расширение схемы. В процессе расширения схемы, как описано далее в статье, приведенные шаги необходимы для конструирования связанных атрибутов (если они являются частью расширения).

Сначала подготовьте ссылку вперед, используя идентификатор ссылки 1.2.840.113556.1.2.50. Обратите внимание, что, хотя данное значение идентификатора ссылки представляет собой OID, компания Microsoft просто резервирует это значение OID для создания идентификатора автоссылки.

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

Второй уникальный (и также необязательный) элемент атрибутов - идентификатор MAPI. Идентификаторы MAPI - особенность Exchange Server. В отсутствие Exchange или необходимости показывать атрибут в списке глобальных адресов (Global Address List, GAL) этот раздел можно пропустить. Идентификаторы MAPI используются для отображения атрибутов на одной из страниц свойств в адресной книге, такой как шаблон общих деталей пользователя (см. экран). Например, если нужно показать классификацию сотрудников (штатный сотрудник или работник по договору) в списке GAL, назначьте соответствующий атрибут как идентификатор MAPI. После того как идентификатор MAPI назначен атрибуту, можно использовать редактор Exchange Details Templates Editor для ввода данных атрибута в представление в списке GAL внутри Office Outlook.

Идентификаторы MAPI должны быть уникальны, так же как идентификаторы OID и ссылок. В прошлом было невозможно формировать уникальные идентификаторы MAPI, так что эти идентификаторы всегда оказывались слабым местом при расширении схемы. К счастью, в Windows Server 2008 появился способ автоматического формирования уникальных идентификаторов MAPI в каталоге, чтобы уменьшить риск дублирования идентификаторов MAPI. Чтобы воспользоваться этой функцией, присвойте значение 1.2.840.113556.1.2.49 атрибуту идентификатора MAPI при создании атрибута. AD формирует уникальный идентификатор MAPI для атрибута после перезагрузки кэша схемы. Обратите внимание, что, хотя это значение представляет собой OID, оно зарезервировано в AD для указания автоматического формирования идентификаторов MAPI, подобно автоматическому формированию идентификаторов ссылок, описанному выше.

Подведем итог. При планировании расширения схемы необходимо учитывать три важнейших входных параметра. Первый - имя класса или атрибута; второй - уникальный префикс, назначаемый всем классам и атрибутам; третий - OID. Для формирования OID необходимо запросить уникальную ветвь OID в организации IANA. Если предстоит создать связанную пару атрибутов, требуется уникальная пара идентификаторов ссылок. Если нужно показать атрибут в списке GAL Exchange, необходимо задействовать уникальный идентификатор MAPI. Как в случае с идентификаторами ссылок, так и в случае с идентификаторами MAPI, использование процесса автоматического формирования внутри AD предпочтительнее статических значений.

Планирование внедрения

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

При подготовке пользовательского расширения схемы используйте временную среду разработки. Службу AD Lightweight Directory Service (AD LDS) можно бесплатно загрузить на рабочие станции Windows XP и Windows 7. На рабочей станции можно создать экземпляр AD LDS, построить расширение схемы в изолированной среде, а затем экспортировать это расширение для последующего импорта в тестовый лес AD. Схема AD LDS совместима с AD, поэтому для экспорта можно использовать LDIFDE. Готовое расширение схемы можно импортировать в тестовый лес AD, а затем убедиться, что импорт выполнен успешно, и важнейшие приложения не пострадали. В отношении AD следует запланировать проверку успешности импорта и правильности репликации в тестовой среде.

Если предстоит проверить расширение схемы в тестовом лесу AD, его схема должна совпадать с производственным лесом. В этом случае тестирование будет полноценным. Можно воспользоваться инструментом AD Schema Analyzer (из состава AD LDS) для обнаружения различий в схеме между двумя лесами AD. В статье «Export, Compare, and Synchronize Active Directory Schemas» на сайте TechNet (http://technet.microsoft.com/en-us/magazine/2009.04.schema.aspx) описан порядок импорта и экспорта расширений схемы, а также способы использования инструмента AD Schema Analyzer. Обратите внимание, что при сравнении схем возможны некоторые различия, в зависимости от пакетов обновления и версий Windows, в частности в индексации атрибутов и хранении отметок об удалении.

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

• поставляемые в файле LDIF (нескольких файлах LDIF);
• правильность префиксов атрибутов;
• зарегистрированные OID;
• зарегистрированные/автоматически формируемые идентификаторы ссылок;
• автоматически формируемые идентификаторы MAPI.

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

• Атрибут снабжен префиксом на основе имени компании-поставщика (Brian Desmond Consulting, LLC: bdcllc).
• Уникальный OID для атрибута издан с использованием номера Private Enterprise Number, зарегистрированного поставщиком.
• Атрибут индексирован (search Flags: 1) и доступен в глобальном каталоге (isMemberOfPartialAttributeSet: TRUE).

Также необходимо проверить доступность атрибута в глобальном каталоге Partial Attribute Set (PAS) и правильность индексов, созданных для атрибута, если атрибут будет использоваться в фильтрах поиска LDAP. Кроме того, полезно убедиться, что данные, хранимые в атрибуте, приемлемы для AD в контексте рассмотренных выше ограничений и рекомендаций.

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

Планомерный подход

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

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

Листинг. Пример записей LDIF

Dn: CN=bdcllcShoeSize,CN=Schema,CN=Configuration,DC=X changetype: add objectClass: top objectClass: attributeSchema cn: sfsuLiveServiceEntitlements attributeID: 1.3.6.1.4.1.35686.100.1.1.2 attributeSyntax: 2.5.5.12 isSingleValued: FALSE showInAdvancedViewOnly: TRUE adminDisplayName: bdcllcShoeSize adminDescription: Stores a user’s shoe size oMSyntax: 64 searchFlags: 1 lDAPDisplayName: bdcllcShoeSize name: bdcllcShoeSize schemaIDGUID:: Js+e3rEsAUWMazlPm5hb6w== isMemberOfPartialAttributeSet: TRUE

Трудно недооценить важность «Схемы Active Directory» для сетей, построенных на базе доменной среды Active Directory. Это основа технологии «AD» и очень важно правильно понимать принципы ее функционирования. Большинство системных администраторов не уделяют схеме должного внимания по причине того, что иметь дело с ней приходится достаточно редко. В данной статье я расскажу, что такое версия схемы, для чего нам необходимо ее знать и самое главное как посмотреть текущую версию. Прежде всего, пару слов о самой схеме, каждый объект, созданный в Active Directory, будь то пользователь или компьютер, имеет определенные параметры, называемые атрибутами. Самым простым примером может служить атрибут «Фамилия» у объекта пользователь. Схема определяет, какие объекты мы можем создавать в Active Directory, и какие атрибуты они будут иметь.

Active Directory допускает использование в рамках одной организации несколько контроллеров домена, построенных на базе разных версий ОС Windows. А именно – на базе Windows Server 2000, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008. Поскольку данные версии выпускались в разные годы, и каждая новая версия несет больший функционал, чем предыдущая, понимание схемы у каждой операционной системы свое. Поэтому при добавлении нового контроллера на базе Windows Server 2008 в организацию, где существующие контроллеры построены на Windows Server 2003, вам приходилось запускать утилиту «Adprep ». Тем самым вы обновляли схему вашей организации до того уровня, с которым работает Windows Server 2008.

Процесс обновления схемы выполнялся до установки первого контроллера Windows Server 2008 и собственно сама процедура установки нового контроллера, могла и не выполняться. Если вы только начинаете работать с какой-то организацией Active Directory и не знаете, какие действия осуществлялись до вашего прихода, вам для понимания полноты структуры, будет нужно знать, на каком уровне работает Схема текущей организации.

Возможные версии схемы:

13 – Windows 2000 Server
30 – Windows Server 2003 RTM, Windows 2003 With Service Pack 1, Windows 2003 With Service Pack 2
31 – Windows Server 2003 R2
44 – Windows Server 2008 RTM

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

Посмотреть версию схемы можно несколькими способами. Самым простым является способ с использованием утилиты «DSQuery». Для этого в командной строке необходимо ввести команду со следующими параметрами:

“dsquery * cn=schema,cn=configuration,dc=domainname,dc=local -scope base -attr objectVersion”

Естественно в части «dc= domainname, dc= local» вы должны подставить имя собственного домена. (Пример: dc= microsoft, dc= com )

Результатом ввода команды является получение атрибута «ObjectVersion », который и будет являться номером версии схемы:

Рис. 1 Получение версии схемы через утилиту «DSQuery».

Второй способ более длинный и подразумевает использование оснастки «ADSIEdit . msc » . Для просмотра версии схемы вам придется подключиться к разделу Active Directory схема.

"CN=Schema,CN=Configuration,DC=domain,DC=local "

И найти значение атрибута "objectVersion ".

Рис.2 Получение версии схемы через оснастку «ADSIEdit . msc ».

Зная версию схему, вы всегда можете с уверенностью сказать нужно ли схему обновлять и если нужно то, до какого уровня.

Следует отметить, что обновления схемы могу производиться программным обеспечением тесно интегрированным с Active Directory. Самый яркий пример Microsoft Exchange Server. И зачастую в организации, планирующей внедрение Exchange Server, необходимо выяснить, была ли осуществлена подготовка схемы? И если была, то какой версией Exchange Server. На текущий момент существуют три версии Exchange, работающие с Active Directory, но вариантов модификации схемы существует шесть.

Понять была ли изме
нена Схема Active Directory Exchange сервером можно по атрибуту «rangeUpper», который принимает следующие значения:

4397 – Exchange Server 2000 RTM
4406 – Exchange Server 2000 With Service Pack 3
6870 – Exchange Server 2003 RTM
6936 – Exchange Server 2003 With Service Pack 3
10628 – Exchange Server 2007
11116 – Exchange 2007 With Service Pack 1

Как можно заметить обновление схемы происходит и при установке набора обновлений SP3 для Exchange Server 2000/2003 и SP1 для Exchange 2007.

Посмотреть значение атрибута «rangeUpper» можно через утилиту DSQuery:

"dsquery * CN=ms-Exch-Schema-Version-Pt, cn=schema, cn=configuration, dc=domainname, dc=local -scope base -attr rangeUpper"

Рис. 3 Получение атрибута «rangeUpper» через утилиту DSQuery.

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

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