Основные концепции службы Active Directory Windows 2000

  1. Глава: Планирование и установка системы Windows 2000.
  2. Глава: Загрузка операционной системы Windows 2000.
  3. Глава: Поддержка оборудования Windows 2000.
  4. Глава: Пользовательский интерфейс Windows 2000.
  5. Глава: Конфигурирование системы Windows 2000.
  6. Глава: Средства управления Windows 2000.
  7. Глава: Диски и файловые системы Windows 2000.
  8. Глава: Восстановление системы Windows 2000.
  9. Глава: Работа с дисковыми ресурсами Windows 2000.
  10. Глава: Службы печати Windows 2000.
  11. Глава: Типовые задачи администрирования Windows 2000.
  12. Глава: Нулевое администрирование Windows (ZAW).
  13. Глава: Средства мониторинга и оптимизации Windows 2000.
  14. Глава: Работа с системным реестром Windows 2000.
  15. Глава: Сообщения Windows 2000 и отладчик Windows 2000.
  16. Глава: Сеть и удаленный доступ к сети Windows 2000.
  17. Глава: Серверы DHCP, DNS и WINS Windows 2000.
  18. Глава: Дополнительные сетевые службы Windows 2000.
  19. Глава: Коммуникационные службы Windows 2000.
  20. Глава: Маршрутизация Windows 2000.
  21. Глава: Работа с Интернетом и электронной почтой Windows 2000.
  22. Глава: Службы Интернета в Windows 2000.
  23. Глава: Основные концепции службы Active Directory Windows 2000.
  24. Глава: Проектирование доменов и развертывание Active Directory Windows 2000.
  25. Глава: Администрирование доменов Windows 2000.
  26. Глава: Средства безопасности Windows 2000.
  27. Глава: Групповые политики Windows 2000.
  28. Карта сайта www.press-brook.com.ua.

Глава 23

Основные концепции службы Active Directory Windows 2000

В рамках этой книги невозможно подробно рассмотреть все аспекты использования службы каталогов 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 обеспечивает эффективную работу сложной корпоративной среды, предоставляя следующие возможности:

Единая регистрация в сети; Пользователи могут регистрироваться в сети с одним именем и паролем и получать при этом доступ ко всем сетевым ресурсам (серверам, принтерам, приложениям, файлам и т. д.) независимо от их расположения в сети.

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

Централизованное управление. Администраторы могут централизованно управлять всеми корпоративными ресурсами. Рутинные задачи администрирования не нужно повторять для многочисленных объектов сети.
Администрирование с использованием групповых политик. При загрузке компьютера или регистрации пользователя в системе выполняются требования групповых политик; их настройки хранятся в объектах групповых политик (GPO) и "привязываются" к сайтам, доменам или организационным единицам. Групповые политики определяют, например, права доступа к различным объектам каталога или ресурсам, а также множество других "правил" работы в системе.
Гибкость изменений. Служба каталогов гибко следует за изменениями структуры компании или организации. При этом реорганизация каталога не усложняется, а может и упроститься. Кроме того, службу каталога можно связать с Интернетом для взаимодействия с деловыми партнерами и поддержки электронной коммерции.

Интеграция с DNS. Служба Active Directory тесно связана с DNS. Этим достигается единство в именовании ресурсов локальной сети и сети Интернет, в результате чего упрощается подключение пользовательской сети к Интернету.

Расширяемость каталога. Администраторы могут добавлять в схему каталога новые классы объектов или добавлять новые атрибуты к существующим классам.

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

Репликация информации. В службе Active Directory используется репликация служебной информации в схеме со многими ведущими (multi-master), что позволяет модифицировать каталог на любом контроллере домена. Наличие в домене нескольких контроллеров обеспечивает отказоустойчивость и возможность распределения сетевой нагрузки.

Гибкость запросов к каталогу. Пользователи и администраторы сети могут быстро находить объекты в сети, используя свойства объекта (например, имя пользователя или адрес его электронной почты, тип принтера или его местоположение и т. п.). Это, в частности, можно сделать при помощи команды Пуск | Поиск (Start | Search), папку Мое сетевое окружение (My Network Places) или оснастку Active Directory - пользователи и компьютеры (Active Directory Users and Computers). Оптимальность процедуры поиска достигается благодаря использованию глобального каталога.

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



Каталоги и Windows 2000

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

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

Стандарт Х.500

Служба DNS (Domain Name Service)
Протокол LDAP (Lightweight Directory Access Protocol)

В 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).


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



Службы DNS и Active Directory

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

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

Домены Active Directory и домены DNS имеют одинаковую иерархическую структуру и схожее пространство имен.
Зоны (zone) DNS могут храниться в Active Directory. Если используется сервер DNS, входящий в состав Windows 2000 .Server, то первичные зоны (primary zone), занесенные в каталог, реплицируются на все контроллеры домена, что обеспечивает лучшую защищенность службы DNS.
Использование клиентами службы 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-запись для себя, освобождая администратора от такой необходимости.

Примечание

DNS-сервер, используемый вместе с Active Directory, должен лишь поддерживать SRV-записи и символы подчеркивания в именах, наличие Dynamic DNS не строго обязательно: такое требование только облегчает работу с сетью. Этот факт очень важен при развертывании Windows 2000 в гетерогенных сетях, где имеются DNS-серверы на других платформах.


