Физическая структура службы Active Directory

Физическое проявление службы Active Directory состоит в наличии отдельного файла данных, расположенного на каждом контроллере домена в домене. Физическая реализация службы Active Directory описывается местоположением контроллеров домена, на которых расположена служба. При реализации службы Active Directory можно добавлять столько контроллеров доменов, сколько необходимо для поддержания служб каталога в данной организации. Имеется пять определенных ролей, которые может играть каждый из контроллеров домена. Они известны как роли хозяина операций (operations master roles). Еще одна роль, которую может выполнять любой отдельный контроллер домена в домене, связана с глобальным каталогом (GC — Global Catalog). В этом разделе мы рассмотрим хранилище данных службы Active Directory и контроллеры домена, на которых оно расположено.

Хранилище данных каталога

Все данные базы данных службы Active Directory хранятся в отдельном файле Ntds.dit на контроллере домена. Этот файл данных по умолчанию находится в папке %SystemRoot%\NTDS, расположенной на контроллере домена. В нем хранится вся информация каталога, предназначенная для данного домена, а также данные, являющиеся общими для всех контроллеров домена в данной организации.
Вторая копия файла Ntds.dit находится в папке %SystemRoot%\ System32. Эта версия файла - поставляемая копия (копия, заданная по умолчанию) базы данных каталога, она используется для установки службы Active Directory. Этот файл копируется на сервер во время установки Microsoft Windows Server 2003, чтобы сервер можно было назначать контроллером домена без необходимости обращаться к инсталляционной среде. Во время выполнения мастера инсталляции Active Directory (Dcpromo.exe) файл Ntds.dit копируется из папки System32 в папку NTDS. Затем копия, сохраненная в папке NTDS, становится действующей копией хранилища данных каталога. Если это не первый контроллер домена в домене, то файл будет обновлен из других контроллеров домена через процесс репликации.

Контроллеры домена

По определению любой компьютер, на котором выполняется Windows Server 2003, и который поддерживает копию базы данных службы Active Directory, является контроллером домена. Все контроллеры домена создаются равными за несколькими исключениями, которые будут рассмотрены далее в этой главе. При использовании процесса репликации с несколькими хозяевами домена (multimaster), описанного в гл. 4, каждый контроллер домена в домене поддерживает новейшую копию базы данных домена и способен создавать изменения в ней.
В дополнение к контроллерам домена, которые содержат службу Active Directory, имеется несколько контроллеров домена специального назначения, которые требуются службе Active Directory для выполнения определенных функций. Они являются серверами глобального каталога (GC) и хозяевами операций (operations masters).

Серверы глобального каталога

На сервере глобального каталога находится глобальный каталог (GC). Он является частичной, предназначенной только для чтения копией всех контекстов именования домена (NC - Naming Context) в лесу. Каталог GC содержит основной, но неполный набор атрибутов для каждого объекта леса в каждом домене NC. Данные каталога GC получают из всех разделов каталога доменов в лесу, они копируются с использованием стандартного процесса репликации службы Active Directory.
Совет. Будет ли атрибут скопирован в каталог GC, определяется схемой. Администраторы могут конфигурировать дополнительные атрибуты, которые будут реплицироваться в каталог GC, используя меню Active Directory Schema (Схема Active Directory), встроенное в консоль управления ММС. Чтобы добавить атрибут к каталогу GC, выберите опцию Replicate This Attribute To The Global Catalog (Копировать этот атрибут в глобальный каталог) на самом атрибуте. В результате значение параметра атрибута isMemberOfPartialAttributeSetбудет установлено на true(истина). Вы можете добавлять атрибут к глобальному каталогу, если ожидаете, что пользователям потребуется искать этот объект в лесу. Редко упоминаемые атрибуты обычно не добавляются к каталогу GC.
Первый контроллер домена, установленный в домене, автоматически является контроллером глобального каталога. Дополнительные контроллеры домена можно назначить как GC, выбирая опцию Global Catalog Server (Сервер глобального каталога) в инструменте администрирования Active Directory Sites And Services (Сайты и службы Active Directory). Это делается с целью оптимизации входа в систему. Как используется каталог GC в процессе входа в систему, описано далее в этом разделе. В главе 5 дается более подробная информация о количестве GC-серверов, которое потребуется при развертывании, и о том, где их следует располагать.

