 |
Вопрос 60 - Поддержка имен стандартных форматов.
|
|
|
|
Форма именований, принятая в каталоге, влияет, как на пользователей, так и на приложения. Например, если Вы желаете отыскать объект в каталоге, то должны точно указать имя свойства, применяемого в качестве критерия поиска.
В различных стандартах (как де-факто, так и де-юре) используются различные форматы имен. Многие из них поддерживаются в Active Directory, что позволяет пользователям, например, обращаться к объектам привычным образом. Перечислим некоторые из поддерживаемых систем именований.
• RFC822. Этот стандарт именований хорошо знаком пользователям Интернета. Кто из Вас не встречался с формой имя@домен, отправляя или получая сообщения по электронной почте? Если Вы, например, хотите задать вопрос Билу Гейтсу, то можете воспользоваться адресом askbill@microsoft.com. Адрес в таком формате можно не только поместить на визитной карточке, но и использовать для входа и систему.
• HTTP URL. Как упоминалось ранее, к службе каталогов Active Directory можно обратиться по протоколу HTTP, Для этого необходимо указать имя URL, формат которого также хорошо знаком пользователям Интернета: http: //имя-домена/путь-к-странице. При этом имядомена — это имя сервера, на котором установлена служба каталога, а путь к странице — путь в иерархичной структуре каталога к интересующему объекту.Например:
http://myserver.mycorp.ru/BIN/Division/Finance/Russian/IvanDemido.
• LDAP URL и имена Х.500. В Active Directory поддерживается доступ и по протоколу LDAP. То, что имена LDAP сложнее по сравнению с именами Интернета, не так важно — ведь обычно LDAP используется приложениями. В рамках LDAP действуют соглашения об именовании Х.500, называемые атрибутированным именованием. Имя при этом состоит из URL сервера, на котором располагается каталог, и далее — атрибутированного имени объекта. Например:
|
|
|
LDAP://My Server.MyCorp.Ru/CN=IvanDemidov,OU=Russian,OU=Finance,OU=Division,0=MyCorp,C=RU
• Имена UNC. В Active Directory поддерживается также и соглашение об универсальном именовании, которое традиционно используется в сетях Windows NT для ссылок на совместно используемые ресурсы: тома, принтеры и файлы. Вы можете обратиться к файлу, опубликованному в Active Directory, например, так:
\\MyServer.MyCorp,Ru\Division.Finance.Russian,MyVolume\WordDocs\YearBudget.doc
Вопрос 61 - Смежные и раздельные пространства имен. Тиражирование Active Directory. Узлы и домены. Деревья и леса.
В каталоге LDAP пространство имен может быть либо смежным, либо раздельным. В первом случае имя дочернего домена всегда содержит имя родительского домена. Например, если домен с именем DC=Finanсе, DC=MyCorp, DC=Ru — дочерний для домена DC=MyCorp, DC=Ru, то это пространство смежных имен. Имя родительского домена всегда может быть восстановлено при отбрасывании первой части дочернего имени.
В пространстве раздельных имен родительский и дочерний домены не связаны друг с другом непосредственно. Например, хотя домен DC=Finance,DC=Ru — дочерний для домена DC=MyCorp,DC=Ru, его имя не содержит имени родительского домена.
Смежные имена или раздельные важно при поиске. В случае применения смежных имен на контроллере домена всегда создаются ссылки (referrals) на дочерние домены. При использовании раздельных имен поиск останавливается и ссылки не создаются.
Одновременное использование смежных и раздельных имен делает механизм поиска в древовидной структуре сложным для понимания. Поэтому в Active Directory вводятся понятия деревьев и леса.
Тиражирование Active Directory
Active Directory использует тиражирование типа мульти-мастер. Как уже упоминалось, в этой службе каталогов более не существует различий между контроллерами доменов — они все равноправны. Изменения, внесенные в каталог на одном контроллере, тиражируются на остальные.
|
|
|
Но хотя концептуально такой подход проще существовавшей в предыдущих версиях модели с одним главным и несколькими резервными контроллерами домена, он требует принятия специальных мер по синхронизации тиражируемой информации. Тиражирование Active Directory основано не на временных интервалах, а на последовательных номерах обновлений USN (Update Sequence Numbers). В каждом контроллере домена имеется таблица, где записаны как свой собственный номер USN, так и USN партнеров по тиражированию. При тиражировании происходит сравнение последнего известного USN партнера с тем, который сообщается. И если сообщенный номер больше записанного, запрашиваются все изменения у партнера по тиражированию (такой тип тиражирования носит название запрашиваемого). После обновления данных USN на контроллере домена становится равным значению, полученному от партнера.
Если данные одного и того же объекта изменились сразу на нескольких контроллерах домена, то обновление выполняется следующим образом.
• По номеру версии. У каждого свойства свой номер версии. С помощью этого номера определяется «наиболее актуальное», то есть имеющее наибольший номер версии, свойство. Это не всегда верное решение, однако оно позволяет согласовывать версии без дополнительных переговоров с партнером по тиражированию и гарантирует идентичность данных на всех контроллерах доменов.
• По временной отметке. Если свойства имеют одинаковый номер версии, то проверяется временная отметка, создаваемая вместе с номером версии при модификации свойств. При этом предполагается, что все контроллеры домена синхронизованы по времени. Предпочтение отдается версии, созданной позднее. И опять же, это не всегда верно, но лучше обслуживать пользователей, чем заниматься длительными переговорами относительно того, кто «главнее».
• По размеру буфера. Если и номер версии, и временные отметки совпадают, то выполняется сравнение в двоичном виде, причем предпочтение получает то свойство, которое в двоичном виде занимает больший объем. Если размеры одинаковы, то считается, что обе версии идентичны и в расчет не принимается ни одна из них.
Давайте проиллюстрируем все сказанное на примере. Допустим, что два администратора на разных контроллерах домена вносят изменения в свойства группы AcctUsers. Один из них предоставил право модификации каталога FinRus, а второй — право модификации каталога FinAdmin, но сделал это на минуту позже первого. При согласовании версий на третьем контроллере домена будет обнаружено, что номера версий совпадают, а время модификации на втором контроллере — более позднее. Поэтому в расчет будет принято только изменение, сделанное вторым администратором.
|
|
|
Замечание. Все операции согласования заносятся в журнал, так что администраторы могут при необходимости восстановить прежние значения.
Узлы и домены
Концепция узлов (sites) используется продуктами семейства Microsoft BackOffice для минимизации графика в глобальной сети. К сожалению, в каждом продукте эта концепция трактуется по-своему. В Windows NT 5.0 вводится еще одно новшество: концепция не оптимизирована под какое-либо определенное приложение, а предполагает в качестве основы сеть IP, для которой обеспечиваются наилучшие условия подключений. В будущем планируется, что все приложения BackOffice будут использовать именно эту концепцию узла.
Узел с Active Directory состоит из одной или нескольких подсетей IP. Администратор может определять эти подсети, а также добавлять к ним новые. При этом он исходит из следующих посылок:
• оптимизация графика тиражирования между узлами по медленным линиям;
• создание клиентам наилучших условий для быстрого обнаружения ближайших к ним контроллеров.
Тиражирование внутри узла и между узлами осуществляется по различным топологиям. Внутри узла контроллер домена задерживает оповещение о сделанных изменениях на некоторый устанавливаемый промежуток времени (по умолчанию равный 10 минутам). В отличие от Microsoft Exchange в Active Directory можно изменять топологию тиражирования внутри узла. По умолчанию это двунаправленное кольцо, однако Вы можете полностью переопределить топологию и задать ее, скажем, в виде звезды.
В любом случае служба каталогов будет отслеживать целостность топологии, то есть ни один контроллер домена не будет исключен из процесса тиражирования. Для этого на всех контроллерах домена исполняется отдельный контрольный процесс, так называемый КСС (Knowledge Consistency Checker). КСС восстанавливает топологию тиражирования в случае нарушения.
|
|
|
Концепция поиска ближайшего ресурса или контроллера домена позволяет сократить трафик в низкоскоростных частях глобальных сетей. Для поиска ближайших ресурсов или контроллеров домена клиенты могут использовать информацию об узле. Начиная вход в сеть, клиент получает от контроллера домена имя узла, к которому принадлежит, имя узла к которому относится контроллер домена, а также информацию о том, является ли данный контроллер домена ближайшим к клиенту. Если это не ближайший контроллер, то клиент может обратиться к контроллеру домена в собственном узле и в дальнейшем работать с ним, как с ближайшим контроллером. Так как данная информация сохраняется в реестре, клиент может ее использовать при следующем входе в сеть.
Если пользователь перемещается со своей рабочей станцией в новое место, то при входе в сеть станция обращается к прежнему контроллеру домена. Только в этом случае он уже не является ближайшим, и сообщает клиенту информацию о ближайшем узле. Эта информация может быть использована клиентом для доступа к DNS и определения адреса ближайшего контроллера домена.
Деревья и леса
Вспомним определения, данные ранее. Итак, дерево характеризуется:
• иерархией доменов;
• пространством смежных имен;
• доверительными отношениями Kerberos между доменами;
• использованием общей схемы;
• принадлежностью к общему глобальному каталогу.
Лес характеризуется:
• одним или несколькими наборами деревьев;
• раздельными пространствами имен между этими деревьями;
• доверительными отношениями Kerberos между доменами;
• использованием общей схемы;
• принадлежностью к общему глобальному каталогу.
На рисунке изображен пример леса. DNS-имя корневого домена в левом поддереве — microsoft-com.; LDAP-имя этого домена в Active Directory можно записать как DC=microsoft, DOCOM, o=Internet. Корневое имя домена во втором поддереве — DC=MSN, DC=COM, o=Internet. Хорошо видно, что пространства имен разделены.
Рис. 27 - Пример леса
Поддомены в каждом из деревьев принадлежат к смежному пространству имен. Например LDAP-имя для российского домена внутри Microsoft могло бы выглядеть как DC=russia,DC=microsoft,DC=COM,o=Internet.
Концепция смежных деревьев в лесу позволяет понять многие механизмы: как осуществляется поиск в лесу или в поддеревьях, почему объекты безопасности остаются действительными в рамках леса и др. Можно формировать виртуальные команды пользователей, находящихся в разных деревьях леса, а также включать в лес любое дерево. Последнее свойство используется, например, при слиянии предприятий или начальном разворачивании сети.
|
|
|
Для обеспечения работы дерева или леса необходимы метаданные. Они хранятся в двух контейнерах (конфигурации и схемы), в каждом из которых своя система имен и топология тиражирования. В конфигурационном контейнере содержится информация, связующая для деревьев в лесу: о доступных контроллерах домена, узлах и вообще всех контроллерах домена. При добавлении в домен нового контроллера конфигурационная информация обновляется и тиражируется.
|
|
|
