Сравнение служб каталогов NDS и Active Directory выявило большие отличия между этими технологиями.

Где начинаются мелочи, там начинаются разногласия.
Поговорка

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

Архитектуру сетевой ОС можно классифицировать в соответствии с логическим или физическим компонентом, вокруг которого группируются сетевые ресурсы. Это может быть сервер сети (NetWare 3.x, UNIX), домен (Windows NT, UNIX при использовании NIS), вся сеть как совокупность взаимосвязанных компонентов (службы каталогов NDS и Active Directory).

В сетях, где ресурсы группируются на уровне серверов, каждый из них имеет собственную базу пользователей и групп, причем сами серверы никак логически не связаны друг с другом. Администратору приходится на каждом сервере создавать бюджеты пользователей и групп пользователей, назначать пароли, управлять правами доступа к файлам и т. д. Особенно это неудобно в случае UNIX, где администратор вынужден следить, чтобы у пользователей и групп не менялись идентификационные номера UID и GID при переходе от одного сервера к другому.

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

В настоящее время такой подход применяется лишь в небольших сетях с малым количеством серверов.

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

В данной статье речь пойдет о службах каталогов NDS от Novell и Active Directory от Microsoft, а также об их преимуществах по сравнению со службой доменов Windows NT. Особое место уделяется сравнительному анализу этих служб каталогов. Правда, такая постановка вопроса может показаться несколько преждевременной, так как Microsoft Active Directory появится лишь в 2000 году в составе Windows 2000. Тем не менее нам было любопытно посмотреть на основные особенности Active Directory, тем более что ее работающая версия уже имеется в составе второй бета-версии Windows NT 5.0. Кроме того, Microsoft предлагает обширную документацию по Active Directory.

Хотя кроме Novell и Microsoft еще ряд компаний выпускают службы каталогов в составе сетевых ОС, в частности Banyan StreetTalk, Sun NIS+ и IBM DSS, их продукты по разным причинам не оказывают сколько-нибудь заметного влияния на компьютерную индустрию и поэтому не будут рассматриваться.

Active Directory ведет свое происхождение от службы доменов Windows NT, поэтому вначале мы кратко рассмотрим возможности и ограничения доменов NT. (Другой известной службой доменов является сетевая информационная служба NIS компании Sun Microsystems. NIS нашла применение в сетях UNIX, хотя она имеет невысокую безопасность и не поддерживает доверительные отношения между доменами - см. врезку "NIS и NIS+".)

Служба доменов Microsoft впервые появилась еще в 1987 году в составе LAN Manager, где она работала на базе OS/2 1.x. С тех пор система доменов претерпела минимальные изменения: основное отличие службы доменов NT по сравнению с LAN Manager состоит в наличии доверительных отношений.

Доменная архитектура (домены NT не следует путать с доменами Internet) предполагает, что серверы, компьютеры, пользователи, принтеры объединяются в логические группы, так называемые домены. Такие домены на предприятии создаются чаще всего по организационному принципу: отдел кадров имеет свой домен, бухгалтерия - свой, и т. д. Внутри домена управление пользователями, глобальными группами пользователей, компьютерами NT и принтерами осуществляется централизованно. Кроме того, на компьютерах NT домена администратор может определить локальных пользователей и локальные группы пользователей данного конкретного компьютера или группы серверов.

Информация об общих сетевых объектах домена хранится на контроллерах домена. Главный контроллер домена (Primary Domain Controller, PDC) является основным хранилищем, работающим в режиме чтения и записи информации. Один домен может иметь только один PDC. Как следствие, домены NT плохо подходят для распределенных сетей.

Резервные контроллеры домена (Backup Domain Controller, BDC) также хранят информацию об общих сетевых объектах, но функционируют исключительно в режиме чтения. Назначение BDC состоит, в первую очередь, в повышении отказоустойчивости, а также в снижении нагрузки на PDC. Один домен может иметь любое число BDC. База данных по домену хранится в защищенной области системного реестра контроллеров домена.

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

Один и тот же сервер NT не может выступать в качестве контроллера для нескольких доменов. Более того, если сервер NT не был назначен при инсталляции ОС в качестве контроллера домена, то для того, чтобы он стал PDC или BDC, операционную систему придется переустановить целиком.

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

Домены NT могут поддерживать между собой доверительные отношения (trust relationships), благодаря которым ресурсы (файлы, принтеры и т. д.) одного домена становятся доступны пользователям другого домена. Однако домены NT не поддерживают транзитивных (переходных) доверительных отношений. Т. е. если домен A доверяет домену B, а домен B - домену C, то это не значит, что домен A доверяет домену C. Это приводит к резкому росту числа доверительных отношений при увеличении количества доменов. Например, при 10 доменах количество доверительных отношений может достигать 90, а при 100 доменах - 9900. Задание таких отношений превращается в серьезную проблему для администраторов NT.

В доменах NT ресурсы располагаются в единственном, притом плоском, пространстве имен (name space), поэтому все имена должны быть уникальны. Как следствие, пользователи нередко имеют такие причудливые имена, как J034 или RMGTH, что, естественно, удобства в работе не добавляет.

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

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

Доменная система NT является нерасширяемой и предусматривает всего пять типов объектов: пользователи, локальные и глобальные группы, принтеры и компьютеры. Такой набор был достаточен в 1987 году, но сейчас этого слишком мало. Широкое распространение технологий электронной почты, факс-сервиса, СУБД, межсетевых экранов и многих других настоятельно требует создания новых типов объектов и расширения возможностей имеющихся. Поэтому очень немногие приложения (даже от Microsoft) базируются на доменной системе NT.

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

Для организации ресурсов корпоративных и распределенных сетей лучше всего подходит служба каталогов. Служба каталогов представляет собой распределенную тиражируемую базу данных, где хранится логическое описание сетевых ресурсов. Сетевые ресурсы организуются в иерархическую структуру, называемую деревом (в сети может быть несколько деревьев). Пользователи, группы пользователей, принтеры, компьютеры и другие представляют собой конечные объекты (листья) дерева. Они содержатся внутри контейнеров, в качестве которых могут выступать объекты "организация", "подразделение" и т. д. (см. Рисунок 1). В современных службах каталогов количество вложений контейнеров не ограничено. С каждым объектом связаны его атрибуты (в NDS они называются свойствами), где хранится информация об объекте. Например, для объекта "пользователь" атрибутами являются фамилия, телефон, адрес электронной почты, список контроля доступа и т. п.

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

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

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

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

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

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

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

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

Служба каталогов Active Directory (AD) должна появиться в операционной системе Windows 2000. Ради сохранения совместимости с доменами NT компания Microsoft была вынуждена в качестве основной функциональной единицы службы каталогов оставить домен, привязав его к доменной службе Internet (DNS) (см. Рисунок 2). Иными словами, каждый домен Active Directory является теперь доменом DNS. Внутри домена AD поддерживается иерархическое пространство имен, где контейнерами выступают объекты типа "подразделение" (Organizational Unit, OU). Домены образуют еще одну иерархическую структуру, называемую деревом (см. Рисунок 3). Между доменами установлены доверительные отношения, которые в отличие от Windows NT 4.0 являются транзитивными.

Хотя AD имеют иерархическую структуру внутри домена, все имена домена должны быть уникальными.

В организации может быть несколько деревьев, объединенных общим понятием леса. Например, компания ACME географически состоит из двух предприятий, одно из которых расположено в Великобритании (acme.co.uk), а второе - в России (acme.ru). Поскольку филиалы не образуют единого пространства имен DNS, то создаются два дерева AD (см. Рисунок 4). Все деревья леса доменов имеют общую схему (schema), конфигурацию и общий Глобальный Каталог. Глобальный Каталог является средством индексации и поиска объектов и их атрибутов в AD.

Тиражирование баз данных AD осуществляется в пределах отдельного домена. Каждый контроллер домена работает в режиме чтения и записи, таким образом ограничение старых доменов NT снимается. Вместе с тем, как и ранее, сервер Windows 2000 может выступать в качестве контроллера лишь для одного домена, причем он должен входить в состав этого домена. Количество контроллеров не ограничено.

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

Принципалами безопасности AD являются пользователи и группы пользователей.

В основе службы каталогов AD лежат два стандарта Internet: динамический DNS и LDAP. При этом DNS служит не только для управления доменами и компьютерами, но и для оповещения и обнаружения служб в сети. В соответствии с документом RFC 2052 сервер DNS для обозначения служб использует запись вида:

<service>.<protocol>.<domain>

Например, сервис LDAP в домене acme.com будет обозначаться как ldap.tcp.acme.com.

Использование DNS в таком качестве имеет ряд особенностей, которые мы постараемся раскрыть при сравнении служб каталогов. В AD отпадает необходимость в сервисе WINS.

Среди компаний, поддержавших Active Directory, самой заметной является Cisco Systems. Вместе с тем многие занимают выжидательную позицию, поскольку служба еще не обкатана. Перспективы использования AD на других платформах, кроме Windows 2000, также не ясны. Во всяком случае сама Microsoft не намерена заниматься переносом AD на платформы UNIX, NetWare, MVS и т. д.

Служба каталогов Novell появилась в 1993 году в составе NetWare 4.0. По сравнению с базой BINDERY в составе NetWare 3.x это был колоссальный шаг вперед. К сожалению, новые возможности оказались очень непросты в освоении. К тому же первые версии NDS работали очень неустойчиво и с большими ограничениями. Лишь с выходом NetWare 4.10 в 1995 году NDS вышла на тот качественный уровень, на котором она могла удовлетворить требованиям корпоративных заказчиков. Сейчас без преувеличения можно сказать, что NDS представляет собой тот козырь, благодаря которому Novell удается выжить в тяжелой конкурентной борьбе с Microsoft.

Основой службы каталогов Novell является дерево NDS, построенное по иерархическому принципу (см. Рисунок 5). В качестве контейнеров могут использоваться следующие объекты: страна (Country, C), местонахождение (Location, L), организация (Organization, O), подразделение (Organizational Unit, OU), лицензированный продукт (Licensed Product, LP). В пределах одного контейнера все имена должны быть уникальными.

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

Принципалами безопасности NDS являются следующие объекты: "пользователь", "группа пользователей", "компьютер", "подразделение" и некоторые другие.

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

Так как NDS разрабатывалась в начале 90-х годов, Novell пришлось ориентироваться на собственные протоколы. Правда, со временем в NDS была добавлена поддержка LDAP, DNS, DHCP и других, но они не являются необходимыми для работы.

Индексация и поиск объектов в сети и их атрибутов могут производиться как посредством встроенных в NDS средств поиска, так и с помощью продукта Catalog Services. Эти средства мы рассмотрим подробнее при сравнении служб каталогов.

С момента появления NDS не только Novell, но и ряд других компаний выпустили приложения, ориентированные на использование NDS. Так, компания Oracle даже подписала с Novell контракт на 25 лет, предусматривающий поддержку NDS в ее продуктах.

Novell перенесла NDS на ряд популярных платформ: кроме NetWare служба каталогов NDS уже работает на Windows NT, SCO UnixWare, Caldera OpenLinux, Sun Solaris, IBM AIX, HP/UX, IBM OS/2. Этот список постоянно расширяется. В настоящее время NDS переносится на мэйнфреймы IBM S/390.

Для сравнения Active Directory и NDS в дополнение к уже имевшейся в сети издательства "Открытые системы" службе каталогов NDS мы поставили и испробовали вторую бета-версию Windows NT Server 5.0, в состав которой входит AD. Но чтобы сравнения были более корректными, мы обратились и к документации производителей. Наиболее интересными оказались документы Novell и Microsoft, где сравниваются NDS и AD. К сожалению, подобным документам часто не хватает объективности. Обе компании стараются выпячивать чужие недостатки, забывая о своих собственных. Особенно этим грешит Microsoft, сравнивая свою, еще не вышедшую, AD с устаревшими версиями NDS.

Многие недостатки той или иной службы каталогов являются продолжением их достоинств. Так, ради совместимости со службой доменов NT Microsoft пошла на большие ограничения в Active Directory. Со своей стороны Novell при переходе от BINDERY к NDS провела столь кардинальные изменения, что на первых порах NDS неоднократно критиковали за плохую совместимость со старыми версиями NetWare 3.x. Тем не менее подход Novell оказался достаточно удачным, так как в начале 90-х годов никто не мог покуситься на лидирующее положение Novell на сетевом рынке. Теперь же NDS имеет значительную фору перед другими службами каталогов, и зачастую она рассматривается как отраслевой стандарт.

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

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

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

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

Неприятная особенность системы тиражирования AD состоит в том, что если после изменений в объекте какой-нибудь пользователь вносит другие изменения до синхронизации реплик (синхронизация осуществляется раз в 15 минут), то в итоге будут сохранены только последние по времени изменения. А ведь изменения могут относиться к совершенно разным, не связанным друг с другом атрибутам объекта. В NDS такого не происходит.

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

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

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

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

Сильной стороной службы каталогов AD является встроенная поддержка протокола LDAP, уже успевшего стать стандартом в Internet. Хотя NDS и поддерживает LDAP v.3, но там это сделано с помощью дополнительного продукта LDAP Services for NDS. В результате использующие протокол LDAP приложения вынуждены общаться с NDS через специальный шлюз для преобразования запросов LDAP в запросы NDS. Это создает определенные трудности, поскольку LDAP и NDS имеют разный синтаксис имен объектов, а права доступа LDAP не переносятся однозначно на права доступа NDS. Кроме того, для поддержки LDAP соответствующую службу приходится устанавливать на каждый сервер NDS.

Хотя Microsoft считает ориентацию AD на доменную службу DNS исключительно важным преимуществом своей службы каталогов, это можно трактовать и как слабость, так как использование AD предусматривает использование динамического DNS и DHCP. В принципе это доставляет неудобства только при миграции от доменов NT к Active Directory (см. следующий раздел).

Гораздо неприятнее, что для оповещения и обнаружения служб AD использует записи DNS о ресурсах сервисов (RFC 2052). Однако DNS плохо подходит для такого рода услуг, поскольку не может динамически отслеживать статус служб, в частности DNS не позволяет проверить факт функционирования того или иного сервиса. Представьте следующую ситуацию: сервер N поддерживает службу LDAP, поэтому во время инсталляции сервера N в базе DNS создается запись для службы LDAP. Если сервер N остановлен или стал недоступен, запись DNS не обновляется. Поэтому любой запросивший сервис LDAP клиент домена "увидит" сервер N, но, попытавшись обратиться к N, клиент не получит ответа. Как следствие, это приведет к заметным задержкам при работе в сети.

При удалении сервера из домена AD запись о нем все равно останется в DNS, так что базу DNS придется исправлять вручную, а разбираться в записях DNS, работающей в динамическом режиме, - занятие малоприятное. Главный же недостаток состоит в том, что управление DNS никак не связано с управлением другими службами AD. Если Microsoft так привержена стандартам Internet, то ей стоило бы обратить внимание на протокол SLP, отвечающий за оповещение и обнаружение служб в сетях TCP/IP (RFC 2165). Кстати, работа NetWare 5 в сетях TCP/IP основана именно на этом стандарте.

Надо сказать, что по удобству управления AD значительно уступает NDS. В NDS имеется NetWare Administrator (см. Рисунок 7) - консоль управления всеми ресурсами и объектами сети (конечно, при наличии соответствующих прав). В AD для этих целей используется более 12 утилит, причем каждая отвечает за свою часть работы. В NDS имеются средства объединения деревьев в одно дерево, в то время как в AD подобные утилиты отсутствуют. Поэтому при объединении сетей предприятий (например, при поглощении одной компании другой) администраторы неизбежно столкнутся с проблемами интеграции.

В настоящее время список поддерживаемых AD клиентских платформ ограничен лишь Windows 2000 и Windows 95/98. Даже старые версии Windows, включая Windows NT 4.0 (которую никак не назовешь устаревшей), не будут полностью совместимы с Active Directory. В то же время NDS поддерживают DOS, Windows 3.x, Windows 95/98, Windows NT 3.51/4.0, Windows 2000, IBM OS/2, Apple MacOS, Caldera OpenLinux, SCO UnixWare и др.

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

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

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

Как это ни покажется странным, но Novell имеет гораздо более удобные средства перехода от доменов NT к NDS, чем Microsoft может предложить при переходе к Active Directory. То же относится и к интеграции: интегрировать NT и NDS гораздо проще, чем NT и AD.

