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

Служба каталогов Active Directory является, без сомнения, одним из главных концептуальных новшеств системы Windows 2000 Server.

По своей сути, служба каталогов — это средство для именования, хранения и выборки информации в некоторой распределенной среде, доступное для приложений, пользователей и различных клиентов этой среды. Можно вспомнить знакомый многим системный реестр Windows и базу данных Диспетчера безопасности учетных записей (SAM) Windows NT. Служба сетевых каталогов хранит информацию об общедоступных приложениях, файлах, принтерах и сведения о пользователях.

Служба каталогов Active Directory обеспечивает эффективную работу сложной корпоративной среды, предоставляя следующие возможности:

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

Если в некоторой распределенной среде отсутствует главный, центральный каталог, то каждому приложению необходимо иметь собственный каталог, в результате чего появляются различные решения и механизмы хранения информации. К примеру, в среде Windows NT Server 4.0 пакет Microsoft Exchange использует одну службу каталога, еще одна база хранит пользовательские учетные записи, а в других распределенных компонентах, таких как Microsoft Message Queuing Server (MSMQ), все равно применяются дополнительные каталоги. Понятно, что наличие нескольких механизмов, реализующих одну и ту же задачу, — далеко не самое удачное решение. Гораздо лучше — единственная служба каталогов, доступная всем клиентам и имеющая одну базу данных, общие схему и соглашения об именовании информации, а также возможность централизованного администрирования. Active Directory используется в Windows 2000 Server по-разному. Операционная система хранит в каталоге информацию о пользовательских учетных записях, принтерах и компьютерах сети, а также многое другое. Большое значение Active Directory имеет для Windows Management Architecture (Архитектура управления Windows) — в частности, с помощью каталога ищутся серверы, на которых располагаются компоненты приложений. К службе Active Directory для хранения разнообразной информации (например, пользовательских адресных книг и сертификатов) обращается пакет Microsoft Exchange. Приложения, созданные на базе модели DCOM и Microsoft Transaction Server (MTS; в Windows 2000 называются Службами компонентов, Component Services), могут обращаться к службе каталогов для поиска удаленных объектов. Active Directory заменит службу каталога, существующую в настоящее время в MSMQ. Поскольку в Active Directory можно хранить информацию новых типов, то есть схему каталогов можно расширять, разработчики корпоративных и коммерческих приложений могут использовать существующие службы каталогов для создания своих продуктов.

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

Можно сказать, что служба Active Directory "стоит на трех китах":

В Active Directory частично реализована модель данных, описываемая стандартом Х.500. Традиционная в сетях TCP/IP служба DNS используется, в частности, для поиска контроллеров Домена, а благодаря протоколу LDAP клиенты могут по имени находить в каталоге Active Directory нужные объекты и получать доступ к их атрибутам.

Все описываемые ниже термины и концепции так или иначе касаются этих трех "составных частей" службы каталогов (однако не следует считать, что для работы Active Directory необходимы только эти компоненты!).

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

Каждый объект принадлежит по крайней мере к одному объектному классу, представляющему собой некоторое семейство объектов с определенными общими характеристиками. Класс объектов определяет тип информации, содержащейся в Active Directory для экземпляров (объектов) данного класса. В качестве примера объектных классов можно привести два стандартных класса: person и domain. Среди множества атрибутов этих классов — cn (Common-Name), userPassword (User-Password) и dc (Domain-Component), url (WWW-Page-Other), соответственно. Атрибуты могут быть как обязательными (mandatory) для данного класса (например, сn и dc), так и дополнительными (optional) (userPassword и url).

Помимо стандартных объектных классов можно описывать дополнительные классы, относящиеся к различным уровням (national и local).

Атрибуты и их типы

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

Помимо атрибутов стандартных типов можно создавать и использовать дополнительные типы атрибутов.

Контейнер

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

Информационное дерево каталога

Элементы каталога организованы в виде иерархического дерева, называемого Directory Information Tree (DIT, Информационное дерево каталога или просто Дерево каталога). Элементы, находящиеся ближе к корню дерева, обычно представляют крупные объекты, например, организации или компании; элементы, располагающиеся на ветвях этого дерева, (листья) представляют более простые объекты — пользователей, устройства, компьютеры.

Схема каталога

Схема каталога (Directory Schema) — это набор правил, описывающих структуру дерева каталога, объявления и синтаксис объектных классов и типы атрибутов, входящих в каталог.

