ГЛАВА

Служба каталогов
Active Directory

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

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

Служба каталогов NTDS

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

У каждого домена свое уникальное имя. Оно может отражать либо его
функциональное назначение (например, DEVELOPERS_DOM), либо гео-
графическое расположение (например, MOSCOW_EAST), либо что-то,
понятное лишь одному автору этого имени (например, MASTER_DOM1).

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

предоставления им такой возможности между доменами устанавлива-
ются доверительные отношения. Эти отношения могут быть как одно-
сторонними (например, домен А доверяет домену Б, но не наоборот),
так и двусторонними (оба домена доверяют друг другу). Доверительные
отношения не транзитивны, иными словами, если домены А и В дове-
ряют домену Б, то это не означает по умолчанию, что А и В доверяют
друг другу. При организации корпоративных сетей используются четы-
ре модели доверительных отношений: модель с одним доменом, модель
с одним мастер-доменом, модель с несколькими мастер-доменами и
модель полностью доверительных отношений. Подробно об этих мо-
делях см. [I].

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

Еще одно слабое место NTDS — относительно невысокая емкость до-
менов. В одном домене может быть не более 40 000 учетных записей,
что опять-таки мало пригодно для крупных организаций.

Кроме того, в домене может существовать только один первичный кон-
троллер домена и несколько резервных. Модификация базы учетных
записей выполняется только на первичном контроллере, а если после-
дний временно недоступен — сеть становится неуправляемой.

Что такое Active Directory

Служба каталогов Active Directory (AD) — сервис, интегрированный с
Windows NT Server. Она обеспечивает иерархический вид сети, нара-
щиваемость и расширяемость, а также функции распределенной безо-
пасности. Эта служба легко интегрируется с Интернетом, позволяет
использовать простые и интуитивно понятные имена объектов, пригод-
на для использования в организациях любого размера и легко масшта-
бируется. Доступ к ней возможен с помощью таких знакомых инст-
рументов, как программа просмотра ресурсов Интернета.

AD не только позволяет выполнять различные административные за-
дачи, но и является поставщиком различных услуг в системе. На при-
веденном ниже рисунке схематично изображены основные функции
службы каталогов.

В Active Directory концепция пространства имен Интернета объедине-
на с системными службами каталогов, что дает возможность единым
образом управлять различными пространствами имен в гетерогенных

средах корпоративных сетей. В качестве основного в AD используется
легкий протокол доступа к каталогу LDAP (lightweight directory access
protocol), позволяющий действовать за рамками операционной систе-
мы, объединяя различные пространства имен. Active Directory может
включать в себя каталоги других приложений или сетевых операцион-
ных систем, а также управлять ими, что значительно снижает нагрузку
на администраторов и накладные расходы.

Каталог — поставщик услуг в системе

Active Directory не является каталогом Х.500, как иногда считают. Она
использует лишь информационную модель Х.500 (без избыточности,
присущей последнему), а в качестве протокола доступа — LDAP. В ре-
зультате достигается так необходимая в гетерогенных системах высо-
кая степень взаимодействия.

LDAP — стандартный протокол доступа к каталогам (RFC1777) — был
разработан как альтернатива протоколу доступа Х.500. В Active Directory
поддерживаются как LDAP v2, так и LDAP v3.

HTTP — стандартный протокол для отображения страниц Web. Active
Directory дает возможность просмотреть любой объект в виде страни-
цы Web. Расширения Internet Information Server, поставляемые совмес-
тно со службой каталога, преобразуют запросы к объектам каталога в
страницы HTML.

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

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

Еще одна особенность Active Directory — поддержка нескольких хра-
нилищ, в каждом из которых может находиться до 10 миллионов объек-
тов. Понятно, что при таких возможностях эта служба каталогов пре-
красно проявляет себя как в малых сетях, так и в больших системах.

Базовые термины и концепции

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

Сфера влияния

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

Пространство имен

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

Объект

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

Контейнер

Контейнер — это объект каталога, который может содержать в себе
другие объекты (как, например, папка —это контейнер для документов,
а шкаф — контейнер для папок). Контейнер каталога является контей-
нером объектов каталога.

Дерево

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

На рисунке внешний вид дерева показывает взаимосвязи между объек-
тами.

Имя

Имена используются для идентификации объектов в Active Directory.
Существует два вида имен: отличительное имя DN (distinguished name)
и относительно отличительное имя RDN (relatively distinguished name).

Отличительное имя объекта содержит имя домена, в котором нахо-
дится объект, а также полный путь к этому объекту в иерархии контей-
нера. Например, отличительное имя для идентификации пользователя
Fyodor Zubanov в домене MicrosoftAO.RU будет выглядеть следующим
образом:

/0=Internet/DC=RU/DC=MiсrosoftAO/CN=Users/CN=Fyodor Zubanov

Относительное отличительное имя объекта — часть отличитель-
ного имени, являющаяся атрибутом объекта. В приведенном при-
мере таковым для объекта пользователя Fyodor Zubanov является

