ВВЕДЕНИЕ

Ситуация Пользователя

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

Рис. 1: Каталоги, ориентированные на приложения.

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

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

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

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

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

Рис 2: Многоцелевые каталоги

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

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

Необходимые требования

Для успешного функционирования многоцелевого управления каталогами технология должна удовлетворять ряду требований:

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

· Распределение, доступ и управление объектами каталога должно использовать стандарты Интернет. Несмотря на широкий спектр использования – часто сквозь корпоративные и географические границы – каталоги должны быть способны принять и разместить объекты, используя стандарты Интернет, такие как Domain Naming Service (DNS) - Служба Именования Доменов и Lightweight Directory Access Protocol (LDAP) - Облегченный Протокол Доступа к Каталогам.

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

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

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

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

Active Directory – наиболее перспективный выбор

В связи с появлением Novell Netware версии 5.0, а также Novell Directory Service (NDS) версии 1.2, Microsoft часто просят дать сравнительную характеристику Active Directory и NDS.

Microsoft считает, что Active Directory в большей степени удовлетворяет требованиям многоцелевой технологии управления каталогами, чем NDS:

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

· Использование стандартов Интернет —Active Directory предоставляет доступ ко всем возможностям LDAP и использует основанное на DNS пространство имен, в то время как NDS не позволяет использовать все возможности LDAP и вообще не поддерживает DNS для формирования имен объектов каталога.

· Гибкая, простая система безопасности —Active Directory поддерживает различные протоколы аутентификации, такие как Kerberos, сертификаты X.509 и Smart Cards, т.е. группы доступа могут эффективно разделять разделы, NDS не поддерживает протоколы Kerberos и Smart Cards, а фирма Novell рекомендует администраторам минимизировать группы доступа, распределенные по разным разделам.

· Упрощение консолидации каталогов – Для удовлетворения требований консолидации и синхронизации каталогов Active Directory использует интерфейс, основанный на LDAP. В то же время NDS предоставляет очень ограниченную поддержку консолидации и ограниченную синхронизацию.

· Предоставление исчерпывающего набора функций и среды разработки приложений —Active Directory привлекла внимание ведущих разработчиков, таких как SAP, Baan, J.D. Edwards, Cisco и многих других; Novell не пользуется широкой поддержкой разработчиков, что снижает преимущества TCO (Total Cost of Ownership – совокупная стоимость владения), предоставляемые NDS.

По этим и другим причинам—описанным ниже и сведенным в Таблице 1 —Microsoft считает, что Active Directory – более перспективный вариант многоцелевых технологий управления каталогами по сравнению с Novell NDS.

Таблица 1: Сравнение Active Directory и NDS на уровне требований

Требование

Active directory

NDS

Масштабируемость без увеличения сложности

· Граница раздела представляет собой домен Windows 2000 с возможностью прямого доступа к объектам внутри домена.

· Разделы используют индексные файлы для ускорения поиска.

· Способность работать с миллионами объектов.

· Оптимизация репликации между узлами и в низкоскоростных сетях.

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

· Единые методы хранения и доступа для разделов и каталогов.

· Разделы не индексируются.

· Novell рекомендует максимум 1000 объектов на раздел, причем разделы не должны перекрываться по WAN-связям.

· Администраторы должны следить за размерами разделов и реструктурировать разделы по мере их наполнения.

· Поиск объектов внутри разделов требует просмотра дерева.

· Разные способы хранения разделов и каталогов.

· Низкая производительность при работе с каталогами, т. к. изменения производятся через определенное время (по умолчанию – 24 часа).

Использование стандартов Интернет

· Реализация в виде сервера LDAP, что не требует трансляции запросов.

· Согласованная интерпретация прав доступа в контексте LDAP.

· Предоставление контекста доступа LDAP во всех случаях.

· Полная интеграция пространства имен и DNS для упрощения доступа к объектам.

· Поддержка LDAP через серверный интерфейс, который должен устанавливаться на каждом NDS-сервере.

· Запросы LDAP должны транслироваться в формат NDS .

· Ограничения на доступ к возможностям NDS через LDAP-интерфейс.

· Разный синтаксис имен при доступе через LDAP и через NDS API.

· Права доступа по-разному интерпретируются при доступе через LDAP и через NDS API.

· Отсутствие интеграции пространства имен с DNS усложняет именование и размещение объектов.

Гибкая система безопасности

· Поддержка известных технологий , таких как Kerberos и Smart Cards.

· Защита реализуется как на уровне объекта, так и на уровне атрибутов объекта.

· Никаких ограничений на группы, перекрывающие разделы (домены).

· Не поддерживаются Kerberos и Smart Cards.

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

· Novell рекомендует сводить к минимуму группы, перекрывающие разделы.

Поддержка синхронизации и консолидации

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

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

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