Схема каталога гарантирует, что все добавления или изменения каталога соответствуют данным правилам, и препятствует появлению некорректных элементов, ошибочных типов атрибутов или классов.

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

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

Любая служба каталога в первую очередь представляет собой некоторое пространство имен (namespace). Пространство имен — это любая ограниченная область, в которой можно по имени обратиться к атрибутам самого объекта или к информации, связанной с этим именем. Процесс преобразования имени в ссылку на объект называется разрешением имен. (Например, в телефонном справочнике по имени абонента ищется его телефон, адрес и т. п, Файловая система — это пространство имен, в котором по имени файла можно найти сам файл.)

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

При инсталляции Windows 2000 Server и организации домена Windows 2000 (или смешанного с Windows NT 4.0 домена) необходимо иметь четкое представление о некоторых базовых понятиях служб каталога вообще и Active Directory — в частности. Без этого невозможно даже правильно сконфигурировать Windows 2000 Server, не говоря уж об эффективной организации доменов.

Домены и Контроллеры доменов

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

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

Для понимания структуры Active Directory рассмотрим сначала отличия Windows 2000 от предыдущих версий. Компьютеры на базе Windows 2000 по-прежнему объединяются в домены. Домены — это известное решение для администрирования групп, предоставляющее каждому пользователю учетную запись в конкретном домене. Однако, в отличие от Windows NT Server 4.0, где доменам давались простые строковые имена (имена NetBIOS), в среде Windows 2000 Server каждый домен должен иметь имя, отвечающее соглашениям именования доменов Domain Name System (DNS). Так, домен MainOffice при обновлении может получить новое имя типа mainqfflce.company.com. В каждом домене один или несколько компьютеров должны выполнять функции контроллеров домена. В среде Windows 2000 Server каждый контроллер домена содержит полную копию базы данных Active Directory этого домена. В Active Directory используются так называемое ядро Extended Storage Engine (ESE) и два различных протокола, обеспечивающих связь между клиентами и базой данных. Для поиска контроллера домена клиент обращается к протоколу, описанному в DNS, — "стандартной", службе каталогов, применяемой в настоящее время для сетей TCP/IP. Для доступа к данным в Active Directory клиент использует протокол Lightweight Directory Access Protocol (LDAP) (рис. 23.1).

Рис 23.1. Доступ к данным с использованием LDAP

Службы DNS и Active Directory

В большинстве современных сетей TCP/IP используется служба DNS, главное назначение которой — преобразовывать простые для запоминания имена типа company.com в IP-адреса. Для этого каждый компьютер-сервер DNS имеет набор записей с информацией о ресурсах. Каждая запись имеет некоторый тип, определяющий характер и назначение хранящейся информации. Например, запись типа А применяется для преобразования доменного имени компьютера в заданный IP-адрес, а запись типа MX — для поиска почтового сервера в определенном почтовом домене. Каждый DNS-сервер "знает" свое место в глобальном пространстве DNS-имен, что позволяет передавать неразрешенные запросы другим серверам. Поэтому — пусть и не сразу— почти каждый клиентский запрос находит нужный сервер, хранящий искомую информацию.

Интеграцию служб Active Directory и DNS можно рассматривать в трех аспектах:

Active Directory может использовать любую стандартную, законченную реализацию службы DNS: не обязательно задействовать DNS-сервер, входящий в Windows 2000 Server (например; можно использовать BIND 8.1.x). Однако лучше остановить свой выбор на нем, поскольку модули Windows 2000 более согласованы друг с другом (хранение и репликация зон и т. п.), ведь необходимо, чтобы выбранный DNS-сервер соответствовал последним стандартам. Например, для Active Directory нужен DNS-сервер, поддерживающий записи типа SRV. Записи подобного типа (SRV records), в соответствии с RFC 2052, позволяют клиентам находить нужные сетевые службы. В Active Directory служба LDAP каждого домена Windows 2000 представлена некоторой SRV-записью службы DNS. Такая запись содержит DNS-имя контроллера этого домена, по которому клиенты Active Directory могут находить IP-адрес компьютера-контроллера домена. После того как нужный контроллер обнаружен, для доступа к данным Active Directory, хранящихся на нем, клиент может использовать протокол LDAP.

Windows 2000 Server поддерживает также службу динамического именования хостов, Dynamic DNS. В соответствии с RFC 2136 служба Dynamic DNS расширяет протокол DNS, позволяя модифицировать базу данных DNS со стороны удаленных систем. Например, при подключении некоторый контроллер домена может сам добавлять SRV-запись для себя, освобождая администратора от такой необходимости.

