Системы имен, принятые в NetWare, Microsoft и Internet

- owner (владелец). Элемент owner обозначает доменное имя, которому принадлежит запись. Его значением всегда должен быть символ @, указывающий на то, что данный домен является зоной происхождения записи.

- class (класс). Значением элемента class всегда выступает in, т. к. серверы MS DNS знают только один класс адресов -- Internet (значением не может быть ни CHAOS, ни любое другое возможное, но редко применяемое значение).

- wins. Элемент wins идентифицирует WINS-запись.

- local (локальная сеть). Элемент local является необязательным. Если он присутствует, он сообщает DNS-серверу о том, что тому не следует задействовать эту запись ресурса при передаче данных другим DNS-серверам. Когда сервер сообщается с DNS-серверами, произведенными вне компании Microsoft, передача записи ресурса WINS может спровоцировать ошибки или сбой в передаче зон. Этот элемент можно не указывать, когда ваш сервер взаимодействует только с другими серверами MS DNS.

- L<значение>. Этот элемент выражает значение лимита времени на поиск и является необязательным. Руководствуясь значением по умолчанию, DNS-сервер считает WINS-сервер не отвечающим, если реакции от него не последовало в течение двух секунд.

- C<значение>. Элемент C<значение> определяет период хранения в кэше WINS и является необязательным. По умолчанию время хранения ответов в кэше WINS приравнивается к 15 минутам. Следует отметить, что ответы службы WINS не следуют обычной практике DNS, предполагающей установку минимального времени жизни (TTL) в записях начала полномочий (SOA) для зоны в качестве значений по умолчанию. Вместо этого они используют значение периода хранения в кэше службы WINS.

- wins__address (адрес WINS). Этот элемент содержит IP-адрес WINS-сервера. Когда для DNS-сервера настроено несколько WINS-серверов, их адреса перечисляются в порядке поиска слева направо, а в качестве разделителя выступает единичный пробел.

Серверы MS DNS в домене in-addr.arpa способны производить обратный поиск, возвращая имена, связанные с конкретным IP-адресом. Серверы MS DNS в корневой зоне при обратном поиске можно настроить на применение WINS-R для выполнения поиска ресурсов NetBIOS, связанных с конкретным IP-адресом. С помощью запроса состояния адаптера (Adapter Status Query) NetBIOS WINS-сервер находит имя (имена), связанное с данным IP-адресом, и возвращает эту информацию серверу MS DNS. Настройка WINS-R для серверов MS DNS в корневой зоне обратного поиска выполняется так же, как и конфигурация WINS для серверов в домене прямого поиска.

Серверы в домене обратного поиска хранят информацию, относящуюся к WINS-R, в записи ресурса следующей формы.

owner class wins-r [LOCAL] [L<value>] [C<value>] <добавляемый_домен>

Представление, значение и применение этих элементов аналогично предыдущему примеру, относящемуся к прямому WINS-разрешению, за исключением двух моментов.

Элемент wins-r идентифицирует версию службы WINS для обратного поиска; он должен выглядеть точно так же, как показано в примере.

Элемент <добавляемый_домен> содержит доменное имя, которое необходимо присоединять ко всем именам NetBIOS, найденным WINS-сервером, при их возврате DNS-серверу в ответ на его запросы.

Помимо всего прочего, функция обратного поиска MS DNS позволяет серверу MS DNS рассматривать хостовую часть имени как имя NetBIOS, а доменную часть -- как идентификатор области NetBIOS, и предоставлять его WINS-серверу для разрешения.

WINS-серверы аналогичны DNS-серверам, однако, предназначены для обслуживания пространства имен NetBIOS. Когда собственные DNS-сервера компании Microsoft настроены на запросы службы WINS для разрешения имен NetBIOS, они сочетают лучшие качества обоих систем. Как бы то ни было, необходимо помнить, что MS DNS может разрешать имена NetBIOS только в корневой зоне. Имена NetBIOS знают только одну сеть -- ту, в которой они находятся.

4 Служба каталогов Active Directory

Active Directory (AD) -- это объектно-ориентированная, иерархическая, распределенная система базы данных службы каталогов, которая обеспечивает централизованное хранение информации об оборудовании, программном обеспечении и человеческих ресурсах всей корпоративной сети. Она основана на стандарте Х.500 и во многом похожа на NetWare Directory Services (NDS). Пользователи сети представлены объектами в дереве Active Directory. Администраторы могут применять эти объекты для предоставления пользователям доступа к ресурсам в любом месте сети. Ресурсы так же, как и пользователи представлены в виде объектов в дереве. В отличие от Windows NT, которая использовала для своих каталогов плоскую, основанную на доменах, структуру, Active Directory расширяет структуру на несколько уровней. Домен все еще остается основным организационным элементом в базе данных Active Directory, но теперь группы доменов могут быть объединены в дерево, а группы деревьев в лес (forest). Администраторы, манипулируя деревом, могут управлять множеством доменов одновременно, а лес дает возможность одновременно управлять множеством деревьев.