Вы можете задаться вопросом, зачем вообще нужны GC-серверы. Во-первых, они используются для поиска в Active Directory. Без каталога GC поиск по запросам, полученным контроллером домена, который не обладает запрошенным объектом, приведет к тому, что он переправит запрос на контроллер домена другого домена. Поскольку GC-каталог содержит полный список всех объектов леса (и не содержит атрибуты объекта), GC-сервер может ответить на любой запрос, используя атрибут, который копировался в GC-каталог, без необходимости передавать его другому контроллеру домена. Запрос, который послан GC-серверу, является LDAP-запросом (Lightweght Directory Access Protocol — облегченный протокол службы каталогов), использующим порт 3268 (заданный по умолчанию порт GC-каталога).

Во-вторых, GC-серверы необходимы для обработки пользовательских входов в систему. Обычно каждый раз, когда пользователь входит в домен, выполняется обращение к GC-каталогу. Это происходит потому, что контроллеры домена, не являющиеся глобальными, не содержат никакой информации об универсальном членстве группы. (Универсальные группы имеются только в доменах, обладающих функциональным уровнем Microsoft Windows 2000 или Windows Server 2003. Функциональные уровни используются в Windows Server 2003, чтобы разрешить функции службы Active Directory всем контроллерам домена, которые могут их поддерживать.) Универсальные группы могут содержать учетные записи пользователей и групп из любого домена определенного леса. Так как универсальное групповое членство распространяется на лес, то групповое членство может быть разрешено только тем контроллером домена, который имеет информацию каталога на уровне леса, т.е. информацию глобального каталога (GC). Чтобы сгенерировать точную лексему защиты для пользователя, запрашивающего идентификацию, требуется контактировать с GC-каталогом для определения универсального группового членства пользователя.

Примечание. Windows Server 2003 поддерживает новую функцию кэширования универсального группового членства, которая дает возможность входить в сеть Windows Server 2003 без контакта с GC-каталогом. Универсальное групповое членство кэши-руется на контроллерах домена, не являющихся контроллерами GC, если эта опция разрешена, а пользователь впервые пытается войти в систему. Как только эта информация попадает в GC-каталог, она кэшируется на неограниченное время на контроллере домена сайта и периодически обновляется (по умолчанию каждые 8 часов). Включение этой функции приводит к ускорению входа в систему пользователей с удаленных сайтов, так как для аутентификации контроллеру домена не требуется обращения к GC-каталогу. Чтобы включить опцию универсального группового членства на сайте, откройте оснастку Active Directory: Sites And Services (Сайты и службы Active Directory) и выберите нужный сайт в дереве консоли. Щелкните правой кнопкой мыши на панели деталей NTDS Site Settings (Параметры настройки сайта NTDS), затем выберите Properties (Свойства). На вкладке Properties выберите опцию Enable Universal Group Membership Caching (Разрешить кэширование универсального группового членства), а затем укажите сайт, с которого будет обновляться кэш. По умолчанию сайт обновит информацию с самого близкого сайта, который имеет глобальный каталог GC.

Функциональные уровни

В Windows Server 2003 каждому лесу и каждому домену в пределах леса может быть назначен определенный функциональный уровень. Функциональные уровни используются для того, чтобы разрешать функции, которые реализованы на комбинациях операционных систем. Когда для домена устанавливается функциональный уровень, то он применяется только к данному домену. Если не определено иначе, домены создаются на функциональном уровне mixed(смешанный) системы Windows 2000; леса создаются на функциональном уровне Windows 2000.
В таблице 2-1 показаны функциональные уровни доменов и операционные системы, поддерживаемые на контроллерах домена.
Табл. 2-1. Функциональные уровни домена

Функциональный уровень домена	Операционные системы, поддерживаемые на контроллерах данного домена
Windows 2000 mixed (смешанный) (значение ро умолчанию)	Windows NT 4, Windows 2000, Windows Server 2003.
Windows 2000 native (основной)	Windows 2000, Windows Server 2003.
Windows Server 2003 interim (промежуточный) Windows Server 2003	Windows NT 4, Windows Server 2003. Windows Server 2003.