· Будет использоваться в Microsoft Exchange 6.0, MSMQ 2.0 и MCIS 3.0.

· Ограничения на размер разделов при консолидации каталогов.

· Не предоставляются формальные методы запроса на изменение истории, для этого требуется вмешательство оператора.

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

· Не используется в Novell GroupWise для учета пользователей и функций адресной книги.

Среда разработки приложений

· Предоставляется Интерфейс управления Активными Каталогами (ADSI), который базируется на технологии COM для упрощения разработки приложений.

· JADSI поддерживает доступ из Java-приложений.

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

· Доступ на основе LDAP предоставляется во всех случаях.

· Не реализован интерфейс ASDI для приложений, работающих в NetWare.

· JNDI поддерживает доступ из Java -приложений.

· Приложения должны работать в рамках раздела.

· Ограниченный LDAP-доступ на основе средств NDS API.

Таблица 2: Сравнение Active Directory и NDS на уровне функций

Функция

Active directory

NDS

Управление пользователями и сетевыми ресурсами

· Масштабируемость позволяет эффективно и без усложнения администрирования хранить, размещать и управлять большим числом объектов.

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

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

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

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

· Низкая производительность при работе с каталогами, поскольку изменения производятся через определенные промежутки времени (по умолчанию – 24 часа).

· Novell не рекомендует применять разделы, распределенные между различными участками сети.

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

· Поддержка известных технологий , таких как Kerberos и Smart Cards.

· Защита реализуется как на уровне объекта, так и на уровне атрибутов объекта.

· Масштабируемость поддерживает большое количество пользователей в экстрасетях (extranet).

· Интеграция с DNS упрощает формирование имен объектов и их нахождения с помощью протоколов Интернета.

· Не поддерживаются Kerberos и Smart Cards.

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

· Ограничения на размер раздела усложняет применение экстрасетей.

· Несовместимость с DNS затрудняет формирование имен объектов, а также их нахождение.

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

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

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

· Ограничения на размер раздела лимитирует использование консолидации каталогов.

· Не предоставляются формальные способы доступа для изменения истории, требуется вмешательство оператора.

Прикрепленная к каталогу инфраструктура

и приложения

· Прочная поддержка ведущих разработчиков.

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

· Доступ в контексте LDAP предоставляется во всех случаях.

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

· NetWare предоставляет ограниченную среду разработки приложений.

· Приложения должны работать в пределах раздела.

· Ограниченный LDAP-доступ на основе средств NDS API.

ТЕМА: Масштабируемость

Критерий масштабируемости

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

· Особенностью механизма хранения данных каталога является возможность поддержки большого количества различных объектов. Определение понятия большое количество – это предмет для дискуссии, хотя в общем случае компания может иметь свыше 50.000 сотрудников, большинство которых имеют компьютеры, различные типы приложений и различные способы подключения к сети. Это означает, что имеет смысл предположить раздел[1] управления каталогами, содержащий 1 миллион объектов.

· Должна обеспечиваться возможность быстрого поиска объектов внутри раздела либо прямо по фамилиям, либо по частичному совпадению свойств объектов (например «найти всех сотрудников, которых зовут “Bob”»).

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

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

Рис. 3: Условный сценарий

Условный сценарий

Наилучший способ сравнения – использовать пример условной компании. На рис. 3 показана компания, расположенная в Северной Америке и имеющая отделения в Азии и Европе. В Америке имеются сайты в Сан-Диего, Чикаго и Бостоне. Сайты внутри Америки подключены к быстрой, надежной сети. Азия и Европа соединены с Америкой более медленной и менее надежной сетью.

Условный Сценарий

· Компания с отделениями в Америке, Азии и Европе

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

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

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

· Некоторые атрибуты (имя, адрес e-mail) должны быть доступны со всех континентов

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

Разделы Active Directory

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

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

Рис. 4: Раздел Active Directory

При использовании Windows 2000 и Active Directory, модель домена расширяется в огромной степени:

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

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

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

По этим причинам Microsoft считает, что большинство компаний будут использовать меньшее количество больших по размеру доменов, когда они развернут Windows 2000.

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

Разделы NDS

Figure 5: Раздел NDS

NDS использует разделы в том числе и для отделения пространства имен от памяти для хранения будущих объектов, а также для определения местоположения копии разделов. Поскольку NDS хранит объекты в разделах, используя неиндексированные файлы, Novell не рекомендует администраторам формировать разделы, содержащие более одной тысячи объектов[3]. При необходимости хранить более 1000 объектов администраторы должны образовать новые разделы.

На рис. 5 показан вариант развертывания NDS на базе того же условного сценария. Каждый континент и сайт требуют нескольких разделов для хранения такого же количества объектов.

Microsoft считает, что схема образования разделов в NDS порождает массу проблем для администраторов, пользователей и приложений:

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

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