CN=Fyodor Zubanov, a RDN его родительского объекта — CN=Users.

Контексты имен и разделы

Active Directory состоит из одного или нескольких контекстов имен или
разделов. Контекст имени — это любое смежное поддерево каталога.
Контексты имен являются единицами тиражирования. Для любого оди-
ночного сервера всегда есть три контекста имен:

— схема;

— конфигурация (топология тиражирования и относящиеся к нему
метаданные);

— один или несколько контекстов имен пользователей (поддеревья,
содержащие действительные объекты каталога).

Домены

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

Дерево доменов

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

Доверительные отношения Kerberos

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

В Windows NT 5.0 доверительные отношения между доменами основы-
ваются на протоколе защиты Kerberos. Эти отношения транзитивны
(сравните с описанием доверительных отношений для NTDS), то есть
если домен А доверяет домену Б, а домен Б доверяет домену В, то до-
мен А также доверяет домену В. На рисунке изображены домены с точ-
ки зрения доверия.

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

Взгляд на домены с точки зрения пространства имен

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

Лес

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

Несколько деревьев в лесу

Узлы

Узел — это место расположения в сети серверов с Active Directory, В
качестве узлов могут выступать одна или несколько подсетей TCP/IP,
что позволяет конфигурировать доступ к каталогу и тиражирование с
учетом физической сети. Когда пользователь входит в сеть, сервер с
Active Directory не надо долго искать — ведь он находится в том же
самом узле и рабочей станции «известно», как добраться до него по
TCP/IP.

Схема

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

Модель данных

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

Глобальный каталог

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

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

Архитектура Active Directory

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

Основная структурная единица Active Directory — дерево доменов, свя-
занных доверительными отношениями друг с другом. Внутри каждого
домена может располагаться иерархия организационных единиц (OU).
Иерархия OU внутри одного домена никак не связана с иерархией OU
в других доменах. Наоборот, они полностью независимы.

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

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

бе ИТ выполнять глобальное администрирование или вмешаться в де-
ятельность другой OU.

Архитектура Active Directory

Такая гибкость позволяет организовать каталог в точном соответствии
со структурой Вашего предприятия. Причем, возможно отразить как
централизованную, так и децентрализованную, а также некоторую сме-
шанную модель управления предприятием. Например, дерево доменов
может быть организовано по централизованной модели, а OU внутри
доменов — по децентрализованной.

Как уже упоминалось, внутри каждого домена — своя политика безо-
пасности (подробнее об этом — в главе 2). Этой политикой определя-
ются, в частности, требования к паролям, время жизни билетов Кег-
beros, блокировки учетных записей и т. д. При создании учетной запи-
си в домене для нее генерируется идентификатор безопасности (SID),
частью которого является идентификатор домена, выдавшего SID. Это
позволяет легко определять, какому домену принадлежит пользователь
или группа и каковы их права доступа к ресурсам. Таким образом, мож-
но говорить о физических границах безопасности домена, в рамках
которых и выполняется его администрирование.

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

Использование схемы

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

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

Также можно задавать новые свойства, в том числе и существующим
классам. При этом все свойства можно разделить на обязательные и
возможные. Все обязательные свойства необходимо указывать при со-
здании объекта. Например объект «пользователь» обязательно должен
иметь общее имя en (common name), пароль и SamAccountName (имя,
используемое для обратной совместимости с предыдущими версиями).

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

Понятно, что такая свобода модификации и наращивания каталога
должна опираться на мощные механизмы хранения и поиска инфор-
мации. В Active Directory таким механизмом хранения служит ESE (Exten-
sible Storage Engine) — улучшенная версия Jet-базы данных, использую-

щейся в Microsoft Exchange версий 4 и 5.х2. В новой базе может содер-
жаться до 17 терабайт данных, до 10 миллионов объектов.

Пример модификации схемы

Еще одна особенность ESE — там хранятся только реально используе-
мые значения свойств. Например, для объекта user определено по умол-
чанию порядка 50 свойств. Но если Вы описали только 4 (имя, фами-
лию, общее имя и пароль), то место для хранения будет отведено толь-
ко для этих атрибутов. По мере описания других атрибутов место для
них будет выделяться динамически.

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

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

Система именований

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

2 В будущих версиях Microsoft Exchange механизм базы данных будет таким
же, как и в Active Directory.

AD, а затем организовывать каталоги, независимо от их расположения
и использующих их операционных систем.

Другая важная особенность Active Directory — избыточная поддержка
нескольких стандартных систем именований. В качестве собственной
системы имен в AD применяется DNS (Domain Name System); в то же
время она может использовать LDAP или HTTP для обмена информа-
цией с приложениями или иными каталогами.

Поддержка DNS