В таблице 2-2 показаны функциональные уровни леса и операционные системы, поддерживаемые на контроллерах домена в лесу.
Табл. 2-2. Функциональные уровни леса

Функциональные уровни леса	Операционные системы, поддерживаемые на контроллерах данного домена в лесу
Windows 2000 (значение по умолчанию)	Windows NT 4, Windows 2000, Windows Server 2003.
Windows Server 2003 interim (промежуточный) Windows Server 2003	Windows NT 4, Windows Server 2003. Windows Server 2003.

Прежде чем повышать функциональный уровень леса до уровня Windows Server 2003, проверьте, всем ли доменам леса установлен функциональный уровень Windows 2000 native или Windows Server 2003. Домены, функциональный уровень которых установлен на Windows 2000 native, будут автоматически подняты до функционального уровня Windows Server 2003, а уровень леса - до уровня Windows Server 2003. После того как это произойдет, к данному домену (лесу) могут быть добавлены только контроллеры домена, работающие на том же функциональном уровне операционной системы. Поднятый функциональный уровень домена или леса нельзя понизить.

Итак, глобальный каталог (GC) используется для того, чтобы облегчить пользовательский вход в систему, допуская использование основных имен пользователя (например, usernarae@contoso.com). Каталог GC понимает основные имена пользователя (UPN - User Principal Names), потому что он содержит информацию о каждом пользователе в каждом домене леса. Контроллеры домена, не имеющие каталога GC, не обладают этими данными, они не способны подтвердить подлинность пользовательского входа в систему, если он задается в таком формате.

Хозяева операций

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

хозяин схемы;
хозяин именования доменов;
хозяин относительных идентификаторов RID;
хозяин эмулятора PDC (Primary Domain Controller — основной контроллер домена);
хозяин инфраструктуры.