Однако служба каталогов -- это не только база данных для хранения информации, она также включает сервисы, которые делают эту информацию доступной для пользователей, приложений и других служб. Active Directory включает глобальный каталог, который делает возможным поиск в каталоге определенного объекта, используя значение заданного атрибута. Приложения могут задействовать каталог для управления доступом к сетевым ресурсам, а другие службы каталогов способны взаимодействовать с AD через стандартизованный интерфейс и протокол LDAP (Lightweight Directory Access Protocol, облегченный протокол службы каталогов).

4.1 Архитектура Active Directory

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

Основное различие между Active Directory и доменами Windows NT 4.0 заключается в том, что Active Directory предоставляет администраторам и пользователям глобальный вид сети. Обе службы каталогов могут использовать множество доменов, но вместо управления пользователями любого домена по отдельности, например, как в Windows NT 4.0, администратор AD создает для каждого пользователя только один объект и может предоставить этому пользователю доступ к ресурсам в любом домене.

Каждый тип объекта описывается классом объекта, который хранится в схеме каталогов. Схема определяет атрибуты, которые должен иметь каждый объект, необязательные атрибуты, которые он может иметь, и место объекта в дереве каталогов. Сама схема также хранится в Active Directory в виде объектов, которые называются объектами классов схемы (class schema objects) и объектами атрибутов схемы (attribute schema objects). Объект класса схемы содержит ссылки на объекты атрибутов схемы, что все вместе формирует класс объекта. Таким образом, атрибут определяется только один раз, несмотря на то, что он может быть использован множеством различных классов объектов. Схема является расширяемой, поэтому приложения и службы, разработанные Microsoft и сторонними фирмами, могут создавать новые классы объектов или добавлять новые атрибуты к существующим классам объектов. Это позволяет приложениям использовать Active Directory для того, чтобы хранить информацию, специфичную для выполняемых ими функций, и предоставлять ее другим приложениям в случае необходимости. Например, вместо того, чтобы поддерживать свой собственный каталог, приложение сервера электронной почты может изменить схему Active Directory и использовать AD для аутентификации пользователей и хранения своей почтовой информации.

4.2 Типы объектов

В Active Directory существует два основных типа объектов: объекты-контейнеры и объекты-листья. Контейнер -- это просто объект, который содержит другие объекты, в то время как лист не может хранить другие объекта. Объекты-контейнеры фактически выполняют те же функции, что и ветви дерева, а объекты-листья "растут" из ветвей. Active Directory использует контейнеры в качестве организационных единиц и групп, чтобы хранить другие объекты. Контейнеры могут содержать иные контейнеры или объекты-листья, такие как пользователи и компьютеры. Руководящий принцип структуры дерева каталогов заключается в том, что права и разрешения распространяются вниз по дереву. Назначение контейнеру права говорит о том, что по умолчанию все объекты в контейнере наследуют это право. Данный факт позволяет администраторам управлять доступом к сетевым ресурсам, назначая права и разрешения контейнерам.

По умолчанию дерево Active Directory составлено из объектов, которые представляют пользователей и компьютеры в сети, логических объектов, используемых для их упорядочивания, а также папок и принтеров, к которым пользователи должны иметь постоянный доступ. Эти объекты, их функции и пиктограммы, используемые для представления их в служебных программах, таких как Active Directory Users and Computers, перечислены в таблице 3.1.

Таблица 3.1 - Типы объектов Active Directory

Пиктограмма	Тип объекта	Назначение
	Domain (Домен)	Контейнерный объект, который хранит объекты организационных единиц и их содержимое
	Organizational unit (Организационная единица)	Контейнерный объект, который хранит компьютеры, пользователей и группы объектов внутри структуры дерева
	User (Пользователь)	Объект-лист, который представляет пользователя сети и хранит идентификационные и аутентификационные данные об этом пользователе
	Computer (Компьютер)	Объект-лист, который представляет компьютер в сети, хранит о нем информацию и обеспечивает компьютеру учетную запись, необходимую для регистрации системы в домене
	Contact (Контакт)	Объект-лист, который представляет пользователя вне домена и используется в специальных целях, таких как доставка почты. При этом пользователь не имеет возможности зарегистрироваться в домене
	Group (Группа)	Контейнерные объекты, которые представляют логически сгруппированных пользователей, компьютеры и/или другие группы. Они не зависят от структуры дерева AD. Члены группы могут быть расположены в любой организационной единице или любом домене дерева
	Shared folder (Совместно используемая папка)	Представляет совместно используемую папку в системе Windows 2000
	Shared printer (Совместно используемый принтер)	Представляет совместно используемый принтер в системе Windows 2000