Novell для перехода и интеграции предлагает замечательный продукт NDS for NT, о котором наш журнал уже неоднократно сообщал (см. "Управление смешанной сетью NetWare и Windows NT" в апрельском номере LAN за 1998 г. и "Интеграция сетей NetWare и Windows NT" в майском номере LAN за 1998 г.). Мы не будем повторяться, отметим только, что с тех пор Novell выпустила новую, вторую версию NDS for NT, позволяющую использовать NDS в сетях Windows NT без участия NetWare. Более того, Novell готовит еще одну версию этого продукта, с помощью которой серверы Windows NT смогут выступать не только в качестве серверов NDS, но и серверов NetWare 4.х, аналогично тому, как NDS работает под UNIX. NDS for NT быстро завоевала признание в крупных сетях, где администраторы уже намучились со службой доменов NT.

Гораздо интереснее посмотреть, что предлагает компания Microsoft. Она не планирует выпуск Active Directory для Windows NT 3.51 и 4.0, т. е. если организация захочет перейти на AD, то ей предстоит модернизировать версии NT до Windows 2000. Это относится как к NT Workstation, так и к NT Server. Очевидно, что такой подход потребует значительных затрат. Тем не менее Windows 2000 и NT смогут сосуществовать друг с другом в смешанной сети, но здесь управление только усложнится, поскольку администрировать придется как службу доменов, так и службу каталогов.

При миграции от доменов NT к службе каталогов AD пользователи могут столкнуться с рядом проблем. Имеющиеся домены NT чаще всего построены по организационному принципу (отдел маркетинга, отдел продаж, отдел кадров), так что преобразовать их в иерархическую структуру - задача отнюдь не тривиальная, тем более что у Microsoft нет средств переноса ресурсов и объектов из одного домена в другой с сохранением прав доступа.

Трудности может создать и доменная служба DNS: при миграции домены NT трансформируются в домены AD. При этом, однако, имена доменов NT должны удовлетворять требованиям DNS. Если в имени доменов содержатcя символы _ (подстрочная черта) или . (точка), то перед миграцией домены придется переименовать. А это может привести к тяжелым последствиям, поскольку нарушатся связи между объектами домена и доверительные отношения между доменами.

Кроме того, практически все предприятия уже имеют DNS, и чаще всего для сервиса DNS используется UNIX. При переходе на AD администратору придется менять структуру DNS всего предприятия, чтобы она отражала структуру дерева или леса Active Directory. Для AD обязательным требованием является поддержка серверами DNS стандарта RFC 2052, а также рекомендуется поддержка динамического режима (RFC 2136). Таких серверов DNS сейчас используется очень мало, в частности даже DNS в составе платформы Windows NT 4.0 Server не обеспечивает такой режим. Поэтому предприятию, скорее всего, придется менять весь сервис DNS.

Продукт NDS for NT компании Novell не предъявляет ни одного из перечисленных требований и не налагает никаких других дополнительных ограничений.

Не следует думать, что автор имел предубеждение против Active Directory компании Microsoft. Поверив громким обещаниям Microsoft в отношении AD, я ожидал увидеть нечто великое и грандиозное. Однако в реальности все оказалось гораздо скромнее. Ради сохранения совместимости со старой службой доменов Microsoft пошла на слишком большие ограничения в функциональности AD.

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

Константин Пьянзин - обозреватель LAN. С ним можно связаться по адресу: koka@lanmag.ru.

Сетевая информационная служба (Network Information Service, NIS) компании Sun является по сути службой доменов, напоминающей LAN Manager. NIS поддерживается практически всеми производителями UNIX, поэтому она весьма популярна в сетях UNIX. В соответствии с NIS компьютеры объединяются в домены, причем в пределах одного домена системные файлы /etc/passwd, /etc/group, /etc/hosts, /etc/networks, /etc/services, /etc/protocols, /etc/aliases и ряд других становятся общими. В домене определены глобальные пользователи, группы пользователей, хосты, сетевые службы и т. д. Кроме того, на компьютерах поддерживаются локальные пользователи, группы и сетевые службы. Как и в других системах, домены NIS не имеют никакого отношения к доменам DNS.

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

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

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

Доверительные отношения между доменами NIS установить нельзя - каждый домен является полностью независимым. Это обстоятельство ограничивает сферу применения NIS.

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

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

К сожалению, служба NIS+ не нашла широкого применения в сетях UNIX - кроме Sun, ее почти никто не поставляет. Это связано с тем, что крупные сети UNIX встречаются нечасто, к тому же NIS+ не имеет выхода на настольные системы.