Первые две роли устанавливаются для леса в целом. Это означает, что задается только один хозяин схемы и один хозяин именования доменов для каждого леса. Следующие три роли функционируют в пределах домена, т.е. задается только одна из этих ролей для каждого домена леса. Когда вы установите Active Directory и создадите первый контроллер домена в лесу, ему будут назначены все эти пять ролей. Если вы добавите домены к лесу, то первый контроллер домена в каждом новом домене возьмет на себя свои прошлые три роли хозяина операций. По мере добавления контроллеров домена вы передадите некоторые из этих ролей другим контроллерам домена. Как передавать роли другим контроллерам домена, описано далее в этой главе.
Хозяин схемы
Хозяин схемы является единственным контроллером домена, который имеет разрешение делать записи в схему каталога. Чтобы сделать любое изменение в схеме каталога, администратор (он должен быть членом группы безопасности Schema Admins — Администраторы схемы) должен связаться с хозяином схемы. Если модификация схемы предпринята на контроллере домена, не являющемся хозяином схемы, она окончится неудачей. После того как было сделано изменение, модификации схемы копируются на остальные контроллеры домена в лесу.
По умолчанию первый контроллер домена, установленный в лесу (контроллер домена для корневого домена леса) принимает роль хозяина схемы. Эта роль может быть передана другому контроллеру в любое время с помощью оснастки Active Directory Schema (Схема Active Directory) или с помощью утилиты командной строки Ntdsutil. Хозяин схемы идентифицирован значением атрибута fSMORoleOwnerв контейнере схемы.
Хозяин именования доменов
Хозяин именования доменов представляет собой контроллер домена, на котором можно добавлять новые домены к лесу или удалять существующие. Администраторы должны связываться с хозяином именования доменов, чтобы добавить или удалить домен. Если хозяин именования доменов недоступен, любая попытка добавить домен к лесу или удалить его потерпит неудачу.
Домены добавляются к лесу одним из способов, которые требуют подключения удаленного вызова процедуры (RPC) к домену, исполняющему роль хозяина именования доменов. Наиболее распространенный метод создания нового домена состоит в выполнении Dcpromo.exe в командной строке, которая запускает мастер инсталляции Active Directory. Во время этого процесса вы получаете возможность установить первый контроллер домена в новый домен. Dcpromo.exe войдет в контакт с хозяином именования домена для того, чтобы сделать это изменение. Если хозяин операции именования доменов недоступен, то создание домена окончится неудачей. Добавить новый домен можно также с помощью утилиты Ntdsutil. Эта утилита создает объект перекрестной ссылки в контейнере разделов в разделе конфигурации каталога, который затем реплицируется на все контроллеры домена в лесу. Далее создание домена можно выполнять с помощью Dcpromo.exe без необходимости входить в контакт с хозяином именования доменов.
Хозяин относительных идентификаторов
Хозяин относительных идентификаторов (RID) - это роль хозяина операций в пределах домена. Она используется для управления RID-пулом, предназначенным для создания новых участников безопасности в пределах домена, таких как пользователи, группы и компьютеры. Каждый контроллер домена производит блок относительных идентификаторов (RID), использующихся для построения идентификаторов защиты (SID), которые однозначно идентифицируют участников безопасности в домене. Блок доступных идентификаторов RID называется RID-пулом. Когда количество доступных RID-идентификаторов в RID-пуле на любом контроллере домена в домене начинает истощаться, делается запрос на другой RID-блок у хозяина RID-идентификаторов. Работа хозяина RID-идентификаторов заключается в выполнении таких запросов и обеспечении того, чтобы никакой RID-идентификатор не был выделен более одного раза. Этот процесс гарантирует каждой учетной записи в домене уникальную защитную особенность.
Если хозяин RID-идентификаторов в течение какого-то времени недоступен, процесс создания новых учетных записей на определенных контроллерах домена может быть прерван. Механизм запроса новых блоков RID-идентификаторов разработан таким образом, чтобы опустошения пула не происходило, ведь запрос делается раньше, чем все имеющиеся в RID-пуле идентификаторы будут розданы. Однако если хозяин RID-идентификаторов находится в автономном режиме, и контроллер домена, запрашивающий новый блок, исчерпает остаток RID-идентификаторов, создание учетной записи окончится неудачей. Чтобы снова сделать возможным создание учетных записей, необходимо или вернуть обладателя роли хозяина RID-идентификаторов в интерактивный режим, или эта роль должна быть передана другому контроллеру домена в данном домене.
Хозяин эмулятора PDC
Роль эмулятора PDC требуется для того, чтобы Windows Server 2003 мог сосуществовать с контроллерами домена, на которых выполняются более ранние версии, чем Windows 2000. В домене, работающем на функциональном уровне Windows 2000 mixed (смешанный), контроллер домена с Windows Server 2003 действует как основной контроллер домена (PDC) для всех низкоуровневых (Microsoft Windows NT версий 4 или 3.51) резервных контроллеров домена (BDC — Backup Domain Controller). В такой среде требуется эмулятор PDC для обработки изменений пароля, реплицирования изменений домена на BDC-домены и выполнения службы главного браузера домена (Domain Master Browser Service). Если эмулятор PDC недоступен, все события, связанные со службами, инициированными низкоуровневыми клиентами, окончатся неудачей.
В доменах, имеющих функциональный уровень Windows 2000 native (основной) или Windows Server 2003, эмулятор PDC используется для обслуживания модификаций пароля. Все изменения пароля, сделанные на других контроллерах домена в домене, посылаются эмулятору PDC. Если на контроллерах домена, не являющихся эмуляторами PDC, пользовательская идентификация терпит неудачу, идентификация повторяется на эмуляторе PDC. Если эмулятор PDC принимал недавнее изменение пароля к этой учетной записи, идентификация пройдет успешно.
Хозяин инфраструктуры
Хозяин инфраструктуры ответственен за обновление справочников групповой принадлежности пользователей в пределах домена. Роль хозяина операций гарантирует, что изменения, сделанные в названиях учетной записи пользователя, будут отражены в информации группового членства для групп, расположенных на различных доменах. Хозяин инфраструктуры поддерживает новейший список этих справочников и реплицирует эту информацию на все другие контроллеры домена в домене. Если хозяин инфраструктуры недоступен, справочники групповой принадлежности пользователей в пределах домена устаревают.
Передача ролей хозяина операций
Роли хозяина операций могут передаваться другому домену для оптимизации функционирования контроллера домена или для замены контроллера домена, если держатель роли стал недоступен. Процесс передачи роли хозяина операций зависит от передаваемой роли. Существуют следующие инструментальные средства для передачи ролей хозяина операций:

хозяин схемы - оснастка Active Directory Schema;
хозяин именования доменов — инструмент администрирования Active Directory Domains And Trusts (Домены и доверительные отношения Active Directory);
хозяин RID, эмулятора PDC и инфраструктуры — инструмент администрирования Active Directory Users And Computers (Пользователи и компьютеры Active Directory).

Для передачи роли хозяина операций должна функционировать связь с обоими контроллерами домена: текущим и предлагаемым держателем роли. В случае отказа сервера текущий держатель роли может быть недоступен для осуществления передачи роли. В этом случае роль может быть захвачена. Захватывать роль хозяина операций следует только в случае крайней необходимости, если указано, что контроллер домена, держатель этой роли, будет недоступен в течение длительного периода времени. Подробнее о захвате ролей хозяина операций см. гл. 15.
Схема
Схема определяет каждый тип объекта, который можно сохранять в Active Directory. Прежде чем создавать объект в Active Directory, его надо сначала определить в схеме. Схема предписывает правила, касающиеся создания объектов в базе данных. Эти правила определяют информацию, которая может быть сохранена с каждым объектом, и тип данных, соответствующих этой информации.
Компоненты схемы
Схема состоит из объектов классов и атрибутов. Объект класса определяет то, какие новые объекты могут быть созданы в каталоге. Для каждого создаваемого в каталоге объекта сначала должен быть определен класс. Пример объекта класса — класс User (Пользователь). Все новые пользовательские объекты, созданные в Active Directory, являются экземплярами класса User.
Схема определяет и то, какая информация может сохраняться для каждого класса объекта. Эта информация определяется в схеме как атрибут объекта. Объект некоторого класса может содержать значения для всех атрибутов, определенных для этого класса, а также для всех родительских классов этого класса. Например, учетная запись пользователя может иметь определенные значения атрибутов для всех объектов в классе User, так же как и для класса organizationalPerson, являющегося родительским классом класса User. При создании нового пользовательского объекта вы можете включать информацию, касающуюся этого пользователя и определяемую в схеме, в качестве атрибута всех классов, к которым этот новый пользовательский объект будет принадлежать.
Тип данных, которые могут храниться в Active Directory для каждого атрибута, определен в схеме как синтаксис атрибута. Если пользовательский класс содержит атрибут, названный display Name, синтаксис для этого атрибута определяется как строковое значение, которое может быть любым алфавитно-цифровым символом. Значение каждого атрибута должно удовлетворять требованиям синтаксиса этого атрибута.
Схема Active Directory поддерживает наследование объектов класса. Все объекты схемы организованы в иерархическом порядке в контексте именования. Благодаря этому любой объект класса способен унаследовать все характеристики объекта своего родительского класса. Например, класс Computer (Компьютер) фактически является дочерним классом от класса User (Пользователь), и поэтому класс Computer наследует все атрибуты, связанные с классом User. В этом случае класс Computer ассоциируется с атрибутами, специфическими для этого класса. С помощью оснастки Active Directory Schema вы можете увидеть организацию наследования объектов класса и иерархию объектов класса. На рисунке 2-1 показан класс Computer (Компьютер). Обратите внимание, что он является дочерним по отношению к классу User, который является дочерним классом класса organizationalPerson, и т.д. Эта система наследования значительно облегчает администраторам создание новых классов объектов, потому что они не должны определять каждый атрибут, связанный с новым классом, а могут просто унаследовать все объединения атрибутов подходящего родительского класса.

Рис. 2-1. Объект класса Computer( Компьютер), отображаемый оснасткой Active Directory Schema

Модификация схемы
Схема Active Directory содержит большинство постоянно используемых классов и атрибутов, необходимых для реализации службы каталога предприятия. Эти атрибуты и классы определяются как объекты Category1 (Категория 1), или основные объекты схемы. Для поддержки классов и атрибутов, определяемых клиентом, при разработке схемы Active Directory закладывались возможности ее расширения. Другими словами, она может быть изменена для включения новых объектов классов и атрибутов, в которых, возможно, нуждается организация. Объекты схемы, которые создаются позднее, определяются как объекты Category2 (Категория 2). Схему обычно расширяют для того, чтобы она удовлетворяла потребностям приложений, пользующихся поддержкой Active Directory. Хорошим примером такого приложения является Microsoft Exchange Server 2000, для поддержки которого при конфигурировании Active Directory было сделано более тысячи дополнений к схеме.

