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

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

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

Для идентификации пользователей и ресурсов в сети используется служба каталогов. По сравнению с предыдущими версиями Windows в Microsoft Windows 2003 возможности Active Directory значительно расширены. Active Directory представляет собой единое средство управления сетью: она позволяет легко добавлять, удалять и перемещать пользователей и ресурсы.

Знакомство с Active Directory

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

Изучив материал этого занятия, вы сможете:

объяснить назначение атрибутов объекта и схемы Active Directory;

дать определение и описать функции компонентов Active Directory.

Объекты Active Directory

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

Объект - это отдельный именованный набор атрибутов, которыми представлен сетевой ресурс. Атрибуты (attribute) объекта являются его характеристиками в каталоге. Например, атрибуты учетной записи пользователя (user account) могут включать в себя его имя и фамилию, отдел, а также адрес электронной почты (рис. 2-1)

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

Примечание Объекты, которые способны содержать другие объекты, называются контейнерами (container). Например, домен - это контейнерный объект, который может содержать пользователей, компьютеры и другие объекты.

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

Схема Active Directory

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

В схеме существуют два типа определений: атрибуты и классы. Также они называются объектами схемы (schema objects) или метаданными (metadata).

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

Классы, также называемые классами объектов (object classes), описывают, какие объекты Active Directory можно создавать. Каждый класс является совокупностью атрибутов. При создании объекта атрибуты сохраняют описывающую его информацию. Например, в число атрибутов класса User входят Network Address, Home Directory и пр. Каждый объект в Active Directory - это экземпляр класса объектов.

В Windows 2000 Server встроен набор базовых классов и атрибутов. Определяя новые классы и новые атрибуты для уже существующих классов, опытные разработчики и сетевые администраторы могут динамически расширить схему. Например, если Вам нужно хранить информацию о пользователях, не определенную в схеме, можно расширить схему для класса Users. Однако такое расширение схемы - Достаточно сложная операция с возможными серьезными последствиями. Поскольку схему нельзя удалить, а лишь деактивировать, и она автоматически реплицируется, вы должны подготовиться и спланировать ее расширение.

Трудно недооценить важность «Схемы 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.

Спонсор поста

Все новинки проката, лучшие фильмы прошлых лет. Лучшие любимое кино на 5ic.ru

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

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

Посмотреть версию схемы можно несколькими способами. Самым простым является способ с использованием утилиты «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 Exchange сервером можно по атрибуту «rangeUpper», который принимает следующие значения:

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

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

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

Процесс обновления схемы является очень важным моментом для каждой организации Active Directory, поэтому следует избегать лишних, неоправданных действий. Понимая сути атрибутов “objectVersion ” и «rangeUpper» дает специалисту преимущество при работе с 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

Схемой (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. Многие сторонние продукты также предусматривают свои способы расширения схемы, которые обеспечивают им возможность отображать свои типы информации из каталога.