Ввиду расширения рынка служб каталогов знакомство с историей появления будет полезно для понимания их сильных и слабых сторон.
При превышающем сотню среднем числе различных каталогов в крупных организациях потребность во всеобъемлющей службе каталогов представляется совершенно очевидной, но пока она остается неудовлетворенной. И кстати, разве, как считалось, Banyan не решила эту проблему еще в 80-х? Что ж, Banyan продает теперь программное обеспечение для порталов, стандарту на каталоги X.500 уже 11 лет, NDS в эру Internet уже можно считать ветераном, а широкие массы готовятся к развертыванию Active Directory, коммерческая версия которой должна появиться в лучшем случае с Windows 2000 в конце 1999 года. Таким образом, «год каталога» еще не наступил.
В этой статье мы рассмотрим основные положения стандарта X.500 и упрощенного протокола доступа к каталогу (Lightweight Directory Access Protocol, LDAP). Кроме того, мы познакомимся с основными предложениями в области каталогов, такими, как Directory Server от Netscape, NDS от Novell и Active Directory от Microsoft, и завершим знакомство кратким обзором метакаталогов.
X.500
Первым годом эры каталогов можно считать 1988, когда CCITT (теперь ITU-T) приняла стандарт X.500. При участии ISO он был обновлен в 1993 и 1997 годах. Несмотря на то что поставщики заявляют о следовании рекомендациям X.500, в действительности лишь немногие их полностью придерживаются, хотя стандарт и служит базой для всех основных каталогов, появившихся после него.
Одну из моделей упорядочивания большого числа уникальных объектов представляет телефонный справочник, до сих пор используемый в качестве примера глобального каталога. Однако в этом случае вы должны знать имя человека для нахождения его номера телефона, и, кроме того, вам придется звонить в город его проживания для обращения в местный адресный стол.
Стандарт X.500 разрабатывался в соответствии с иной моделью, для преодоления недостатков названной. X.500 описывает набор взаимодействующих друг с другом компонентов для манипулирования логической базой данных с информацией о множестве объектов. Первоначально он предоставлял каталог для стандарта на обмен сообщениями X.400, разработанного для стандартизации бюджетов электронной почты, во множестве появившихся вследствие объединения сетей. Однако впоследствии X.500 был расширен для включения многих других объектов, так что некоторые стали рассматривать его как лучший способ уникальной идентификации любого объекта во всех сетях.
Ядро модели X.500 составляет распределенная база данных, содержащая полезную информацию об объекте, такую, как его характеристики и местонахождение в сети. Эти характеристики называются атрибутами. Пользователи каталога — люди и компьютерные программы — могут читать или модифицировать информацию из базы данных при условии, что у них есть надлежащие права. В терминологии X.500 вся распределенная база данных называется информационной базой каталога (Directory Information Base, DIB), а ее распределенные компоненты — системными агентами каталога (Directory System Agent, DSA).
DIB имеет хранилище данных с иерархической структурой под названием «информационное дерево каталога» (Directory Information Tree, DIT, см. Таблицу 1). Каждый элемент (entry) в структуре дерева состоит из одного или более узлов (DSA Specific Entry, DSE). DSE без нижележащих или дочерних элементов называется листом (leaf), а DSE с хотя бы одним дочерним элементом называется ветвью (nonleaf). Каждый из этих элементов имеет относительное отличительное имя (Relative Distinguished Name, RDN). Полная последовательность RDN для элемента от корня до DSE составляет отличительное имя (Distinguished Name, DN). Отличительное имя позволяет уникальным образом идентифицировать элемент внутри каталога и, теоретически, во всех имеющихся каталогах вообще.
 |
