Средства Active Directory (стр. 2 из 3)

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

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

2 В будущих версиях Microsoft Exchange механизм базы данных будет таким же, как и в Active Directory.

AD, а затем организовывать каталоги, независимо от их расположения
и использующих их операционных систем.

Другая важная особенность Active Directory - избыточная поддержка
нескольких стандартных систем именований. В качестве собственной
системы имен в AD применяется DNS (Domain Name System); в то же
время она может использовать LDAP или HTTP для обмена информа-
цией с приложениями или иными каталогами.

Поддержка DNS

В Active Directory объединены лучшие возможности Х.500 и сервиса
обнаружения DNS . DNS - сервис, наиболее часто используемый как в
Интернете, так и в интрасетях. Он с успехом применяется для преоб-
разования имени в IP-адрес как в масштабах Интернета, так и в неболь-
ших сетях.

DNS как поисковая служба Windows NT

Active Directory использует DNS в качестве своего поискового сервиса.
Имя домена в AD - не что иное,-как полностью определенное имя DNS.
Например, fyodor.ru может быть как доменом DNS, так и доменом
Windows NT. (Вспомните, что в предыдущих версиях Windows NT имя
домена было NetBIOS-именем.) Указывая имя FyodorZ@microsoft.com,
можно в равной степени рассматривать его и как почтовый адрес в
Интернете, и как имя пользователя в домене Windows NT. На рисунке
видно, что домены Windows NT могут размещаться в Интернете или
интрасетях так же, как и любые иные ресурсы - посредством DNS.

Традиционно DNS был присущ один недостаток - статичность базы,
что вело к необходимости обновлять данные и тиражировать измене-
ния на другие серверы DNS вручную. В Windows NT 4.0 было реализо-

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

'Сладкая парочка' 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). КСС восстанавливает топологию ти-
ражирования в случае нарушения.

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