В Active Directory объединены лучшие возможности Х.500 и сервиса
обнаружения DNS . DNS — сервис, наиболее часто используемый как в
Интернете, так и в интрасетях. Он с успехом применяется для преоб-
разования имени в IP-адрес как в масштабах Интернета, так и в неболь-
ших сетях.

DNS как поисковая служба Windows NT

Active Directory использует DNS в качестве своего поискового сервиса.
Имя домена в AD — не что иное,-как полностью определенное имя DNS.
Например, fyodor.ru может быть как доменом DNS, так и доменом
Windows NT. (Вспомните, что в предыдущих версиях Windows NT имя
домена было NetBIOS-именем.) Указывая имя FyodorZ@microsoft.com,
можно в равной степени рассматривать его и как почтовый адрес в
Интернете, и как имя пользователя в домене Windows NT. На рисунке
видно, что домены Windows NT могут размещаться в Интернете или
интрасетях так же, как и любые иные ресурсы — посредством DNS.

Традиционно DNS был присущ один недостаток — статичность базы,
что вело к необходимости обновлять данные и тиражировать измене-
ния на другие серверы DNS вручную. В Windows NT 4.0 было реализо-

вано решение, объединяющее сервис DNS с сервисом WINS и позволяв-
шее динамически обновлять базу имен. Кроме того, в состав операци-
онной системы был включен графический инструмент для админист-
рирования DNS, что позволяло легко освоить эту «науку» даже неиску-
шенным пользователям.

«Сладкая парочка» DNS+WINS работала следующим образом. При по-
ступлении от DNS-клиента запроса на разрешение имени (например,
mydesktop.mycorp.ru) разрешение имени хоста выполнялось на серве-
ре WINS, к которому обращался сервер DNS, и которому возвращался
разрешенный IP-адрес. Такая конфигурация делала возможным исполь-
зование DHCP (Dynamic Host Configuration Protocol) для динамическо-
го назначения адресов. Хотя интеграция DNS с WINS и была времен-
ным решением, она хоть немного скрасила жизнь администраторам до
принятия стандарта на динамический DNS3.

В динамическом сервере DNS обновлением и тиражированием базы
занимается непосредственно сервер. Серверы, на которых установле-
на служба каталогов Active Directory, используют динамический DNS для
публикации самих себя в базе DNS. Если Вы уже начали применять
комбинацию WINS-DNS, то можете считать, что подготовили почву для
прозрачного перехода к динамическому DNS.

Поддержка имен стандартных форматов

Форма именований, принятая в каталоге, влияет, как на пользователей,
так и на приложения. Например, если Вы желаете отыскать объект в
каталоге, то должны точно указать имя свойства, применяемого в каче-
стве критерия поиска.

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

• RFC822. Этот стандарт именований хорошо знаком пользователям
Интернета. Кто из Вас не встречался с формой имя@домен, отправ-
ляя или получая сообщения по электронной почте? Если Вы, напри-
мер, хотите задать вопрос Билу Гейтсу, то можете воспользоваться
адресом askbill@microsoft.com. Адрес в таком формате можно не толь-
ко поместить на визитной карточке, но и использовать для входа и
систему.

• HTTP URL. Как упоминалось ранее, к службе каталогов Active Direc-
tory можно обратиться по протоколу HTTP, Для этого необходимо
указать имя URL, формат которого также хорошо знаком пользова-
телям Интернета: http : //имя-домена/путь-к-странице. При этом имя

домена — это имя сервера, на котором установлена служба каталога,
а путь к странице — путь в иерархичной структуре каталога к инте-
ресующему объекту. Например:

HTTP://MyServer.MyCorp.Ru/BIN/Division/Finance/Russian/IvanDemido.

• LDAP URL и имена Х.500. В Active Directory поддерживается доступ
и по протоколу LDAP. То, что имена LDAP сложнее по сравнению с
именами Интернета, не так важно — ведь обычно LDAP использует-
ся приложениями. В рамках LDAP действуют соглашения об имено-
вании Х.500, называемые атрибутированным именованием. Имя при
этом состоит из URL сервера, на котором располагается каталог, и
далее — атрибутированного имени объекта. Например:

LDAP://My Server.MyCorp.Ru/CN=IvanDemidov,OU=Russian,OU=Finance,
OU=Division,0=MyCorp,C=RU

• Имена UNC. В Active Directory поддерживается также и соглашение
об универсальном именовании, которое традиционно используется
в сетях Windows NT для ссылок на совместно используемые ресур-
сы: тома, принтеры и файлы. Вы можете обратиться к файлу, опубли-
кованному в Active Directory, например, так:

\\MyServer.MyCorp,Ru\Division.Finance.Russian,MyVolume\WordDocs\
YearBudget.doc

Смежные и раздельные пространства имен

В каталоге LDAP пространство имен может быть либо смежным, либо
раздельным. В первом случае имя дочернего домена всегда содержит
имя родительского домена. Например, если домен с именем DC=Finan-
се, DC=MyCorp, DC=Ru — дочерний для домена DC=MyCorp, DC=Ru, то это про-
странство смежных имен. Имя родительского домена всегда может быть
восстановлено при отбрасывании первой части дочернего имени.

