Средства Active Directory

       'Сладкая парочка' DNS+WINS работала следующим образом. При по- 
ступлении от DNS-клиента запроса на разрешение имени (например, 
mydesktop.mycorp.ru) разрешение имени хоста выполнялось на серве- 
ре WINS, к которому обращался сервер DNS, и которому возвращался 
разрешенный IP-адрес. Такая конфигурация делала возможным исполь- 
зование DHCP (Dynamic Host Configuration Protocol) для динамическо- 
го назначения адресов. Хотя интеграция DNS с WINS и была времен- 
ным решением, она хоть немного скрасила жизнь администраторам до 
принятия стандарта на динамический DNS3.

       В динамическом сервере DNS обновлением  и тиражированием базы 
занимается непосредственно сервер. Серверы, на которых установле- 
на служба каталогов Active Directory, используют динамический DNS для 
публикации самих себя в базе DNS. Если Вы уже начали применять 
комбинацию WINS-DNS, то можете считать, что подготовили почву для 
прозрачного перехода к динамическому DNS.

       Смежные и раздельные пространства имен

       В каталоге LDAP пространство имен может  быть либо смежным, либо 
раздельным. В первом случае имя дочернего домена всегда содержит 
имя родительского домена. Например, если домен с именем DC=Finan- 
се, DC=MyCorp, DC=Ru - дочерний для домена DC=MyCorp, DC=Ru, то это про- 
странство смежных имен. Имя родительского домена всегда может быть 
восстановлено при отбрасывании первой части дочернего имени.

       В пространстве раздельных имен родительский и дочерний домены не 
связаны друг с другом непосредственно. Например, хотя домен DC=Fi- 
nance,DC=Ru - дочерний для домена DC=MyCorp,DC=Ru, его имя не 
содержит имени родительского домена.

       Смежные имена или раздельные важно при  поиске. В случае примене- 
ния смежных имен на контроллере домена всегда создаются ссылки 
(referrals) на дочерние домены. При использовании раздельных имен 
поиск останавливается и ссылки не создаются.

       Одновременное использование смежных и раздельных имен делает 
механизм поиска в древовидной структуре сложным для понимания. 
Поэтому в Active Directory вводятся понятия деревьев и леса.

       Тиражирование Active Directory

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

       Но  хотя концептуально такой подход проще существовавшей в преды- 
дущих версиях модели с одним главным и несколькими резервными 
контроллерами домена, он требует принятия специальных мер по син- 
хронизации тиражируемой информации. Тиражирование Active Direc- 
tory основано не на временных интервалах, а на последовательных 
номерах обновлений USN (Update Sequence Numbers). В каждом кон- 
троллере домена имеется таблица, где записаны как свой собственный 
номер USN, так и USN партнеров по тиражированию. При тиражирова- 
нии происходит сравнение последнего известного USN партнера с тем, 
который сообщается. И если сообщенный номер больше записанного, 
запрашиваются все изменения у партнера по тиражированию (такой 
тип тиражирования носит название запрашиваемого). После обновле- 
ния данных USN на контроллере домена становится равным значению, 
полученному от партнера.

       Если  данные одного и того же объекта изменились сразу на несколь- 
ких контроллерах домена, то обновление выполняется следующим 
образом.

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

       По  временной отметке. Если свойства имеют одинаковый номер 
версии, то проверяется временная отметка, создаваемая вместе с но- 
мером версии при модификации свойств. При этом предполагается,

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

         По размеру буфера. Если и номер версии, и временные отметки 
совпадают, то выполняется сравнение в двоичном виде, причем пред- 
почтение получает то свойство, которое в двоичном виде занимает 
больший объем. Если размеры одинаковы, то считается, что обе вер- 
сии идентичны и в расчет не принимается ни одна из них.

       Давайте проиллюстрируем все сказанное  на примере. Допустим, что два 
администратора на разных контроллерах домена вносят изменения в 
свойства группы AcctUsers. Один из них предоставил право модифика- 
ции каталога FinRus, а второй - право модификации каталога FinAd- 
min, но сделал это на минуту позже первого. При согласовании версий 
на третьем контроллере домена будет обнаружено, что номера версий 
совпадают, а время модификации на втором контроллере - более позд- 
нее. Поэтому в расчет будет принято только изменение, сделанное вто- 
рым администратором.

       Замечание. Все операции согласования заносятся в журнал, так что 
администраторы могут при необходимости восстановить прежние 
значения.

       Узлы  и домены

       Концепция узлов (sites) используется продуктами семейства Microsoft 
BackOffice для минимизации графика в глобальной сети. К сожалению, 
в каждом продукте эта концепция трактуется по-своему. В Windows NT 5.0 
вводится еще одно новшество: концепция не оптимизирована под ка- 
кое-либо определенное приложение, а предполагает в качестве осно- 
вы сеть IP, для которой обеспечиваются наилучшие условия подключе- 
ний. В будущем планируется, что все приложения BackOffice будут ис- 
пользовать именно эту концепцию узла.

       Узел  с Active Directory состоит из одной или  нескольких подсетей IP. 
Администратор может определять эти подсети, а также добавлять к ним 
новые. При этом он исходит из следующих посылок:

       . оптимизация графика тиражирования  между узлами по медленным 
линиям;

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

       Тиражирование внутри узла и между узлами осуществляется по различ- 
ным топологиям. Внутри узла контроллер домена задерживает опове- 
щение о сделанных изменениях на некоторый устанавливаемый про- 
межуток времени (по умолчанию равный 10 минутам). В отличие от

       Microsoft Exchange в Active Directory можно изменять топологию тира- 
жирования внутри узла. По умолчанию это двунаправленное кольцо, 
однако Вы можете полностью переопределить топологию и задать ее, 
скажем, в виде звезды.

       В любом случае служба каталогов будет отслеживать целостность то- 
пологии, то есть ни один контроллер домена не будет исключен из 
процесса тиражирования. Для этого на всех контроллерах домена ис- 
полняется отдельный контрольный процесс, так называемый КСС 
(Knowledge Consistency Checker). КСС восстанавливает топологию ти- 
ражирования в случае нарушения.

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

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

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

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

       Любой объект в каталоге Active Directory может  иметь несколько имен:

       общее, относительное и т. п. Единственным всегда неизменным иден- 
тификатором объекта является Глобальный уникальный идентифика- 
тор GU1D (Globally Unique Identifier). GUID - это многозначное число, 
создаваемое контроллерами домена. Алгоритм создания идентифика- 
тора не допускает дублирования. Именно этот никогда не изменяемый 
идентификатор может использоваться в Active Directory для того, что- 
бы свободно переименовывать домены, как и любые объекты4.

       GUID также позволяет перемещать домены в дереве или в лесу. Во 
время частичного тиражирования в глобальный каталог заносится под- 
множество свойств объекта. В это подмножество входит и GUID. Если 
объект перемещен, то глобальный каталог может использовать GUID 
для поиска объекта и его отличительного имени на основе нового от- 
носительного ID и LDAP-пути к новому местоположению.

       4 В Windows NT 5.0 скорее всего не будет реализован механизм переименова- 
ния доменов, так как разработчики столкнулись с целым рядом непредви- 
денных трудностей, преодоление которых перенесено к моменту выхода 
Windows NT 6.0.

       Включение домена в лес не сложнее подключения к дереву доменов 
и рассматривалось ранее.

       Если  используется сервер динамического DNS Windows NT 5.0, то при 
перемещении или переименовании домена средствами администриро- 
вания автоматически выполняется коррекция записей в базе DNS. При 
использовании UNIX DNS-сервера создается файл, в который заносят- 
ся и подлежащие удалению, и новые записи. Дополнительно в Windows 
NT Workstation 5.0 автоматически изменяются настройки TCP/IP, и вно- 
сится новое имя домена.

       Доступ  к Active Directory

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

       Управление  узлами

       Конфигурируя  узлы, Вы управляете топологией тиражирования. Для 
доступа к информации об узлах необходимо загрузить в ММС слепок 
Microsoft Site Replication Manager. Соответствующее окно примет вид, 
изображенный на рисунке. Загружая этот слепок впервые, Вы увидите 
один узел, указанный во время установки операционной системы и имя 
своего собственного компьютера в этом узле.

       Окно Microsoft Management Console - Microsoft Site Replication 
Manager

       Для описания узла необходимо описать входящие в него подсети. Опи- 
сание подсетей выполняется в формате www, xxx. yyy. zzz/mm, где первая 
часть (до косой черты) - адрес подсети, a mm - число немаскируемых 
разрядов, считая от начала. Например, 155.1-1.0/22. Все маскируемые 
разряды должны быть равны 0.

       Чтобы добавить новый узел, подведите мышь к папке Sites в левой ча- 
сти окна, щелкните ее правой кнопкой и выберите из контекстного 
меню команду New и подменю Site. В поле появившегося диалогового 
окна укажите имя нового узла, включаемого в топологию тиражирования.