· Приложения фирмы Novell автоматически формируют немалое число объектов внутри раздела. Например, Netware образует три объекта для каждого пользователя DHCP и от одного до трех объектов для каждого пользователя ZenWorks.

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

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

Необходимость механизма каталогов

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

Механизм каталогов в Active Directory

Active Directory содержит механизм, который называется Global Catalog (глобальный каталог). Этот механизм позволяет администраторам сформировать каталог и поместить в него атрибуты объектов, представляющие интерес для пользователей некоторого домена. Global Catalog базируется на концепции Windows 2000 : trees (деревья) и forests (леса). Механизм Global Catalog позволяет определить участие каждого домена в формировании каталога.

Рис. 6: Дерево доменов Windows 2000, содержащее Global Catalog

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

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

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

· Доступ к каталогам Global Catalog осуществляется точно так же, как и ко всем другим каталогам внутри разделов Active Directory.

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

Механизм каталогов в NDS

NDS предоставляет механизм, который называется Catalog Services. Администраторы разрешают доступ пользователям и приложениям непосредственно к объектам, содержащим требуемые данные. Доступ осуществляется путем формирования запросов. Novell рекомендует использовать механизм каталогов для освобождения от необходимости совершать прогулки по дереву при осуществлении поиска данных.

Рис. 7: Архитектура каталогов NDS

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

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

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

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

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

Microsoft считает, что требования масштабируемости, которые предъявляет большинство клиентов, очень трудно удовлетворить при помощи средств NDS.

ТЕМА: Поддержка стандартов Интернет

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

По мнению Microsoft в контексте управления каталогами имеются два наиболее важных аспекта поддержки стандартов Интернет:

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

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

Active Directory и LDAP V3

Рис. 8: LDAP и Active Directory

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

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

NDS и LDAP

Поддержка LDAP в NDS осуществляется через специальный LDAP-сервис для NDS. Как говорит сама фирма Novell, “Сервис LDAP для NDS есть интерфейс между NDS и приложениями, совместимыми с LDAP.”[4] Этот сервис работает как транслятор между LDAP-запросами и способом, при помощи которого NDS получает данные из раздела.

Рис. 9: LDAP и NDS

Хотя Novell претендует на полную совместимость с LDAP V3, Microsoft считает, что способ поддержки LDAP в NDS имеет много недостатков:

· LDAP-сервис должен устанавливаться на каждом сервере NDS, который поддерживает средства LDAP. Novell также отмечает: “Если вы сразу не установите сервис LDAP для NDS с намерением сделать это позже, вам придется затратить значительное время на эту установку. Поскольку схема требует синхронизации дерева, время ожидания будет зависеть от размеров дерева NDS.”[5]

· LDAP и NDS используют разный синтаксис имен.[6]

· Права доступа к данным предоставляются по-разному при доступе через LDAP и непосредственно через интерфейс NDS.[7]

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

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

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

Active Directory и DNS

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

Microsoft пошла другим путем и снабдила Active Directory механизмом, который уже используется во всем мире для поиска информации в Internet: DNS. Имена доменов в Windows 2000 базируются на именах DNS. Поскольку домены фактически являются разделами в Active Directory, поля имен могут быть помещены непосредственно через DNS. Более того, имя объекта Active Directory содержит DNS-имя раздела этого объекта, имеет глобальную уникальность и исчерпывающе описывает поиск объекта в компании Intranet, а также в Internet в целом.

NDS и DNS

Способ формирования имен в NDS не включает в себя имена DNS. Для размещения объекта в NDS пользователи должны знать, как найти подходящий сервер NDS. Кроме этого, интранет-приложения, написанные для непосредственного доступа к объектам через NDS, должны использовать имена объектов, отличные от тех, которые есть в приложениях Интернет, использующих LDAP, поскольку синтаксис имен в NDS и LDAP различный.

ТЕМА: безопасность

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

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

· Каковы возможности разграничения доступа после того, как аутентификация произведена.

· Каковы ограничения, накладываемые системой разграничения доступа.

Active Directory и аутентификация

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

NDS и аутентификация

NDS поддерживает сертификаты X.509, но не поддерживает протоколы аутентификации Kerberos или Smart Cards. Кроме этого, как отмечалось выше, разграничение доступа осуществляется по-разному при доступе к NDS через LDAP и непосредственно через интерфейсы NDS.

Безопасность и наследование

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

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

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

Active Directory и наследование прав доступа

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

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

NDS и наследование прав доступа

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

Active Directory и группы

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

NDS и группы

Из-за концепции, которую поддерживает NDS, Novell рекомендует администраторам минимизировать количество групп, члены которых находятся в разных разделах, поскольку в этом случае сильно возрастает нагрузка на сеть. Microsoft считает, что это создает значительные сложности для администраторов NDS при определении разделов – никто не может гарантировать, что эту рекомендацию не придется нарушить, чтобы удовлетворить требованиям бизнеса.