| Таблица 1. Каждый элемент в информационном дереве каталога имеет один или более узлов, называемых Directory Systems Agent (DSA) — Specific Entries (DSE). DSE имеет имя — Re-lative Distinguished Name (RDN). Distinguished Name (DN) представляет всю цепочку RDN для элемента. Одна из функций DN — уникальным образом идентифицировать элемент в каталоге(-ах). |
Например, такой класс объектов, как «частное лицо», содержит следующие атрибуты: имя, адрес, номер телефона. Вы можете затем создать класс объектов «удаленное лицо» как подкласс объектов «частное лицо» с такими дополнительными атрибутами, как номер сотового телефона и адрес электронной почты. Атрибуты «частного лица» передаются классу объектов «удаленное лицо» в результате наследования. С одной стороны, наследование является одной из наиболее мощных и полезных функций службы каталога, с другой — оно порождает множество проблем ввиду разнообразия вариантов наследования между классами объектов.
Таблица демонстрирует одну из наиболее привлекательных особенностей стандарта X.500, а именно распределение DIT между несколькими хранилищами данных. Я провел через дерево центральную ось до моего имени. Другие отходящие от вершины ветви представляют Великобританию и Канаду. От них, в свою очередь, ответвляются организации, входящие в этот каталог. Помимо компании Ascolta, где я работаю, ветвь Соединенных Штатов содержит все зарегистрированные в каталоге американские организации.
В отличие от телефонного каталога, где базу данных для конкретного географического региона составляет и пополняет местная телефонная сеть, соответствующая часть каталога X.500 находится под контролем организации, к чьей юрисдикции принадлежат листья ниже ее зарегистрированной точки демаркации. В данном примере это ветвь компании Ascolta. Будучи представленным в виде единой иерархии с одним корнем, каталог находится в действительности на множестве отдельных серверов и хранилищ данных. Эта концепция аналогична принятой в DNS. Компания либо сама заведует собственной DNS, либо обращается за услугами к сервис-провайдеру. Как бы то ни было, за правильность информации отвечают те, кто находится к ней ближе.
Всемирная DIB компонентов DSA завершает распределенную структуру X.500. Каждый DSA содержит и обслуживает свою уникальную часть DIT. Ввиду глобального характера X.500 всю базу данных хранить на одном компьютере попросту непрактично. Кроме того, циркулирующая внутри каталога информация имеет гораздо больше шансов быть правильной, когда каждый из владельцев DSA будет отвечать исключительно за свою часть информации.
Опрос по цепочке (chaining) и прямая ссылка (referral) представляют собой два основных коммуникационных процесса между агентами X.500. Запрос по цепочке передается от одного DSA к другому и проходит через всю структуру глобального иерархического дерева. DSA передает запрос другому DSA и ждет, пока ответ не вернется по всей цепочке назад. Прямая ссылка позволяет ускорить этот медленный процесс. В этом случае DSA отвечает на запрос сообщением имен и адресов агентов, к которым иначе пришлось бы обращаться по цепочке. Данные методы аналогичны используемым в DNS для установления соответствия между именем хоста и IP-адресом.
Тиражирование базы данных в соответствии с моделью «главный—подчиненный» было введено в X.500 в 1992 году. При таком подходе запись производится только в главную копию, и лишь потом изменения передаются подчиненным копиям. Данному методу было отдано предпочтение над моделью с несколькими главными копиями ввиду его меньшей сложности и обеспечения лучшей целостности данных.
 |