4.3 Присваивание объектам имен

Каждый объект в базе данных Active Directory однозначно идентифицируется по имени, которое может быть представлено в нескольких формах. Соглашения о присваивании объектам имен основаны на стандарте LDAP, определенном в документе RFC 2251, опубликованном рабочей группой инженеров Интернета (IETF). Отличаемое имя (DN, distinguished name) объекта состоит из имени домена, в котором расположен объект, и пути вниз по дереву домена через контейнеры до самого объекта. Часть имени объекта, которая хранится в самом объекте, называется его относительным отличаемым именем (RDN, relative distinguished name).

Указание имени объекта и перечисление имен его родительских контейнеров вплоть до корня домена однозначно идентифицирует объект внутри домена, даже если объект имеет такое же имя, как другой объект в ином контейнере. Таким образом, если существуют два пользователя с именами John Doe и Jane Doe, то для них обоих можно применять относительное отличаемое имя jdoe. До тех пор пока они расположены в разных контейнерах, их DN будут отличаться.

4.4 Канонические имена

Большинство приложений Active Directory ссылаются на объекты, используя их канонические имена. Каноническое имя (canonical name) -- это отличаемое имя, начинающееся с имени домена, за которым перечислены имена родительских контейнеров объекта, начиная с корня домена, разделенные прямыми слэшами, а в конце указано RDN, как приведено ниже:

zaker.com/sales/inside/jdoe

В этом примере jdoe -- это объект пользователя в контейнере inside, который расположен В контейнере sales В домене NY.zacker.com.

4.5 Форма записи LDAP

То же отличаемое имя может быть приведено в форме записи LDAP, и будет выглядеть следующим образом:

cn=jdoe,ou=inside,ou=sales,dc=zaker.dc=com

Этот способ записи изменяет порядок следования имен на обратный, сначала в левой части идет RDN, а имя домена расположено справа. Элементы разделены точкой и включают аббревиатуры LDAP, которые указывают тип каждого элемента. Это следующие аббревиатуры:

- cn -- common name (обычное имя);

- ou -- organizational unit (организационная единица);

- dc -- domain component (компонент домена).

В большинстве случаев LDAP-имена не включают аббревиатур, которые могут быть опущены без изменения однозначности или функциональности имени. Также возможно записать LDAP-имя в формате URL, как определено в RFC 1959, тогда оно будет выглядеть следующим образом:

Idap://czl.zacker.com/cn=jdoe,ou=sales,dc=zacker.dc=com

Этот формат отличается тем, что имя сервера, поддерживающего службу каталогов, должно следовать сразу за идентификатором idap://, а за именем сервера располагается то же LDAP-имя, что упоминалось ранее. Этот способ записи позволяет пользователям осуществлять доступ к информации при помощи стандартного Web-браузера.

4.6 Глобальные уникальные идентификаторы

Помимо отличаемого имени каждый объект в дереве имеет глобальный уникальный идентификатор (GUID, globally unique identifier), являющийся 128-разрядным числом, которое автоматически назначается агентом системы каталогов (Directory System Agent) при создании объекта. В отличие от DN, которое изменяется при переименовании объекта, или когда объект перемещается в другой контейнер, GUID является постоянным и служит основным идентификатором объекта.

4.7 Основные имена пользователей

Отличаемые имена используются приложениями и службами при взаимодействии с Active Directory, но для пользователей эти имена являются малопонятными и сложными для набора и запоминания. Поэтому каждый объект пользователя имеет основное имя пользователя (UPN, user principal name), которое состоит из имени пользователя и суффикса, разделенных символом @. Оно похоже на стандартный формат адреса электронной почты Интернета, определенный в RFC 822. Это имя обеспечивает пользователей упрощенным идентификатором и устраняет необходимость запоминания их места в иерархии дерева домена.