ТЕМА: Синхронизация и консолидация

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

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

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

· Наличие средств, позволяющхе синхронизировать изменения с другими каталогами.

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

Active Directory и синхронизация

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

Наконец, вскоре после выпуска сервера Windows 2000 Microsoft предполагает выпустить дополнительный продукт, который будет использовать механизм отслеживания изменений объектов Active Directory для соответствующих объектов, хранящихся в NDS.

NDS и синхронизация

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

Active Directory и консолидация

Как уже говорилось в разделе "Масштабируемость", Active Directory предоставляет масштабируемость до миллиона объектов в одном разделе. Такой уровень масштабируемости позволяет использовать Active Directory как место консолидации для управления ориентированными на разные приложения каталогами. Например:

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

· Microsoft Message Queue Service версии 2.0 (MSMQ), входящая в состав Windows 2000 Сервер, будет использовать Active Directory вместо базы данных SQL Server 6.5, которую использует MSMQ версии 1.0.

· Microsoft Commercial Internet Services Internet (MCIS) будет использовать Active Directory для аутентификации доступа пользователей, начиная с версии 3.0.

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

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

NDS и консолидация

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

Microsoft также считает, что управление каталогами в NDS будет иметь ограниченное применение в схемах консолидации, поскольку приложение может добавить или изменить каталог в разделе[8], а затем очень долго искать соответствующую копию объекта. Это будет иметь место, даже если каталог находится на том же сервере, что и сам раздел.

ТЕМА: Среда разработки

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

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

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

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

· Возможности, предоставляемые системой управления каталогами

· Насколько легко можно использовать эти возможности

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

Интерфейс служб Active Directory (ADSI)

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

· Active Directory

· Любыми, совместимыми с LDAP

· Другими каталогами клиентов, в том числе и с NDS

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

Приложения для работы с Active Directory

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

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

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

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

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

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

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

Среда разработки в NDS

Microsoft считает что у фирмы Novell имели место сложности со средой разработки в связи с наличием хорошо известной проблемы реализации приложений в виде загружаемых модулей Netware (Netware Loadable Modules, NLMs). Несмотря на объявление о поддержке ADSI для NDS, приложения, работающие на серверах NetWare, не смогут использовать ADSI, поскольку эта ОС не поддерживает COM и основанные на этой технологии средства, такие как Visual Basic. Вместо этого приложения NetWare должны использовать либо NDS API, либо вызовы JNDI при работе на виртуальном компьютере Java , который входит в Novell NetWare 5.0.

В дополнение к этим ограничениям приложения, использующие NDS как средство хранения данных, должны учитывать ограничения разделов NDS и не смогут просто образовать требуемое число объектов в разделе. Например, приложение e-mail не сможет использовать контейнер для размещения адресной книги в разделе, если ожидается, что эта адресная книга может содержать более 1000 элементов (т.е. объектов). Может быть, по этой причине собственный продукт GroupWise фирмы Novell использует NDS для аутентификации и управления пользователями, а для адресной книги и учета пользователей использует отдельную базу данных.

Выводы

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

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

Результаты сравнения показывают, что Active Directory:

· Лучше, чем NDS управляет пользователями и ресурсами сети

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

· Является лучшей, чем NDS платформой консолидации и централизации управления каталогами

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

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

Дополнительная информация

Для получения дополнительной информации о Windows 2000 посетите Web site по адресу http://www.microsoft.com/ntserver/, the Windows NT Server Forum on MSN™, и The Microsoft Network online service (GO WORD: MSNTS).

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

[2] Active Directory использует буферные серверы для обеспечения эффективного движения копий внутри сайтов и через «медленные» сети. Изменения проходят один раз через такой сервер, который затем распространяет эти изменения по другим контроллерам домена в сайте.

[3] Эта рекомендация содержится в руководстве для Novell Netware 5.0, которе можно найти по адресу: http://www.novell.com/documentation/en/nw5/nw5/usnds/basicenu/data/h0000017.html

[4] Эта фраза цитируется из документа http://www.novell.com/whitepapers/nw5/nds.html

[5]Эта рекомендация содержится в on-line документации по Novell Netware 5.0 по адресу: http://www.novell.com/documentation/en/nw5/nw5/usnds/ldap_enu/data/h0000013.html

[6]Это объясняется более подробно в on-line документации по Novell Netware 5.0 по адресу: http://www.novell.com/documentation/en/nw5/nw5/usnds/ldap_enu/data/h0000011.html

[7] Это объясняется более подробно в on-line документации по Novell Netware 5.0 по адресу:: http://www.novell.com/documentation/en/nw5/nw5/usnds/ldap_enu/data/h0000007.html

[8] Объекты не могут быть модифицированы ни в Active Directory , ни в NDS вторичных каталогах.