Кроме использования приложений, пользующихся поддержкой Active Directory, администраторы могут расширять схему другими методами. Это можно сделать в пакетном режиме с помощью средств администрирования с командной строкой, включая инструменты LDAP Data Interchange Format Directory Exchange (LDIFDE) и Comma Separated Value Directory Exchange (CSVDE). Схема может быть расширена программно, используя Active Directory Service Interfaces (ADSI) и сценарии Microsoft Visual Basic.

Дополнительная информация. Для получения дополнительной информации об инструментах LDIFDE или CSVDE напечатайте название команды в командной строке для вызова онлайновой подсказки. Для получения дополнительной информации об ADSI и ADSI Edit обратитесь к комплекту разработки программного обеспечения Microsoft Windows Platform (SDK), который можно загрузить или заказать на компакт-диске на сайте http:// www.microsoft.com/msdownload/platformsdk/sdkupdate.Чacть ADSI Platform SDK можно просмотреть интерактивно на сайте http://msdn.microsoft.com/library/default.asp?url=/library/

en-us/netdir/adsi/directory_services.asp.
Схема может быть изменена через интерфейс пользователя Windows Server 2003 с помощью оснастки Active Directory Schema. Сначала нужно зарегистрировать оснастку, выполнив команду Regsvr32 Schmmgmt.dll из командной строки. Для изменения схемы вы должны быть членом глобальной группы Schema Admins (Администраторы схемы). Чтобы понять, как работает изменение схемы, представьте себе, что организации необходимо сохранять записи о датах, когда служащие приступили к работе, т.е. сохранять дату начала работы служащего как ат-
рибут пользовательского объекта в Active Directory. Чтобы этот атрибут был доступен при создании каждого нового пользовательского объекта, он сначала должен быть определен в схеме.
С помощью оснастки Active Directory Schema вы можете добавить новый атрибут к схеме и связать его с объектом класса User. Для этого выполните следующие шаги.

Откройте оснастку Active Directory Schema (Схема Active Directory).
Выберите папку Attributes (Атрибуты) на панели дерева.
В меню Action (Действие) щелкните на Create Attribute (Создать атрибут).
В окне предупреждения Schema Object Creation (Создание объекта схемы) щелкните на Continue (Продолжить).
В диалоговом окне Create New Attribute (Создание нового атрибута) введите информацию в раздел Identification (Идентификация):

Common Name (обычное имя);
LDAP Display Name (отображаемое LDAP-имя);
Unique X500 Object ID (уникальный идентификатор объекта Х500);
Description (описание).

В разделе Syntax And Range (Синтаксис и диапазон) внесите информацию в поля:

Syntax (синтаксис);
Minimum (минимум);
Maximum (максимум).

Выберите, будет ли новый атрибут многозначным (Multi-Valued) атрибутом.

Подробная информация, касающаяся содержания каждого поля, становится доступной при выборе соответствующего текстового поля и нажатии клавиши F1.
Получение идентификатора Х 500 Object ID
Иногда два приложения могут попытаться сделать несовместимые модификации в схеме. Чтобы решить эту проблему, каждый класс и атрибут в Active Directory могут быть идентифицированы уникальным идентификатором объекта (OID — Object Identifier) для гарантии того, что другой объект схемы не использует тот же самый OID. Организация, планирующая создание новых OID, должна зарегистрироваться в Международной организации по стандартизации (ISO — International Standards Organization) или в Американском национальном институте стандартов (ANSI - American National Standards Institute). При регистрации организация стандартов выделит вам часть пространства OID, которое затем можно расширять для удовлетворения своих потребностей. Например, компании может быть предоставлено число типа 1.2.840.ХХХХ. Оно организовано в иерархическом порядке и содержит следующие части:

1 - ISO;
2-ANSI;
840 - Соединенные Штаты Америки;
ХХХХ — уникальное число, идентифицирующее вашу компанию.

