Студопедия  
Главная страница | Контакты | Случайная страница

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

Построение служб управления каталогами в сети Windows'NT. Понятие домeнной структуры и доверительных отношений, относительные преимущества

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

СЛУЖБА ДОМЕНОВ WINDOWS NT

Служба доменов 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

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

Служба каталогов 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 являются пользователи и группы пользователей.

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

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

NDS

Служба каталогов 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

Для сравнения 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, для чего ему требуется расширить схему службы каталогов и создать новые типы объектов. Без участия главного администратора всего дерева это сделать невозможно.

 


Дата добавления: 2015-01-30; просмотров: 39 | Нарушение авторских прав

1 | 2 | 3 | 4 | <== 5 ==> | 6 | 7 | 8 | 9 | 10 |


lektsii.net - Лекции.Нет - 2014-2020 год. (0.017 сек.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав