Обзор

Ситуация на потребительском рынке

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

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

Каталоги для конкретных приложений

·

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

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

Многофункциональные каталоги

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

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

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

Требования к службе каталогов

Многофункциональная служба каталогов должна отвечать следующим требованиям.

· Доступность глобальных данных. Во всех приложениях, начиная от приложений электронной почты и заканчивая теми, которые используются в системе ERP (Enterprise Resource Planning – планирование ресурсов предприятия), требуется, чтобы данные каталога реплицировались по организации, особенно если она географически разделена на подраззделения, связанные между собой глобальной сетью. В связи с тем, что в глобальных сетях имеются источники сбоев и их пропускная способность ограничена, службы каталогов должны позволять перемещать через нее большие объемы данных (не имея при этом сложной конфигурации) таким образом, чтобы обеспечить возможность быстрого и эффективного поиска, а также доступность данных независимо от местонахождения пользователя.

· Интеграция со стандартами Интернета. Учитывая, что службы каталогов часто будут не только выходить за пределы одной организации, но и пересекать географические границы, необходимо, чтобы приложения могли находить каталоги и получать к ним доступ с помощью стандартной службы DNS (Domain Naming Service), а также обеспечивать надежную поддержку доступа к данным с помощью протокола LDAP (Lightweight Directory Access Protocol). Кроме того, каталоги должны интегрироваться с технологиями инфраструктуры открытого ключа PKI (Public Key Infrastructure), чтобы обеспечить доступ к данным каталогов через Интернет, защитив при этом ресурсы организации и упростив управление.

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

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

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

Наилучший перспективный выбор – служба каталогов Active Directory

После выпуска компанией Novell системы Netware версии 5.1 и службы каталогов NDS (Novell Directory Service) версии 8 [1]в корпорацию Майкрософт стали поступать многочисленные просьбы провести сравнительный анализ службы каталогов Active Directory системы Windows 2000 Server со службой каталогов NDS. Корпорация Майкрософт считает, что служба Active Directory намного лучше отвечает потребностям пользователей в многофункциональном каталоге, чем служба NDS:

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

· Наилучшая служба каталогов для Интернета. Служба каталогов Active Directory реализуется как собственный (native) LDAP-каталог, обеспечивающийэффективную обработку запросов LDAP. Таким образом, в качестве локатора в Интернете используется только служба DNS и обеспечивается работа встроенных служб инфраструктуры открытого ключа PKI. Службе каталогов NDS требуется некоторое время на преобразование атрибутов и классов LDAP в их NDS-эквиваленты и на обратное преобразование в процессе запросов. Не все компоненты службы каталогов NDS предоставляются на основе протокола LDAP; она не поддерживает службу DNS для задания имени объектам каталога и не объединена с инфраструктурой открытого ключа PKI.

· Наилучшая служба каталогов для приложений. Служба каталогов Active Directory полностью интегрирована в систему Windows и предлагает интерфейсы ADSI (ADSI – Active Directory Service Interfaces) – набор объектных классов на основе модели COM, который позволяет упростить разработку поддерживающих каталог приложений. Более того, корпорация Майкрософт привлекла авторитетных разработчиков таких ведущих производителей, как SAP, Baan, J.D. Edwards, Cisco и многих других. Сделав выбор в пользу минимального набора общих компонентов нескольких систем, компания Novell отказалась от тесной интеграции с Windows и, как хорошо известно, в настоящее время потенциал ее разработок невелик и идет на убыль.

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

В силу этих, а также других причин, изложенных далее в этом документе и подытоженных в табл. 1, корпорация Майкрософт делает вывод, что многоцелевая служба каталогов Active Directory является более перспективной, чем служба NDS компании Novell.

