Все новости от 26 октября 1998 г.

Глобальные службы каталогов для NT

Введение

К сожалению, самые ценные ресурсы в сети Windows NT - учетные записи пользователей и информационных систем - содержатся в отдельных каталогах и не подозревают о наличии друг друга. В сетях крупных предприятий сотни каталогов, и подобный пробел в системе управления просто обескураживает. "Это не только лишняя работа и дополнительные расходы, но еще и угроза безопасности, - сетует президент аналитической фирмы Burton Group Джеми Льюис (Jamie Lewis). - Из-за несинхронизированных каталогов пользователи теряют доступ к приложениям и то и дело звонят в техническую службу. А в тех случаях, когда давно уволившиеся сотрудники все еще значатся в некоторых каталогах, страдает безопасность".

Каждый раз, когда устанавливается новое приложение или приходит новый сотрудник, администраторам приходится заводить учетные записи в многочисленных каталогах, приписывая новым объектам требуемые ресурсы в интрасети, подсистемах электронной почты, средствах удаленного доступа и т. п. Если же работник увольняется из компании, администратор непременно должен исключить его из всех систем. По данным Forrester Research, сеть крупной корпорации из списка Fortune 1000 насчитывает в среднем свыше 180 отдельных каталогов.

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

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

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

Microsoft и Novell решают эту проблему, разрабатывая сетевые службы каталогов для NT: Microsoft - компонент будущей ОС NT 5.0 Active Directory (AD), а Novell - специальную версию Novell Directory Services (NDS). Хотя каждый из продуктов значительно лучше доменной системы NT 4.0, без изъянов все же не обошлось.

(Третий игрок на этом рынке, компания Netscape выпустила продукт Directory Server. По сравнению с AD и NDS ему недостает ряда тонких механизмов, таких, как репликация с несколькими ведущими серверами [multimaster], поэтому он позиционируeтся преимущественно для Интернета и интрасетей. См. раздел "Стратегия Netscape в области каталогов".)

С помощью Active Directory компания Misrosoft намерена превратить каждую сеть NT из скопления отдельных доменов в связную систему, управляемую на уровне предприятия. Однако первую реализацию Active Directory, включенную в бета-версию NT 5.0, нельзя назвать совершенной: в ней отсутствуют, например, такие важные компоненты, как репликация нескольких серверов. Но и Novell, обладая десятилетним опытом в этой области, выпустила не безупречный продукт. Средства управления текущей версии (1.1) NDS for NT оставляют желать лучшего: ее богатыми функциональными возможностями пользоваться в реальной работе совсем не легко. В NDS не представлен ряд важных технологий, таких, как поддержка инфраструктуры с открытым ключом защиты (public key infrastructure, PKI).

Каждая из компаний вынашивает честолюбивые замыслы в отношении своей службы каталогов, однако суждено ли им осуществиться - большой вопрос. Пока Active Directory существует лишь в бета-версии, а NDS for NT постоянно дорабатывается. Настоящий обзор и посвящен разбору достоинств и недостатков каждого продукта и должен помочь в выработке долгосрочной стратегии.

Средства управления

Изначальная доменная структура NT сохранилась и в AD, который представляет собой группу взаимосвязанных доменов. Домены делятся на самостоятельные организационные единицы (organizational units, OU). Теперь пользователей можно наделять администраторскими правами в пределах подмножества того или иного домена. В ранних версиях NT (включая 4.0) на выделение администраторских полномочий налагалось строгое ограничение: по отношению к доменам действовал принцип "все или ничего".

Наряду с организационными единицами, вводится иерархический принцип именования объектов в доменах NT, что позволяет назначать имена по схемам, отражающим реальную структуру организации, например, johnd.sales.ny.bigcorp (схема <объект>...<домен>) вместо одиночного имени johnd. Отчасти это облегчает управление, но, разумеется, не решает всех проблем.

Например, чтобы организовать доступ некоторого OU к внешнему ресурсу, такому, как сервер филиала, необходимо подключить к этому ресурсу еще и все группы пользователей, имеющиеся в OU. Сами OU средствами защиты не распоряжаются, так что в этом плане AD ничем не отличается от предшествующей системы доменов. В иерархических деревьях NDS, напротив, явно прописаны права по управлению системой защиты, которыми могут обладать не только администраторы, но и "начальники" (principals) - произвольные объекты NDS с приложенными схемами защиты.

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

Масштабируемость

Как Microsoft, так и Novell признают, что масштабируемость в их решениях для NT оставляет желать лучшего. В этом они недалеко ушли от доменов NT 4.0, управление которыми реализовано по жесткой схеме. Все данные, связанные с аутентификацией, сервер домена NT 4.0 помещает в системный реестр. Такое решение выпадает из общей идеи и налагает много ограничений, особенно для старых доменов NT. Прежде всего, это недостаточная возможность развития. Традиционные домены "понимают" объекты всего пяти типов: пользователи, локальные группы, глобальные группы, принтеры и компьютеры. Хотя для многих сетей этого набора вполне достаточно, расширению он не поддается. Администратор не может добавить к профилю пользователя, скажем, адрес его электронной почты. Сей факт объясняет, почему такие приложения, как Microsoft Exchange (своя же разработка!), вынуждены пользоваться отдельным каталогом, не имеющим отношения к стандартному каталогу домена.

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

Проблема расширения схемы объектов может решаться по-разному. Microsoft предлагает переместить ее из реестра в специальную базу данных JET, механизм которой сходен с Access или Exchange. По утверждению компании, в каждом домене такая БД сможет обрабатывать до миллиона объектов. Это огромный скачок по сравнению с нынешними возможностями реестра.

Еще важнее тот факт, что каждая схема становится объектом базы данных, и ее можно настраивать как угодно. Например, корпоративным отделам ИТ нередко приходится внедрять новое приложение без достаточной подготовки пользователей. Имея службу AD, можно запросить в каталоге список ПК на процессоре 486, установленных в определенном месте. Тем самым легко выявляются устаревшие компьютеры, требующие модернизации для работы с новым приложением. Полученный список можно затем переслать в отдел снабжения, который закажет необходимые детали и отправит список технической службе. В приведенном примере незначительные изменения в схеме упростили работу трех различных подразделений компании, не говоря уже о сбережении сил пользователей: никому не пожелаешь начинать работу с новым приложением на непригодной для него машине.

В NDS вся информация о разделах каталога хранится в Directory Information Base (DIB). В отличие от базы JET в Active Directory, DIB строится на иерархической файловой системе, по своей структуре напоминающей каталог X.500. По функциональным возможностям разделы близки к доменам AD, однако в части расширяемости уступают им. Так, Novell не рекомендует включать в один раздел более 5000 объектов, а также задействовать в нем глобальные каналы связи. Особенно неприятно последнее ограничение, оно вынуждает администратора заводить для работы с разделами множество серверов, а затем добавлять к ним еще и резервные серверы. К тому же, для каждого офиса компании придется создавать свой раздел, чтобы не затрагивать глобальные коммуникации, а это усложняет структуру всей сети.

Репликация

Для решения задач многосерверного управления в обоих каталогах реализованы сложные схемы репликации и синхронизации с целью преодоления недостатков схемы простой подчиненности NT 4.0, при которой роль главного сервера играет первичный контроллер домена (PDC), обновляющий подчиненные серверы - резервные контроллеры (BDC). Эта схема весьма несовершенна, поскольку все обновления должны происходить в одном и том же месте (PDC) и распространяются по остальной сети через BDC. В каждом из новых продуктов предпринята попытка отойти от сценария "главный-подчиненный" и реализовать репликацию по схеме "главный-главный", однако к истинному "равноправию" серверов ближе подошел AD.

Почему? Дело в том, что в схеме репликации Novell используются копии трех типов: главные, открытые на чтение и запись и открытые только на чтение. Первый образец какого-либо раздела обычно определяется как главный, а последующим (дублирующим) разделам назначаются атрибуты либо "для чтения и записи", либо "только для чтения". Для внесения большинства изменений в равной степени подходят как главная копия, так и дубликат, открытый на чтение и запись, однако реально управлять разделом можно только с главной копии. Такое ограничение не позволяет считать NDS истинной системой с равноправными главными серверами: если сервер с главной копией выходит из строя, то до исправления ситуации работать с разделом нельзя.

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

Подход к репликации в каждой из служб каталогов различается еще одним тонким, но заслуживающим внимания аспектом. Речь идет о единице репликации как совокупности данных, подлежащих целостному копированию. В AD единственной такой единицей служит домен, причем каждый сервер может владеть только одним доменом. Вследствие этого, для каждого домена необходимо предусмотреть отдельный "запасной" сервер, играющий роль резервного контроллера этого домена (BDC). Поэтому в сети под AD, состоящей из 10 доменов, должно быть 20 серверов - по два на домен (один основной и один резервный). Такая расточительность в использовании BDC компенсируется емкостью: каждый домен в AD может содержать 10 млн объектов. NDS в этом случае потребуется только 12 серверов: 10 в качестве первичных контроллеров плюс два резервных сервера, каждый из которых вмещает все десять доменов и резервирует своего собрата. На производительности сети может сказаться ограничение NDS на размер домена (5000 объектов), однако заметное "торможение" наблюдается лишь в короткие периоды замены первичного сервера и потому вполне допустимо.

Все эти схемы репликации нуждаются в надежном методе синхронизации, способном охватить изменения объектов, происходящие на множестве серверов, разбросанных по всему миру. Две конкурирующие компании и здесь избрали различные подходы. Microsoft отдала предпочтение операциям с кодами Update Sequence Number (USN), которые представляют собой 64-разрядные целые числа, присваиваемые всякому вновь созданному объекту. При каждой модификации объекта его USN изменяется в сторону увеличения. В момент репликации серверы попарно сравнивают каждый объект и сохраняют тот его экземпляр, у которого USN больше.

В NDS применяется более простой прием - сравнение временных меток. Предполагается, что системное время во всей организации одно и то же, а записи подлежит объект с самой поздней среди всех копий временной меткой. Механизм синхронизации времени в NDS достаточно громоздок, но без сверки времени сетевых узлов NT 5.0 вообще не сможет работать (этого требует, например, промышленный стандарт Kerberos 5.0).

Где репликация, там и транспортная подсистема. Здесь Microsoft опять идет дальше, предлагая различные решения на выбор. В AD несколько средств транспортировки, включая протоколы SMTP и RPC (Remote Procedural Call), в то время как NDS всецело полагается на собственный метод. В AD один сервер может извещать другой о своих изменениях хоть по электронной почте. Эта особенность может показаться не такой уж важной, но на практике она устраняет многие проблемы, связанные с конфигурированием системы. Например, чтобы "научить" брандмауэр пропускать трафик репликации, не обязательно открывать на нем новые порты.

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

Доверительные отношения

По сравнению с NT 4.0 работа с доверительными отношениями в обеих службах каталогов стала намного эффективнее. Символ излишней сложности старой версии в этом плане - знакомая каждому администратору Windows NT проблема N(N-1). Если число доменов NT - N, то общее число доверительных отношений как раз выражается указанной формулой. Таким образом, 15 доменов порождают 15 х 14 = 210 отношений. Это объясняется тем, что в NT 4.0 доверительные отношения нетранзитивны. То есть, если домен B доверяет домену A, а домен C - домену B, то прямого доступа к A у C все равно не будет.

Доверительные отношения в AD, как и в NDS, полностью транзитивны и могут порождаться автоматически. Однако на этом сходство двух служб заканчивается: как и в других случаях, одни и те же функции реализуются в каталогах по-разному. Доверительные отношения тесно связаны с использованием реестров контроля доступа (ACL). Напомним, что они ведутся для каждого объекта и определяют, кто имеет доступ к объекту и что может с ним делать.

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

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

Открытые стандарты

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

Microsoft и Novell стараются придерживаться открытых стандартов. Так как продукты Novell основаны на более старых технологиях и стандартах, ей, вероятнее всего, придется догонять. Microsoft обладает преимуществом возможности применения в своих продуктах новейших технологий. AD использует стандарты IETF в ядре системы и включает Dynamic DNS (DDNS) для назначения имен и Kerberos 5.0 для целей аутентификации.

Однако применение протоколов DDNS ставит некоторые вопросы совместимости, так как это еще не официальный стандарт. Для них, по крайней мере, пока, потребуется развернуть на серверах NT службы AD DNS, которые могут нарушить существующую инфраструктуру DNS предприятия, по всей вероятности базирующуюся на системах Unix. Novell тоже намерена применить эти протоколы и отойти от своей специальной схемы. Следующая версия NDS будет поддерживать полную аутентификацию PKI как для внешней службы сертификации, так и для внутренней.

Это дополнение позволит NDS использовать либо свою традиционную схему аутентификации на базе GQ, либо более распространенные системы X.509. Microsoft также планирует полную поддержку PKI в AD и придерживается совместимости со спецификацией IPSec. С использованием механизма Kerberos AD сможет аутентифицировать разные клиентские системы, в том числе Unix.

В качестве главного протокола связи и AD, и NDS используют протокол Lightweight Directory Access Protocol (LDAP). Он обеспечивает взаимодействие между приложениями, предоставляя единую спецификацию для реализации доступа к любому каталогу. Но, несмотря на наличие такого средства добавления новых приложений, Novell упустила один компонент: поддержку формата LDAP Data Interchange Format (LDIF), позволяющего сохранять информацию о схеме каталога в простом текстовом файле. Без этого объекты схемы трудно импортировать и экспортировать. Следовательно экспортировать специальные объекты, такие, как унаследованные системы, в каталог другого поставщика будет не легко.

Стратегия Netscape в области каталогов

Один из наиболее важных аспектов службы каталогов - поддержка приложений. В этой области Novell несомненно отстает. За десятилетие существования NDS очень ограниченное число приложений доработано с учетом ее преимуществ. Кроме того, схема объектов NDS не является открытой, так что приложения должны подсоединяться на уровне рабочих мест. Novell признает, что Microsoft Active Directory Services Interface (ADSI) представляет собой намного более четкий и простой интерфейс со структурой каталога, чем скрытый LDAP API. Хотя AD еще не вышел, Microsoft уже добилась его широкой поддержки такими крупными поставщиками, как Cisco Systems. Кроме того, Microsoft обеспечит обратную совместимость для приложений, оставив неизменными API Security Accounts Manager (SAM).

Традиционные приложения, такие, как Internet Information Server, обращаются к информации домена, сохраняемой в системном реестре (Registry) посредством SAM. Те же приложения смогут обращаться к AD без всякой модификации, хотя и не смогут воспользоваться преимуществами новых функций AD - для этого их придется переписать. Поддержка каталога повлияет не только на приложения, но также и на нижележащую сетевую инфраструктуру. Будущие сети станут использовать каталог для определения параметров обслуживания с гарантированным качеством (QoS) и предложат такие средства, как аутентификация при дистанционном доступе.

Администрирование

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

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

Если служба каталога необходима сейчас, сомневаться не приходится - есть лишь один готовый вариант: NDS. Но срочно внедрять корпоративный каталог нужно лишь в случае крайней необходимости. Даже при самых хороших условиях на это уйдет не меньше полутора лет. За это время начнутся поставки NT 5.0, и будущее NDS окажется под вопросом. Если Microsoft сможет реализовать свою стратегию и выпустит AD вовремя, модернизация сетей NT 4.0 станет гораздо легче.

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

Microsoft несомненно поставила Novell в тупик, сделав Active Directory простым в эксплуатации при очень тесной интеграции с другими своими продуктами. Если на предприятии широко применяются такие приложения, как SQL Server и Exchange, то выбор AD очевиден. Однако ни одна из служб каталогов не представляет собой нечто превосходное во всех отношениях, и обе тяготеют к универсальной поддержке LDAP, что ведет к стиранию различий между ними.

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

Глоссарий

Организационная единица (Organizational unit). Группа объектов, определенных в пределах домена или раздела, отражающая иерархию предприятия. OU может использоваться для администрирования и назначения имен. Инфраструктура с открытым ключом (Public key infrastructure). Способ работы с секретными ключами шифрования, предусматривающий методы аутентификации посредством сертификатов и обмена ключами. Защищаемые объекты (Security principals). Объекты (например, компьютеры или принтеры), к которым применима схема защиты. Устройство администрирования (Unit of administration). Объект, который имеет доступ к другим объектам для модификации их схем защиты. Играет важную роль в установлении защитных ограничений, определяя, каким образом объекты группируются для администрирования. Единица репликации (Unit of replication). Объект, копируемый в процессе синхронизации каталога. Каталоги могут реплицировать домены, OU или разделы.

Коротко: NDS против Active Directory

По параметру…	Следует отдать предпочтение…	Потому что...
Доступность	NDS	NDS уже есть, хотя это и не совершенная служба каталогов. Срок начала поставок Active Directory пока неизвестен.
Поддержка разработчиками	Active Directory	Microsoft создала стандарт ADSI (принятый Novell) с целью исключения трудностей, характерных для API LDAP. Кроме того, в AD есть API, необходимые для разработки специальных схем реплицирования. В NDS их нет.
Совместимость	Active Directory	Active Directory предлагает поддержку виртуальных контейнеров, позволяющих присоединять к любой точке каталога внешние каталоги. NDS не взаимодействует с доменами прежних версий. Кроме того, компания Cisco объявила о приобретении лицензии на AD с целью его переноса на Unix.
Простота внедрения и эксплуатации	Active Directory	Microsoft продемонстрировала свою утилиту для модернизации, разработанную совместно с Computer Associates. Она позволяет автоматически обнаруживать и моделировать ресурсы NetWare в автономном режиме. Кроме того, в ней предприняты меры для сосуществования доменов старых версий с новыми Active Directories. Novell пока не продемонстрировала никаких инструментов модернизации и не предусмотрела возможности сосуществования старых доменов, доменов AD и NDS.
Репликация	Active Directory	Хотя оба поставщика поддерживают форму репликации с несколькими главными узлами, в схеме Novell требуется наличие единственной главной копии при всех модификациях раздела. Microsoft поддерживает "плавающий маркер", который может передаваться между копиями, так что, когда бы сервер не отказал, схемы все равно будут модифицированы.
Масштабируемость	Active Directory	Novell ограничивает число объектов раздела каталога и не рекомендует включать в него объекты глобальной сети. Microsoft не накладывает никаких ограничений.
Защита	Active Directory	Оба поставщика объявили о планах поддержки стандартов Kerberos и PKI, но Microsoft пошла на шаг дальше, поддержав еще и IPSec.