Листья и контейнеры LDAP

После того как с помощью DNS нужный контроллер домена обнаружен, для доступа к данным Active Directory используется протокол LDAP. Как и DNS, LDAP — это стандарт, разработанный консорциумом IETF и происходящий от сложной, но не используемой широко службы каталогов Х.500, созданной в середине 80-х годов. Active Directory поддерживает не только версию 2 протокола LDAP, описанную в RFC 1777, но и версию 3, рассматриваемую в RFC 2251. В настоящее время практически все фирмы-поставщики служб каталогов предлагают LDAP-совместимые продукты, поэтому клиенты LDAP сторонних поставщиков могут обращаться к LDAP-серверу Active Directory. Протокол LDAP работает поверх TCP/IP и — как следует из названия протокола — определяет способы доступа к каталогу со стороны клиентов. Помимо механизма доступа данный протокол реализует соглашения по именованию информации в каталоге, в явном виде описывая структуру этой информации. Для клиента все данные, хранящиеся в базе LDAP, представляются в виде иерархического дерева. Каждый узел дерева (объект или элемент) может быть либо контейнером (container), либо листом (leaf). Различие между ними вполне очевидно: контейнеры могут содержать другие элементы, а листья — нет.

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

Схема Active Directory достаточно сложна и содержит сотни и сотни объектных классов и типов атрибутов. Ниже для примера перечислены некоторые интересные классы:

Каждый элемент Active Directory и каждый атрибут любого элемента имеют список управления доступом (ACL), который определяет права и возможности пользователей в отношении доступа к конкретным элементам и атрибутам. Например, список ACL может позволить одним пользователям читать атрибуты некоторого элемента, другим пользователям — читать и изменять некоторые из атрибутов, а остальным — запретить какой-либо доступ к элементу. Эффективное управление доступом невозможно без достоверной аутентификации клиентов, Active Directory использует для этой цели протокол Kerberos. (Kerberos — стандарт, созданный консорциумом IETF и поддерживаемый многими поставщиками; ключевая технология для обеспечения распределенной безопасности Windows 2000.)

Механизмы именования в Active Directory

Каждый домен в Windows 2000 имеет DNS-имя, однако DNS-имена не применяются для именования отдельных элементов базы данных Active Directory. Вместо "этого следует использовать имена, принятые в LDAP. Согласно требованиям протокола LDAP один {или — очень редко — несколько) из атрибутов элемента каталога служит для именования этого элемента. Например, для идентификации экземпляра (элемента) объектного класса user может быть задействовано значение атрибута сn; а для объекта класса organizational Unit — значение атрибута оu.

На рис. 23.2 показана гипотетическая структура очень простого домена Windows 2000 для компании BHV. Предположим, что эта компания имеет два структурных подразделения (отдел продаж и редакционную группу) и доменное имя компании — bhv.com. По функциональным обязанностям члены редакционной группы делятся на администрацию и редакторов. Практически в любом домене для деления пространства имен используются подразделения или организационные единицы (OU), и демонстрационный домен — не исключение. Ниже корня домена располагаются два подразделения: sales (отдел продаж) и office (редакционная группа). Имя каждого подразделения определяется значением ее атрибута оu.

Рис 23.2 Структура каталога простого домена Windows 2000

Ниже подразделения sales располагаются объекты класса user. Имя.каждого объекта определяется атрибутом en (Common-Name), и эти объекты хранят информацию о пользователях домена. Организационная единица office делится еще на два подразделения: Admins и Editors. Ниже располагаются элементы каталога для отдельных работников, имена которых также определяются атрибутами сп.

Для получения информации о некотором элементе, например, Director, клиент должен указать уникальное имя этого элемента, которое называется отличительным, или различающимся, именем (distinguished name). Отличительное имя — это набор имен, отражающих путь от корня дерева домена до интересующего элемента. Для элемента Director, например, отличительным именем будет cn=Director, ou=Admms, dc=bhv, dc=eom. В последних двух элементах имени dc означает domain component, эти элементы представляют DNS-имя домена в соответствии с соглашениями LDAP. Отличительные имена уникальным образом идентифицируют узлы в базе данных Active Directory, однако их нельзя назвать "дружественными". Можно не перечислять в имени все типы атрибутов явно (cn=, ou=, dc= и т. п.), а записать это имя как //bhv.com/Admins/Director. В передаваемых LDAP-пакетах всегда указывается отличительное имя, однако в пользовательском интерфейсе можно применять более удобную и простую форму имени. Помимо отличительного имени каждый объект каталога имеет относительное отличительное имя (relative distinguished name), которое является атрибутом самого этого объекта, а не образуется как цепочка имен до объекта от корня дерева. Таким образом, для элемента Director, например, относительным отличительным именем будет cn=Director. Для родительского объекта этого элемента относительное отличительное имя — ou=Admins. В Active Directory имеется несколько контекстов имен (naming contexts), или разделов (partitions), которые представляют собой законченные, непрерывные поддеревья каталога и являются объектами репликации. Каждый сервер с Active Directory имеет по меньшей мере три контекста имен:

Организация доменов: Лес и Деревья

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

Домены с непрерывными "смежными" DNS-именами могут быть объединены в дерево доменов (domain tree), или доменное дерево (рис. 23.3).

Рис 23.3. Несколько доменов можно объединить в один

Какие преимущества дает объединение доменов в подобную иерархию? Появляется возможность поиска в корневом домене, при котором также проверяются элементы в дочерних доменах. Кроме того, наличие автоматически созданных двусторонних доверительных отношений между всеми доменами, входящими в дерево, значительно упрощает администрирование всей сети. Также можно группировать домены, не имеющие "смежных" DNS-имен. В результате этого возникнет лес (forest), состоящий из нескольких доменов и/или деревьев доменов. Как и в дереве доменов, все домены, входящие в лес, связаны между собой двусторонними доверительными отношениями, используют общую схему, конфигурацию и глобальный каталог. Главное различие между деревом доменов и лесом заключается в том, что все домены, входящие в дерево, должны иметь "смежные" DNS-имена, а для доменов, образующих лес, это не обязательно.

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

Принципиальное отличие доменов Windows 2000 от доменов Windows NT 4.0 заключается в том, что все домены Windows 2000 связаны между собой транзитивными доверительными отношениями, созданными с использованием протокола Kerberos. Эти отношения устанавливаются по умолчанию, автоматически, и являются двунаправленными. Под транзитивностью подразумевается тот факт, что все домены в дереве доверяют друг другу: т. е. если домен А доверяет домену Б, а домен Б доверяет домену В, то домен А также доверяет домену В. Такой подход упрощает администрирование доменов при сохранении высокого уровня безопасности.

Поиск информации:
Индексы и Глобальный каталог

При помощи протокола LDAP несложно получить доступ к некоторому объекту (элементу), если клиенту известно имя домена, к которому этот объект относится, и отличительное имя объекта. Что же делать, если клиент знает только имя домена, а отличительное имя объекта ему не известно? Предположим, что клиенту известны значения только некоторых атрибутов объекта. В Active Directory можно осуществлять поиск, зная только значение атрибута. Например, с помощью запроса к каталогу можно найти все объекты класса user со значением Director. Поскольку общее число элементов в каталоге бывает достаточно велико, такой поиск может выполняться медленно. Для ускорения поиска Active Directory позволяет индексировать атрибуты заданных типов.

Более сложный случай: предположим, что клиент знает, в каком лесе выполнять поиск, однако ему неизвестно, в каком домене данного леса находится искомый атрибут. Даже если для данного атрибута имеется индекс, поиск в каждом домене, входящем в лес, может отнять много времени. Для решения этой проблемы в Active Directory существует глобальный каталог (Global Catalog, GC). Все домены, входящие в некоторое дерево или лес доменов, используют общий, единый глббальный каталог, в котором имеется копия каждого элемента этих доменов. Однако в глобальный каталог входят только некоторые из атрибутов каждого элемента — те, которые могут представлять интерес в "масштабах" леса. В Active Directory имеется набор стандартных атрибутов для каждого объекта, которые всегда присутствуют в глобальном каталоге, но с помощью оснастки Схема Active Directory (Active Directory Schema) администраторы могут указывать и свои атрибуты для хранения в глобальном каталоге (нужно только помнить при этом, что при изменении схемы требуется полная синхронизация всех атрибутов объектов, хранящихся в глобальном каталоге, для всех доменов в лесе, и это может вызвать значительный трафик в сети). При необходимости можно также индексировать типы атрибутов в глобальном каталоге для ускорения поиска.

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

Эта информация используется при регистрации в сети клиентов Active Directory. Фактически не только пользователи, но и все объекты (например, каждый компьютер), проходящие аутентификацию в Active Directory, должны обращаться к серверу глобального каталога. Если в момент регистрации пользователя глобальный каталог недоступен, то этот пользователь сможет зарегистрироваться только локально, а не в сети. Исключение составляют члены групп администраторов домена (Domain Admins).

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