Таблица 1. Сравнение службы каталогов Active Directory со службой NDS в разрезе требований
Требование	Служба каталогов Active Directory	Служба каталогов NDS версии 8
Доступность глобальных данных	· Раздел ограничивается доменом Windows 2000 (в котором может содержаться несколько сайтов и каналов связи глобальной сети), обеспечивающим прямой доступ к объектам и их эффективный поиск через границы сайтов. · Автоматически оптимизируется репликация между сайтами и по медленным сетевым каналам. · Благодаря тому, что глобальные каталоги обновляются одновременно с другими циклами репликации, они никогда не устаревают. · Поддержка перечней объектов каталогов гарантирует безопасность на уровне объектов и на уровне атрибутов.	· Компания Novell рекомендует использовать разделы, которые не связаны по глобальной сети, что сводит диапазон эффективного поиска к одному сайту. · Непосредственный поиск объектов в разделах требует обхода дерева. · Формирование разделов NDS, охватывающих связи глобальной сети, требует сложной конфигурации. · Каталоги устаревают, поскольку они перестраиваются только через заданные интервалы времени (по умолчанию через каждые 24 часа). · Каталоги не обеспечивают безопасность на уровне объектов и на уровне атрибутов в рамках баз данных каталогов.
Поддержка стандартов Интернета	· Служба Active Directory реализована как сервер с собственной поддержкой протокола LDAP, что обеспечивает быструю и эффективную обработку запросов. · Обеспечивается доступ на основе протокола LDAP ко всем компонентам, что упрощает администрирование. · Объединение со службой DNS упрощает использование Active Directory при работе с Интернетом. · Обеспечивается интегрированная поддержка технологий инфраструктуры открытого ключа PKI	· Запросы LDAP необходимо преобразовать в форматы службы каталогов NDS, что загружает систему обработкой запросов. · Неполный доступ на основе протокола LDAP к компонентам NDS усложняет администрирование. · Отсутствие интеграции системы именования объектов со службой DNS усложняет использование NDS при работе с Интернетом. · Ограниченная интеграция с технологиями инфраструктуры открытого ключа PKI.
Среда разработок приложений	· Поддержка ведущих коллективов разработчиков. · Для упрощения разработки предлагается интерфейс ADSI (Active Directory Services Interface) на базе модели COM. · Разработчики могут использовать языки программирования, включая Visual Basic®, Java, C, C++ и другие. · Обеспечивает доступ на основе протокола LDAP ко всем компонентам. · Используемая модель разделов упрощает разработку приложений.	· Ограниченная поддержка разработчиков. · Отсутствует реализация интерфейса ADSI для использования приложениями, работающими под управлением системы NetWare. · Неполный доступ на основе протокола LDAP к компонентам NDS усложняет программирование. · Приложения должны функционировать в рамках раздела.

(продолжение)

Таблица 1. Сравнение службы каталогов Active Directory со службой NDS в разрезе требований

Поддержка централизованного управления каталогами

· Модель разделов позволяет организациям объединять большие каталоги без усложнения администрирования.

· Встроенные основанные на протоколе LDAP интерфейсы журнала изменений упрощают использование системы как платформы метакаталогов.

· Архитектура каталогов позволяет быстро и эффективно посылать запросы большого количества объектов в другие страны и отделения организации.

· Растущая поддержка со стороны независимых поставщиков программного обеспечения.

· Используется в программных продуктах и службах корпорации Майкрософт, таких как Exchange 2000, SQL Server™, COM+, Microsoft Message Queue Services (MSMQ), Site Server и других.

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

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

· Недостаточная поддержка со стороны независимых поставщиков программного обеспечения.

· Продукт GroupWise компании Novell не полностью работает со службой каталогов NDS.

Доступность глобальных данных

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

· Механизм хранения данных, используемый в работе каталога, должен поддерживать множество различных объектов.

· Исходя из того, что обычно компании насчитывают свыше 50 000 служащих, большинство которых имеют компьютеры, свои профили приложений и сетевые подключения, которые будут представлены как объекты каталога, вполне разумно предположить, что раздел службы каталогов[2] должен содержать, по меньшей мере, 1 000 000 объектов.

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

Рис. 1. Типичная ситуация

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

Типичная ситуация

Краткое описание ситуации

· Отделения организации расположены в трех регионах (Северная Америка, Азия, Европа)

· Три сайта в Северной Америке

· Хорошая связь между сайтами; низкое качество связи между регионами

· Все атрибуты объектов службы каталогов должны быть доступны в пределах каждого региона

· Некоторые атрибуты (например, имена и адреса электронной почты) должны быть доступны из любого региона

Концепция доступности глобальных данных лучше всего описывается на примере типичной ситуации. На рис. 1 схематично изображена компания, расположенная в Северной Америке и имеющая отделения в Азии и Европе. В Северной Америке у нее есть сайты в Сан-Диего, Чикаго и Бостоне. В пределах Северной Америки имеется быстрое и надежное сетевое подключение, тогда как связь Северной Америки с Азией и Европой более медленная и менее надежная. Компании необходимо реализовать такой каталог, чтобы ко всей хранящейся в ее североамериканских филиалах информации об объектах (например, пользователях, компьютерах и принтерах) был доступ из любой части Северной Америки; а к информации об объектах, хранящейся в азиатских отделениях организации, был доступ из любой точки Азии и т.д. Кроме того, из-за трудностей подключения к азиатским и европейским отделениям организация желает использовать отдельные разделы сети, но иметь при этом доступ из любого отделения компании к некоторому подмножеству всех данных каталога (например, списки сотрудников, телефонных номеров и адресов электронной почты).

Разделы службы каталогов Active Directory

Рис. 2. Схема разделов
службы каталогов Active Directory

Подпись: Раздел службы каталогов Active Directory ограничивается доменом Windows 2000. Другими словами, все элементы домена Windows 2000, которые связаны с объектами службы Active Directory, доступны внутри одного раздела. Поскольку служба Active Directory поддерживает репликацию с несколькими основными копиями, на всех контроллерах домена будет доступна полная реплика раздела, даже если домен распространяется на несколько сайтов.

Важно отметить, что многие компании, использующие операционную систему Windows NT® 4.0, не реализуют домены, охватывающие несколько сайтов, что приводит к появлению большего количества мелких доменов, чем могло бы потребоваться при использовании новой модели доменов Windows 2000. Это происходит потому, что система Windows NT 4.0 лишь отчасти поддерживает делегирование административных прав и в ней число пользователей и компьютеров не превышает 40 000 на один домен. На практике это означает, что для управления большим числом пользователей и компьютеров или для предоставления отделениям организации или местным подразделениям необходимой административной автономии, многие организации развертывают несколько доменов Windows NT 4.0.

Однако с использованием системы Windows 2000 и службы Active Directory модель домена существенно расширяется.

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

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

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

Исходя из этих соображений, корпорация Майкрософт считает, что большинство организаций, которые развернут систему Windows 2000, будут использовать намного меньшее число доменов значительно большего размера.

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

Рис. 3. Схема разделов с использованием
службы NDS версии 8

Разделы службы NDS

Возможно, система индексированного хранения является наиболее важным компонентом, который появился в службе NDS версии 8. Эта система позволяет разделу NDS эффективно хранить значительно больше объектов, чем это допускали предыдущие версии службы NDS, что исключает необходимость хранить в разных разделах данные, соответствующие одному сайту.[4] Однако из-за того, что служба NDS для репликации данных между серверами использует подключение типа точка-точка, администраторы обычно не создают разделов, простирающихся на несколько сайтов, – служба NDS недостаточно эффективно реплицирует данные.

Например, в том случае, если имеются два сайта с пятью серверами репликации в каждом из них, служба NDS проведет односторонний сеанс репликации с подключением типа точка-точка между каждой парой серверов этого раздела (в общей сложности 90 подключений)[5]. Несмотря на то, что благодаря высокой скорости работы локальной сети, подключения внутри сайта стоят недорого, между сайтами глобальной сети будет установлено 25 подключений, и единственное событие репликации (то есть, изменение, сделанное в одной реплике, и реплицируемое на все серверы репликации) в итоге пройдет по глобальной сети 5 раз (по одному разу на каждый сервер репликации). Кроме того, эта ситуация значительно усложняется с каждым добавленным в раздел сайтом.

Репликация между сайтами с использованием службы NDS

Напротив, средство KCC (Knowledge Consistency Checker – проверка согласованности знаний) службы Active Directory автоматически анализирует топологию сети и настраивает серверы-плацдармы. В результате между сайтами используется только одно подключение, и одно событие репликации единственный раз отправляется по глобальной сети. Далее, для уменьшения количества подключений, требуемых внутри сайта, в службе Active Directory используется алгоритм дерева распространения. Кроме того, в службе Active Directory поддерживается расписание сеансов репликации с тем, чтобы уменьшилось время, в течение которого подключения к глобальной сети должны оставаться открытыми, а также автоматически сжимаются все данные, отправляемые по глобальной сети.[6]

Используя разработанный компанией Novell метод WAN Manager для моделирования поведения сервера-плацдарма и дерева распространения, администраторы могут настраивать топологии репликации, однако таблицы маршрутизации должны составляться вручную на каждом сервере репликации. Кроме того, метод WAN Manager не позволяет проводить сжатие данных и обеспечивает только работу базовых служб расписания репликации. Корпорация Майкрософт считает, что из-за этого администраторы NDS редко используют на практике метод WAN Manager для реализации разделов, включающих связи по глобальной сети.

Репликация между сайтами с использованием службы Active Directory

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

Корпорация Майкрософт считает, что такая модель разбиения на разделы имеет существенные недостатки. Используя конфигурации, в которых данные не реплицируются между сайтами (то есть, данные Сан-Диего не реплицируются в Чикаго и Бостон), служба NDS обеспечивает очень ограниченную возможность вести эффективный поиск в масштабах компании. Рассмотрим случай, когда пользователь в Бостоне отсылает сообщение по электронной почте сотруднику по имени Bob, но никак не может вспомнить его фамилию, кроме того, что она начинается с буквы S, или не может вспомнить, где живет Bob, – в Сан-Диего или в Чикаго. В службе Active Directory реплика из Бостона будет содержать данные сотрудников компании из всей Северной Америки, и сервер сможет быстро выполнить поиск «всех сотрудников с именем Bob, фамилия которых начинается с буквы S», не подключаясь ни к одному из серверов каталога в Сан-Диего или Чикаго.

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

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

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

Потребность в каталогах

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

Каталоги службы Active Directory

В составе службы Active Directory имеется средство под названием «глобальный каталог» (Global Catalog), позволяющий администраторам строить специализированный каталог, содержащий подмножество атрибутов объектов, представляющих интерес за пределами одного домена. Глобальный каталог определяет порядок участия в нем доменов на основе концепции деревьев и лесов связанных доменов Windows 2000 Server.

Лес доменов Windows 2000 с репликами глобального каталога

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

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

· Глобальные каталоги не требуют специальной установки, и их просто настраивать.

· Глобальные каталоги обновляются вместе с остальными циклами репликации, что гарантирует их согласованность с соответствующими объектами доменов.

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

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

Каталоги службы NDS

В службе NDS предлагается механизм для создания каталогов, называемый Catalog Services (служба каталогов). Создавая каталоги NDS, администраторы предоставляют возможность пользователям и приложениям выполнять запросы в единственном месте, где собраны копии объектов из разных разделов NDS. Компания Novell рекомендует использовать каталоги для того, чтобы избежать необходимости делать обход дерева при поисках по всему дереву.

Архитектура каталога службы NDS

Для создания каталогов и управления ими администраторы используют служебную программу Catalog Service Manager (диспетчер службы каталогов). С ее помощью можно определить разделы, которые подлежат включению в каталоги, и атрибуты объектов, представляющие интерес для администраторов. Администраторы также используют служебную программу Catalog Service Manager при проведении операций, которые компания Novell называет процессом Dredger – процессом, предназначенным для периодического перестраивания каталогов.

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

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

· Поскольку на обработку разделов процессом Dredger требуется определенное время, компания Novell рекомендует перестраивать каталоги не слишком часто (по умолчанию каждые 24 часа). Поэтому каталоги устаревают; возникает рассогласование с объектами, по которым составлялись каталоги.

· Прошедшие обработку процессом Dredger объекты теряют свои первоначальные свойства, связанные с управлением доступом. Права на управление доступом применяются ко всему каталогу. Если пользователям предоставляется доступ к каталогу, они получают доступ ко всем объектам и атрибутам.

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

Используя определенные в начале этого раздела критерии для оценки возможности службы NDS обеспечить доступность глобальных данных, корпорация Майкрософт приходит к выводу, что службе NDS будет трудно соответствовать требованиям, предъявляемым во многих важных случаях применения каталогов.

Поддержка стандартов Интернета

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

· Протокол LDAP V3 (Lightweight Directory Access Protocol Version 3), предназначенный для выполнения запросов, доступа к хранящимся в службах каталогов объектам и управления ими.

· Служба DNS (Domain Naming Service), предназначенная для поиска компьютеров и служб в сети с помощью стандартного формата именования.

· Технологии PKI (Public Key Infrastructure – инфраструктура открытого ключа), в которых используются цифровые сертификаты стандарта X.509 для обеспечения проверки подлинности и защиты от несанкциониронанного доступа данных при подключениях к сети.

Служба Active Directory и протокол LDAP V3

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

Протокол LDAP и служба Active Directory

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

Служба NDS и протокол LDAP V3

Несмотря на заявления компании Novell о том, что служба NDS полностью совместима с протоколом LDAP V3, корпорация Майкрософт считает, что метод, с помощью которого служба NDS обеспечивает поддержку протокола LDAP, уступает тому, который используется службой Active Directory, в следующем:

· В службе NDS данные не хранятся в собственной форме протокола LDAP и поэтому,

· чтобы получить доступ к данным службы NDS с помощью протокола LDAP, администраторы должны установить отдельно службу обработки запросов LDAP;

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

Протокол LDAP и служба NDS

· Для обработки каждого запроса LDAP служба NDS должна выполнить следующие операции.

· Преобразовать запрос в формат Unicode.

· Найти каждый упомянутый в запросе класс и атрибут и сопоставить соответствующему классу или атрибуту NDS.

· Отправить преобразованный запрос в NDS на обработку.

· Провести обратное сопоставление каждого полученного результата запросам LDAP. Для каждого правила синтаксиса (например, в случае почтового адреса) также необходимо провести сопоставление, чтобы результат сохранился правильно;

· Преобразовать код успешного выполнения или код ошибки между формами NDS и LDAP.

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

· Различия между формами LDAP и формами данных, хранящихся в NDS, могут стать причиной неоднозначного сопоставления данных о классах и атрибутах. Это обстоятельство может стать причиной некорректной работы в том случае, если несколько приложений под управлением протокола LDAP будут выполняться одновременно: каждое из них может потребовать своего сопоставления, а служба NDS будет вынуждена использовать только одно из возможных.

· При использовании протокола LDAP доступны не все функциональные возможности службы NDS (например, управление схемой). Хотя это не требуется для совместимости, тем не менее, для того чтобы воспользоваться такими возможностями, как управление схемой с помощью средств расширенного контроля LDAP, в приложениях приходится реализовывать дополнительные методы доступа к службе NDS.

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

Службы Active Directory и DNS

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

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

Корпорация Майкрософт выбрала другой метод и объединила службу Active Directory с уже используемым во всем мире механизмом поиска служб в Интернете: службой DNS. Имена доменов системы Windows 2000 Server основаны на системе именования DNS. Поскольку имеется взаимно однозначное отношение между доменами и разделами Active Directory, разделы используют имя домена DNS, в котором они содержатся. Каждый объект, хранящийся в каталоге Active Directory, имеет два компонента, составляющих его полное имя: имя DNS раздела Active Directory, содержащего этот объект, и обычное имя самого объекта в форме LDAP, которое описывает его местонахождение в дереве раздела. Это позволяет клиентам Active Directory выполнять поиск имен DNS, привязку LDAP и требуемую операцию LDAP (например, запрос) в одно действие, при условии, что имеется полное имя объекта. Далее, службой Active Directory гарантируется, что полное составное имя объекта отличается от всех других объектов службы, имеющихся в мире, и полностью описывает способ поиска этого объекта в локальной сети организации или в Интернете.

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

С введением службы DNS в именах электронной почты появился знак @ и возможность указывать как имя пользователя, так и имя домена DNS, в котором их (точнее, их сервер электронной почты) можно найти. В настоящее время, когда отправляется почтовое сообщение, например, по адресу bob@streetmarket.com, почтовый сервер организации проводит автоматический поиск службой DNSсервера электронной почты с именем streetmarket.com, получает в ответ адрес TCP/IP и отправляет сообщение по этому адресу, тогда как сервер электронной почты организации StreetMarket определяет, как отправить это сообщение адресату bob. Похожий процесс идет, когда пользователь получает доступ к веб-странице в Интернете. В URL-адресе содержится не только имя веб-сервера DNS, управляющего этой страницей, но и имя самой страницы. Обозреватели с помощью службы DNS сначала ведут поиск веб-сервера и, обнаружив его, отправляют ему для поиска имя страницы.

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

Служба каталогов NDS и служба DNS

Форма именования объектов, используемая службой каталогов NDS, не поддерживает имена DNS. Чтобы найти объект в NDS, пользователям сначала необходимо узнать, как найти подходящий сервер NDS. Кроме того, поскольку у службы NDS и протокола LDAP различные синтаксисы имен, приложения интрасети, созданные для доступа к службе NDS непосредственно с помощью вызовов протокола NCP (NetWare Core Protocol), и приложениями Интернета, использующие протокол LDAP, будут применять различные имена объектов.

Инфраструктура открытого ключа

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

Сравнение решений PKI, предлагаемых компанией Novell и корпорацией Майкрософт

Предвидя тенденцию развития в направлении технологии безопасности с использованием инфраструктуры открытого ключа (PKI), корпорация Майкрософт в течение нескольких лет прилагала значительные усилия для того, чтобы система Windows 2000 полностью включила эту инфраструктуру. Инфраструктура PKI расширяет возможности служб шифрования с использованием открытого ключа, которые появились в системе Windows еще до выхода системы Windows 2000 (например, к ним относятся службы сертификации), предлагая встроенный набор служб и средств администрирования для создания и развертывания приложений, основанных на открытом ключе, а также управления ими. Корпорация Майкрософт считает, что технологии инфраструктуры открытого ключа системы Windows 2000 превосходят предложения компании Novell с использованием этих же технологий в следующих трех областях:

· Средства управления;

· Интеграция с операционной системой;

· Интеграция с приложениями.

Управление

Инфраструктуре открытого ключа компании Novell, интегрированной в службу каталогов NDS для хранения сертификатов, недостает следующих возможностей управления:

· Управление ключами. Инфраструктура открытого ключа Windows 2000 представляет интегрированные механизмы ключей восстановления для службы EFS (Encrypting File System – шифрованная файловая система) Windows 2000, она является основой системы архивации и депонирования (escrow) сервера Exchange и предлагает независимым поставщикам программного обеспечения и разработчикам полный набор интерфейсов прикладного программирования API (Application Programming Interface) для управления ключами. Инфраструктура открытого ключа компании Novell не предлагает средств для восстановления, архивации или депонирования ключей шифрования. Это означает, что если ключи будут потеряны или повреждены, данные, зашифрованные с ними, использовать будет нельзя. Кроме того, инфраструктура открытого ключа компании Novell не поддерживает механизма аннулирования сертификатов после того, как они были выданы. Например, нет никакой возможности отменить сертификат, выданный уволенному служащему. Это требование имеет принципиальное значение при использовании приложений электронной коммерции.

· Доступ и управление в Интернете. Инфраструктура открытого ключа, используемая в Windows 2000, интегрирована со службами IIS (Internet Information Services) для конечных пользователей и администраторов PKI. Конечные пользователи могут сделать запрос и получить сертификат с помощью обычного обозревателя или клиента интегрированной консоли MMC (Microsoft Management Console – консоль управления Microsoft). В то же время у администратора или конечного пользователя нет возможности с помощью веб-обозревателя получить доступ к инфраструктуре открытого ключа, используемой компанией Novell. Для работы в экстрасетях требуется, чтобы конечные пользователи могли запрашивать и получать сертификаты по Интернету без специализированного клиентского программного обеспечения. При использовании инфраструктуры открытого ключа компании Novell требуется клиент ConsoleONE для создания запроса и управления сертификатами конечного пользователя.

· Распространение ключей клиентам. Инфраструктура открытого ключа в Windows 2000 интегрирована со средствами групповой политики службы каталогов Active Directory с тем, чтобы корневые ключи распространялись автоматически. Инфраструктура открытого ключа компании Novell не интегрирована с ее собственным продуктом Z.E.N.Works, в результате чего не обеспечено массовое распространение сгенерированных ключей или корневых ключей на ПК конечных пользователей. Это значит, что каждый пользователь должен вручную создавать запрос, загружать сертификаты и управлять ими с помощью клиента ConsoleONE.