В пространстве раздельных имен родительский и дочерний домены не
связаны друг с другом непосредственно. Например, хотя домен DC=Fi-
nance,DC=Ru — дочерний для домена DC=MyCorp,DC=Ru, его имя не
содержит имени родительского домена.

Смежные имена или раздельные важно при поиске. В случае примене-
ния смежных имен на контроллере домена всегда создаются ссылки
(referrals) на дочерние домены. При использовании раздельных имен
поиск останавливается и ссылки не создаются.

Одновременное использование смежных и раздельных имен делает
механизм поиска в древовидной структуре сложным для понимания.
Поэтому в Active Directory вводятся понятия деревьев и леса.

Тиражирование Active Directory

Active Directory использует тиражирование типа мульти-мастер. Как уже
упоминалось, в этой службе каталогов более не существует различий
между контроллерами доменов — они все равноправны. Изменения,
внесенные в каталог на одном контроллере, тиражируются на остальные.

Но хотя концептуально такой подход проще существовавшей в преды-
дущих версиях модели с одним главным и несколькими резервными
контроллерами домена, он требует принятия специальных мер по син-
хронизации тиражируемой информации. Тиражирование Active Direc-
tory основано не на временных интервалах, а на последовательных
номерах обновлений USN (Update Sequence Numbers). В каждом кон-
троллере домена имеется таблица, где записаны как свой собственный
номер USN, так и USN партнеров по тиражированию. При тиражирова-
нии происходит сравнение последнего известного USN партнера с тем,
который сообщается. И если сообщенный номер больше записанного,
запрашиваются все изменения у партнера по тиражированию (такой
тип тиражирования носит название запрашиваемого). После обновле-
ния данных USN на контроллере домена становится равным значению,
полученному от партнера.

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

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

• По временной отметке. Если свойства имеют одинаковый номер
версии, то проверяется временная отметка, создаваемая вместе с но-
мером версии при модификации свойств. При этом предполагается,

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

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

Давайте проиллюстрируем все сказанное на примере. Допустим, что два
администратора на разных контроллерах домена вносят изменения в
свойства группы AcctUsers. Один из них предоставил право модифика-
ции каталога FinRus, а второй — право модификации каталога FinAd-
min, но сделал это на минуту позже первого. При согласовании версий
на третьем контроллере домена будет обнаружено, что номера версий
совпадают, а время модификации на втором контроллере — более позд-
нее. Поэтому в расчет будет принято только изменение, сделанное вто-
рым администратором.

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

Узлы и домены

Концепция узлов (sites) используется продуктами семейства Microsoft
BackOffice для минимизации графика в глобальной сети. К сожалению,
в каждом продукте эта концепция трактуется по-своему. В Windows NT 5.0
вводится еще одно новшество: концепция не оптимизирована под ка-
кое-либо определенное приложение, а предполагает в качестве осно-
вы сеть IP, для которой обеспечиваются наилучшие условия подключе-
ний. В будущем планируется, что все приложения BackOffice будут ис-
пользовать именно эту концепцию узла.

Узел с Active Directory состоит из одной или нескольких подсетей IP.
Администратор может определять эти подсети, а также добавлять к ним
новые. При этом он исходит из следующих посылок:

• оптимизация графика тиражирования между узлами по медленным
линиям;

• создание клиентам наилучших условий для быстрого обнаружения
ближайших к ним контроллеров.

Тиражирование внутри узла и между узлами осуществляется по различ-
ным топологиям. Внутри узла контроллер домена задерживает опове-
щение о сделанных изменениях на некоторый устанавливаемый про-
межуток времени (по умолчанию равный 10 минутам). В отличие от

Microsoft Exchange в Active Directory можно изменять топологию тира-
жирования внутри узла. По умолчанию это двунаправленное кольцо,
однако Вы можете полностью переопределить топологию и задать ее,
скажем, в виде звезды.

В любом случае служба каталогов будет отслеживать целостность то-
пологии, то есть ни один контроллер домена не будет исключен из
процесса тиражирования. Для этого на всех контроллерах домена ис-
полняется отдельный контрольный процесс, так называемый КСС
(Knowledge Consistency Checker). КСС восстанавливает топологию ти-
ражирования в случае нарушения.

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

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

Деревья и леса

Вспомним определения, данные в начале этой главы.
Итак, дерево характеризуется:

• иерархией доменов;

• пространством смежных имен;

• доверительными отношениями Kerberos между доменами;

• использованием общей схемы;

• принадлежностью к общему глобальному каталогу.
Лес характеризуется:

• одним или несколькими наборами деревьев;

• раздельными пространствами имен между этими деревьями;

• доверительными отношениями Kerberos между доменами;

• использованием общей схемы;

• принадлежностью к общему глобальному каталогу.

