Учебная работа. Реферат: Средства Active Directory

Учебная работа. Реферат: Средства Active Directory

КОНТРОЛЬНАЯ РАБОТА

ПО (то есть программное обеспечение — комплект программ для компьютеров и вычислительных устройств) ДИСЦИПЛИНЕ: Операционные системы, среды и оболочки.

НА ТЕМУ: Средства 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 снутри 1-го домена никак не связана с иерархией OU
в остальных доменах. Напротив, они вполне независимы.

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

В каждом отдельно взятом домене могут быть сделаны доп OU
для выполнения определенных задач. Так в домене головного кабинета — OU
отдела кадров и бухгалтерии, в филиалах — OU торговых представи-
тельств. При всем этом административные права для каждой из этих OU
могут делегироваться центральной службой ИТ сотрудникам упомяну-
тых групп. Крайние же, будучи наделены административными пол-
номочиями лишь в рамках собственных OU, никак не сумеют помешать службе ИТ делать глобальное администрирование либо вмешаться в де-
ятельность иной OU.

Архитектура Active Directory

Таковая упругость дозволяет организовать каталог в четком согласовании
со структурой Вашего компании. При этом, может быть отразить как
централизованную, так и децентрализованную, также некую сме-
шанную модель управления предприятием. к примеру, дерево доменов
быть может скооперировано по централизованной модели, а OU снутри
доменов — по децентрализованной.

Как уже упоминалось, снутри всякого домена — своя Политика безо-
пасности (подробнее о этом — в главе 2). Данной политикой определя-
ются, а именно, требования к паролям, время жизни билетов Кег-
beros, блокировки учетных записей и т. д. При разработке учетной запи-
си в домене для нее генерируется идентификатор сохранности (SID),
частью которого является идентификатор домена, выдавшего SID. Это
дозволяет просто определять, какому домену принадлежит юзер
либо группа и каковы их права доступа к ресурсам. Таковым образом, мож-
но гласить о физических границах сохранности домена, в рамках
которых и производится его администрирование.

Организационные единицы являются контейнерами, в каких могут
содержаться остальные организационные единицы либо объекты (пользо-
ватели, группы, принтеры либо ресурсы распределенной файловой си-
стемы). Разрешение создавать объекты либо изменять их атрибуты мо-
жет быть выдано отдельным юзерам либо группам, что позволя-
ет наиболее верно делить административные возможности.

Внедрение схемы

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

каталог содержит нужную информацию о юзерах и объек-
тах данной организации. Такие характеристики 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 дозволяет хранить характеристики, имеющие несколько значений, напри-
мер, несколько телефонных номеров 1-го юзера. При всем этом
совершенно не нужно создавать атрибуты всякого телефонного номера.

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

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

одна из задач службы каталогов 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 на контроллере домена становится равным значению,
приобретенному от напарника.

Если данные 1-го и такого же объекта поменялись сходу на несколь-
ких контроллерах домена, то обновление производится последующим
образом.

По номеру версии.
У всякого характеристики собственный номер версии. С по-
мощью этого номера определяется ‘более животрепещущее’, другими словами
имеющее больший номер версии, свойство. Это не постоянно верное
решение, но оно дозволяет согласовывать версии без дополни-
тельных переговоров с партнером по тиражированию и гарантиру-
ет идентичность данных на всех контроллерах доменов.

По временной отметке.
Если характеристики имеют однообразный номер
версии, то проверяется временная отметка, создаваемая вкупе с но-
мером версии при модификации параметров. При всем этом предполагается,

что все контроллеры домена синхронизованы по времени. Предпоч-
тение отдается версии, сделанной позже. И снова же, это не постоянно
правильно, но лучше обслуживать юзеров, чем заниматься дли-
тельными переговорами относительно того, кто ‘главнее’.

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

Давайте проиллюстрируем все произнесенное на примере. Допустим, что два
админа на различных контроллерах домена заносят конфигурации в
характеристики группы AcctUsers. Один из их предоставил Право модифика-
ции каталога FinRus, а 2-ой — Право модификации каталога FinAd-
min, но сделал это на минутку позднее первого. При согласовании версий
на 3-ем контроллере домена будет найдено, что номера версий
совпадают, а время модификации на втором контроллере — наиболее позд-
нее. Потому в расчет будет принято лишь изменение, изготовленное вто-
рым админом.

Замечание.
Все операции согласования заносятся в журнальчик, так что
админы могут по мере необходимости вернуть прежние
значения.

Узлы и домены

Теория узлов (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

Сейчас, имея общее информация обо всех объектах
системы: дисках, устройствах, сетевых ресурсах, юзерах, груп-
пах, доменах и т. п. Доступ к сиим объектам разбит на функциональ-
ные группы, для которых сделаны слепки,
применяемые консолью уп-
равления ММС (Microsoft Management Console). Тщательно ознакомить-
ся с внедрением всякого из слепков можно и в главе б и остальных
главах, посвященных отдельным способностям операционной систе-
мы. А на данный момент разглядим только самые общие способности доступа к
каталогу.

Управление узлами

Конфигурируя узлы, Вы управляете топологией тиражирования. Для
доступа к инфы о узлах нужно загрузить в ММС слепок
Microsoft Site Replication Manager. Соответственное окно воспримет вид,
изображенный на рисунке. Загружая этот слепок в первый раз, Вы увидите
один узел, обозначенный во время установки операционной системы и имя
собственного собственного компа в этом узле.

Окно

Microsoft Management Console — Microsoft Site Replication
Manager

Для описания узла нужно обрисовать входящие в него сабсети. Опи-
сание субсетей производится в формате www, xxx. yyy. zzz/mm, где 1-ая
часть (до косой черты) — адресок сабсети, 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 и не
могут быть изменены, также нереально добавлять новейшие. Синтакси-
сы не представлены никакими объектами в каталоге. Создавая новейший
атрибут, нужно найти его синтаксис.

Некие свойства объектов, определяющих классы, содержат-
ся в парных атрибутах. значения 1-го атрибута пары быть может
изменено админом, а другого — нет. Если имя атрибута начи-
нается со слова System, то админы не могут его изменять. Это
изготовлено с целью защиты системы и обеспечения ее работоспособнос-
ти. Интересно отметить, что это правило распространяется и на те
классы, которые сделали Вы сами. При разработке класса можно назна-
чить исходные значения атрибутов, но предстоящая модификация си-
стемных атрибутов невозможна.

До этого чем добавлять либо изменять классы, нужно выполнить две
процедуры: во-1-х, внести в реестр доп сутствующее там по дефлоту; а во-2-х, — убедиться, что Ваш
комп будет распознан остальными контроллерами домена как
единственный, на котором допускается модификация схемы.

Итак, в реестре нужно выполнить последующее добавление:

Ветвь 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

]]>