Версия Схемы Active Directory. Расширение схемы Active Directory

Как известно — ничего вечного нет, все меняется, особенно в такой отрасли как IT. Развернутая один раз инфраструктура постоянно развивается, расширяется, совершенствуется и наступает момент когда в вашу Active Directory требуется ввести контроллер домена под управлением более поздней версии операционной системы.

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

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

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

Вроде бы понятно, но не совсем, поэтому перейдем к распространненным ошибкам и заблуждениям.

• Обновление схемы необходимо для включения в домен ПК под управлением более новых версий ОС Windows. Это не так, даже самые последние версии Windows могут вполне успешно рабоать в домене уровня Windows 2000 без обновления схемы. Хотя, если вы все-таки обновите схему, то ничего страшного не произойдет.

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

Также заострим ваше внимание на режиме работы леса и домена. Домены входящие в лес могут иметь различные режимы работы, например один из доменов может работать в режиме Windows 2008, а остальные в режиме Windows 2003. Схема работы леса не может быть выше, чем схема работы самого старого домена. В нашем примере режим работы леса не может быть выше, чем Windows 2003.

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

Ознакомившись с теорией, перейдем к практическому примеру. Допустим у нас есть домен уровня Windows 2000 (смешаный режим) — самый низкий уровень AD — в котором имеется контроллер под управлением Windows 2003, а наша цель — создать новый контроллер взамен вышедшего из строя.

Новый сервер работает под управлением Windows 2008 R2. Заметьте, у нас не возникло никаких сложностей по включению данного сервера в существующий домен.

Однако при попытке добавить новый контроллер домена мы получим ошибку:

Для успешного включения контроллера под управлением более новой версии ОС нам потребуется обновить схему леса и схему домена. Исключение составляет Windows Server 2012, который при добавлении нового контроллера домена произведет обновление схемы самостоятельно.

Для обновления схемы используется утилита Adprep которая находится в папке \support\adprep на установочном диске Windows Server. Начиная с Windows Server 2008 R2 эта утилита по умолчанию 64-разрядная, при необходимости использовать 32-разрядную версию следует запускать adprep32.exe .

Для выполнения обновления схемы леса данная утилита должна быть запушена на Хозяине схемы , а для обновления схемы домена на Хозяине инфраструктуры . Чтобы узнать какие из контроллеров имеют необходимые нам роли FSMO воспользуемся командой:

Netdom query FSMO

В Windows 2008 и новее данная утилита устанвлена по умолчанию, а в Windows 2003 ее нужно установить с диска из директории \support\tools

Результатом вывода данной команды будет перечисление всех ролей FSMO и контроллеров имеющих данные роли:

В нашем случае все роли находятся на одном контроллере, поэтому копируем папку \support\adprep на жесткий диск (в нашем случае в корень диска C:) и приступаем к обновлению схемы леса. Для успешного выполнения операции ваш аккаунт должен входить в группы:

• Администраторы схемы
• Администраторы предприятия
• Администраторы домена, в котором находится хозяин схемы

Чтобы обновить схему леса выполните команду:

C:\adprep\adprep /forestprep

Ознакомьтесь со стандартным предупреждением и продолжите нажав C , затем Enter .

Начнется процесс обновления схемы. Как видим ее версия изменится с 30 (Windows 2003) до 47 (Windows 2008 R2).

После обновления схемы леса следует обновить схему домена. Перед этим следует убедиться что домен работает как минимум в режиме Windows 2000 (основной режим). Как помним, у нас домен работает в смешанном режиме, поэтому следует изменить режим работы домена на основной или повысить его до Windows 2003. Так как в данном домене у нас нет контроллеров под управлением Windows 2000, то наиболее разумно будет повысить режим домена.

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

C:\adprep\adprep /domainprep

И внимательно читаем выводимую информацию. Обновляя схему домена с уровня Windows 2000 или Windows 2003 необходимо выполнить изменение разрешений файловой системы для групповых политик. Данная операция производится один раз и в дальнейщем, например обновляя схему с уровня 2008 на 2008 R2, выполнять ее нужно. Для обновления разрешений объектов GPO введите команду:

С:\adprep\adprep /domainprep /gpprep

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

Данную операцию можно выполнить на любом контроллере домена, однако вы должны входить в группу Администраторы предприятия и Хозяин именований и Хозяин инфраструктуры должны быть доступны.

C:\adprep\adprep /rodcprep

Как видим, обновление схемы домена, будучи правильно спланировано не вызывает каких либо затруднений, однако в любом случае следует помнить, что это необратимая операция и иметь под рукой необходимые резервные копии.
Источник http://interface31.ru/tech_it/2013/05/obnovlenie-shemy-active-directory.html

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

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

Схема является расширяемой, поэтому системный администратор может создавать новые типы объектов и их свойства, добавлять новые свойства для тех объектов, которые уже существуют. Схема внедряется и хранится вместе с Active Directory в глобальном каталоге. Ее обновление производится автоматически, благодаря чему специально созданное приложение может самостоятельно добавить в нее новые свойства и классы.
Расширить стандартную схему непросто. Некорректное изменение схемы может нарушить работу как сервера, так и всей службы каталогов. Чтобы решить эту задачу следует необходимым опытом и знаниями. Так в первую очередь необходимо знать правила именования.

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

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

Составные имена (DN);
-относительные составные имена (RDN);
-глобальные уникальные идентификаторы (GUID);
-основные имена пользователей (UPN).

Каждый объект Active Directory обладает составным именем . Имя является идентификатором объекта и содержит данные, достаточные для нахождения объекта в каталоге. Составное имя включает в себя имя домена, который содержит объект, и полный путь к нему. К примеру, составное имя пользователя Andrew Kushnir в домене server.comможет выглядеть таким образом:
DC=COM/DC=SERVER/CN=Users/CK=Andrew Kushnir

Если полное составное имя объекта неизвестно или изменено, найти объект можно по его свойствам, одно из которых - относительное составное имя (часть составною имени). В предыдущем примере относительным составным именем для объекта Andrew Kushnir будет СК=Andrew Kushnir, а для родительского объекта - CN=Usere.

Кроме составного имени каждый объект Active Directory обладает глобальным уникальным идентификатором (GUID) , представляющим собой 128-разрядное число. Идентификатор не изменяется даже после того, как объект переместили или переименовали. Глобальный уникальный идентификатор является уникальным для всех доменов, в том числе, когда объект перемещается из одного домена в другой домен.
Проще всего запомнить основное имя пользователя (UPN). Основное имя состоит из сокращенного имени пользователя плюс DNS-имя домена, где находится объект. Формат основного имени пользователя следующий:

Имя пользователя, символ суффикс DNS домена

К примеру, основное имя пользователя Andrew Kushnir в домене server. сою могло выглядеть как [email protected]. Основное имя пользователя не зависит от его составного имени, поэтому объект пользователя можно перемещать или переименовывать без необходимости изменять регистрационное имя пользователя в домене.

Как известно - ничего вечного нет, все меняется, особенно в такой отрасли как IT. Развернутая один раз инфраструктура постоянно развивается, расширяется, совершенствуется и наступает момент когда в вашу Active Directory требуется ввести контроллер домена под управлением более поздней версии операционной системы.

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

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

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

Вроде бы понятно, но не совсем, поэтому перейдем к распространенным ошибкам и заблуждениям.

• Обновление схемы необходимо для включения в домен ПК под управлением более новых версий ОС Windows. Это не так, даже самые последние версии Windows могут вполне успешно работать в домене уровня Windows 2000 без обновления схемы. Хотя, если вы все-таки обновите схему, то ничего страшного не произойдет.

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

Также заострим ваше внимание на режиме работы леса и домена. Домены входящие в лес могут иметь различные режимы работы, например один из доменов может работать в режиме Windows 2008, а остальные в режиме Windows 2003. Схема работы леса не может быть выше, чем схема работы самого старого домена. В нашем примере режим работы леса не может быть выше, чем Windows 2003.

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