На рисунке изображен пример леса. DNS-имя корневого домена в ле-
вом поддереве — microsoft-com.; LDAP-имя этого домена в Active Direc-
tory можно записать как DC=microsoft, DOCOM, o=Internet. Корневое имя
домена во втором поддереве — DC=MSN, DC=COM, o=Internet. Хорошо вид-
но, что пространства имен разделены.

Пример леса

Поддомены в каждом из деревьев принадлежат к смежному простран-
ству имен. Например LDAP-имя для российского домена внутри Micro-
soft могло бы выглядеть как DC=russia,DC=microsoft,DC=COM,o=Internet.

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

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

Управление деревом и лесом

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

Как и любыми, объектами службы каталогов необходимо управлять.
Представьте себе небольшую фирму, организовавшую деревья и леса

Active Directory в соответствии со своей структурой. Более чем очевид-
но, что это нельзя сделать раз и навсегда. Предприятие может расти,
его структура — перестраиваться, отделы и подразделения — исчезать
или создаваться заново. В соответствии с этими изменениями надо
будет модифицировать и структуру сети, и такие возможности в Active
Directory предусмотрены. К операциям реструктуризации и переимено-
вания объектов в каталоге относятся:

• простое добавление доменов;

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

• переименование доменов;

• переразмещение деревьев доменов и лесов;

• слияние деревьев в лес.

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

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

Любой объект в каталоге Active Directory может иметь несколько имен:

общее, относительное и т. п. Единственным всегда неизменным иден-
тификатором объекта является Глобальный уникальный идентифика-
тор GU1D (Globally Unique Identifier). GUID - это многозначное число,
создаваемое контроллерами домена. Алгоритм создания идентифика-
тора не допускает дублирования. Именно этот никогда не изменяемый
идентификатор может использоваться в Active Directory для того, что-
бы свободно переименовывать домены, как и любые объекты4.

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

4 В Windows NT 5.0 скорее всего не будет реализован механизм переименова-
ния доменов, так как разработчики столкнулись с целым рядом непредви-
денных трудностей, преодоление которых перенесено к моменту выхода
Windows NT 6.0.

Включение домена в лес не сложнее подключения к дереву доменов
и рассматривалось ранее.

Если используется сервер динамического DNS Windows NT 5.0, то при
перемещении или переименовании домена средствами администриро-
вания автоматически выполняется коррекция записей в базе DNS. При
использовании UNIX DNS-сервера создается файл, в который заносят-
ся и подлежащие удалению, и новые записи. Дополнительно в Windows
NT Workstation 5.0 автоматически изменяются настройки TCP/IP, и вно-
сится новое имя домена.

Доступ к Active Directory

Теперь, имея общее представление о том, что же такое Active Directory,
поговорим о доступе к объектам в каталоге и управлении ими. Как уже
упоминалось, в каталоге содержится информация обо всех объектах
системы: дисках, устройствах, сетевых ресурсах, пользователях, груп-
пах, доменах и т. п. Доступ к этим объектам разделен на функциональ-
ные группы, для которых созданы слепки, используемые консолью уп-
равления ММС (Microsoft Management Console). Подробно ознакомить-
ся с использованием каждого из слепков можно и в главе б и других
главах, посвященных отдельным возможностям операционной систе-
мы. А сейчас рассмотрим лишь самые общие возможности доступа к
каталогу.

Управление узлами

Конфигурируя узлы, Вы управляете топологией тиражирования. Для
доступа к информации об узлах необходимо загрузить в ММС слепок
Microsoft Site Replication Manager. Соответствующее окно примет вид,
изображенный на рисунке. Загружая этот слепок впервые, Вы увидите
один узел, указанный во время установки операционной системы и имя
своего собственного компьютера в этом узле.

Окно Microsoft Management Console - Microsoft Site Replication
Manager

Для описания узла необходимо описать входящие в него подсети. Опи-
сание подсетей выполняется в формате www, xxx. yyy. zzz/mm, где первая
часть (до косой черты) — адрес подсети, a mm — число немаскируемых
разрядов, считая от начала. Например, 155.1-1.0/22. Все маскируемые
разряды должны быть равны 0.

Чтобы добавить новый узел, подведите мышь к папке Sites в левой ча-
сти окна, щелкните ее правой кнопкой и выберите из контекстного
меню команду New и подменю Site. В поле появившегося диалогового
окна укажите имя нового узла, включаемого в топологию тиражирования.

Управление службой каталогов

Загрузив слепок Directory Service Manager, Вы увидите окно, аналогич-
ное изображенному на рисунке. В левой части окна находится дерево
доменов (или один домен, если это единственный контроллер домена
в сети). Для каждого домена существуют: контейнер Computers, где пе-
речислены компьютеры и их роль в домене, контейнер System с инфор-
мацией о системных сервисах и объектах, а также контейнер Users, в
котором хранится информация обо всех пользователях.

Диалоговое окно Microsoft Management Console - Directory
Service Manager

