Сервис каталогов (Directory Service)
Сервис каталогов — одно из маркетинговых названий, активно «раскручиваемых» в последнее время. Ведущие производители программного обеспечения представляют его как волшебную палочку, которая может решить многие проблемы сети. На рынок активно продвигаются такие продукты, как Novell NDS и Netscape Directory Service. До того как начать разбираться, чем же могут они помочь системному администратору, имеет смысл выяснить, что такое сервис каталогов.
Под термином «сервис каталогов» обычно понимают сетевой сервис, позволяющий по одному атрибуту, например по имени, найти другой атрибут, например адрес. Это выглядит немного похожим на сервис баз данных, и это действительно так. Отличие сервиса каталогов от сервиса баз данных состоит в том, что сервис каталогов оптимизирован на обращение по чтению, и поэтому запись в него может быть довольно медленной процедурой. Кроме того, в сервисе каталогов чаще всего не предусмотрено введение сложных отношений между различными записями, как это бывает даже в простейших базах данных. Другой отличительной чертой, косвенно связанной с оптимизацией на чтение, является возможность построения глобальной службы каталогов в некоторых сервисах каталогов.
Все еще не понятно? Обратимся к примерам.
Каждый, кто когда-либо пользовался Internet, одновременно пользовался и глобальной службой, которая подпадает под определение «сервис каталогов», — сервисом доменных имен (Domain Name Service, DNS). Использование этой службы по возможности скрыто от пользователя, но не от администратора. В задачу службы входит поиск по имени компьютера его IP-адреса и некоторых других параметров. Дело в том, что в Internet каждый компьютер имеет свой уникальный номер (например, 192.168.11.195), и все сообщения, адресованные этому компьютеру, передаются с включением в сообщение номера этого компьютера в качестве адреса назначения. Но человеку трудно запоминать номера, ему легче запоминать имена. Поэтому необходимо иметь возможность по имени компьютера находить его номер. В начале развития Internet, когда компьютеры, подключенные к сети, можно было пересчитать по пальцам, данную роль выполнял файл со списком имен и соответствующих номеров (для знакомых с UNIX — это, конечно, файл /etc/hosts). Главная копия этого файла находилась в предопределенном компьютере, при регистрации нового компьютера регистрационные сведения сообщались определенному человеку, который вносил в этот файл изменения. Затем новая копия файла ночью рассылалась на все остальные компьютеры. Когда количество компьютеров возросло, возникли некоторые трудности. Во-первых, файл становился слишком большим, а поиск в нем — делом долгим. Во-вторых, стало трудно подбирать машинам уникальные имена. И, в-третьих, изменения требовалось вносить все чаще, так что за ними стало труднее следить из одного центра. Решением проблем послужило создание иерархической глобальной структуры доменов. Иерархическая структура доменов похожа на иерархическую структуру каталогов файловой системы. Так, в файловой системе файл с полным именем c:\docs\article\myarticle.doc является файлом, информация о котором находится в каталоге article, информация о каталоге article, в свою очередь, находится в каталоге docs, а информация о каталоге docs — в корневом каталоге диска C. Когда нам необходим этот файл, то мы (или система от нашего имени) сначала находим в корневом каталоге каталог docs, затем в нем — каталог article и уже в нем — файл myarticle.doc. Практически каждый, кто работает с компьютером, когда-либо делал нечто подобное.
Аналогично в доменной структуре существуют «каталоги», называемые зонами. Зона и все входящие в нее подзоны называются доменом. Для каждой зоны выделен как минимум один сервер, который «знает» все имена, входящие в зону, и адреса серверов подзон. Так, существуют серверы корневой зоны, которые знают адреса серверов зон первого уровня. В зоны первого уровня входят зоны: com, edu, org, net, ru, us и др. Они, в свою очередь, знают адреса серверов второго уровня и т.д.
Если программе надо найти адрес какого-либо компьютера, пусть, к примеру, это будет www.somecompany.com, она сначала обращается к одному из корневых серверов и узнает адрес сервера для зоны com. Затем она обращается к этому серверу и
узнает адрес сервера для зоны somecompany. И уже у этого сервера программа узнает адрес компьютера с именем www.Чтобы такую процедуру не проделывать каждый раз, когда требуется организовать соединение, ответ от серверов на некоторое время запоминается и повторные запросы не требуются. Но это же приводит к тому, что непосредственно после изменения соответствия имени и адреса на одном из серверов не все заинтересованные стороны сразу замечают это. Поэтому процесс внесения изменений в зону не очень быстр. Внимательный читатель может задать вопрос: а откуда компьютер знает адреса корневых серверов? Очень просто — эти адреса меняются довольно редко, и информация о них записывается на диск при установке программного обеспечения, поддерживающего поиск, а затем только изредка обновляется. Но клиенту не обязательно знать даже это. Вся информация вносится системным администратором, а клиенту надо только указать ближайший DNS-сервер, который и проделывает все эти достаточно сложные процедуры.
Такое построение позволяет создать глобальный сервис имен и дать возможность каждой организации самой вносить изменения в зоны, касающиеся их самих или тех организаций, которым они предоставляют такой сервис. Сервис работает достаточно хорошо — об этом можно судить хотя бы потому, что многие пользователи даже не подозревают о его присутствии.
Другим примером сервиса директорий является NIS (Network Information Service) — сервис, разработанный фирмой SUN и широко распространенный в мире Unix. В отличие от DNS, NIS — локальный сервис, предоставляющий информацию только в пределах организации, для которой он сконфигурирован. Поэтому в этом сервисе отсутствует понятие домена. В NIS может быть расположена практически любая информация, которая имеет форму «ключ — значение», например имя компьютера — его IP-номер. Но если этот сервис уже предоставляется DNS, то зачем же тогда иметь еще и NIS? Во-первых, не все сети подключены к Internet и им не нужен полный доменный сервис, предоставляемый DNS. Во-вторых, некоторые организации большинству своих компьютеров присваивают номера, специально зарезервированные для локальных целей, частных сетей. По соглашению упоминание об этих номерах не должно появляться в глобальной сети. В данном случае иногда лучше разместить информацию о таких номерах в NIS.
Однако мы полагаем, что невозможность находить номера компьютеров по их имени явилась основной причиной популярности NIS. Важная сфера применения NIS — распространение информации об учетных карточках пользователя: его идентификаторе, пароле, начальной рабочей директории. Это удобно, когда есть сеть из нескольких рабочих станций UNIX и пользователь может работать на любой из них.
До разработки NIS системный администратор был вынужден вручную заводить учетную карточку на каждом из компьютеров. Хорошо, если их два-три, а если десяток? Конечно, системные администраторы могут написать небольшую программку, сделав запись о пользователе на одном компьютере и потом скопировав ее на другие. Но если один из них в это время не включен, то он не будет иметь регистрационной записи пользователя. Кроме того, пользователь в таком случае вынужден менять пароль на каждой из машин. Это превращается в кошмар, когда их несколько и не сразу вспомнишь, где уже поменял, а где еще нет. При применении NIS все существенно упрощается, ибо все изменения проводятся лишь на одной машине. Системный администратор делает учетную запись только на главном сервере, и практически мгновенно эта информация становится доступной во всей сети. Пользователь может сменить пароль на любой из машин сети, и это изменение сразу становится доступным для остальных машин.
Как уже было сказано, NIS может распространять большое количество разнообразной информации. Сервис применяется для распространения информации о почтовых адресах, сетевых ресурсах, экспортируемых различными машинами, и иной полезной информации. NIS является достаточно гибкой системой, и администратор может выбирать, какую информацию компьютер будет запрашивать у сервера NIS, а какую будет брать из файлов, расположенных на локальном диске. Более того, современные реализации NIS позволяют синхронизовать их информацию с информацией DNS-сервера. При правильной конфигурации пользователь может даже не замечать работу NIS. В общем, NIS — исключительно полезная система.
Тем не менее есть у нее и серьезные недостатки, вызванные ее «почтенным возрастом» — NIS была выпущена фирмой SUN в 80-е годы. Тогда просто еще не знали о нынешних проблемах. Сейчас простая, бездоменная структура NIS не удовлетворяет потребностям большого предприятия со сложной структурой. (Действительно, в большой корпоративной сети возникают проблемы, подобные тем, которые решились введением DNS в Internet.)
Другой проблемой NIS является то, что он не соответствует современным требованиям безопасности. Теперь, когда к сети подключено огромное количество пользователей и кое-кто из них не очень добросовестен, требования безопасности выходят на первый план.
Заметим, что относительно недавно фирма SUN выпустила новую версию — NIS+, которая исправляет многие недостатки NIS, но большого распространения эта система не получила.
Несомненно, проблемы, которые решались с помощью NIS, остаются. Более того, в современных сетях с огромных количеством различных компьютеров и операционных систем эти проблемы стали еще острее. Все более популярной заменой NIS в таких сетях становятся системы, реализующие протокол LDAP, — его поддерживают такие продукты, как NetWare Directory Service и Netscape Directory Service.
LDAP (The Lightweight Directory Access Protocol — упрощенный протокол доступа к каталогам) является упрощенной (о чем можно догадаться из названия) версией стандартного X.500 DAP-протокола — части OSI-модели. DAP-протокол очень сложен, ему необходимо наличие сложного стека протоколов OSI, и клиент, полностью реализующий его, требует от компьютера огромного количества ресурсов. LDAP изначально был задуман как «ворота» из Internet со стандартными протоколами TCP/IP к компьютеру с OSI-протоколами и X.500-сервисом, позволяющим клиенту получать информацию из Internet с X.500-сервера. Это дало возможность существенно упростить протокол, сделав реальным с небольшими затратами ресурсов использовать LDAP-клиенты практически на любой машине, работающей с TCP/IP.
В дальнейшем появились серверы, реализующие доступ к информации с использованием LDAP-протокола без всякого участия X.500-сервера, непосредственно из файлов на компьютере с LDAP-сервером. И в настоящее время вы можете использовать LDAP и как «ворота», и как самостоятельный сервис.
Несмотря на существенные упрощения, LDAP унаследовал многие черты X.500. И прежде всего это касается методов представления информации в данном сервисе.
X.500, как и DNS, является глобальным сервисом, то есть каждая запись здесь должна иметь уникальное по всему миру имя. Имена в X.500 обладают довольно громоздкой структурой (как, пожалуй, и все в OSI), и LDAP унаследовал это свойство. Имена состоят из пар «имя поля — значение», разделенных запятой. Так, имя человека (пусть это будет Иванов Иван Петрович), работающего в учреждении, которое называется «Институт изучения сервиса каталогов», в X.500 могло бы иметь следующий вид:
cn=Иванов Иван Петрович, o=Институт изучения сервиса каталогов,с=ru
В этом примере адрес имеет структуру «страна — организация — личность». В большой организации в адрес могут входить также наименования подразделений. Такая структура адреса соответствует X.500-стандарту и может использоваться и в LDAP. Однако поскольку DNS с его глобальной структурой присвоения имен широко распространен в Internet, для LDAP рекомендована другая структура адреса, которая больше соответствует структуре DNS. Допустим, у нашего института есть зарегистрированное доменное имя iisk.ru, тогда адрес в LDAP того же Ивана Петровича мог бы выглядеть следующим образом:
cn=Иванов Иван Петрович, dc=iisk,dc=ru.
Видно, что такое наименование совместно с глобальной системой DNS-имен отвечает требованию глобальной уникальности. Важным является то, что каждая организация в пределах своего сервера имеет право самостоятельно выбирать схему наименования. Так, например, ничто не мешает иметь запись:
uid=iip@iisk.ru,dc=iisk,dc=ru
для того же Ивана Петровича. Важно только, что часть dc=iisk,dc=ru остается постоянной.
LDAP в отличие от DNS и NIS имеет объектную направленность, означающую, что каждая запись имеет информацию о собственном типе и, следовательно, о той информации, которая содержится в этой записи. Для каждого типа определена информация, которую этот тип обязан содержать и которую он может содержать при необходимости. Пусть наш пример именует запись с типом «пользователь». Тогда он обязан содержать поле uid (идентификатор пользователя) и может содержать такие поля, как пароль, адрес электронной почты. Другой пример: запись с типом «компьютер» должна содержать имя компьютера и может содержать его IP-номер. Кроме того, в стиле объектного программирования у каждого типа могут появляться производные типы. В этом случае новый тип имеет все свойства родительского типа и добавляет некоторые свои. Так, он должен иметь все обязательные записи родительского типа и может добавлять собственные.
Система типов зафиксирована не очень строго. Каждый сервер может иметь собственную систему типов, которые должен понимать и клиент. Сейчас существует некоторое количество стандартных типов, которые должен поддерживать любой сервер, а системный администратор может по необходимости вводить новые. Конечно, при введении новых типов нужно обеспечивать соответствующих клиентов информацией об этих типах.
В итоге, несмотря на упрощения, LDAP остается достаточно громоздим сервисом. Но эта громоздкость видна системному администратору и скрыта от пользователя. Так, если системный администратор настраивает клиентские программы, чтобы они получали информацию из LDAP о паролях пользователей, то именно системный администратор сообщает всю необходимую информацию, а пользователю достаточно ввести только свое имя.
Очень важной особенностью LDAP являются его возможности разграничивать доступ между пользователями. Протокол LDAP позволяет потребовать от пользователя идентифицировать и аутентифицировать себя, прежде чем он получит какую-либо информацию. Причем доступная информация определяется по личности пользователя. Конечно, поддерживаются и анонимные запросы с возможностью ограничения доступа. Но выдать определенному пользователю только разрешенную информацию — это еще не все. Необходимо защитить от перехвата информацию, передаваемую по сети. В современной сети одним из способов улучшения безопасности является использование криптографических методов. Для реализации такой защиты большинство серверов и клиентов LDAP поддерживают возможность использования стандарта SSL — протокола использования криптографических средств на уровне соединения, что повышает привлекательность их использования в системах, где безопасность достаточно важна.
Сейчас появляется все больше продуктов, использующих LDAP-сервис. В частности, великолепная поддержка LDAP на уровне клиента встроена в Solaris, Linux и FreeBSD. Эти системы могут запрашивать у сервера LDAP такую информацию, как IP-номера компьютеров, имена и пароли пользователей. Современные почтовые программы — sendmail, postfix и некоторые другие — позволяют настроить получение информации о месте расположения почтовых ящиков пользователей. Вместе с серверами Novell NDS и Netscape Directory Service поставляется специальное программное обеспечение, позволяющее синхронизовать информацию, хранящуюся в доменном контроллере на NT-сервере, и информацию, поставляемую LDAP-сервером. Novell NDS, кроме того, позволяет разделять информацию, предоставляемую в LDAP, и информацию, предоставляемую клиенту и серверу Novell. Такая универсальность позволяет легко строить большие корпоративные сети, в которых поддержка гетерогенной среды является существенным требованием. Действительно, единый источник информации позволяет избежать многих неудобств и ошибок, возникающих в случаях, когда каждая система администрируется отдельно.
Разработан стандарт на доступ к LDAP-серверу как к ресурсу WWW — стандарт на формат URL. Некоторые браузеры, например современные версии Netscape, уже умеют осуществлять доступ по такому URL. Допустим, компания с доменным именем somecompany.com имеет LDAP-сервер с адресом ldap.somecompany.com. Тогда получить информацию о пользователе с uid=someuser можно по URL: ldap://ldap.somecompany.com/uid=someuser, dc=somecompany, dc=com. Информация, которую может предоставлять сервер, зависит от того, как системный администратор настроил типы данных и права доступа к разным полям. Таким образом, LDAP-сервер может стать дополнительным информационным ресурсом компании, поскольку его обновление существенно проще, чем обновление Web-страниц.
В связи с популярностью программ, использующих LDAP-сервис, становятся все более популярны и программные продукты, поставляющие этот сервис. Для UNIX существует свободно распространяемый продукт OpenLDAP — полный LDAP-сервер. Данный продукт может работать почти на любом UNIX. С ним поставляется набор небольших программ, облегчающих миграцию информации о хостах, пользователях и прочей полезной информации из простых файлов в LDAP-сервер. К сожалению, он не поддерживает ни NT-сервер, ни Novell-сервер. Поэтому OpenLDAP удобно применять только в сети Unix-компьютеров.
Другим продуктом, позволяющим создать LDAP-сервер в организации, является Netscape Directory Service. Этот продукт поставляется в варианте для многих UNIX и для NT-сервера. К тому же в состав продукта входят как утилиты для миграции информации из UNIX-систем, так и программы, позволяющие синхронизировать информацию, хранящуюся в контроллере домена NT-сервера и LDAP-сервера. Изменения информации, произведенные средствами NT, становятся доступными пользователям LDAP; изменения, произведенные средствами LDAP, становятся видны NT-серверу. Netscape Directory Service поддерживает широкий набор средств для обеспечения безопасности, в том числе и использование SSL — протокола обеспечения аутентификации и шифрования соединений. Таким образом, Netscape Directory Service является хорошим выбором в гетерогенной среде. Однако этот сервис не поддерживает Novell- продукты.
Novell NDS работает на следующих системах: NetWare, Solaris, Windows NT. Объявлено также о выпуске версии этого продукта для Linux. Novell NDS — это даже несколько больше, чем просто LDAP-сервер. NDS является достаточно полной системой, позволяющей интегрировать ресурсы UNIX-, Novell- и NT-серверов. Она включает дополнительное программное обеспечение, служащее для интеграции сервиса на контроллере домена в NT, программное обеспечение, устанавливаемое на Solaris и добавляющее улучшенные функции аутентификации пользователя в сети. На UNIX она может сосуществовать с NIS/DNS-стандартным расположением информации в файлах. Все это делает Novell NDS чрезвычайно привлекательным продуктом, особенно для гетерогенных сетей. Но это уже тема для отдельного разговора.
Наблюдая за развитием сервиса каталогов, можно сделать вывод о том, что его роль постоянно возрастает. Очевидно, это связано с усложнением сетей даже в небольших организациях, с развитием и усложнением Internet. Кроме рассмотренных сервисов, которые являются сейчас наиболее популярными, существуют и другие системы. Какие из них станут популярными, а какие вскоре забудутся — сейчас сказать сложно. В настоящее время популярность LDAP растет, но даже создатели LDAP не считают, что он может заменить DNS. Кроме того, DNS также не стоит на месте, у него появляются все новые возможности. Видимо, на ближайшее время эти две системы останутся наиболее популярными и будут существовать параллельно, дополняя друг друга.
КомпьютерПресс 7'2000