Ознакомившись с теорией, перейдем к практическому примеру. Допустим у нас есть домен уровня Windows 2000 (смешанный режим) - самый низкий уровень AD - в котором имеется контроллер под управлением Windows 2003, а наша цель - создать новый контроллер взамен вышедшего из строя.

Новый сервер работает под управлением Windows 2008 R2. Заметьте, у нас не возникло никаких сложностей по включению данного сервера в существующий домен.

В нашем случае все роли находятся на одном контроллере, поэтому копируем папку \support\adprep на жесткий диск (в нашем случае в корень диска C:) и приступаем к обновлению схемы леса. Для успешного выполнения операции ваш аккаунт должен входить в группы:

• Администраторы схемы
• Администраторы предприятия
• Администраторы домена, в котором находится хозяин схемы

Чтобы обновить схему леса выполните команду:

C:\adprep\adprep /forestprep

Ознакомьтесь со стандартным предупреждением и продолжите нажав C , затем Enter .

Начнется процесс обновления схемы. Как видим ее версия изменится с 30 (Windows 2003) до 47 (Windows 2008 R2).

После обновления схемы леса следует обновить схему домена. Перед этим следует убедиться что домен работает как минимум в режиме Windows 2000 (основной режим). Как помним, у нас домен работает в смешанном режиме, поэтому следует изменить режим работы домена на основной или повысить его до Windows 2003. Так как в данном домене у нас нет контроллеров под управлением Windows 2000, то наиболее разумно будет повысить режим домена.

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

C:\adprep\adprep /domainprep

И внимательно читаем выводимую информацию. Обновляя схему домена с уровня Windows 2000 или Windows 2003 необходимо выполнить изменение разрешений файловой системы для групповых политик. Данная операция производится один раз и в дальнейшем, например обновляя схему с уровня 2008 на 2008 R2, выполнять ее нужно. Для обновления разрешений объектов GPO введите команду:

С:\adprep\adprep /domainprep /gpprep

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

Данную операцию можно выполнить на любом контроллере домена, однако вы должны входить в группу Администраторы предприятия и Хозяин именований и Хозяин инфраструктуры должны быть доступны.

C:\adprep\adprep /rodcprep

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

Схемой (schema) в AD DS называется набор определений для всех имеющихся в каталоге типов объектов и связанных с ними атрибутов. Именно схема задает способ, которым в AD DS должны храниться и конфигурироваться данные обо всех пользователях, компьютерах и других объектах для того, чтобы они имели стандартный вид по всей структуре AD DS. Она защищается за счет применения списков разграничительного контроля доступа (Discretionary Access Control List - DACL) и отвечает за предоставление возможных атрибутов для каждого объекта в AD DS. По сути, схема представляет собой базовое определение самого каталога и является основой функциональности среды домена. При делегировании прав на управление схемой избранной группе администраторов должна соблюдаться предельная осторожность, поскольку вносимые в схему изменения влияют на всю среду AD DS.

Объекты схемы

Сохраняемые внутри структуры AD DS элементы, вроде пользователей, принтеров, ком­пьютеров и сайтов, в рамках схемы называются объектами. У каждого такого объекта име­ется свой список атрибутов, которые определяют его характеристики и могут применяться для его поиска.

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

Одним из главных преимуществ структуры AD DS является возможность напрямую изменять и расширять схему, включая в нее специальные атрибуты. Обычно расширение набора атрибутов происходит во время установки системы Microsoft Exchange Server, при которой схема расширяется так, что увеличивается в размере чуть ли не в 2 раза. При выполнении обновления с Windows Server 2003 или Windows Server 2008 AD до Windows Server 2008 R2 AD DS тоже происходит расширение схемы, в результате которого в нее добавляются атрибуты, присущие конкретно Windows Server 2008 R2. Многие сторонние продукты также предусматривают свои способы расширения схемы, которые обеспечива­ют им возможность отображать свои типы информации из каталога.

С момента выпуска службы 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.

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

Когда организация собирается расширить схему, она обеспечивает уникальность идентификатора объекта путем получения собственного корневого номера 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

Кроме того, хотя атрибут 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 только в случае крайней необходимости.