КОНТРОЛЬНАЯ РАБОТА
ПО ДИСЦИПЛИНЕ: Операционные системы, среды и оболочки.
НА ТЕМУ: Средства Active Directory
Что такое
Active
Directory
Служба каталогов Active Directory (AD) - сервис, интегрированный с Windows NT Server. Она обеспечивает иерархический вид сети, наращиваемость и расширяемость, а также функции распределенной безопасности. Эта служба легко интегрируется с Интернетом, позволяет использовать простые и интуитивно понятные имена объектов, пригодна для использования в организациях любого размера и легко масштабируется. Доступ к ней возможен с помощью таких знакомых инструментов, как программа просмотра ресурсов Интернета.
AD не только позволяет выполнять различные административные задачи, но и является поставщиком различных услуг в системе. На приведенном ниже рисунке схематично изображены основные функции службы каталогов.
В Active Directory концепция пространства имен Интернета объединена с системными службами каталогов, что дает возможность единым образом управлять различными пространствами имен в гетерогенных
средах корпоративных сетей. В качестве основного в AD используется легкий протокол доступа к каталогу LDAP (lightweight directory access protocol), позволяющий действовать за рамками операционной систе- мы, объединяя различные пространства имен. Active Directory может включать в себя каталоги других приложений или сетевых операцион- ных систем, а также управлять ими, что значительно снижает нагрузку на администраторов и накладные расходы.
Каталог - поставщик услуг в системе
Active Directory не является каталогом Х.500, как иногда считают. Она использует лишь информационную модель Х.500 (без избыточности, присущей последнему), а в качестве протокола доступа - LDAP. В ре- зультате достигается так необходимая в гетерогенных системах высо- кая степень взаимодействия.
LDAP - стандартный протокол доступа к каталогам (RFC1777) - был разработан как альтернатива протоколу доступа Х.500. В Active Directory поддерживаются как LDAP v2, так и LDAP v3.
HTTP - стандартный протокол для отображения страниц Web. Active Directory дает возможность просмотреть любой объект в виде страни- цы Web. Расширения Internet Information Server, поставляемые совмес- тно со службой каталога, преобразуют запросы к объектам каталога в страницы HTML.
Active Directory позволяет централизовано администрировать все ре- сурсы, любые произвольные объекты и сервисы: файлы, периферийные устройства, базы данных, подключения к Web, учетные записи и др. В качестве поискового сервиса используется DNS. Все объекты внутри домена объединяются в организационные единицы (OU), составляю- щие иерархичные структуры. В свою очередь, домены могут объеди- няться в деревья.
Администрирование упростилось по сравнению с предыдущими вер- сиями: больше нет первичного и резервных контроллеров домена. Все контроллеры доменов, используемые службой каталогов, равноправны. Изменения можно вносить на любом контроллере, а на остальные они будут тиражироваться автоматически.
Еще одна особенность Active Directory - поддержка нескольких хра- нилищ, в каждом из которых может находиться до 10 миллионов объек- тов. Понятно, что при таких возможностях эта служба каталогов пре- красно проявляет себя как в малых сетях, так и в больших системах.
Архитектура Active Directory
Основная структурная единица Active Directory - дерево доменов, свя- занных доверительными отношениями друг с другом. Внутри каждого домена может располагаться иерархия организационных единиц (OU). Иерархия OU внутри одного домена никак не связана с иерархией OU в других доменах. Наоборот, они полностью независимы.
Такая двухъярусная иерархичная структура предоставляет высокую сте- пень свободы в администрировании деревьев доменов. Например, всем деревом доменов целиком может управлять центральная служба инфор- мационных технологий (ИТ), а во всех доменах будут созданы свои собственные организационные единицы, где учтены как работники, ответственные за локальную поддержку на местах, так и ресурсы, обес- печивающие эту поддержку.
В каждом отдельном домене могут быть созданы дополнительные OU для выполнения конкретных задач. Так в домене головного офиса - OU отдела кадров и бухгалтерии, в филиалах - OU торговых представи- тельств. При этом административные права для каждой из этих OU могут делегироваться центральной службой ИТ сотрудникам упомяну- тых групп. Последние же, будучи наделены административными пол- номочиями только в рамках своих OU, никак не смогут помешать службе ИТ выполнять глобальное администрирование или вмешаться в де- ятельность другой OU.
Архитектура Active Directory
Такая гибкость позволяет организовать каталог в точном соответствии со структурой Вашего предприятия. Причем, возможно отразить как централизованную, так и децентрализованную, а также некоторую сме- шанную модель управления предприятием. Например, дерево доменов может быть организовано по централизованной модели, а OU внутри доменов - по децентрализованной.
Как уже упоминалось, внутри каждого домена - своя политика безо- пасности (подробнее об этом - в главе 2). Этой политикой определя- ются, в частности, требования к паролям, время жизни билетов Кег- beros, блокировки учетных записей и т. д. При создании учетной запи- си в домене для нее генерируется идентификатор безопасности (SID), частью которого является идентификатор домена, выдавшего SID. Это позволяет легко определять, какому домену принадлежит пользователь или группа и каковы их права доступа к ресурсам. Таким образом, мож- но говорить о физических границах безопасности домена, в рамках которых и выполняется его администрирование.
Организационные единицы являются контейнерами, в которых могут содержаться другие организационные единицы или объекты (пользо- ватели, группы, принтеры или ресурсы распределенной файловой си- стемы). Разрешение создавать объекты или изменять их атрибуты мо- жет быть выдано отдельным пользователям или группам, что позволя- ет более четко разделять административные полномочия.
Использование схемы
Определение схемы, данное при первом ознакомлении с этим терми- ном, несколько расплывчато и, возможно, не дает общего понимания ее назначения. В схеме задано, какие объекты и с какими свойствами допустимы в каталоге. Во время установки Active Directory на первый контроллер доменов в лесу, служба каталогов по умолчанию создает схему, где содержатся все объекты и заданы свойства, необходимые для нормального функционирования службы каталогов. Предусматривает- ся также тиражирование каталога на все контроллеры домена, которые будут включены в лес позднее.
Каталог содержит необходимую информацию о пользователях и объек- тах данной организации. Такие свойства Active Directory, как отказоус- тойчивость и расширяемость, позволяют использовать этот сервис в различных приложениях, например, по учету кадров. Стандартно в Active Directory уже определены такие атрибуты пользователя, как его имя, фамилия, номера телефонов, название офиса, домашний адрес. Но если понадобятся такие сведения, как зарплата сотрудника, его трудо- вой стаж, медицинская страховка, сведения о поощрениях и т. п,, то эти параметры можно задать дополнительно. Active Directory позволяет 'наращивать' схему, добавлять в нее новые свойства и классы на осно- ве существующих и с наследованием их свойств.
Также можно задавать новые свойства, в том числе и существующим классам. При этом все свойства можно разделить на обязательные
и возможные.
Все обязательные свойства необходимо указывать при со- здании объекта. Например объект 'пользователь' обязательно должен иметь общее имя en (common name), пароль и SamAccountName (имя, используемое для обратной совместимости с предыдущими версиями).
Возможные свойства можно и не указывать. Они лишь выполняют вспо- могательные функции и могут быть полезны, например, для админис- траторов или для других пользователей. Проиллюстрируем сказанное на примере приложения по учету кадров. Всех сотрудников предприя- тия можно условно разделить на две группы: постоянные и временные. Для постоянных сотрудников целесообразно создать новый класс Full- TimeEmp. В качестве возможных свойств этого класса можно добавить в схему зарплату и семейное положение. При этом права на чтение и изменение этих свойств будут иметь только сотрудники отдела кадров, а на чтение - лишь сам сотрудник. Администраторы сети также не имеют прав доступа к этим сведениям.
Понятно, что такая свобода модификации и наращивания каталога должна опираться на мощные механизмы хранения и поиска инфор- мации. В Active Directory таким механизмом хранения служит ESE (Exten- sible Storage Engine) - улучшенная версия Jet-базы данных, использую-
щейся в Microsoft Exchange версий 4 и 5.х2. В новой базе может содер- жаться до 17 терабайт данных, до 10 миллионов объектов.
Пример модификации схемы
Еще одна особенность ESE - там хранятся только реально используе- мые значения свойств. Например, для объекта user определено по умол- чанию порядка 50 свойств. Но если Вы описали только 4 (имя, фами- лию, общее имя и пароль), то место для хранения будет отведено толь- ко для этих атрибутов. По мере описания других атрибутов место для них будет выделяться динамически.
ESE позволяет хранить свойства, имеющие несколько значений, напри- мер, несколько телефонных номеров одного пользователя. При этом совсем не надо создавать атрибуты каждого телефонного номера.
Подробнее о классах и атрибутах схемы, а также о том, как вносить в нее изменения, мы поговорим в одном из следующих разделов этой главы.
Система именований
Одна из задач службы каталогов 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). КСС восстанавливает топологию ти- ражирования в случае нарушения.
Концепция поиска ближайшего ресурса или контроллера домена по- зволяет сократить трафик в низкоскоростных частях глобальных сетей. Для поиска ближайших ресурсов или контроллеров домена клиенты могут использовать информацию об узле. Начиная вход в сеть, клиент получает от контроллера домена имя узла, к которому принадлежит, имя узла к которому относится контроллер домена, а также информа- цию о том, является ли данный контроллер домена ближайшим к кли- енту. Если это не ближайший контроллер, то клиент может обратиться к контроллеру домена в собственном узле и в дальнейшем работать с ним, как с ближайшим контроллером. Так как данная информация со- храняется в реестре, клиент может ее использовать при следующем входе в сеть.
Если пользователь перемещается со своей рабочей станцией в новое место, то при входе в сеть станция обращается к прежнему контролле- ру домена. Только в этом случае он уже не является ближайшим, и со- общает клиенту информацию о ближайшем узле. Эта информация мо- жет быть использована клиентом для доступа к 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.
В поле появившегося диалогового окна укажите имя нового узла, включаемого в топологию тиражирования.
Схема: классы, атрибуты и их модификация
Для того, чтобы добраться до схемы, загрузите соответствующий сле- пок ММС: в меню консоли управления выберите Console
и дайте ко- манду Add/Remove Snap-In.
В появившемся окне щелкните Add
и в списке доступных слепков укажите Schema manager.
Появится диало- говое окно Microsoft Management Console.
Окно ММС с загруженным слепком Schema Manager
В правой части окна перечислены все классы ^атрибуты схемы. Каж- дый класс в схеме представлен объектом, его определяющим. Объекты являются экземплярами класса Class Schema.
Каждый атрибут в схеме также представлен объектом, определяющим этот атрибут. Объекты являются экземплярами класса Attribute Schema и могут иметь атрибуты, перечисленные в Приложении В. Атрибуты могут содержать данные, тип которых определяется синтаксисом.
Для каждого атрибута возможен только один синтаксис, например, Integer,
String, BOOL. Синтаксисы в Active Directory определены Microsoft и не могут быть изменены, также невозможно добавлять новые. Синтакси- сы не представлены никакими объектами в каталоге. Создавая новый атрибут, необходимо определить его синтаксис.
Некоторые характеристики объектов, определяющих классы, содержат- ся в парных атрибутах. Значения одного атрибута пары может быть изменено администратором, а другого - нет. Если имя атрибута начи- нается со слова System, то администраторы не могут его изменять. Это сделано с целью защиты системы и обеспечения ее работоспособнос- ти. Любопытно отметить, что это правило распространяется и на те классы, которые создали Вы сами. При создании класса можно назна- чить начальные значения атрибутов, но дальнейшая модификация си- стемных атрибутов невозможна.
Прежде чем добавлять или изменять классы, необходимо выполнить две процедуры: во-первых, внести в реестр дополнительное значение, от- сутствующее там по умолчанию; а во-вторых, - убедиться, что Ваш компьютер будет распознан остальными контроллерами домена как единственный, на котором допускается модификация схемы.
Итак, в реестре надо выполнить следующее добавление:
Ветвь HKEY_LOCAL_MACHINE
Ключ SystemCurrentControlSetServicesNTDSParameters Имя Schema Update Allowed Тип DWORD Значение Любое целое положительное число
Целостность каталога требует, чтобы изменения вносились только на одном компьютере в каждый момент времени с последующим тиражи- рованием их на другие контроллеры домена. В противном случае воз- можен конфликт между изменениями. Для предотвращения подобных конфликтов вводится понятие мастер схемы,
обозначающее именно тот контроллер, на котором, и только на котором, возможна модифи- кация схемы. В принципе, таковым может быть назначен любой кон- троллер в домене, но по умолчанию мастером схемы становится пер- вый установленный контроллер домена. Процесс определения того, какой из компьютеров может выступать в этой роли называется опера- цией единственного плавающего мастера (floating single master opera- tion).
Текущий мастер схемы отличается значением атрибута FSMO- Role-Owner для контейнера схемы (CN=schema, CN=configu ration, DC=...).
Если Ваш компьютер - единственный контроллер домена, то масте- ром схемы является именно он. Если в домене несколько контролле- ров, Вы можете принудительно потребовать от нужного контроллера стать мастером. Для этого к корневому DSE (объект с пустым DN) до- бавьте атрибут becomeSchemaMaster равный 1. Сервер пошлет текущему мастеру запрос на смену мастера и тот изменит атрибут FSMO-Role- Owner на имя контроллера, запросившего эту операцию, после чего
передаст ему новое значение атрибута, а также перешлет на новый мастер сделанные ранее, и, возможно, оставшиеся незамеченными, из- менения. Тот примет эти изменения и станет новым мастером схемы.
Active Directory поддерживает кэш схемы, повышающий быстродей- ствие приложений, часто обращающихся к каталогу. Кэш схемы явля- ется представлением классов и атрибутов схемы в оперативной памя- ти компьютера. Кэш загружается в память во время загрузки операци- онной системы. При внесении изменений в схему кэш, спустя некото- рое время, автоматически обновляется.
Заключение
Служба каталогов Active Directory, сочетающая в себе открытые стан- дарты, простоту администрирования, глобальный каталог, возможность наращивания, средства тиражирования, распределенную систему безо- пасности и полную обратную совместимость с предыдущей службой каталогов - идеальная платформа для построения сетей для крупных предприятий и организаций, а также гетерогенных сетей.
Эта служба каталогов, использующая лучшие из стандартов имен DNS и Х.500, LDAP, иные протоколы и богатый набор API, предоставляет гро- мадные возможности совместимости с другими системами. Active Direc- tory позволяет из одной точки управлять всеми ресурсами сети: файла- ми, периферийными устройствами, подключениями к хостам, базами данных, доступом к Web, пользователями, любыми произвольными объ- ектами, сервисами и сетевыми ресурсами. Поддерживаемый в ней иерархичный взгляд на систему, удобные средства администрирования и мощные механизмы поиска позволяют значительно снизить админи- стративные затраты.
Таким образом, можно сделать вывод: появление Active Directory сни- мет последние ограничения на использование Windows NT в больших организационных структурах.
Список
использованной литературы:
1. Безопасность сети на основе Microsoft® Windows 2000. Учебный курс MSCE.2001//Москва//«Русская Редакция».
2. В. Олифер Н. Олифер. Сетевые операционные системы.2003//С. Петербург//Питер.
3. Подход профессионала Автор: Зубанов Ф. В. Год издания: 01.01.2002
4. Грег Тодд. Windows 2000 Datacenter Server //по материалам сайта http: www.citforum.ru
5. http://www.5ballov.ru
6. http://www.xserver.ru