В большинстве случаев часть UPN с именем пользователя является RDN объекта пользователя, а суффикс -- DNS-именем домена, в котором расположен объект пользователя. Однако, если сеть состоит из множества доменов, то можно выбрать имя одного домена для использования в качестве суффикса для UPN всех пользователей. Таким образом, UPN может оставаться неизменным, даже если объект пользователя будет перемещен в другой домен.

UPN -- это внутреннее имя, которое применяется только в сети Windows 2000, поэтому оно не обязано соответствовать Интернет-адресу электронной почты пользователя. Тем не менее, это хорошая идея -- взять доменное имя электронной почты сети в качестве суффикса, тогда пользователи должны будут помнить только один адрес для доступа к электронной почте и регистрации в сети.

4.8 Домены, деревья и леса

Сетевая парадигма Windows NT всегда базировалась на доменах, и все сети за исключением самых маленьких требуют нескольких доменов для поддержки своих пользователей. Windows 2000 делает более простым управление множеством доменов, объединяя их в большие по размеру системы, называемые деревьями и лесами. Когда, выдвижением сервера на роль контроллера домена, создается новая база данных Active Directory, то образуется первый домен в первом дереве первого леса. Если в том же дереве формируются дополнительные домены, то все они разделяют одну схему, конфигурацию и Global Catalog Server (GCS, сервер глобального каталога), а также объединяются транзитивными доверительными отношениями.

Доверительные отношения являются способом взаимодействия доменов между собой с целю обеспечения единого каталога сети. Если домен А доверяет домену В, то пользователи домена В могут получить доступ к ресурсам в домене А. В доменах Windows NT доверительные отношения работают только в одном направлении и должны быть заданы администраторами явно. Если в сети необходимо создать полные доверительные отношения между тремя доменами, например, то понадобится шесть отдельных доверительных связей, так чтобы каждый домен доверял каждому другому домену. Active Directory автоматически создает доверительные отношения между доменами в одном дереве. Эти доверительные отношения распространяются в обоих направлениях, для аутентификации используют протокол обеспечения безопасности Kerberos и являются транзитивными, то есть если домен А доверяет домену В и домен В доверяет домену С, то домен А автоматически доверяет домену С. Таким образом, дерево (tree) является отдельной административной единицей, которая охватывает несколько доменов. Кошмар администрирования, заключающийся в ручном установлении доверительных отношений между доменами, устранен, и пользователи имеют возможность получить доступ к ресурсам в других доменах.

Домены в дереве разделяют непрерывное пространство имен. В отличие от доменов Windows NT, которые имеют одно, плоское имя, домен Active Directory имеет иерархическое имя, основанное на пространстве имен DNS, такое как mycorp.com. Разделение непрерывного пространства имен означает, что если первый домен в дереве получает имя mycorp.com, последующие домены в этом дереве будут иметь имена, построенные на основе имени родительского домена, такие как sales.mycorp.com и mis.mycorp.com (рисунок 3).

Рисунок 3 - Родительский и дочерние домены Active Directory

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

В большинстве случаев одного дерева достаточно для сети почти любого размера. Тем не менее, возможно создать несколько деревьев и объединить их вместе в структуру, известную как лес (forest). Все домены в лесу, включенные в разные деревья, разделяют одну и ту же схему, конфигурацию и GCS. Каждый домен в лесу имеет транзитивные доверительные отношения с другими доменами, не зависящие от деревьев, в которых они расположены. Единственное различие между деревьями в лесу заключается в том, что они используют отдельные пространства имен. Каждое дерево имеет свой корневой домен и дочерние домены, которые основаны на его имени. Первый домен, созданный в лесу, называется корневым доменом леса (forest root domain).

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

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

4.9 DNS и Active Directory

Windows NT опирается на NetBIOS и использует сервер имен NetBIOS, называемый Windows Internet Naming Service (WINS, служба имен Интернета для Windows), чтобы выявлять компьютеры в сети и разрешать их имена в IP-адреса. Основное ограничение NetBIOS и WINS заключается в том, что они используют плоское пространство имен, в то время как пространство имен Active Directory -- иерархическое. Пространство имен AD основано на том же принципе, что и пространство системы доменных имен (DNS), поэтому для разрешения имен и выявления контроллеров домена каталог использует вместо WINS-серверов DNS-серверы. Чтобы служба Active Directory работала корректно, необходимо наличие в сети хотя бы одного сервера DNS.

Домены в Active Directory называются стандартными доменными именами DNS, которые могут совпадать или не совпадать с именами, применяемыми организацией в Интернете. Например, если уже есть зарегистрированное доменное имя mycorp.com, предназначенное для Интернет-серверов, то можно задать это же имя родительскому домену в дереве AD или создать новое имя для внутреннего использования. Новое имя не обязательно регистрировать, так как область его применения будет ограничена только сетью Windows 2000.