Для добавления нового объекта в систему, щелкните правой кнопкой
мыши контейнер, в который Вы желаете поместить новый объект. Вы-
берите из контекстного меню команду New, а затем — тип объекта.

Список добавляемых объектов зависит от типа выбранного контейне-
ра. Так, например, в контейнер System можно поместить:

• Computer (компьютер);

• Contact (контакт);

• DistributionList (список рассылки);

• Group (группа);

• GroupOfNames (группа имен);

• Local policy (локальная политика);

• nTDSsettings (установки NTDS);

• organizationalPerson (персона организации);

• person (персона);

• printQueueu (очередь печати);

• publicFolder (общая папка);

• remoteAddress (удаленный адрес);

• site (узел);

• storage (хранилище);

• user (пользователь);

• volume (том).

Добавление нового объекта в каталог

Для редактирования свойств любого объекта надо щелкнуть его пра-
вой кнопкой мыши и в контекстном меню выбрать команду Properties.
Внешний вид диалогового окна, которое появится вслед за этим, в зна-
чительной степени зависит от типа объекта. Например, для домена в
этом окне будет вкладка Trust relationships, а для пользователя —
вкладка его свойств. Общими для всех объектов будут вкладки Object,
где указывается путь к объекту в каталоге, и Security, где можно опре-
делять права доступа к этому конкретному объекту.

Ниже на рисунке изображено диалоговое окно, появляющееся по ко-
манде Properties с вкладками General, Managed by. Object и Security.

Вкладка General позволяет определять локальную политику, которая

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

Диалоговое окно Computer Properties, вкладка General

Выбрав вкладку Object, можно просмотреть некоторые общие парамет-
ры каждого объекта в каталоге: путь к нему, его класс, даты создания и мо-
дификации, а также номер версии. Сравнив номера версий (USN) объек-
тов на разных компьютерах, Вы отследите тиражирование каталогов.

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

На этой вкладке показаны только основные права и запреты на доступ
к объекту и список учетных записей пользователей, этими правами
обладающих. Как показано на рисунке, если объект — домен, то общи-
ми правами доступа являются полный доступ (Full Control), чтение
(Read), запись (Write), создание (Create all child objects) и удаление
дочерних объектов (Delete all child objects).

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

группы Creators, и включить в новую, обладающую требуемыми права-
ми. Учитывая, что подобных «исключений из правил» в большой орга-
низации множество, практика создания отдельных групп для каждого
из них может превратить администрирование в кошмар. Так что явные
запрещения существенно облегчают работу и позволяют нашему
пользователю оставаться членом группы Creators.

Диалоговое окно Computer Properties, вкладка Object

Диалоговое окно Computer Properties, вкладка Security

Если Вам требуется более тонкая настройка доступа к объекту, щелк-
ните кнопку Advanced. Появится диалоговое окно Access Control Set-
ting for Computer со списком контроля доступа к объекту.

Редактор списка контроля доступа к объекту

В списке перечислены разрешения на доступ, и для каждого из них
указаны:

• тип (разрешен или запрещен);

• имя учетной записи (в формате имя домена/имя учетной записи);

• вид доступа (зависит от типа объекта; если доступ сложный, указы-
вается Special Access);

• к чему применим (только для контейнерных объектов; в зависимос-
ти от типа объекта Вам может встретиться один из следующих вари-
антов: «только к этому контейнеру», «к этому контейнеру и всем вло-
женным в него>>, «только ко вложенным контейнерам», «только ко
вложенным неконтейнерным объектам» и т. д.).

По умолчанию объект наследует свойства родительского объекта. Если
этого не требуется, то надо выключить флажок Inherit permissions
from parent.

Чтобы отредактировать выделенную строку в списке контроля доступа
(назначить сложные права доступа или изменить глубину воздействия),
щелкните View/Edit. На экране появится диалоговое окно Permission
Entry for Computer.

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

Диалоговое окно Permission Entry for Computer

Поиск в каталоге

Для поиска объекта в каталоге (или в любой его ветви) надо в меню
диалогового окна Microsoft Directory Service Manager выбрать ко-
манду Find. Появится диалоговое окно Find, знакомое как пользовате-
лям Windows NT 4.0, так и пользователям Windows 95. Однако внешний
вид окна немного изменился. Теперь можно выбрать и предопределен-
ные категории объектов, и выполнить более сложный запрос. В пер-
вом случае список категорий содержит:

• Users and Groups (пользователи и группы);

• Computers (компьютеры);

• Shared file folders (совместно используемые папки файлов);

• Directory folders (папки каталога).

Стандартный поиск, в каталоге

В поле In можно выбрать ту ветвь в каталоге, где будет выполняться по-
иск. Результаты поиска будут стандартным образом выведены в поле в
нижней части окна. Указав на любой элемент в списке результатов
поиска, Вы увидите его полное LDAP-имя.

