Реферат Средства Active Directory
Работа добавлена на сайт bukvasha.net: 2015-10-28Поможем написать учебную работу
Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
от 25%
Подписываем
договор
КОНТРОЛЬНАЯ РАБОТА
ПО ДИСЦИПЛИНЕ: Операционные системы, среды и оболочки.
НА ТЕМУ: Средства 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-именем.) Указывая имя [email protected],
можно в равной степени рассматривать его и как почтовый адрес в
Интернете, и как имя пользователя в домене 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
Ключ System\CurrentControlSet\Services\NTDS\Parameters
Имя 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