Листья и контейнеры 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 достаточно сложна и содержит сотни и сотни объектных классов и типов атрибутов. Ниже для примера перечислены некоторые интересные классы:

user — описывает конкретного пользователя домена. Среди атрибутов этого класса: canonicalName (Каноническое имя), userPrincipalName (Полное имя пользователя), homePostalAddress (Домашний почтовый адрес), telephoneNumber (Номер телефона), thumbnailPhoto (Фотография).

printQueue — позволяет клиенту находить некоторый принтер. Среди атрибутов: location (Местоположение), printStatus (Состояние принтера) и printLanguage (Язык принтера).

compoter — идентифицирует некоторый компьютер домена. Среди множества атрибутов этого класса: operatingSystem (Операционная система), operatingSystemServicePack, dNSHostName (DNS-имя хоста) и machineRole (Назначение компьютера; этот атрибут указывает, является ли данный компьютер контроллером домена, рядовым сервером или рабочей станцией).

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

Каждый элемент 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.


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

Примечание

Объектам Active Directory (в частности, подразделениям) можно давать и русские имена (возможно, из нескольких слов). Однако, если локальная сеть подключается к Интернету, нужно учитывать, что в стандартных интернетовских DNS-именах разрешены только латинские буквы!

Ниже подразделения 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 имеет по меньшей мере три контекста имен:

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

Конфигурация (Configuration) (топология репликации и связанные с ней метаданные, например, сведения о контроллерах домена).

Один (в нашем примере — bhv.com) или несколько пользовательских, или доменных, контекстов имен (т. е. контекстов, содержащих реальные, рабочие объекты каталога), при этом контроллеры домена хранят реальные объекты только своего домена.


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

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


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

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

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



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

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



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

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

Хозяин схемы (Schema Master). Контроллер, выполняющий роль основного контроллера схемы, управляет всеми обновлениями и модификациями схемы.

Хозяин именования доменов (Domain Naming Master). Контроллер, управляющий доменными именами, следит за добавлением и удалением доменов в лесе.


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

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

Хозяин RID (Relative ID Master, RID Master). Контроллер, выполняющий эту роль, генерирует последовательности относительных идентификаторов (RID) для всех контроллеров своего домена. Когда на некотором контроллере создается объект типа "пользователь", "группа" или "компьютер", этому объекту назначается уникальный идентификатор безопасности (SID), который образуется из доменного SID (единого для всех идентификаторов безопасности, создаваемых в этом домене) и относительного идентификатора (уникального для каждого идентификатора безопасности, создаваемого в домене). Когда диапазон (пул) относительных идентификаторов исчерпан, контроллер домена запрашивает новый диапазон у контроллера, являющегося хозяином RID.

Хозяин РDС (Primary Domain Controller (PDC) Emulator). Если в домен входят компьютеры, не имеющие клиента для Windows 2000, или резервные контроллеры домена (BDC) Windows NT, то контроллер-эмулятор PDC выполняет функции основного контроллера домена (PDC) Windows NT. Он обрабатывает изменения клиентских паролей и обновляет информационные базы на BDC-контроллерах. Хозяин PDC первым получает изменения пароля, выполненные на любом другом контроллере своего домена. Если на некотором контроллере домена из-за неверного пароля не пройдет аутентификация пользователя, то перед тем как запрос на регистрацию будет отвергнут, он сначала передается контроллеру, выполняющему роль хозяина PDC.

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

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



Передача ролей 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.


Открытое решение С использованием ADSI
Рис 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)

Характеристика

Преимущества

Открытость

Любой поставщик службы каталога может создать ADSI-provider; пользователи могут выбирать любую удобную им службу каталога, сохраняя все возможности ее администрирования

Независимость от службы каталогов

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

Поддержка Java

С помощью Java COM объекты ADS! обеспечивают апплетам и приложениям Java простой доступ к службам каталогов

Безопасность

ADSI поддерживает программные модели аутентификации (Authentication model) и авторизации (Authorization model)

Простая модель программирования

Можно создавать административные и другие ориентированные на использование каталогов программы, не вдаваясь в детали API конкретного производителя службы каталога

Сервер автоматизации OLE

Для создания приложений, работающих с каталогами, можно использовать любые средства разработки контроллеров автоматизации OLE (Visual Basic, PERL, Rexx, C/C++ и другие). Администраторы и разработчики могут использовать любые знакомые им инструменты проектирования, что увеличивает эффективность их работы

Большой набор функций

Одни и те же модели ADSI можно использовать как для написания простых сценариев, так и для создания сложных приложений

Расширяемость

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



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

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

Таблица 23.2. Запросы на комментарии (RFC), относящиеся к Active Directory и DNS
Номер RFC Описание
1777 Протокол LDAP version 2 (DRAFT STANDARD)
1823 LDAP Application Program Interface
2052 Указание местоположения служб (DNS SRV records)
2136 Динамическое обновление Domain Name System (DNS UPDATE, Dynamic DNS) (предлагается в качестве стандарта, PROPOSED STANDARD)
2251 Протокол LDAP version 3 (предлагается в качестве стандарта, PROPOSED STANDARD)