Помимо стандартных запросов, можно формировать более сложные,
комбинированные из нескольких простых. Для этого в поле Find вы-
берите пункт Custom Search. В появившемся диалоговом окне Find
Custom Search Вы увидите три новых поля: Field, Condition, Value.

Сложный поиск в каталоге

Поле Field позволяет выбрать имя объекта каталога. Для этого щелк-
ните одноименную кнопку, в появившемся меню выберите класс объек-
тов, а затем — свойство объекта. Перечень свойств стандартных объек-
тов приведен в Приложении А. Если Вы хотите задать класс, отличный
от перечисленного в меню, то выберите в нем пункт More. На экране
появится список всех доступных классов.

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

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

Например, если Вы хотите найти всех пользователей, общие имена
(сп) которых начинаются с буквы U, то в этом случае Вам надо выб-
рать класс users, для него свойство — сп. Условием станет строка Begin
f rom, а в качестве значения укажите U. Щелкните Add, и запрос появит-
ся в списке запросов. Кстати, Вы можете добавить в этот список до-
полнительные запросы или удалить запросы, включенные туда ранее.
Когда все необходимые запросы будут сформированы, нажмите кноп-
ку Find.

Схема: классы, атрибуты
и их модификация

Для того, чтобы добраться до схемы, загрузите соответствующий сле-
пок ММС: в меню консоли управления выберите Console и дайте ко-
манду Add/Remove Snap-In. В появившемся окне щелкните Add и в
списке доступных слепков укажите Schema manager. Появится диало-
говое окно Microsoft Management Console.

Окно ММС с загруженным слепком Schema Manager

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

Каждый атрибут в схеме также представлен объектом, определяющим
этот атрибут. Объекты являются экземплярами класса Attribute Schema
и могут иметь атрибуты, перечисленные в Приложении В. Атрибуты
могут содержать данные, тип которых определяется синтаксисом. Для
каждого атрибута возможен только один синтаксис, например, Integer,

String, BOOL. Синтаксисы в Active Directory определены Microsoft и не
могут быть изменены, также невозможно добавлять новые. Синтакси-
сы не представлены никакими объектами в каталоге. Создавая новый
атрибут, необходимо определить его синтаксис.

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

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

Итак, в реестре надо выполнить следующее добавление:

Ветвь HKEY_LOCAL_MACHINE

Ключ System\CurrentControlSet\Services\NTDS\Parameters
Имя Schema Update Allowed
Тип DWORD
Значение Любое целое положительное число

Целостность каталога требует, чтобы изменения вносились только на
одном компьютере в каждый момент времени с последующим тиражи-
рованием их на другие контроллеры домена. В противном случае воз-
можен конфликт между изменениями. Для предотвращения подобных
конфликтов вводится понятие мастер схемы, обозначающее именно
тот контроллер, на котором, и только на котором, возможна модифи-
кация схемы. В принципе, таковым может быть назначен любой кон-
троллер в домене, но по умолчанию мастером схемы становится пер-
вый установленный контроллер домена. Процесс определения того,
какой из компьютеров может выступать в этой роли называется опера-
цией единственного плавающего мастера (floating single master opera-
tion). Текущий мастер схемы отличается значением атрибута FSMO-
Role-Owner для контейнера схемы (CN=schema, CN=configu ration, DC=...).

Если Ваш компьютер — единственный контроллер домена, то масте-
ром схемы является именно он. Если в домене несколько контролле-
ров, Вы можете принудительно потребовать от нужного контроллера
стать мастером. Для этого к корневому DSE (объект с пустым DN) до-
бавьте атрибут becomeSchemaMaster равный 1. Сервер пошлет текущему
мастеру запрос на смену мастера и тот изменит атрибут FSMO-Role-
Owner на имя контроллера, запросившего эту операцию, после чего

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

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

Добавление нового класса

Для добавления нового класса щелкните правой кнопкой контейнер
Classes в схеме и выберите в контекстном меню команду Add Class.
Появится диалоговое окно Create New Class, в поля которого надо
ввести несколько обязательных параметров:

• в поле Common Name (en) — общее имя класса;

• в поле LDAP Display — имя, используемое LDAP;

• в поле Unique X. 500 Object ID — уникальный идентификатор клас-
са (вопросы получения правильных идентификаторов рассмотрены
в конце этого раздела);

• в поле Parent Class — родительский класс; его указание позволяет
новому классу наследовать все атрибуты родительского. Если новый
класс не имеет родителей, то в поле указывается «Тор».