Изменение местоположения глобального каталога

Сервером глобального каталога можно назначить любой контроллер домена с учетом требований сетевой среды к операциям поиска и обслуживания запросов на регистрацию. Для этой цели используется оснастка Active Directory — сайты к службы (Active Directory Sites and Services): в ней нужно выбрать требуемый контроллер домена и открыть окно Свойства: NTDS Setting (NTDS Settings Properties), в котором установить флажок Глобальный каталог (Global Catalog). При этом уже имеющиеся в сети серверы глобального каталога сохраняют свой статус, и если таких серверов в сети становится несколько (два и больше), то между ними начинается репликация данных с применением обычных механизмов и расписаний репликации.

Репликация

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

В Windows NT Server 4.0 также имеется механизм репликации каталога (который в этом продукте значительно проще), для реализации которого контроллер домена функционирует или , как главный контроллер домена (PDC), или как резервный контроллер домена (BDC). Такие различия в Windows 2000 Server отсутствуют: имеется единое понятие контроллер домена.

Причина таких изменений следующая. В Windows NT Server 4.0 изменять можно только ту копию данных, которая хранится на PDC. В отличие от этого в Active Directory используется так называемая multi-master replication (дословно — "репликация со многими основными контроллерами доменов"). Каждый контроллер домена имеет полную копию базы данных своего домена с возможностью чтения и записи. Клиент может изменить любую копию, после чего все изменения распространяются по всем другим копиям, хранящимся на других контроллерах данного домена (при этом копируются только измененные атрибуты элементов каталога). Если два клиента одновременно изменят один и тот же атрибут какого-нибудь элемента, то зафиксируется последнее изменение (хотя нужно отметить, что для определения окончательного варианта изменений обычно используются номера версий, version numbers, а не временные отметки, timestamps).

Рис 23.4. Изменение элемента в каталоге влечет за собой копирование этих изменений во все реплики, хранящиеся на контроллерах домена

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

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

Сайты

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

Для того чтобы "локализовать" доступ, Active Directory позволяет администраторам делить один домен на несколько сайтов (site), как показано на рис. 23.5. Сайт — это одна или несколько IP-подсетей, входящих в ту часть сети, где соединения между компьютерами выполняются быстро и надежно. По сути, сайты отображают физическую топологию коммуникационных каналов всей сети. Например, сайтом имеет смысл сделать несколько подсетей, связанных между собой с помощью Ethernet. Когда клиент через DNS находит некоторый контроллер домена, этот контроллер определяет, находится ли клиент в том же сайте, что и данный контроллер. Если нет, клиент "передается" другому контроллеру домена, располагающемуся в том же сайте, что и клиент.

Репликация Active Directory по сути выполняется между сайтами, а не между доменами. В стандартном случае репликация между компьютерами, входящими в сайт (intra-site replication), выполняется чаще, чем между компьютерами, относящимися к различным сайтам (inter-site replication). Администраторы могут управлять частотой выполнения репликаций, хотя из-за того, что полоса пропускания каналов между сайтами меньше, чем скорость передачи данных внутри сайта, практически всегда репликации между сайтами осуществляются реже. Для повышения производительности данные, передаваемые при репликации между сайтами, сжимаются, благодаря чему более эффективно используются низкоскоростные каналы, связывающие сайты.

Рис 23.5. Деление одного домена Active Directory на несколько сайтов

Основные контроллеры операций

Как уже упоминалось, в Active Directory реализована репликация в режиме multi-master. Однако некоторые изменения в каталоге целесообразнее (эффективнее) выполнять в режиме с одним основным контроллером (single-master), называемым основным контроллером операций (operations master), который и управляет всеми подобными изменениями.

Основной контроллер операций отвечает за выполнение определенных функций, которые называют ролями контроллера операций. Поскольку эти роли могут назначаться разным контроллерам домена внутри домена или леса и передаваться от одного контроллера к другому, для них существует другое определение — гибкие операции с одним основным контроллером (Flexible Single Master Operations, FSMO).

Роли контроллера операций (FSMO)

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

Роли, уникальные для леса

Две следующие роли можно назначать только одному контроллеру в пределах леса:

Роли, уникальные для домена

Следующие три роли можно назначать только одному контроллеру в рамках домена; они не являются глобальными для леса:

Передача ролей FSMO