Как только вы получили это число, можно управлять своей собственной частью иерархии. Например, если вы создаете новый атрибут с именем EmployeeStartDate(Дата начала работы служащего), ему можно назначить число типа 1.2.840.ХХХХ.12.
Пусть OID для контакта в Active Directory задан в виде 1.2.840.113556.1.5.15. Первые три части числа выделены для ISO, ANSI и США соответственно. Число 113556 ANSI предоставил компании Microsoft, которая назначила 1 - на Active Directory, 5 — на классы Active Directory, 15 - на класс Contact (Контакт).
Комплект ресурсов MicrosoftWindowsServer2000 ResourceKitсодержит инструмент по имени OIDGen, который можно использовать для создания уникальных идентификаторов OID для классов или атрибутов объекта без необходимости регистрировать OID. Этот инструмент не должен использоваться, если схема будет развертываться вне вашей организации. Для внешнего развертывания Microsoft предлагает сгенерировать и зарегистрировать ваш новый OID. Подробности см. на сайте http://msdn.microsoft.com/certification/ad-registration.asp.
На рисунке 2-2 показано создание нового атрибута с помощью оснастки Active Directory Schema (Схема Active Directory).

Рис. 2-2. Создание нового атрибута схемы

Примечание. Добавление нового атрибута к схеме не подразумевает, что атрибут будет автоматически доступен из любого средства администрирования. Инструментальные средства администрирования, подобные Active Directory Users And Computers (Пользователи и компьютеры Active Directory), показывают только некоторые атрибуты для каждого класса и не показывают атрибуты, которые добавляете вы. Если вы хотите, чтобы новый атрибут появился в инструменте администрирования, нужно изменить существующий инструмент или создать ваш собственный. О том, как изменять и создавать инструментальные средства администрирования, см. в разделе Directory Services (Службы каталога) документа Platform SDK на сайте http:// msdn.microsoft.com/library/default.asp?url=/library/en-us/ netdir/ad/extending_the_user_interface_for_directory_objects.asp.
Дезактивация объектов схемы
Расширение схемы не является сложной операцией, но перед ее осуществлением необходимо провести предварительное планирование, ведь все изменения схемы являются необратимыми. Объекты не могут быть удалены из схемы. Если вы сделаете ошибку при расширении схемы, вы можете отключить (дезактивировать) объект. В Windows Server 2003 дезактивированные объекты схемы могут снова использоваться при необходимости, а новые объекты схемы могут создаваться с тем же самым именем, которое имел дезактивированный объект.
Есть несколько моментов, которые надо иметь в виду при дезактивации класса схемы и объектов атрибутов. Сначала вы можете дезактивировать только классы и атрибуты, которые вы специально создавали, т.е. объекты Category2. Вы не можете дезактивировать объекты Category1 или базовую схему. Нельзя отключить атрибут, являющийся членом класса, который не дезактивирован. Это ограничение предотвращает ошибки в создании новых экземпляров недезактивированного класса, если становится нужен дезактивированный атрибут.
Чтобы дезактивировать объект атрибута или класса Category2, установите булевое значение атрибута isDefunctобъекта схемы на true(истина). Это можно выполнить, используя инструмент ADSI Edit (Редактирование ADSI) или оснастку Active Directory Schema (Схема Active Directory). На рисунке 2-3 показано, какие флажки параметров установки надо очистить для дезактивации атрибута EmployeeStartDate, созданного в примере, представленном ранее.
После того как объект схемы был дезактивирован, он считается несуществующим. Сообщения об ошибках в случае попытки создания нового экземпляра несуществующего класса или атрибута те же самые, которые появляются, если класс или атрибут схемы не существуют. Единственное действие, которое можно выполнить с дезактивированным
объектом схемы, состоит в его повторной активации. Для этого просто установите атрибут isDefuntна false(ложь). После активации несуществующего объекта схемы его можно снова использовать для создания новых экземпляров класса или атрибута. Процесс дезактивации/активации не влечет за собой никаких неблагоприятных последствий.

Рис. 2-3. Использование оснастки Active Directory Schema( Схема Active Directory) для дезактивации атрибута схемы