Лишкуг(1в(№ ЧК1К1 Create New Class

Модификация классов

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

Внимание! Если Вы только что создали новый класс, то он может не
отобразиться в списке классов. В этом случае закройте консоль управ-
ления и заново откройте слепок Schema Management. Новый класс бу-
дет расположен в конце списка.

На экране появится диалоговое окно Class Properties, имеющее три
вкладки: General, Relationship и Attributes. В первой из них отобра-
жаются параметры класса, указанные при его создании.

Диалоговое окно Class Properties, вкладка General

Вкладка Relationship позволяет описать взаимоотношения редактиру-
емого класса с остальными. В этом диалоговом окне показан родитель-
ский класс редактируемого класса, изменить который нельзя — выбор
родительского класса возможен только в момент создания нового. Но
можно добавить вспомогательные классы в список поля Auxiliary
Classes. В этом случае редактируемый класс будет также наследовать
все их обязательные и возможные атрибуты за исключением возмож-
ных старших классов.

Возможные старшие классы — это классы, которые могут выступать в
роли родительских для рассматриваемого. Вы можете дополнять спи-
сок этих классов, щелкая кнопку Add, расположенную рядом с полем
Possible Superior.

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

Для удаления из списков вспомогательного класса или возможного
старшего класса выделите его имя в соответствующем поле и щелкни-
те кнопку Delete.

Диалоговое окно Class Properties, вкладка Relationship

И, наконец, Вы можете указать для класса обязательные и возможные
атрибуты. Для этого откройте вкладку Attributes.

Диалоговое окно Class Properties, вкладка Attributes

Обязательными являются атрибуты, для которых необходимо указать
начальное значение при создании объекта данного класса. Добавьте их
в поле Mandatory и щелкните кнопку Add.

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

ные атрибуты добавляются в поле Optional, затем также следует щел-
кнуть соответствующую кнопку Add.

Для удаления атрибута из списка выделите его имя и щелкните соот-
ветствующую кнопку Remove.

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

Чтобы добавить новый атрибут щелкните правой кнопкой мыши кон-
тейнер Attributes в схеме и выберите из контекстного меню команду
Add Attribute. Появится диалоговое окно Create New Attribute, в ко-
тором следует задать несколько обязательных параметров:

• в поле Common Name — en (общее имя атрибута);

• в поле LDAP Display — имя, используемое LDAP;

• в поле Unique X. 5 00 Object ID — уникальный идентификатор атри-
бута (вопросы получения правильных идентификаторов рассмотре-
ны в конце этого раздела);

• в поле Syntax — синтаксис атрибута (тип хранимых атрибутом
данных);

• в поле Minimum — минимальное значение атрибута: для числовых
данных — минимальная величина, для строковых — минимальное
число символов в строке;

• в поле Maximum — максимальное значение атрибута: для числовых
данных — максимальная величина, для строковых — максимальное
число символов в строке.

Диалоговое окно Create New Attribute

Если атрибут может иметь несколько значений, включите флажок

Multi-valued.

•

После того, как Вы щелкните кнопку ОК, система проверит уникаль-
ность созданного атрибута и внесет его в схему.

Модификация атрибутов

Вы можете изменить некоторые свойства атрибута. Для этого дважды
щелкните нужный атрибут в списке атрибутов схемы — появится диа-
логовое окно Attribute properties. Изменить можно описание атрибу-
та, минимальное и максимальное значения, а также указать, является ли
он индексируемым.

Получение действительных идентификаторов
объектов (OID)

Возможно, Вы уже обратили внимание на идентификаторы объектов
(Х500 OID), которыми описываются классы и атрибуты. Эти идентифи-
каторы уникальны в мировом масштабе. Подобно тому, как для работы
в Интернете Вам необходим правильный адрес IP, для создания клас-
сов и атрибутов следует знать действительный диапазон OID.

Выдачей идентификаторов занимается уполномоченный ISO (Interna-
tional Standard Organization). Обратившись к нему, Вы получите ветвь
ISO-ITU OID: например, 1.23.45.66666. Внутри своей организации Вы
можете расширить эту ветвь в соответствии с потребностями. Напри-
мер, для одного из подразделений можете выделить ветвь 1.23.45.66666.1.
Тогда внутри подразделения для классов будет выделена ветвь
1.23.45.66666.1.1, а для атрибутов - 1.23.45.666666.1.2. Создаваемые внут-
ри этого подразделения классы будут иметь идентификаторы с номе-
ром 1.2 3.45.66666.1.1.Х, а создаваемые атрибуты - 1.23.45.66666.1.2.Y, где
х и у — целое десятичное не превышающее 228-!.

Заключение

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

Эта служба каталогов, использующая лучшие из стандартов имен DNS
и Х.500, LDAP, иные протоколы и богатый набор API, предоставляет гро-
мадные возможности совместимости с другими системами. Active Direc-
tory позволяет из одной точки управлять всеми ресурсами сети: файла-
ми, периферийными устройствами, подключениями к хостам, базами
данных, доступом к Web, пользователями, любыми произвольными объ-
ектами, сервисами и сетевыми ресурсами. Поддерживаемый в ней
иерархичный взгляд на систему, удобные средства администрирования
и мощные механизмы поиска позволяют значительно снизить админи-
стративные затраты.

Таким образом, можно сделать вывод: появление Active Directory сни-
мет последние ограничения на использование Windows NT в больших
организационных структурах.