Компоненты службы Active Directory.
SRV-записи.
Служба доменных имен использует SRV-записи для определения местонахождения серверов, предоставляющих услуги определенных служб. Каждая SRV-запись, используемая для работы с Active Directory, представляет собой DNS-псевдоним службы, записанный в формате: _Service._Protocol.DnsDomainName
где:
· service — название сетевой службы, которая доступна на данном сервере (например: Idap, kerberos, kpasswd);
· Protocol — протокол, который клиенты могут использовать для подключения к указанной службе (tcp, udp);
· DnsDomainName — доменное имя домена, к которому принадлежит указанный сервер.
Например, для LDAP-сервера, принадлежащего к домену kstu.ru, DNS-имя службы будет выглядеть следующим образом: _ldap._tcp.kstu.ru
SRV-записи регистрируются в базе данных DNS-сервера непосредственно контроллерами домена. По умолчанию каждый контроллер домена регистрирует в базе данных DNS пятнадцать различных SRV-записей. Если контроллер домена выполняет также функции сервера глобального каталога, в базе данных службы DNS регистрируется двадцать SRV-записей.
Перечень ресурсных записей, которые каждый контроллер домена Windows Server 2003 регистрирует на сервере DNS в процессе своей загрузки, хранится в файле %SysfemRoot%\system32\config\netlogon.dns. Если на контроллере домена размещены реплики разделов приложений, в базе данных службы DNS дополнительно регистрируются три ресурсных записи — одна А-типа и две SRV-типа для каждой реплики. Это записи _ldap._tcp.<имя_раздела> и _ldap._tcp.<имя__сайта>._sites.<имя_разделах. В текущей версии Active Directory эти записи не используются службой каталога. Однако они позволяют приложениям обращаться к службе доменных имен для поиска сервера, содержащего интересующий раздел приложения.
Служба DNS, реализованная в Windows Server 2003, поддерживает динамическую регистрацию ресурсных записей. Это означает, что контроллеры домена Windows Server 2003 способны автоматически регистрировать в базе данных DNS-сервера все необходимые SRV-записи. Однако, если вы используете реализацию DNS-сервера, которая не поддерживает режим динамической регистрации ресурсных записей, все указанные SRV-записи должны быть зарегистрированы вручную.
Перейдем от терминологии к рассмотрению механизмов и подсистем, составляющих архитектуру Active Directory. Для начала рассмотрим структуру службы каталога. Active Directory представляет собой совокупность служб, обслуживающих обращения пользователей к каталогу. Каталог рассматривается как распределенная база данных, в которой хранятся сведения об объектах сети. Пользователь не может работать с каталогом напрямую, а взаимодействует с ним через целый ряд подсистем и механизмов, которые в совокупности называются службой каталога. С точки зрения обслуживания обращений пользователей подсистемы службы каталога образуют некую структуру, в которой компания Microsoft выделяет пять уровней.
1. Интерфейсы доступа к каталогу. Это самый верхний уровень службы каталога, отвечающий за непосредственное взаимодействие с приложениями пользователей. На данном уровне описаны все возможные методы доступа к каталогу. Можно рассматривать данный уровень как набор прикладных интерфейсов программирования (Application Program Interfaces, API), посредством которых приложения пользователей могут взаимодействовать с системным агентом каталога.
2. Системный агент каталога (Directory System Agent, DSA). Любой клиент, подключающийся к каталогу, взаимодействует с DSA. Мы уже сталкивались с системным агентом каталога при рассмотрении спецификации Х.500. Все запросы, поступающие от пользователей, обрабатываются агентом, он же возвращает клиентам результаты запросов.
3. Уровень базы данных (Database Layer). Данный уровень службы каталога осуществляет преобразование запросов пользователей в формат, приемлемый для расширяемой оболочки хранилища. Это преобразование необходимо, поскольку расширяемая оболочка хранилища манипулирует данными в представлении реляционной базы данных. Однако вышестоящие уровни представляют содержимое каталога в виде древовидной структуры.
4. Расширяемая оболочка хранилища (Extensible Storage Engine, ESE). Расширяемая оболочка хранилища представляет собой механизм управления реляционным хранилищем данных, в форме которого реализован каталог. Компания Microsoft рассматривает ESE в качестве стандартного механизма управления реляционными хранилищами и широко применяет ее в различных своих продуктах. ESE берет на себя все обязанности по обслуживанию запросов, поступающих от пользователей (и преобразованных в соответствующий формат на вышестоящем уровне) на извлечение данных из каталога и манипуляции ими. Можно представить ESE как систему управления базой данных (СУБД). При этом в качестве базы данных выступает непосредственно хранилище данных.
5. Файлы хранилища (Data Store files). Хранилище данных реализовано в виде набора файлов, которые используются непосредственно для организации хранения данных каталога. Поскольку информация, содержащаяся в этих файлах, критически важна для функционирования Active Directory, доступ к ним имеет только расширяемая оболочка хранилища. В данном случае можно говорить о самом низшем уровне операций в рамках службы каталога.
Понятие домена является ключевым для Active Directory. Домены выступают в качестве основного средства формирования пространства имен каталога. Другие уровни формирования структуры каталога сосредотачиваются либо на административной иерархии, либо на физической структуре сети.