Для передачи ролей FSMO, уникальных для всего леса, используются оснастки Схема Active Directory (Active Directory Schema) (для назначения роли "хозяин схемы") и Active Directory- домены и доверие (Active Directory Domains and Trusts) (для назначения роли "хозяин именования доменов"). В окне соответствующей оснастки нужно вызвать контекстное меню для корня структуры, выбрать команду Подключение к контроллеру домена (Change Domain Controller) и соединиться с нужным контроллером домена. Затем в контекстном меню выбрать команду Хозяин операций (Operations Master) и в появившемся окне, нажав кнопку Изменить (Change), подтвердить передачу роли выбранному контроллеру домена.

Роли FSMO уникальные дм домена, назначаются контроллерам домена При помощи оснастки Active Directory - пользователи компьютеры (Active Directory Users and Computers), в окне которой на панели структуры следует выбрать домен, а в его контекстном меню - команду Хозяева операций открывающую одноименное окно. В этом окне на вкладках ИВ, PDC и Инфраструктура можно видеть существующих хозяев операций и выбрать контроллеры доменов, которые будут выполнять соответствующие роли.

Отказы основных контроллеров операций

Может возникнуть законный вопрос: что произойдет, если откажет какой-нибудь единственный (поскольку это заложено в концепции FSMO) в домене или лесе основной контроллер операций, выполняющий определенную роль? Как будет обеспечиваться отказоустойчивость сети? Некоторые роли контроллеров операций очень важны для поддержания сети в рабочем состоянии. Другие контроллеры операций могут без проблем отсутствовать в течение достаточно долгого времени: отказ будет замечен только при выполнении в сети определенных операций.

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

Интерфейсы API в Active Directory

Имеется множество каталогов сетевых ресурсов, например, LDAP-каталоги, Active Directory, Banyan StreetTalk, Microsoft Windows NT Directory Service, Novell Directory Service, и каталогов конкретных приложений, таких как Lotus Notes, cc:Mail или Microsoft Exchange. Все эти службы каталогов имеют свои интерфейсы программирования, что усложняет как администрирование каталогов (поскольку управление каждым каталогом выполняется отдельно), так и создание корпоративных приложений, обращающихся к используемым в организации каталогам.

Решение проблемы компания Microsoft видит в применении Active Directory Service Interface (ADSI) — набора СОМ-интерфейсов программирования, при помощи которого пользователи и независимые поставщики программного обеспечения (ISV) могут применять единый хорошо проработанный интерфейс для регистрации в различных службах каталогов, доступа к ним и управления этими службами.

Одним из наиболее распространенных и открытых интерфейсов доступа к базам данных является Open Data Base Connectivity (ODBC). Этот интерфейс поддерживается практически всеми реляционными базами данных. ADSI можно рассматривать как "ODBC для служб каталогов". ADSI позволяет создавать механизмы (называемые поставщиками ADSI, ADSI-providers) доступа к информации конкретного типа каталога. Прикладные программы, написанные с использованием ADSI, будут работать с любыми службами каталогов, для которых имеется поставщик ADSI. Так обеспечивается открытое, универсальное решение проблемы использования различных каталогов (рис. 23.6). Windows NT Server 4.0 уже имеет несколько поставщиков

ADSI для различных служб каталогов, a Windows 2000 Server имеет поставщика ADSI для Active Directory.

Рис 23.6. Открытое решение С использованием ADSI

В основе ADSI лежит модель СОМ-объектов, что упрощает написание сценариев доступа к каталогу. Например, администратор может создать сценарий для присвоения значений некоторым элементам Active Directory. Разработчики программных продуктов могут использовать данный API, например, для анализа элементов каталога. Для низкоуровневого программирования на C/C++ Active Directory также имеет стандартный LDAP API, который определяется как набор вызовов С-функций и описан в RFC 1823. Интерфейсы ADSI являются одним из компонентов Open Directory Service Interfaces (ODSI, Интерфейсы службы открытого каталога), входящих в Windows Open Services Architecture (WOSA, Архитектура открытых служб Windows). Для наглядности основные достоинства ADSI перечислены в табл. 23.1.

Таблица 23.1. Достоинства Active Directory Service Interface (ADSI)

Active Directory и промышленные стандарты (RFC)

В табл. 23.2 перечислены некоторые основные стандарты, реализуемые в службе каталогов Active Directory и DNS-сервере, входящем в состав Windows 2000 Server.

Таблица 23.2. Запросы на комментарии (RFC), относящиеся к Active Directory и DNS