Интеграция с операционной системой

Инфраструктура открытого ключа системы Windows 2000 интегрирована с такими основными компонентами операционной системы, как служба шифрования EFS, веб-сервер IIS, обозреватель Internet Explorer и поддержка стандарта IPSEC, обеспечивающего безопасную передачу по протоколу IP. Система Windows 2000 обеспечивает также платформу для независимых поставщиков программного обеспечения смарт-карт (на основе стандартов PC/SC) и включает поставщиков службы криптографии (CSP – cryptographic service providers), что предоставляет возможность входа в систему со смарт-картой без дополнительной настройки.

Инфраструктуре открытого ключа, используемой компанией Novell, недостает полной интеграции с операционной системой NetWare. Кроме того, инфраструктура открытого ключа, используемая компанией Novell, сформирована поверх службы NDS и не интегрирована в ее основные средства проверки подлинности и авторизации. Например, сервер Certificate Server (сервер сертификатов) компании Novell не поддерживает выдачу сертификатов для смарт-карт. Совсем недавно компания Novell объявила об интеграции инфраструктуры открытого ключа с функцией проверки подлинности в службе каталогов NDS в составе службы NMAS (Novell Modular Authentication Service). Похоже, что служба NMAS создана с помощью собственной технологии компании Novell, а не на основе отраслевых стандартов для проверки подлинности с использованием инфраструктуры открытого ключа, таких как стандарт PKinit. Кроме того, ряд вопросов о том, как будет администрироваться подобная система, остаются открытыми.

Интеграция приложений

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

Интеграция приложений

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

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

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

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

· Возможности, которыми обладает каталог;

· Простота использования этих возможностей;

· Богатство возможностей платформы, под управлением которой работают приложения и каталог.

Интерфейсы службы Active Directory

Чтобы облегчить создание приложений, работающих с каталогом Active Directory и другими LDAP-совместимыми каталогами, корпорация Майкрософт разработала интерфейсы ADSI (Active Directory Service Interfaces – интерфейсы службы Active Directory). ADSI – широкий набор интерфейсов прикладного программирования на основе модели COM (Component Object Model), разработанной корпорацией Майкрософт, которые можно использовать для создания приложений, обеспечивающих доступ и управление:

· Службой Active Directory;

· Любым LDAP-каталогом;

· Прочими службами каталогов в имеющейся сети, включая NDS.

Интерфейсы службы каталогов Active Directory ADSI абстрагируют возможности служб каталогов различных поставщиков сетевых услуг, предоставляя единый набор интерфейсов службы каталогов для управления сетевыми ресурсами. Это существенно упрощает разработку распределенных приложений, а также администрирование распределенных систем. Разработчики и администраторы с помощью единого набора интерфейсов службы каталогов учитывают ресурсы в ней и управляют ими, в какой бы сетевой среде эти ресурсы ни содержались. Таким образом, интерфейсы ADSI облегчают выполнение основных задач администрирования, таких как добавление новых пользователей, управление принтерами и поиск ресурсов в распределенной среде. В сочетании с поддерживающими модель COM средствами, такими как системы разработки Microsoft Visual Basic, Visual C++® и Visual J++®, интерфейсы ADSI облегчают разработчикам возможность создания работающих с каталогом приложений.

Приложения, работающие со службой каталогов Active Directory

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

· Интеграция с групповой политикой. Возможности групповой политики позволяют администраторам задавать наборы приложений, включая специфические настройки, которые должны быть доступны пользователям в зависимости от роли пользователя в организации, домена, членом которого он является, и группы безопасности системы Windows 2000 Server, к которой он принадлежит. Когда пользователь приходит в организацию или добавляется к группе безопасности системы Windows 2000 Server, его приложения могут быть установлены и настроены автоматически, что значительно снижает стоимость установки и настройки.

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

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

· Модель расширения ADSI. В составе интерфейса ADSI имеется средство под названием ADSI Extension Model (модель расширения ADSI), которая позволяет разработчикам сопоставлять бизнес-правила, основанные на модели COM, с объектами, хранящимися в службе Active Directory. Это предоставляет разработчикам и администраторам согласованный и простой способ обеспечения взаимодействия с приложением и его объектами. Модель расширения также облегчает применение методов для групп объектов, таких как «Все пользователи из бухгалтерии» для упрощения администрирования.

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

Система Windows 2000 Server вместе со службой Active Directory представляют полноценную платформу для создания работающих с каталогом приложений. В подтверждение этого факта такие ведущие поставщики, как Baan, J.D. Edwards, SAP и Cisco обеспечили поддержку службы Active Directory в своих программных продуктах. Кроме того, среди требований программы "Эмблема готовности к работе с Windows 2000 Server" требуется, чтобы приложения при необходимости могли быть интегрированы со службой Active Directory. Корпорация Майкрософт полагает, что мощный потенциал платформы разработки системы Windows 2000, большие коллективы разработчиков, изучившие систему Windows и являющиеся ее приверженцами, а также наличие программы "Эмблема готовности к работе с Windows 2000 Server" позволят создать большое число разнообразных приложений, работающих со службой каталогов Active Directory.