| Рисунок 1. Directory System Agent (DSA) взаимодействуют по Directory System Protocol (DSP). Клиенты же взаимодействуют с агентами по Directory Access Protocol (DAP). Запросы и изменения создаются клиентами с помощью Directory User Agent (DUA). |
Разница между DAP и DSP состоит в том, что DSP отвечает за выполнение опросов по цепочке и предназначен для организации взаимодействия DSA, в то время как DAP служит для обращения клиентов к DSA. Для создания запросов и обновления каталога клиенты используют пользовательского агента каталога (Directory User Agent, DUA). Архитектурные взаимосвязи между компонентами X.500 показаны на Рисунке 1.
Списки контроля доступа (Access Control List, ACL) предназначены, в соответствии с названием, для контроля доступа к объектам каталога. Стандарт X.500 предусматривает два базовых механизма защиты: идентификацию и метод открытых/частных ключей, известных как сертификаты X.509. Последний подход реализуют такие разработчики, как VeriSign.
ПРОБЛЕМЫ РЕАЛИЗАЦИИ X.500
Одним из препятствий к распространению X.500 стало то, что, в соответствии с первоначальным вариантом стандарта, DAP должен был базироваться на протоколах OSI, но реализация OSI требовала слишком значительных ресурсов и поэтому не нашла широкой поддержки. Однако многие из функциональных возможностей OSI оказались впоследствии включены в IPv6. Тем не менее если вы планируете внедрить каталог на базе X.500, то мы советовали бы вам убедиться, что он поддерживает TCP/IP в соответствии с RFC 1277, где описывается поддержка IP-адресов при использовании отличных от OSI нижних уровней. Если же у вас есть интерес к полностью опирающимся на X.500 продуктам, то для начала вам не помешает ознакомиться с перечнем всех имеющихся реализаций X.500 в RFC 2116.
X.500 разрабатывался с целью создания глобальной службы, опирающейся на независимо управляемых и распределенных DSA. Каталог X.500 на базе Internet имеет около 1,5 млн элементов в DIB. (Поиск по этому каталогу можно произвести с http://ganges.cs.tcd.ie/ntrg/x500.html.) Но это мизер по сравнению с числом узлов в Internet. Другие продукты, все частично базирующиеся на X.500, получили известность благодаря количеству подключенных сетевых узлов. Это оставляет надежду, что X.500 будет использоваться в качестве глобального справочника.
Главная проблема, которую стандарт X.500 пытался решить, — это изобилие адресов электронной почты. Именно поэтому стандарт X.400 обычно связывается с каталогом. С усложнением приложений они предъявляют все более высокие требования к каталогу, а это ставит такие вопросы, как управление с помощью правил и качество обслуживания. Программному обеспечению коллективной работы, приложениям для планирования корпоративных ресурсов и др. требуются сервисы, которые X.500 был готов предложить более 10 лет назад. К сожалению, глобальный каталог X.500 не получил распространения. Как уже упоминалось, одна из причин этого состоит в его чрезмерной сложности и требовательности к ресурсам, чтобы каталог можно было реализовать на узлах локальной сети, когда тем требуется доступ к нему.
LDAP
Подмножество X.500 под названием «упрощенный протокол доступа к каталогу» (Lightweight Directory Access Protocol, LDAP) позволило найти выход из тупика. В конечном итоге главная роль X.500 может состоять в том, что он способствовал появлению и определил характер LDAP.
LDAP считается протоколом доступа. Он был разработан в качестве альтернативы DAP как точка входа в каталоги X.500. Впоследствии он вырос в полноценную службу каталогов и теперь представляет собой и протокол доступа, и стандарт на распределенную службу каталогов. Все крупнейшие разработчики служб каталогов используют LDAP в качестве базового метода подачи запросов к своим DIB.
С развитием электронной коммерции служба каталога должна обладать функциональностью «желтых страниц», чтобы клиенты могли отыскать продукты и информацию через Internet. Взгляд на каталог как хранилище информации о пользователях и приложениях меняется на мнение, что служба каталогов должна вмещать всю информацию о любом объекте в сети. Это остается справедливым вне зависимости от того, что собой представляет конкретный объект — модем, маршрутизатор, микросхему, саморегистрирующееся приложение, активного пользователя или временную службу.
LDAP преодолел ограничения X.500, сдерживавшие его широкое распространение. LDAP не требует синхронной связи между серверами или клиентами. Запросами и ответами можно обмениваться в любом порядке, покуда каждый запрос получает ответ, если он того требует. Кроме того, взаимодействие между клиентами и серверами LDAP реализуется с помощью TCP, а не OSI.
LDAP во многом следует принципам X.500. Они оба поддерживают иерархическое пространство имен, используя элементы с атрибутами класса объектов. Вам не придется делать выбор — или LDAP, или X.500, так как серверы LDAP и X.500 взаимодействуют с серверами LDAP, передавая запросы агентам X.500 DSA. Результаты будут возвращены клиентам LDAP.
NETSCAPE DIRECTORY SERVER
Наилучшим примером каталога полностью на базе LDAP может служить Directory Server от Netscape. В апреле 1996 года Netscape удалось привлечь под знамена LDAP 40 компаний, включая IBM, DEC и VeriSign. Объявление ими поддержки LDAP как метода доступа к каталогам как LDAP, так и X.500 позволило привлечь на сторону LDAP и других поставщиков.
В своей службе каталогов Netscape использует в качестве базового протокола LDAP 2 (RFC 1777), а также недавно принятый LDAP 3 (RFC 2251). Directory Server может выполняться на множестве платформ, в том числе Windows NT, NetWare и UNIX. Netscape предоставляет клиентов LDAP с интерфейсом HTML, Netscape Communicator 4.x, а также комплект для разработки программного обеспечения, с помощью которого пользователи могут создавать своих собственных клиентов LDAP и интегрировать их в корпоративные приложения.
Directory Server имеет двухчастный коммуникационный механизм. Внешний интерфейс сервера — точка доступа — обрабатывает запросы LDAP. Внутренний интерфейс отвечает за подключаемые модули для управления базой данных. Это позволяет как использовать стандартную базу данных Netscape, так и заменить ее на другую реляционную базу данных. Стандартная база данных может работать одновременно с другими подключаемыми базами данных, так что внутренний интерфейс может охватывать несколько хранилищ данных и в то же время обслуживать единый каталог LDAP, называемый в Directory Server деревом каталога.
Такая структура позволяет близко следовать стандарту и в то же время отойти от идеала X.500 с деревом DIT в качестве единого полного распределенного хранилища данных. Directory Server имеет по сути ту же иерархию, что и X.500, за исключением дополнительного суффикса сервера, заменяющего корневой элемент, определенный в X.500. Это позволяет интегрировать его с DNS, причем последняя может идентифицировать конкретный сервер LDAP и найти отличительное имя на сервере Directory Service.
Netscape определяет корневое отличительное имя (Root Distinguished Name, RDN), специально создаваемый элемент для Netscape Management Services. Кроме того, Netscape определяет базовое отличительное имя (Base Distinguished Name, BDN), конфигурируемое на клиенте. Оно служит началом пути поиска клиента.
Обычно это корень каталога компании, что означает, что весь частный каталог доступен для поиска. Это также называется базой поиска, или, как в Netscape Communicator, корнем поиска.
 |
| Рисунок 2. Структура базы данных Netscape Communications с разделением на поставщика и заказчиков следует модели «главный—подчиненный». Все изменения в базе данных должны производиться на сервере поставщика, тогда как серверам заказчиков разрешаются только операции чтения. При такой модели отказ сервера поставщика может сделать невозможным процесс модификации. |
Процесс тиражирования Netscape предусматривает различные методы обеспечения доступности и распределения нагрузки. В целях обеспечения целостности данных сервер поставщика всегда является главным источником информации для службы каталогов. Однако серверы заказчиков могут служить источниками информации для других серверов в сети. Кроме того, сервер заказчика может содержать часть базы данных. Например, вы хотите опубликовать часть каталога в Internet, а часть оставить закрытой. В этом случае всю информацию можно поместить на сервере поставщика и создать его реплику на сервере заказчика, где будет содержаться только информация, которую вы хотели бы предоставить для общего доступа по внешнюю сторону брандмауэра.
Процесс тиражирования контролируется посредством соглашения о тиражировании между серверами. Он может быть инициирован как поставщиками, так и заказчиками. При внесении изменений информация на стороне поставщика тиражируется на серверы заказчиков. Те, в свою очередь, при надлежащей конфигурации могут запрашивать ее через предопределенные интервалы времени с целью оптимизации использования пропускной способности в случае медленных каналов связи. Частота тиражирования должна быть приведена в соответствие с динамикой изменений информации в каталогах (слабое место реализаций LDAP).
Directory Server предлагает также прямые ссылки для запросов службы каталога за пределы контекста службы каталога или базы поиска. Эта функция на базе LDAP 3 позволяет передавать запросы на сервер, где поддерживается пространство имен, по которому запрос пытается произвести поиск. Она необходима для достижения цели X.500 — создания глобального каталога. Если мы не можем создать глобальное дерево DIT, то во всяком случае способны создать «раскидистое» логическое дерево DIT посредством перекрестных ссылок на другие пространства имен на данном предприятии или даже за пределами зоны его юрисдикции. В отличие от идеала X.500, процесс перекрестных ссылок LDAP эффективен настолько, насколько эффективна конфигурация клиента LDAP по локализации соответствующих пространств имен.
Репутация Netscape резко повысилась, когда Ford Motor Company и Cisco Systems предпочли Directory Server решениям Microsoft и Novell для организации узлов электронной коммерции. Cisco уже практически завершила переход от собственного каталога на 400 000 пользователей, составляющих почти две трети клиентов компании. Обе эти компании тесно сотрудничают с Microsoft, так что, как показывает их выбор, у Microsoft остается все меньше шансов на успех Active Directory.
NOVELL DIRECTORY SERVICES
Novell Directory Services (NDS) является, вероятно, наиболее широко используемой службой каталогов по числу поддерживаемых мест вследствие преобладания NetWare в локальных сетях. Первоначально NDS базировалась на X.500, но потом она вышла за пределы стандарта, не дожидаясь, пока стандарт ее догонит. Зрелость NDS — это и преимущество, и недостаток в том смысле, что поддержка LDAP реализуется в виде сервиса, который требуется установить на каждый раздел.
Цель Novell состоит в превращении NDS в глобальную службу каталога, которую сторонники X.500 так и не смогли создать. Переносимые версии NDS имеются для таких операционных систем, как Solaris от Sun Microsystems, Linux, IBM AS/400 и Windows NT. Последняя версия NDS была разработана для провайдеров услуг Internet, чтобы они могли предлагать своим клиентам службу каталога точно так же, как теперь услуги DNS. Novell также сотрудничает с Lucent Technologies над интеграцией NDS в УАТС производства Lucent.
В NDS агенты DSA называются разделами. Каждый раздел хранится на отдельной машине. Разделы не перекрываются, обеспечивая распределенную информационную базу. Все вместе разделы в дереве NDS составляют каталог. Разделы могут тиражироваться, как того требует стандарт X.500, но NDS следует при этом модели с несколькими главными копиями. Это обеспечивает большую локальную надежность в случае проблем в сети и большую доступность службы при сеансах записи ввиду наличия нескольких копий с поддержкой записи для сохранения информации. В NDS эти теневые копии X.500 называются репликами.
В отличие от Active Directory, Novell не рекомендует, чтобы разделы (домены) простирались за пределы локальной сети, так как тиражирование между репликами раздела производится автоматически и может поглотить всю пропускную способность канала глобальной сети. NDS также следует стандарту X.500 в определении объектов и атрибутов, называемых в NDS свойствами. Novell использует термины «лист» и «объект-контейнер» вместо соответствующих терминов «лист» и «родительский элемент».
Несмотря на то что NDS не является каталогом X.500 в строгом смысле слова, она воплощает дух X.500. NDS не поддерживает DAP или другие протоколы, описанные в X.500, а вместо них опирается на собственные протоколы. NDS поддерживает LDAP и собственно IP, но все же она представляет собой закрытую систему, так как LDAP реализуется в виде дополнительного сервиса. Это отнюдь не означает, что NDS обречена на неудачу. Если Novell удастся развить свой успех в области сотрудничества с провайдерами Internet и такими игроками, как AT&T и Nortel Networks, то рынок может выбрать NDS в качестве стандарта де-факто, а X.500 может быть модифицирован с целью включения в него некоторых подходов Novell к распределенному управлению базой данных.
MICROSOFT ACTIVE DIRECTORY
В полнофункциональных бета-версиях Active Directory основное внимание уделяется стабильности. Microsoft построила Active Directory вокруг LDAP, с сервисами в качестве интерфейса к собственной внутренней базе данных. Active Directory опирается на концепцию доменов, несправедливо характеризуемых «негибкими» в предыдущих версиях Windows NT. Что действительно заслуживало такой характеристики в предшествующих версиях NT, так это нерасширяемая база данных в виде плоского файла, выбранная на роль каталога.
Домены аналогичны разделам NetWare, но каждый домен Active Directory содержит полную копию базы данных. Клиенты определяют местонахождение контроллеров доменов (Domain Controller, DC) с помощью DNS, а затем используют LDAP для обращения к серверу каталогов. Для того чтобы DNS могла работать с Active Directory, каждый DC именуется в соответствии со стандартными соглашениями об именах, например dc1.ascolta.com.
Элемент DNS содержит запись SRV (RFC 2052). Эта запись устанавливает соответствие между IP-адресами и именами хостов для сервисов, выполняющихся на указанном сервере. Записи SRV аналогичны записям MX, используемым почтовыми серверами SMTP для установления соответствия между именами и IP-адресами машин, на которых они выполняются. Клиент затем использует LDAP для запроса информации у сервиса Active Directory на машине, местонахождение которой он определил с помощью DNS. Active Directory не будет работать без сервера DNS.
Active Directory поддерживает LDAP 2 и 3. Если для определения местонахождения сервисов Active Directory использует имена DNS, то для объектов в каталоге — имена LDAP. Это означает, что один из атрибутов элемента служит в качестве стандартного имени для объекта. Active Directory вводит собственные соглашения об именах для объектов службы каталогов, например //ascolta.com/employee/chacon.
Имя Active Directory используется в графическом пользовательском интерфейсе, в то время как имя LDAP передается внутри системы. Каталог придерживается соглашения dc=RDN, таким образом он может поместить имя DNS в иерархию, например dc=ascolta и dc=com, для обозначения такого элемента DNS, как ascolta.com. Чтобы быть частью одного дерева, домены должны иметь смежные пространства имен DNS. В противном случае взаимоотношение между деревьями называется лесом, и поиск проводится «по лесу среди вершин деревьев».
Другим отличием Active Directory от LDAP наряду с NDS является концепция индексируемого каталога для ускорения поиска. В Active Directory это называется глобальным каталогом. Запрашивающая сторона может обратиться к глобальному каталогу, когда она не знает LDAP-имя элемента. Таким образом, запрос может производиться по какому-либо атрибуту(-ам). Глобальный каталог состоит из атрибутов элементов, указываемых администратором, и может охватывать все деревья в лесу Active Directory.
Например, если единственное, что вы знаете об объекте, — это имя, например Майкл, то вы можете произвести поиск по атрибуту «Майкл», и запрос выдаст записи обо всех Майклах в глобальном каталоге. Каждому Майклу соответствует полный элемент в Active Directory, так что вы можете перейти на этот элемент после выбора нужного имени по другим индексируемым атрибутам или просмотра по очереди всех найденных элементов.
Процесс тиражирования может создать определенные трудности. Если домен простирается по другую сторону канала глобальной сети, то избыточный трафик может создать заторы. В Active Directory эта проблема решается с помощью сайтов (site). Сайт — это одна или более подсетей, куда входят устройства с общими высокоскоростными локальными средствами соединения, такие, как маршрутизатор с интерфейсами Ethernet. Внутри сайта тиражирование производится автоматически. Сами же сайты связаны друг с другом через предмостовые серверы (bridgehead) с каждой стороны последовательного интерфейса на маршрутизаторе, так как он предоставляет обычно более медленные сервисы, такие, как frame relay по линиям T-1/E-1. Процесс тиражирования между предмостовыми серверами контролируется посредством введения ограничений на частоту тиражирования.
МЕТАКАТАЛОГИ
Метакаталог — это каталог каталогов, а также свидетельство того, что проблема службы каталогов еще далеко не решена.
Рассмотренные выше службы каталогов, а также предлагаемые компаниями Zoomit (http://www.zoomit.com) и Isocor (http://www.isocor.com) претендуют на роль метакаталога для Internet и объединений частных предприятий. Какая именно из них подойдет для конкретной организации, зависит от особенностей сети.
Метакаталог-победитель будет скорее всего ориентироваться на LDAP, а не на X.500. Некоторые разработчики предлагают метакаталоги на базе архитектуры Directory Server, NDS и Active Directory, т. е. метакаталог, вероятнее всего, будет представлять собой концепцию, а не определенный продукт. Метакаталог будет обеспечивать единое представление для пользователей независимо от того, сервисами скольких каталогов он в действительности пользуется.
Метакаталог можно организовать двумя способами. При первом подходе вся информация из каталогов копируется в метакаталог. Таким образом, она вся целиком имеется в собственном хранилище метакаталога. Что касается преимуществ такого подхода, все запросы могут быть выполнены посредством поиска в хранилище каталога, без необходимости перебора всех других объектов нижележащих служб каталогов. Что касается его недостатков, эта модель приводит к дублированию данных и увеличивает требования к ресурсам, в особенности когда атрибуты каталога содержат крупные блоки информации, в частности изображения или ключи шифрования.
Другая проблема с дублированием хранилищ — это тиражирование между метакаталогом и отдельными каталогами. Каждый отдельный каталог будет продолжать взаимодействовать с приложениями и пользователями, для которых он был создан. Однако изменения в каждом из каталогов должны будут тиражироваться не только между распределенными хранилищами в его собственной архитектуре, но и в метакаталог.
Второй подход к организации метакаталога — это непосредственно отображение схемы метакаталога на другие каталоги и создание таким образом окна во все каталоги из одной точки наблюдения. Это исключает дублирование информации и позволяет подключать к метакаталогу новые каталоги при их появлении в системе. Однако каждый нижележащий каталог должен контролировать доступ к вышележащему метакаталогу.
Еще вопрос, в какой мере введение еще одного каталога решает проблему множества каталогов. Множество вопросов, касающихся широкомасштабного каталога внутри компании или для нескольких компаний, по-прежнему остается. Например, базовая схема каждого каталога должна соответствовать всем остальным, а контекст защиты для каждого каталога или организационной единицы должен находиться под контролем для правильной передачи прав вниз по иерархии. Это те же самые проблемы, что и при реализации базовой службы каталогов. С развитием технологии служба каталогов будет, очевидно, ставить, наряду с техническими, и политические вопросы.
Майкл Чакон — старший преподаватель образовательного центра по сетевым технологиям Ascolta Training Company (http://www.ascolta.com). С ним можно связаться по адресу: hchacon@ascolta.com.Ресурсы Internet
Подробная информация о Novell Directory Services имеется на http://developer.novell.com/nds/nds_tech_over.htm.
Дополнительную информацию о Netscape Direc-tory Server можно найти на http://developer.netscape.com/docs/manuals/directory/.
Подробности об Microsoft Active Directory можно узнать на http://www.microsoft.com/windows/server/Overview/exploring/directory.asp/.
Обширный перечень различных источников информации по RFC приводится на http://www.rfc-editor.org/rfc.html.