Часть2. Архитектура Active Directory
Теоретическая часть:
Теперь, ознакомившись с базовыми терминами и концепциями, попытаемся составить из них единую четкую картину — поговорим об устройстве Active Directory подробно.
Основная структурная единица Active Directory — дерево доменов, связанных доверительными отношениями друг с другом. Внутри каждого домена может располагаться иерархия организационных единиц (OU). Иерархия OU внутри одного домена никак не связана с иерархией OU в других доменах. Наоборот, они полностью независимы.
Такая двухъярусная иерархичная структура предоставляет высокую степень свободы в администрировании деревьев доменов. Например, всем деревом доменов целиком может управлять центральная служба информационных технологий (ИТ), а во всех доменах будут созданы свои собственные организационные единицы, где учтены как работники, ответственные за локальную поддержку на местах, так и ресурсы, обеспечивающие эту поддержку.
В каждом отдельном домене могут быть созданы дополнительные OU для выполнения конкретных задач. Так в домене головного офиса — OU отдела кадров и бухгалтерии, в филиалах — OU торговых представительств. При этом административные права для каждой из этих OU могут делегироваться центральной службой ИТ сотрудникам упомянутых групп. Последние же, будучи наделены административными полномочиями только в рамках своих OU, никак не смогут помешать службе ИТ выполнять глобальное администрирование или вмешаться в деятельность другой OU.
Рисунок 6. Архитектура Active Directory
Такая гибкость позволяет организовать каталог в точном соответствии со структурой Вашего предприятия. Причем, возможно отразить как централизованную, так и децентрализованную, а также некоторую смешанную модель управления предприятием. Например, дерево доменов может быть организовано по централизованной модели, а OU внутри доменов — по децентрализованной.
Как уже упоминалось, внутри каждого домена — своя политика . Этой политикой определяются, в частности, требования к паролям, время жизни билетов Кегberos, блокировки учетных записей и т. д. При создании учетной записи в домене для нее генерируется идентификатор безопасности (SID),частью которого является идентификатор домена, выдавшего SID. Это позволяет легко определять, какому домену принадлежит пользователь или группа и каковы их права доступа к ресурсам. Таким образом, можно говорить о физических границах безопасности домена, в рамках которых и выполняется его администрирование.
Организационные единицы являются контейнерами, в которых могут содержаться другие организационные единицы или объекты (пользователи, группы, принтеры или ресурсы распределенной файловой системы). Разрешение создавать объекты или изменять их атрибуты может быть выдано отдельным пользователям или группам, что позволяет более четко разделять административные полномочия.
Использование схемы
Определение схемы, данное при первом ознакомлении с этим термином, несколько расплывчато и, возможно, не дает общего понимания ее назначения. В схеме задано, какие объекты и с какими свойствами допустимы в каталоге. Во время установки Active Directory на первый контроллер доменов в лесу, служба каталогов по умолчанию создает схему, где содержатся все объекты и заданы свойства, необходимые для нормального функционирования службы каталогов. Предусматривается также тиражирование каталога на все контроллеры домена, которые будут включены в лес позднее.
Каталог содержит необходимую информацию о пользователях и объектах данной организации. Такие свойства Active Directory, как отказоустойчивость и расширяемость, позволяют использовать этот сервис в различных приложениях, например, по учету кадров. Стандартно в Active Directory уже определены такие атрибуты пользователя, как его имя, фамилия, номера телефонов, название офиса, домашний адрес. Но если понадобятся такие сведения, как зарплата сотрудника, его трудовой стаж, медицинская страховка, сведения о поощрениях и т. п., то эти параметры можно задать дополнительно. Active Directory позволяет «наращивать» схему, добавлять в нее новые свойства и классы на основе существующих и с наследованием их свойств.
Также можно задавать новые свойства, в том числе и существующим классам. При этом все свойства можно разделить на обязательные и возможные. Все обязательные свойства необходимо указывать при создании объекта. Например объект «пользователь» обязательно должен иметь общее имя en (common name), пароль и SamAccountName (имя, используемое для обратной совместимости с предыдущими версиями).
Возможные свойства можно и не указывать. Они лишь выполняют вспомогательные функции и могут быть полезны, например, для администраторов или для других пользователей. Проиллюстрируем сказанное на примере приложения по учету кадров. Всех сотрудников предприятия можно условно разделить на две группы: постоянные и временные. Для постоянных сотрудников целесообразно создать новый класс FullTimeEmp. В качестве возможных свойств этого класса можно добавить в схему зарплату и семейное положение. При этом права на чтение и изменение этих свойств будут иметь только сотрудники отдела кадров, а на чтение — лишь сам сотрудник. Администраторы сети также не имеют прав доступа к этим сведениям. Понятно, что такая свобода модификации и наращивания каталога должна опираться на мощные механизмы хранения и поиска информации. В Active Directory таким механизмом хранения служит ESE (Extensible Storage Engine) — улучшенная версия Jet-базы данных, использующейся в Microsoft Exchange версий 4 и 5.х2. В новой базе может содержаться до 17 терабайт данных, до 10 миллионов объектов.
Рисунок 7. Пример модификации схемы
Еще одна особенность ESE — там хранятся только реально используемые значения свойств. Например, для объекта user определено по умолчанию порядка 50 свойств. Но если Вы описали только 4 (имя, фамилию, общее имя и пароль), то место для хранения будет отведено только для этих атрибутов. По мере описания других атрибутов место для них будет выделяться динамически.
ESE позволяет хранить свойства, имеющие несколько значений, например, несколько телефонных номеров одного пользователя. При этом совсем не надо создавать атрибуты каждого телефонного номера.
Система именований
Одна из задач службы каталогов Active Directory — обеспечить однотипный взгляд на сети независимо от того, сколько и каких пространств имен и каталогов в них используется. Вы можете включать будущих версиях Microsoft Exchange механизм базы данных будет таким же, как и в Active Directory. AD, а затем организовывать каталоги, независимо от их расположения и использующих их операционных систем.
Другая важная особенность Active Directory — избыточная поддержка нескольких стандартных систем именований. В качестве собственной системы имен в AD применяется DNS (Domain Name System); в то же время она может использовать LDAP или HTTP для обмена информацией с приложениями или иными каталогами.
Поддержка DNS
В Active Directory объединены лучшие возможности Х.500 и сервиса обнаружения DNS . DNS — сервис, наиболее часто используемый как в Интернете, так и в интрасетях. Он с успехом применяется для преобразования имени в IP-адрес как в масштабах Интернета, так и в небольших сетях.
Рисунок 8. 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.
Поддержка имен стандартных форматов
Форма именований, принятая в каталоге, влияет, как на пользователей, так и на приложения. Например, если Вы желаете отыскать объект в каталоге, то должны точно указать имя свойства, применяемого в качестве критерия поиска.
В различных стандартах (как де-факто, так и де-юре) используются различные форматы имен. Многие из них поддерживаются в 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, U=Division, 0=MyCorp,C=RU
• Имена UNC. В Active Directory поддерживается также и соглашение об универсальном именовании, которое традиционно используется в сетях Windows NT для ссылок на совместно используемые ресурсы: тома, принтеры и файлы. Вы можете обратиться к файлу, опубликованному в Active Directory, например, так:
\\MyServer.MyCorp,Ru\Division.Finance.Russian,MyVolume\WordDocs\YearBudget.doc
Смежные и раздельные пространства имен
В каталоге 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. Хорошо видно, что пространства имен разделены.
Рисунок 9. Пример леса
Под-домены в каждом из деревьев принадлежат к смежному пространству имен. Например LDAP-имя для российского домена внутри Microsoft могло бы выглядеть как DC=russia,DC=microsoft,DC=COM,o=Internet.
Концепция смежных деревьев в лесу позволяет понять многие механизмы: как осуществляется поиск в лесу или в поддеревьях, почему объекты безопасности остаются действительными в рамках леса и др. Можно формировать виртуальные команды пользователей, находящихся в разных деревьях леса, а также включать в лес любое дерево. Последнее свойство используется, например, при слиянии предприятий или начальном разворачивании сети.
Для обеспечения работы дерева или леса необходимы метаданные. Они хранятся в двух контейнерах (конфигурации и схемы), в каждом из которых своя система имен и топология тиражирования. В конфигурационном контейнере содержится информация, связующая для деревьев в лесу: о доступных контроллерах домена, узлах и вообще всех контроллерах домена. При добавлении в домен нового контроллера конфигурационная информация обновляется и тиражируется.
Управление деревом и лесом
Итак, деревья и лес - это объекты Active Directory.
Как и любыми, объектами службы каталогов необходимо управлять. Представьте себе небольшую фирму, организовавшую деревья и леса Active Directory в соответствии со своей структурой. Более чем очевидно, что это нельзя сделать раз и навсегда. Предприятие может расти,его структура — перестраиваться, отделы и подразделения — исчезать или создаваться заново. В соответствии с этими изменениями надо будет модифицировать и структуру сети, и такие возможности в Active Directory предусмотрены. К операциям реструктуризации и переименования объектов в каталоге относятся:
• простое добавление доменов;
• простое удаление доменов;
• переименование доменов;
• переразмещение деревьев доменов и лесов;
• слияние деревьев в лес.
Добавление домена — самая простая из перечисленных операций. Домен можно подключить к дереву во время установки контроллера домена. Все что для этого нужно сделать — указать существующий в Active Directory домен в качестве родительского. При этом между доменами будут установлены доверительные отношения Kerberos, что позволит новому домену присоединиться к дереву.
Удаление домена не является удалением в полном смысле этого слова — домен просто исключается из дерева. Проделать эту операцию можно в любое время. Но предварительно следует убедиться, что у исключаемого домена нет дочерних доменов — иначе доверительные отношения дочернего домена окажутся разорванными, и он также будет исключен из дерева.
Любой объект в каталоге Active Directory может иметь несколько имен:
общее, относительное и т. п. Единственным всегда неизменным идентификатором объекта является Глобальный уникальный идентификатор GU1D (Globally Unique Identifier). GUID - это многозначное число, создаваемое контроллерами домена. Алгоритм создания идентификатора не допускает дублирования. Именно этот никогда не изменяемый идентификатор может использоваться в Active Directory для того, чтобы свободно переименовывать домены, как и любые объекты.
GUID также позволяет перемещать домены в дереве или в лесу. Во время частичного тиражирования в глобальный каталог заносится подмножество свойств объекта. В это подмножество входит и GUID. Если объект перемещен, то глобальный каталог может использовать GUID для поиска объекта и его отличительного имени на основе нового относительного ID и LDAP-пути к новому местоположению.
В 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.
Определение схемы и ее использование.
Организация DNS службы.
Процедура добавление домена.
Процедура удаления домена.
Пространство имен.
Как происходит тиражирование внутри узла и межу узлами?
Характеристики дерева доменов.
В каких случаях происходит тиражирование?