Среда для разработки службы NDS

Корпорация Майкрософт считает, что у компании Novell имеются трудности с привлечением ведущих разработчиков сетевых продуктов и приложений для сред NetWare и NDS. Причины этого в том, что компания Novell на протяжении нескольких последних лет не использует своих разработчиков для решения задач по реализации приложений в качестве NLM-модулей (NetWare Loadable Module – загружаемый модуль NetWare). Даже недавно выпущенная платформа Java Virtual Machine для NetWare и партнерство с IBM с целью включения приложения WebSphere 3.0 Standard Edition компании IBM в систему NetWare 5.1 не принесли большого успеха, поскольку компании Novell не удалось доказать преимущества NetWare как платформы, работающей с языком Java, по сравнению со схожими программными продуктами таких конкурентов, как компании Sun Microsystems и IBM. В итоге после многолетних попыток компании Novell расширить сбыт своих программных продуктов появилось лишь несколько приложений, работающих со службой NDS.

По существу, стало ясно, что компания Novell перенаправляет усилия разработчиков на создание службы каталогов NDS на таких платформах, как Windows, и уходит от системы NetWare. Например, компания Novell вложила средства в разработку службы NDS Provider для интерфейса ADSI. Поскольку интерфейс ADSI основан на COM-технологиях корпорации Майкрософт и модель COM не работает под управлением системы NetWare, усилия компании Novell по продвижению ADSI, в конечном счете, будут способствовать дальнейшей пропаганде системы Windows среди разработчиков и независимых поставщиков программного обеспечения. В свою очередь, корпорация Майкрософт надеется, что разработчики, выбравшие систему Windows, в конце концов, выберут и службу каталогов Active Directory, а не NDS, поскольку Active Directory в большей степени интегрирована в среду операционной системы Windows и обладает более широким набором средств разработки.

У компании Novell существуют также нерешенные технические проблемы со службой NDS. Так, одним из серьезных вопросов является то, что приложения должны работать в соответствии с ограничениями, накладываемыми на разделы службы NDS. Например, чтобы избежать поиска, требующего обхода дерева, приложение электронной почты должно иметь данные о том, как разделен базовый каталог NDS. До сих пор наличие возможности поиска по всему дереву является обязательным требованием для многих распространенных архитектур приложений. Возможно, именно по этой причине в собственном программном продукте GroupWise не используется служба NDS, хотя с момента ее выхода прошло уже несколько лет.

Централизованное управление каталогом

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

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

К числу требований к многофункциональным каталогам, способствующим унификации, относятся следующие:

· Наличие средств синхронизации с другими каталогами.

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

· Способность развернуть многие приложения непосредственно в каталоге (вместо того, чтобы использовать отдельное хранилище для приложений) с перспективой уменьшения количества каталогов.

Служба каталогов Active Directory и синхронизация

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

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

Корпорация Майкрософт основывает свою стратегию синхронизации на использовании элемента DirSync. Например, в разработанном корпорацией Майкрософт продукте "Службы для NetWare версии 5" содержится компонент MSDSS (Microsoft Directory Synchronization Services – служба синхронизации каталогов), выполняющий двустороннюю синхронизацию со всеми версиями службы каталогов NDS компании Novell и одностороннюю синхронизацию с системными базами данных NetWare 3.x. Служба MSDSS автоматически распространяет изменения, сделанные в одном каталоге, в другой каталог, даже если древовидные структуры, используемые в каждом из них, различны. Это делает службы MSDSS идеальным решением, например в средах, содержащих сеть NetWare и систему Windows 2000 Server в качестве сервера приложения.

Каталог NDS и синхронизация

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

Каталог Active Directory и метакаталоги

Корпорация Майкрософт считает, что архитектуры метакаталогов являются наилучшим решением комплексного и централизованного управления каталогами. Следуя такой точке зрения, корпорация Майкрософт приобрела корпорацию Zoomit Corporation – лидера отрасли в технологиях метакаталогов. Программный продукт VIA корпорации Zoomit, переименованный корпорацией Майкрософт в службы MMS (Metadirectory Services – службы метакаталогов), находит широкое применение в сотнях организаций всего мира. Службы MMS позволяют реализовать центрально-лучевую архитектуру, с помощью которой можно подключиться ко многим существующим службам каталогов (и другим хранилищам информации, подобных каталогам), изменить службы управления, поддержать бизнес-правила и наиболее передовые технологии объединения.

Управление централизованным каталогом с помощью служб MMS

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

Службы MMS обладают следующими преимуществами:

· На основе службы Active Directory становится просто создать метакаталог, который пользователи, администраторы и приложения могут рассматривать как отправную точку при создании запросов и обновлений;

· Технологии брокеров в службах MMS позволяют компаниям выполнять преобразование данных, отслеживать местонахождение объектов и поддерживать отношения собственности во многих различных каталогах и хранилищах;

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

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