DNS основана на записях о ресурсах (resource records), которые содержат информацию об определенных машинах в сети. Традиционно администраторы должны создавать эти записи вручную, но в сети Windows 2000 это вызовет проблемы. Задача создания записей о сотнях компьютеров вручную является долгой и трудной, и она усложняется использованием протокола DHCP (Dynamic Host Configuration Protocol, протокол динамической конфигурации хоста), который служит для автоматического назначения сетевым системам IP-адресов. Из-за того, что IP-адреса систем, управляемых DHCP, могут меняться, должен быть способ, который позволил бы обновлять записи DNS, чтобы отразить эти изменения.

Microsoft DNS Server, включенный в Windows 2000, поддерживает новый тип SRV записей о ресурсах, который позволяет клиентским системам использовать запросы DNS для выявления контроллеров доменов Windows 2000. Сервер DNS от Microsoft также поддерживает динамическую систему DNS (DDNS), которая работает вместе с Microsoft DHCP Server, чтобы динамически обновлять записи о ресурсах для определенных систем при изменении их IP-адресов. Многие из более старых серверов DNS, используемых сегодня (такие как BIND версии 4.хх), не поддерживают новые возможности и не будут работать с Active Directory. Тем не менее, эти новые возможности DNS были стандартизированы и реализованы в программных продуктах других производителей, таких как последние версии BIND. Поддержка записей о ресурсах типа SRV является единственной из этих новых возможностей, непременно требуемой для Active Directory. Иные возможности, такие как DDNS, защищенная DDNS и инкрементные зонные передачи, являются рекомендуемыми, но не необходимыми.

Active Directory все еще сравнительно новый продукт, и он должен пройти некоторую проверку на зрелость, которая может затронуть связь между службой каталогов и DNS. Если AD развертывается в сети предприятия, то использование Microsoft DNS Server станет хорошим выбором, так как он, несомненно, будет обновляться, чтобы соответствовать любым изменениям, происходящим в самой службе каталогов.

4.10 Сервер глобального каталога

Для поддержки больших корпоративных сетей база данных Active Directory позволяет создавать разделы и реплики. Это означает, что каталог может быть разбит на разделы, которые будут храниться на разных серверах, и копии каждого из этих разделов могут быть размещены на отдельных серверах. Однако такое разделение каталога делает для приложений более трудным определение местоположения специфической информации. Поэтому Active Directory поддерживает глобальный каталог (global catalog), который предоставляет полную картину всей структуры каталога. Когда контроллер домена содержит информацию Active Directory только для одного домена, глобальный каталог представляет собой реплику всего Active Directory кроме того, что он включает для каждого объекта только основные атрибуты, известные как связующие данные (binding data).

Так как глобальный каталог состоит из значительно меньшего количества данных, чем весь каталог, он может храниться на одном сервере, и доступ к нему пользователей и приложений осуществляется быстрее. Глобальный каталог делает для приложений более простым поиск определенных объектов в Active Directory, позволяя использовать для этого любые атрибуты, включенные в связующие данные.

5 Служба каталогов Novell (NDS)

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

С ростом популярности NetWare для организаций стало обычным делом иметь несколько серверов, каждый из которых обладает собственной регистрационной базой. Чтобы добавить нового пользователя администраторам раньше приходилось создавать учетную запись для него в базе регистрационных данных каждого сервера, к которому пользователь мог иметь доступ. Если в сети было лишь небольшое количество серверов, эта рутинная работа вызывала раздражение, но все-таки была выполнима. Если же большая сеть достигала размеров, когда в ней были уже десятки и сотни серверов NetWare, поддержка отдельных регистрационных баз для каждой машины становилась фактически неосуществимой.

Чтобы решить эту проблему, Novell создала службу каталогов, которая осуществляет функции централизованного хранилища информации обо всей корпоративной сети. Администраторы создают для каждого пользователя одну учетную запись в службе каталогов и затем могут использовать эту запись для предоставления пользователю прав доступа к ресурсам, расположенным в любом месте сети. По большей части основанная на стандарте Х.500, разработанном Международной Организацией по стандартизации (ISO), NetWare Directory Services (NDS, служба каталогов NetWare) впервые была реализована в 1993 г. как часть операционной системы NetWare 4. Поначалу включавшая кое-какие недоработки, NDS имела достаточно времени для совершенствования, а также изменила название с NetWare Directory Services на Novell Directory Services (Служба каталогов Novell), которое отражает возможность использования этого программного продукта для приложений и операционных систем, отличных от NetWare.

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

