Стратегия именования объектов

Цель лекции: Дать представление о планировании стратегии именования объектов в Active Directory.

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

Соглашение об именовании

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

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

Active Directory следует соглашению об именовании, принятому в DNS. Active Directory поддерживает несколько типов имен, поэтому при работе с Active Directory можно использовать разные форматы имен :

Относительные составные имена

Относительное составное имя (RDN) объекта уникально идентифицирует объект, но только в его родительском контейнере. Таким образом, оно уникально идентифицирует объект относительно других объектов в том же самом контейнере. Например: CN=wjglenn, OU=Users, DC=kd, DC=ru.

Здесь относительным составным именем объекта является CN=wjglenn. RDN родительской организационной единицы (OU) - Users. У большинства объектов RDN - это тоже самое, что и атрибут Common Name.

Active Directory автоматически создает RDN по информации, указываемой при создании объекта, и не допускает, чтобы в одном и том же родительском контейнере существовали два объекта с одинаковыми RDN.

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

Составные имена

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

Вот типичный пример составного имени: CN=wjglenn, OU=Users, DC=kd, DC=ru.

Это DN означает, что объект пользователя wjglenn содержится в контейнере Users, в свою очередь содержащемся в домене kd.ru. Если объект wjglenn переместят в другой контейнер, его DN изменится и будет отражать новое местоположение в иерархии. DN гарантированно уникальны в лесу, существование двух объектов с одинаковыми DN невозможно.

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

Каноническое имя объекта используется во многом так же, как и составное. Просто у него другой синтаксис. Составному имени, приведенному в предыдущем подразделе, соответствовало бы следующее каноническое имя: kd.ru/Users/wjglenn.

Таким образом, в синтаксисе составных и канонических имен - два основных отличия. Первое - каноническое имя формируется от корня к объекту, а второе - в каноническом имени не используются тэги LDAP-атрибутов (например, CN и DC).

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

Основное имя пользователя (UPN), генерируемое для каждого объекта пользователя, имеет вид имя_пользователя@имя_домена. Пользователи могут входить в сеть под своими основными именами, а администратор при желании может определить для этих имен суффиксы. Основные имена пользователей должны быть уникальными, но Active Directory не проверяет соблюдение этого требования. Лучше всего принять соглашение об именовании, не допускающее дублирования основных имен пользователей.

Краткий обзор DNS

DNS является службой разрешения имен и использует иерархическое пространство имен для поиска компьютеров (см. рис 6.1). Корневой домен обозначается точкой ("."). Он представляет собой верхний уровень DNS, остальное пространство имен располагается ниже. На следующем уровне под корневым доменом располагаются домены первого уровня, включая несколько основных (generic) доменных имен (com, edu, mil, net, org и т. д.), около двухсот сокращений названий стран, несколько доменов, которые были введены позже (biz, info, pro и т. д.). Под доменами верхнего уровня расположены домены второго уровня, которые обычно относятся к названиям компаний и должны быть зарегистрированы властями Интернета. Ниже доменов второго уровня располагаются поддомены. Поддомены обычно относятся к отделам или подразделениям в пределах компании. Эти поддомены регистрируются и управляются с DNS-серверов, которые содержат информацию о доменах второго уровня.

Поскольку DNS использует иерархическое пространство имен, то достаточно просто сконфигурировать его как распределенную базу данных. Прежде чем в Интернете была реализована доменная система имен, вся информация, необходимая для разрешения имен, хранилась в единственном файле. Поскольку количество хостов в Интернете очень сильно увеличилось, то управление одним файлом стало непрактичным. Была разработана система DNS, использующая распределенную базу данных. Применение распределенной базы данных означает, что информация DNS хранится на многих компьютерах во всем мире (в случае Интернета) и повсюду в корпоративной сети (в случае внутренней сети). Каждый DNS-сервер обслуживает только одну маленькую часть базы данных DNS. Вся база данных разделена на зонные файлы на основе имен доменов. Зонные файлы распределены между несколькими серверами. К примеру, существует около дюжины серверов, которые содержат зонные файлы для корневого домена. Они хранят информацию о DNS-cepверах, которые несут зонную информацию для доменов высшего уровня. Корневые серверы не содержат всю информацию о доменах высшего уровня, но они знают, какие серверы имеют эту информацию.

DNS-серверы, хранящие информацию о доменах высшего уровня, содержат также информацию о том, на каких серверах находятся зонные файлы для доменов следующего уровня. Например, сервер может содержать зонные файлы для домена com, то есть этот сервер знает обо всех доменах второго уровня, которые зарегистрированы с доменом com, но он может не знать отдельные детали о домене второго уровня. Сервер домена высшего уровня знает, какой компьютер на следующем уровне содержит детали, касающиеся домена второго уровня, и так продолжается до самого низа пространства имен DNS. Сервер, ответственный за домен com, может иметь домен kd, зарегистрированный как домен второго уровня. Этот сервер может передавать любые запросы на информацию о домене kd на сервер, который содержит зонные файлы для kd.com.