Служба NDS и централизованное управление каталогами

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

· Представляет собой XML-службы синхронизации данных между NDS и некоторыми известными службами каталогов, включая службу Active Directory;

· Не имеет многих важных служб метакаталогов (например, возможности автоматически создавать и поддерживать объединенное пространство имен, содержащее несколько каталогов), что подтверждается мнением признанных в отрасли аналитических компаний, таких как The Burton Group.

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

После того, как появится более подробная информация о продукте DirXML, корпорация Майкрософт уточнит свои выводы о нем.

Служба Active Directory и уменьшение количества каталогов

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

Наилучшим примером продукта корпорации Майкрософт, работающего с каталогом Active Directory, является Exchange 2000 – следующая версия Exchange Server корпорации Майкрософт. Exchange 2000 является первой версией Exchange Server, в которой нет собственной службы каталогов, и которая целиком будет опираться на службу Active Directory. Применение службы Active Directory в Exchange 2000 позволяет выполнять администрирование почтовых ящиков и учетных записей пользователей в одном месте и исключить необходимость в синхронизации данных с системой Windows 2000. Корпорация Майкрософт интегрирует службу Active Directory с другими важными программными продуктами, такими как Microsoft SQL Server, Microsoft Office, Microsoft Site Server и технологии COM, для того, чтобы они получили те же преимущества.

Корпорация Майкрософт работает также с ведущими независимыми поставщиками программного обеспечения над тем, чтобы поддержка службы Active Directory была в их продуктах. Например, поставщики SAP и Baan продемонстрировали клиентам, что можно находить службы с помощью поиска идентифицирующей приложения информации (другими словами, данных о местонахождении серверов), хранящихся в каталоге Active Directory. Компания Cisco Systems увеличивает количество продуктов, использующих идентифицирующую пользователя информацию, которая хранится в каталоге Active Directory для оказания индивидуальных сетевых услуг. В силу того, что корпорация Майкрософт твердо убеждена в важности интеграции, она внесла требования по интеграции со службой каталогов Active Directory в программу "Эмблема готовности к работе с Windows 2000 Server". Увидевшие эмблему пользователи поймут, что их стремление работать с меньшим количеством каталогов осуществится с помощью данного приложения.

Служба NDS и план уменьшения количества каталогов

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

Заключение

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

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

· Служба Active Directory лучше справляется с управлением сетевыми ресурсами, чем NDS;

· Служба Active Directory лучше подходит для Интернет-приложений, таких как приложения электронной коммерции, и экстрасетей, чем NDS;

· Служба Active Directory лучше подходит для приложений и имеет большую поддержку со стороны основных разработчиков инфраструктур и приложений, чем NDS;

· Служба Active Directory лучше подходит для объединения каталогов и централизованного управления каталогами, чем NDS.

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

[1] Служба каталогов NDS версии 8 реализует ту же технологию работы с каталогами, что и предложенные компанией Novell службы каталогов NDS eDirectory и NDS Corporate Edition. Корпорация Майкрософт считает, что эти предложения отличаются от службы каталогов NDS версии 8 системы Netware 5.1 только ценой и конфигурацией включенных служб. Выводы, полученные в результате сравнительного анализа для службы каталогов NDS версии 8, относятся в равной степени и к службам каталогов NDS eDirectory и NDS Corporate Edition.

[2] Раздел службы каталогов схож с таблицей базы данных в том, что в нем представлен набор объектов, доступ к которым можно получить непосредственно с помощью запросов и операций обновления без использования связей с другими разделами и без ссылок на них.

[3] Чтобы обеспечить эффективный трафик репликации между сайтами и по медленным каналам связи, в службе Active Directory используются серверы-плацдармы. Обновления транспортируются между серверами-плацдармами лишь один раз и затем передаются ими на другие контроллеры домена данного сайта.

[4] В версиях службы NDS, предшествующих NDS версии 8, разделы хранят объекты в файлах обычного формата, которые не индексируются. Из-за того, что поиск без индексирования сильно загружает систему, компания Novell рекомендует администраторам не создавать разделы содержащие более 5 000 объектов; при использовании таких продуктов компании Novell, как Z.E.N.Works, эта цифра еще меньше. При необходимости хранить более 5 000 объектов администраторы должны создавать дополнительные разделы. Из этого следует, что для сайтов, содержащих более 5 000 объектов, часто требуется создавать несколько разделов в одном сайте. Корпорация Майкрософт напоминает об этом ограничении потому, что для разделов, одновременно содержащих и серверы со службами NDS версии 8, и серверы службами NDS более ранних версий, все еще необходимо следовать указанной рекомендации, потому что эффективность работы всего раздела определяется емкостью служб NDS ранних версий.

[5] Поскольку имеются 10 серверов репликации, из формулы n*(n-1) следует, что потребуется установить 90 отдельных односторонних подключений

[6] Практически, степень сжатия, достигаемая при использовании службы Active Directory, составляет от 8:1 до 10:1