Сейчас NDS может работать на серверах UNIX и Windows NT точно также, как на серверах NetWare, и является наиболее распространенной службой каталогов. Популярность NetWare, безусловно, претерпит изменения из-за конкуренции с Windows NT и Windows 2000, но Novell имеет огромное преимущество за счет того, что ее служба каталогов существует уже давно, и NDS остается далеко впереди благодаря своей гибкости и стабильности.

5.1 Архитектура NDS

NDS фактически является базой данных, составленной из объектов, выстроенных в иерархическое дерево, похожее на то, что использует файловая система (рис. 4.1).

На вершине дерева находится абстрактный объект (Root), от которого ответвляются все остальные объекты. Объект (object) -- это логический элемент, который может представлять пользователей, оборудование, программное обеспечение и организационные компоненты. Каждый объект состоит из набора свойств (properties), которые содержат информацию об объекте. Свойства для объекта пользователя содержат идентификационную информацию о нем, а также список групп, к которым принадлежит пользователь, права доступа к другим объектам дерева NDS и какие-нибудь ограничения для данной учетной записи.

Рисунок 4.1 - База данных NDS имеет форму иерархического дерева

5.2 Контейнеры и листья

Существуют два типа объектов, используемых для построения дерева NDS: объекты-контейнеры (container objects) и объекты-листья (leaf objects). Объект-контейнер имеет подчиненные ему объекты, формирующие ветвь дерева. Объекты-листья не могут содержать другие объекты, напоминая листья настоящего дерева, которые являются конечными точками ветки.

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

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

5.3 Присваивание имен объектам NDS

Иерархическая структура базы данных NDS несет на себе не только организационные функции, но также обеспечивает уникальный идентификатор для каждого объекта дерева. В однородном файле базы данных, таком как база регистрационных данных (bindery) в старых версиях NetWare, каждый объект имел одно имя, которое должно было являться уникальным. Для одного сервера решение, такое как bindery, является разумным, но для корпоративной службы каталогов подобной NDS намного более вероятной кажется ситуация, когда понадобится иметь два объекта с одинаковыми именами. Например, если в отделе маркетинга работает Joanne Smith, а в отделе продаж -- Joe Smith, то принятое соглашение об именах объектов пользователей может потребовать, чтобы оба эти сотрудника имели имя jsmith.

В дереве NDS можно иметь два объекта с одинаковыми именами, пока они находятся в разных контекстах. Контекст (context) объекта -- это просто его расположение в дереве NDS, определяемое именами контейнеров, в которых объект содержится. Перечисляются имена всех контейнеров, лежащих на пути к корню, в качестве разделителя используется точка, которая ставится между именами. Каждый объект в дереве NDS имеет уникальный идентификатор, составленный из имени объекта и его контекста. Такая комбинация называется отличаемым именем (DN, distinguished пате) объекта. Таким образом, если в дереве существуют два пользователя с одинаковыми именами объектов, то используются следующие отличаемые имена:

j smith.NY.Sales.corpnet

j smith.Chicago.Marketing.corpnet

В этих именах контекст указывает путь от объекта (Root) справа и дальше вниз по дереву NDS к объекту. Контейнер corpnet является объектом organization, расположенным на верхнем уровне дерева, ближайшем к объекту (Root), и таким образом можно сказать, что он наиболее значимый объект в имени. Объект, который наиболее удален от корня, является менее значимым объектом.

5.4 Пространства имен NetWare

NetWare по умолчанию использует стандартную 8.3-систему DOS для именования файлов и каталогов, но также поддерживает другие файловые системы, задействуя пространства имен (name spaces), которые принимают форму добавочных записей в DET, содержащих дополнительную информацию о файлах или каталогах. Например, для обеспечения совместимости с длинными именами файлов и каталогов систем Windows потребуется установить модуль поддержки пространства длинных имен -- Long.nam, загружаемый с консоли сервера. Поскольку стандартная запись DET не может содержать имя файла или каталога длиной в 255 символов, сервер формирует дополнительную запись для хранения длинного имени, и головная запись DET для данного файла включает ссылку на этот добавочный элемент DET.

При первой загрузке модуля нового пространства имен требуется выполнить команду ADD NAME SPACE из командной строки консоли сервера с указанием вида пространства имен и тома, которому оно должно быть добавлено, как в следующем примере:

ADD NAME SPACE LONG TO SYS

NetWare включает модули пространств имен (все они имеют расширение nam), поддерживающие следующие файловые системы:

- Windows VFAT;

- Macintosh;

- OS/2 HPFS;

- NFS; FTAM.

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

Может показаться заманчивым добавить все доступные пространства имен для всех томов, хотя бы из соображений обеспечения максимальной гибкости при хранении информации, но этого следует избегать. Установка каждого нового пространства имен добавляет одну строку в DET данного тома для каждого файла или каталога. Таким образом, одно пространство имен удваивает размер DET. Добавление множества пространств имен резко увеличивает размер таблицы и уменьшает число записей DET, кэшируемых в памяти сервера.

Серверы NetWare хранят последние использованные записи DET в кэшпамяти, чтобы иметь к ним быстрый доступ в случае возникновения такой потребности. Лишнее пространство имен сокращает количество кэшируемых записей вдвое, поскольку необходимы уже две записи для каждого файла или каталога. Меньшее количество кэшируемых записей означает, что серверу с большей вероятностью потребуется получить доступ к информации DET на диске, чем найти ее в кэш-памяти. Установка слишком большого числа дополнительных пространств имен для конкретного тома способна ощутимо снизить производительность данного тома.

Следовательно, оптимальным решением будет привлечение только тех пространств имен, которые действительно необходимы какому-либо тому NetWare. Кроме того, нужно стремиться избегать использования множества пространств имен для одного тома, создавая вместо этого специализированные тома, призванные хранить конкретные типы информации. Например, выделение одного тома для хранения Macintosh-файлов будет более целесообразно, чем добавление пространства имен MAC для всех томов, в предположении, что кто-либо захочет хранить на них файлы Macintosh.

Также есть возможность настройки объема памяти, который сервер будет выдерживать для кэширования записей DET. Команда SET MINIMUM DIRECTORY CACHE BUFFERS определяет число буферов, автоматически выделяемых для кэш-памяти DET при старте сервера. Величина этого параметра по умолчанию составляет 20, и ее можно изменить на любое значение от 10 до 8000. Когда сервер запускается, он заказывает дополнительные буферы для DET-кэша по требованию в соответствии со значением значения, указанным командой SET MAXIMUM DIRECTORY CACHE BUFFERS. Значение последнего параметра по умолчанию устанавливается равным 500, возможны его изменения в пределах от 20 до 20 000.

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

6 Протокол SAP

Системы NetWare используют Service Advertising Protocol (SAP, протокол извещения об услугах) для составления и поддержания списка файловых серверов, серверов печати, серверов шлюзов и многопротокольных маршрутизаторов, расположенных в сети. Серверы при помощи SAP информируют другие системы в сети о своем присутствии. Клиент NetWare, прежде чем отправлять запросы к серверам, должен узнать об их существовании из сообщений SAP. Каждый сервер посылает широковещательные сообщения SAP с интервалом по умолчанию в 60 секунд. Эти сообщения содержат имя сервера, его адрес и описание услуг, предоставляемых им. Другие системы в сети при получении сообщения SAP создают для каждого сервера, перечисленного в сообщении, временную запись в своей базе данных ресурсов сети (bindery) или NDS, надлежащим образом сохраняя сопровождающую информацию.

Вдобавок к этой автоматически предоставляемой широковещательной рекламе, серверы также могут вырабатывать собственные запросы SAP для того, чтобы затребовать информацию от определенного сервера. NetWare использует этот тип транзакции SAP для реализации защиты от копирования, которая предотвращает возможность работы в одной сети двух серверов с одним и тем же номером лицензии, а клиенты применяют его для выявления ближайших к ним серверов. Для данного типа транзакций предусмотрены отдельные форматы пакетов: запроса ближайшего сервера (Nearest Server Request) и ответа ближайшего сервера (Nearest Server Reply). Обычные широковещательные сообщения SAP, содержащие информацию о сервере, задействуют тип пакета Standard Server Reply (ответ обычного сервера). (Тип сообщения Standard Server Request (запрос обычного сервера) не используется.)

Запросы и ответы SAP применяют различные форматы пакетов, но все сообщения SAP переносятся стандартными дейтаграммами IPX со значением в поле типа пакета (Packet Туре), равным 4, и номером сокета назначения (Destination Socket) 0452, как показано на рис. 12.12.

6.1 Кадр запроса SAP

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

? Тип пакета (Packet Туре), 2 байта. Указывает на функцию сообщения при помощи следующих шестнадцатеричных значений:

* 1 -- запрос обычного сервера (не используется);

* 3 -- запрос ближайшего сервера.

? Тип сервера (Server Туре), 2 байта. Определяет тип услуг, требуемых от сервера, в соответствии со следующими шестнадцатеричными значениями:

* 0000 -- не определены;

* 0003 -- Print Queue (очередь печати);

* 0004 -- File Server (файловый сервер);

* 0005 -- Job Server (сервер задач);

* 0007 -- Print Server (сервер печати);

* 0009 -- Archive Server (архивный сервер);

* 000а -- Job Queue (очередь заданий);

* 0021 - NAS SNA Gateway (шлюз NAS SNA);

* 0024 -- Remote Bridge Server (сервер удаленного моста);

* 002d -- Time Synchronization VAP (временная синхронизация процессов с дополнительными услугами (VAP));

* 002е -- Dynamic SAP (динамический SAP);

* 0047 -- Advertising Print Server (сервер объявлений о печати);

* 004b -- система индексированного управления записями Btrieve VAP 5.0;

* 004с - SQL VAP;

* 007а - TES-NetWare VMS;

* 0098 -- NetWare Access Server (сервер доступа к NetWare);

* 009a -- Named Pipes Server (сервер именованных каналов);

* 009e -- Portable NetWare-UNIX (сервер удаленной печати и управления файлами для клиентов NetWare);

* 0107 - NetWare 386;

* 0111 -- Test Server (сервер тестирования);

* 0166 -- NetWare Management (управление NetWare);

* 026а --NetWare Management;

* ffff -- маска.

6.2 Кадр ответа SAP

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

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

Формат для сообщения ответа SAP приведен на рисунке 5.1. Функции его полей описаны ниже.

Рисунок 5.1 - Формат сообщения ответа SAP

-Тип пакета (Packet Туре), 2 байта. Указывает на функцию сообщения при помощи следующих шестнадцатеричных значений:

* 2 -- ответ стандартного сервера (Standard Server Reply);

* 3 -- ответ ближайшего сервера (Nearest Server Reply).

-Тип сервера (Server Type), 2 байта. Определяет тип услуг, предоставляемых сервером, возможны те же значения, что и в формате сообщения запроса.

-Имя сервера (Server Name), 48 байтов. Содержит имя сервера.

-Адрес сети (Network Address), 4 байта. Указывает адрес сети, в которой расположен сервер.

-Адрес узла (Node Address), 6 байтов. Содержит адрес сетевого интерфейса сервера.

-Сонет (Socket), 2 байта. Объявляет сокет, который сервер использует для приема запросов на свои услуги.

-Промежуточная сеть (Intermediate Network), 2 байта. Фиксирует количество транзитов (то есть маршрутизаторов или сетевых адресов) между сервером и системой назначения.

6.3 Проблемы SAP

На протяжении всей своей истории существования наиболее часто NetWare критикуют за ее тесную связь с протоколом SAP и огромное количество широковещательного трафика, который этот протокол создает в сети. NDS сократила объем вырабатываемого трафика за счет того, что информация о серверах хранится в базе данных службы каталогов. В случае нормального выполнения процессов репликации NDS данные SAP реплицируются через сеть посредством однонаправленной передачи сообщений между серверами, что является более предпочтительным вариантом, нежели чем широковещание. NetWare 5 еще дальше продвинулась в решении этой проблемы, включив поддержку протокола обнаружения работающих служб (SLP, Service Location Protocol), позволяющего автоматически настраивать сетевые ресурсы и стандартизированного проблемной группой проектирования сети Интернет (IETF, Internet Engineering Task Force).

Заключение

В результате проделанной работы проведено знакомство с системами имен, принятыми в NetWare, Microsof и Internet.

Детально рассмотрены такие понятия как:

- служба доменных имен DNS;

- служба имен интернета для Windows WINS;

- служба каталогов Novell NetWare NDS;

- служба каталогов Active Directory;

Рассмотрены архитектура данных служб, особенности их построения, структура и содержание баз данных служб имен, достоинства и недостатки.

Библиографический список

1. Чеппел Л. TCP/IP Учебный курс: Пер. с англ. - СПб: БХВ-Петербург, 2003 - 976 с.

2. Закер К. Компьютерные сети. Модернизация и поиск неисправностей: Пер. с англ. - СПб: БХВ-Петербург, 2001 - 1001 с.

3. Терминология и основы DNS - http://icc.mpei.ru/documents/00000894.html.

4. Сети NetWare - http://www.hardline.ru/5/59/1193/1586-14.html.

5. FreeBSD - http://www.freebsd.org/doc/ru/books/handbook/network-dns.html.

Размещено на Allbest.ru