Использование метода распределенной базы данных означает, что никакому серверу в Интернете не требуется иметь всю информацию DNS. Большинство серверов хранят информацию о некоторой части дерева, но когда приходит запрос, который они не могут выполнить, им известно, какой DNS-сервер хранит необходимую информацию. DNS-серверы используют делегированные записи, ретрансляторы (forwarders) и корневые ссылки для определения того, какой DNS-сервер имеет необходимую информацию.

Текущие записи, хранящиеся в зонных файлах DNS, называются записями ресурсов (RR - Resource Records). Записи ресурсов содержат текущую информацию о домене, на DNS-сервере системы Windows Server 2003 можно создать двадцать два различных типа записей ресурсов .

Служба DNS Locator

Служба DNS Locator (указатель DNS ) очень важна для Active Directory, потому что DNS обеспечивает информацию, которая необходима клиентам для поиска контроллеров домена в сети.

Чтобы облегчить нахождение контроллеров домена, Active Directory использует указатель служб (service locator) или записи SRV. Первая часть SRV-записи идентифицирует службу, на которую указывает запись SRV :

Интегрированные зоны Active Directory

Один из самых больших плюсов выполнения DNS в операционной системе Windows Server 2003 заключается в использовании интегрированных зон (integrated zones) Active Directory, которые дают множество преимуществ .

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

Когда зона сконфигурирована как интегрированная зона Active Directory, можно просматривать информацию DNS в Active Directory .

Определение стратегии именования

При выработке стратегии именования необходимо учитывать требования к именованию, предъявляемые как Active Directory, так и DNS :

Клиенты используют DNS для разрешения IP-адресов серверов, на которых выполняются важные сетевые сервисы Active Directory. Следовательно, Active Directory и DNS неразрывно связаны.

В DNS имена образуют иерархию и формируются путем "движения" от родительских доменов к дочерним доменам. Так, у домена kd.ru может быть дочерний домен sales.kd.ru, у того, в свою очередь, - дочерний домен europe.sales.kd.ru. Имя каждого домена соответствует пути, идентифицирующему домен в иерархии DNS, т. е. пути к корневому домену (корневой домен обозначается точкой).

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

Все имена доменов Active Directory идентифицируются по DNS, но можно использовать и NetBIOS-имена (Network Basic Input/Output System) - унаследованную систему именования, которая применялась в старых версиях Windows и по-прежнему поддерживается в Windows Server 2003. Windows автоматически генерирует NetBIOS-имена для каждой службы, выполняемой на компьютере, добавляя к имени компьютера дополнительный символ. Доменам также присваиваются NetBIOS-имена, при этом совместимость с NetBIOS-именами - это плоская модель, длина имени не более 16 символов.

Существует возможность назначать разные NetBIOS- и DNS-имена, но такой подход не допустим.

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

Идентификаторы защиты

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

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

При выработке стратегии именования представляют интерес две роли хозяев операций :

Два сервера, выполняющих эти роли, должны быть доступны, когда создаются и именуются новые участники системы безопасности (security principals).

Правила имен участников системы безопасности

Объекты участников системы безопасности - это объекты Active Directory, которым назначены идентификаторы защиты и которые указываются при входе в сеть и предоставлении доступа к ресурсам домена.

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

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

К создаваемым именам для участников системы безопасности предъявляются следующие требования :

Допускается применение одного и того же имени участника системы безопасности в разных доменах. Так, можно создать пользователя wjglenn в доменах hr.kd.ru и sales.kd.ru. Это не приведет к проблемам, поскольку составное, относительное составное и каноническое имена каждого объекта автоматически генерируются Active Directory и все равно позволяют глобально идентифицировать этот объект.

Правила именования доменов

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

Краткие итоги

В этой лекции приведено соглашение об именовании в Active Directory, с описанием разных форматов имен:

Дан краткий обзор службы доменных имен DNS и указана ее взаимосвязь с Active Directory. Один из самых больших плюсов выполнения DNS в операционной системе Windows Server 2003 заключается в использовании интегрированных зон (integrated zones) Active Directory, которые дают множество преимуществ.

При выработке стратегии именования необходимо учитывать требования к именованию, предъявляемые как Active Directory, так и DNS:

При выработке стратегии именования интерес представляют две роли хозяев операций:

Два сервера, выполняющих эти роли, должны быть доступны, когда создаются и именуются новые участники системы безопасности (security principals).

Сформулированы правила именования участников системы безопасности и доменов.