Книги, научные публикации
Pages: | 1 | ... | 5 | 6 | 7 | 8 | 9 | ... | 18 | Distributed Systems Guide Microsoft Windows 2000 Server Microsoft Press Распределенные системы Книга 1 Microsof Windows 2000 ...
-- [ Страница 7 ] --Входящее подключение от ОС к DC1_A (поддерживаемое объектом подключения, сгенерированным Контроллер ОС2ДА на DC1A) :
? Входящее подключение..
:
ХсЙГфсншер 0И1ДА отОС1_АкОС1_В Основной сервер-шшадзм (поддерживаемое объектом подключения, сгенерированным на DC1_B) Сайт А Сайт В Рис. 6-8. Два сайта н два сервера-плацдарма с входящими подключениями друг от друга Если основной сервер-плацдарм в сайте А терпит сбой, сервер-плацдарм в сайте В теряет свое входящее подключение от отказавшего сервера и, таким образом, теря ет связь с сайтом. Если поручить серверу заменить отказавший сервер-плацдарм в Репликация Active Directory ГЛАВА 6 сайте А, новый сервер-плацдарм создает только входящие подключения. Это изме нение не удастся реплицировать в сайт В, так как на сернере-плацдарме в сайте В нет входящего подключения. На рис. 6-9 изображено подключение, созданное пос ле добавления нового сервера-плацдарма в сайт А.
Входящее подключение от DC1_B к DC2_A (поддерживаемое обьектом подключения, сгенерированным на DC2_A) Коитрвляер &С2_А Новый основной еервер-шаадарл Ксштрошер DC1_f DИ1_A Отказавший сер&ер-плацдарм - Сервер-плацдарм Нет входящих подключений Сайт А O T D C 2 А к DC1_B Сайт В Рис. 6-9. Новое входящее подключение от существующего сервера без входящего подключения от нового сервера-плацдарма Пока не создан новый сервер-плацдарм сайта А на контроллере домена в сайте В, невозможно никакое входящее подключение от сайта А к сайту В, хотя в сайте А теперь есть сервер-плацдарм. Причина в том, что КСС создает только входящие соединения и не обладает сведениями о новом сервере.
На рис. 6-10 новый сервер-плацдарм для сайта А добавлен па контроллер домена в сайте В. Далее описана последовательность операций, - Контроллер DC2_/i добавлен на DC2J!
в качестве основного сервера-плацдарма Репликация сведений в сайте А Двустороннее подключение. о новом сервере-плацдарме обеспечивающее сайта А на ОС1_В репликацию между сайтами Новый основной Входящее подключение и~ I Контроллео DC2_ ат DC -A K DC1-B сервер-плацдарм ОС2_А (поддерживается обьектом Отказавший подключения, Сервер-плацдарм DC1_S сервер-плацдарм DC1.A сгенерированным на DC1_B) Сайт А Сайт В Рис. 6-10. Двустороннее подключение между сайтами после добавления нового сервера-плацдарма сайта А в сайте В 1. Администратор в сайте В входит на контроллер дометта и добавляет DC2_A в качестве основного сервера-плацдарма. Для этого он выбирает ПС2А в контей нере Servers сайта А в консоли Active Directory Sites and Services и добавляет его к списку основных серверов-плацдармов для соответствующего транспорта.
Служба каталогов Active Directory 274 ЧАСТЬ 2. Назначение сервера-плацдарма реплицируется (как изменение в разделе конфи гурации) на все контроллеры домена в сайте В, в том числе на сервер-плацдарм DC1_B.
3. Сервер-плацдарм DC1_B генерирует объект входящего подключения от DC2_A, которое завершает создание двустороннего маршрута репликации между серве рами-плацдармами в сайтах А и В. С этого момента между этими двумя серве рами-плацдармами возможна полноценная репликация.
Отказ основного сервера-плацдарма из-за неправильной конфигурации Если после конфигурирования основных серверов-плацдармов ни один из них не способен реплицировать соответствующий раздел каталога, КСС регистрирует в журнале ошибку конфигурации. (Домен с серверами в сайте не представлен серве ром-плацдармом.) Далее КСС пытается найти альтернативный сервер-плацдарм, как будто не было никаких назначений основных серверов-плацдармов.
Мосты связей сайтов Объект моста связей сайтов представляет набор связей сайтов с одним протоколом обмена. Обычно межсайтовый мост соответствует маршрутизатору (или набору маршрутизаторов) в IP-сети.
Примечание Если для какого-либо протокола моста отсутствует сервер-плацдарм, создание маршрутов невозможно.
Но умолчанию все создаваемые связи сайтов объединены мостами (то есть явля ются транзитивными). Все связи сайтов для конкретного протокола явно принад лежат соответствующему мосту. Поэтому для полностью связной IP-сети настраи вать какой-либо мост не надо. На рис. 6-11 иллюстрируется связь трех сайтов по средством двух связей сайтов и моста, обеспечивающего взаимодействие между двумя сайтами, не обладающими явными связями.
Мост связей сайтов SM-SA [Связь сайтов SM| *лf*л Связь сайтов ЗАВ^^Щ Контрвгшз-р-1 Контроллер Сайт Seattle Сайт Atlanta Контроллер Сайт Milan Рис. 6-11. Мост связей сайтов, связывающий сайты Milan и Atlanta Если IP-сеть не связна, можно отключить параметр Bridge all site links (Устано вить мост для всех связей сайтов) для IP-протокола [на вкладке General (Общие) Репликация Active Directory ГЛАВА 6 в окне свойств объекта протокола IP или SMTP]. В этом случае все межсайтовьте IP-подключения считаются нетранзитивными, и мосты разрешается настроит], в соответствии с реальной моделью маршрутов сети.
Управление мостами связей сайтов Объект моста создается для конкретного протокола с указанием для него двух и более связей сайтов.
Чтобы объяснить значение межсайтового моста, рассмотрим пример:
Х стоимость связи SM между сайтами Seattle и Milan по IP 4;
т стоимость связи SA между сайтами Seattle и Atlanta Ч 3;
Х между сайтами Milan и Atlanta отсутствует связь сайтов;
Х мост SM-SA построен на связях сайтов SA и SM.
Здесь наличие моста SMЧSA предполагает, что стоимость пересылки сообщений от сайта Milan к еайту Atlanta составляет 4+3=7.
Каждая связь сайтов в мосте должна иметь по крайней мере один общий сайт с дру гой связью сайтов, иначе не удастся вычислить стоимость межсайтовых связей в мосте. Например, в системе, где имеется четыре сайта W, X, Y и Z и где связь WX соединяет W и X, а связь YZ Ч Y и Z, бессмысленно создавать мост, соединяющий WX и YZ.
Раздельные мосты (даже для одного протокола) независимы. Для иллюстрации это го добавим следующие объекты в наш пример:
Х подключение DA, соединяющее сайты Detroit и Atlanta и имеющее стоимость 2;
Х мост DA-SA, объединяющий связи DA и SA.
Наличие дополнительного моста означает, что стоимость пересылки IP-сообщения от сайта Seattle к сайту Detroit равна 2+3=5, но это не означает, что стоимость пе ресылки IP-сообщений от сайта Detroit к сайту Milan будет равна 2+3+4=9. Как правило, всегда используют один мост для моделирования всей IP-сети.
Производительность Любую сеть, описываемую комбинацией связей сайтов и мостов, с равным успехом можно описать одними связями сайтов. Преимущество в создании мостов Ч в зна чительном сокращении описания сети и облегчении ее обслуживания, так как от падает необходимость описывать все возможные пути между парами сайтов.
Однако при количестве сайтов, превышающем 200, во время работы КСС высокая нагрузка на процессор возникает каждые 15 минут. Установка параметра Bridge all site links (Установить мост для всех связей сайтов) позволяет создать единый мост для всей сети, при этом создаются дополнительные маршруты, которые следует обрабатывать. Их больше, чем в случае, когда мосты не применяются или приме няются выборочно. В частности, в соответствии с условиями указанными на рис, 6-': на производительность КСС влияют следующие факторы:
Х распознавание службой КСС явных связей между сайтами Atlanta и Seattle, Seattle и Milan;
Х при наличии моста служба КСС также должна рассчитывать неявные пути меж ду Milan и Atlanta как отдельный путь с комбинированной стоимостью;
Служба каталогов Active Directory 276 ЧАСТЬ Х межсайтовые связи между контроллерами одного домена по умолчанию транзи тивны без создания моста. При его наличии служба КСС должна вычислять транзитивные маршруты между сайтами;
Х межсайтовые мосты добавляют дополнительные возможности по подключению, но они обычно не пользуются из-за общей высокой стоимости. Службе КСС приходится затрачивать дополнительное время и вычислительные ресурсы для устранения излишних связей.
Таким образом, в больших сетях, где важно время обработки данных, можно улуч шить быстродействие путем отключения параметра Bridge all site links (Установить мост для всех связей сайтов) и создавать мосты связей сайтов, лишь когда их ис пользование выгодно. Если после этого задержки продолжаются, рекомендуется за менить мосты па несколько сайтов, объединенных явно заданными связями. Подроб нее о рекомендациях по масштабированию КСС Ч на Web-странице Web Resources по адресу ссылка Microsoft Knowledge Base (выполните поиск по ключевому слову Q2443(>8).
Репликация глобального каталога Сервер глобального каталога это контроллер домена, который хранит определен ные данные обо всех объектах леса. Глобальный каталог требуется для процесса вхо да в систему, поэтому лучше разместить в сайте по крайней мере один сервер гло бального каталога. Глобальный каталог хранит реплики всех разделов каталога леса Ч полные реплики разделов схемы и конфигурации, полную реплику раздела своего домена и частичные реплики остальных разделов каталога домена в лесу. Если у объекта-атрибута класса attributeSchema атрибут isMemberOfPartialAttributeSet равен TRUE, соответствующий атрибут реплицируется не только во все реплики данного, но и на все серверы глобального каталога.
На рис. 6-12 изображены логические разделы каталога базы данных Active Directory сервера глобального каталога. (Сама база данных, хранящаяся в файле Ntds.dit, в действительности не поделена на разделы.) Верхние три сегмента представляют разделы каталога, которые являются полными репликами, хранимыми на контрол лере домена. Три нижних сегмента представляют разделы каталога Ч частичные реплики, размещаемые в глобальном каталоге.
Schema (раздел схемы) Ч Configuration (раздел конфигурации) Ч Reskit.com (раздел домена) Ч Noam.Reskit.com (эаздея домена) Ч Avionics.com (раздел домена) Seville.avionics.corn (раздел домена) Рис. 6-12. База данных каталога на контроллере домена сервере глобального каталога Репликация Active Directory ГЛАВА 6 Серверы глобального каталога запрашивают обновления контроллеров-источников разделов всех доменов в лесу. Контроллер-источник может быть как обычным кон троллером домена, так и другим сервером глобального каталога.
На рис. 6-13 изображены связи партнеров репликации между разделами каталога на двух серверах глобального каталога, которые являются полномочными контрол лерами разных доменов. Как и все контроллеры домена, для репликации разделов схемы и конфигурации глобальный каталог применяет единую топологию, а для каждого раздела домена - отдельную топологию. Репликация между разделами каталога домена двунаправлена.
Один из серверов является полномочным для avionics.com, другой Ч для reskit.com.
Таким образом, контроллер домена avionics.com может быть источником репликации частичной реплики avionic.com на сервер глобального каталога е reskit.com, а кон троллер домена reskit.com Ч источником репликации частичной реплики reskit.com на сервер глобального каталога avionies.com. Стрелками показаны однонаправленные связи репликации от источников, храпящих полные реплики, к приемникам, облада ющим частичными репликами только для чтения. Ни один из контроллеров не является полномочным для домена noain.reskit.com, поэтому серверы глобального каталога выполняют репликацию этих частичных реплик между собой.
Домен Avonics.com Schema (раздел схемы) Ч - - HP p - Schema (раздел схемы) Configuration - _ <Р а з Д е л конфигурации) (раздел конфигурации) Ж^ -^ ~ Avionics.com _С~_--И КЧ Reskit.com (полная (полная реплика раздела домена) - 1 ^ ^,** ^зU-Ч -1 реплика раздела домена) ьй f^~ --Н ~~ N am - r eskit.com (частичная Noam.reskit.com (частичнаяЧ feЩ?n rf^^g^^ реплика раздела домена) ^ri^ ^^^^^^^Ш^ реплика раздела домена) Reskit.com (частичнаяЧ iLЩ- И ' f~~- Ч f ЧAvionics.com (частичная реплика раздела домена) ^ < Ч: >~~~^ реплика раздела домена) Seville.avionics.com (частичнаяЧ шйц ЧSeville.avionics.com (частичная реплика раздела домена) реплика раздела домена) Рис. 6-13. Связи разделов каталога между двумя серверами глобального каталога Репликация удаленных свойств Для удаления атрибута из глобального каталога необходимо присвоить атрибуту isMemberOfPartialAttributeSet значение FALSE. Атрибут будет удален после следу ющего цикла репликации.
Добавленные атрибуты При добавлении атрибута R набор атрибутов частичной реплики контроллер доме на должен реплицировать значения данного атрибута для каждого обьекта в час тичной реплике раздела каталога. Это достигается посредством полной синхрони зации между всеми подключениями репликации глобального каталога. Если воз можна синхронизация частичной реплики раздела каталога по RPC-подключению, контроллер домена попытается выполнить по данному подключению полную сип Служба каталогов Active Directory 278 ЧАСТЬ хронизатщю, не прибегая к другим подключениям. Если это удается, то созданный им вектор обновления данных позднее оптимизирует полную синхронизацию для других подключений.
Внимание! Добавляя атрибуты в набор атрибутов глобального каталога, следует соблюдать осторожность, поскольку это вызовет синхронизацию глобального ката лога на всех серверах глобального каталога в лесе. Хотя работа службы при этом и не прерывается, подобная репликация серьезно нагружает сеть, при этом нагрузка почти такая же, как при повышении статуса обычного контроллера домена до сер вера глобального каталога.
Репликация универсальных групп В универсальную группу (universal group) разрешается включать членов из любого домена леса, поэтому информация о членстве в универсальной группе хранится не на каждом контроллере домена (контроллеры домена хранят объекты только для своего домена), а только на серверах глобального каталога, где содержаться все объекты леса. А значит, только серверы глобального каталога способны хранить сведения о членстве в универсальной группе. По этой причине необходим сервер глобального каталога для входа в систему доменов, где есть универсальные груп пы, Во время входа глобальный каталог перечисляет универсальные группы и при соединяет сведения о членстве в таких группах к маркеру безопасности пользова теля. Другие типы групп (глобальные и локальные) не поддерживаются глобаль ным каталогом Ч на нем хранятся данные только об именах объектов групп. Под держка глобальных и локальных групп осуществляется контроллером домена. Это означает, что репликация членства в глобальных и локальных группах серверами глобального каталога не требуется, что значительно уменьшает трафик репликации.
Примеры сценариев межсайтовой репликации Далее описаны сценарии, в которых сочетаются разные способы использования межсайтовых связей и мостов.
Один домен, охватывающий несколько сайтов На рис. 6-14 показаны две связи сайтов: NYCЧSEA и SEA DFW. В данной среде стандартный режим транзитивных связей сайтов отключен, потому что сеть не пол ностью связна и нет моста связей сайтов. В итоге КСС создает подключение толь ко между NYC и SEA и между SEA и DFW. Так как все контроллеры домена распо ложены в одном домене и поддерживают полную копию раздела этого домена, реп ликация осуществляется через сайт-концентратор SEA без подключения между DFW и NYC. При изменениях в KYC эти изменения (во всей полноте) реплициру ются в SEA. Из-за того что контроллеры домена, хранящие полные реплики разде ла домена, реплицируют входящие изменения только из другой полной реплики до мена, SEA-DC-01 считается допустимым партнером для DFW-DC-01, и поэтому в свою очередь DFW-DC-01 транзитивпо реплицирует изменения NYC от SEA-DC-01, Справедливо также и обратное Ч изменения реплицируются от DFW к SEA, а за тем KNYC. Таким образом, изменения, происходящие в SEA, реплицируются пря мо на DFW и NYC, но для вступления их в силу репликация должна пройти дваж ды: сначала от DPW к NYC, а затем от NYC к DFW.
Репликация Active Directory ГЛАВА Контроллер SEA-OC-Q Связь сайтов SEA-DFW (сервер глобального кагалфга) Связь сайтов NYC-SEA Стоимость Ч 5 Член домена ResWteom Стоимость Ч Контроллер WC-DC-flf Контроллер DFW-DC-Q глобального, каталога) (сервер гло&альнзго каталога) Член домена Reskit.com Ч лея йвм-ена ResNit.com Рис. 6-14. Домен размещенный в трех сайтах, объединенных нетранзитивными связями Связи сайтов в среде двух доменов в трех сайтах На рис. 6-15 показано, что сайт SEA содержит контроллер домена noain.reskit.eoin, но в нем нет контроллера домена reskit.com. Как в этом случае изменения будут реплицироваться от NYC к DFW?
Если есть транзитивные связи сайтов или вручную созданы мосты NYЧSEA и SEAЧ DFW, KCC создаст объект-подключение для репликации между DEW и NYC. Если же ни одно из этих условий не выполняется, контроллер DEW-DC-01 никогда не получит изменений от NYC и наоборот, потому что в сайте SEA есть только один контроллер домена и он является контроллером другого домена (noam.reskit.com).
Если SEA-DC-01 не содержит реплику домена reskit.com, транзитивная репликация данных домена между NYC и DFW невозможна. Схема и данные о конфигурации могут реплицироваться между NYC и SEA и между SEA и DFW.
Контроллер SEA-OG-Ot ;
(не сервер глобального каталога) Связь сайтов SEA-DFW Связь сайтов NYC-SEA Член-домена Noam.reskit.com Стоимость Ч 5 Стоимость Ч Контроллер DFW-0G-0! Контроллер NYC-DC- {сервер глобального каталога);
{сервер глобального каталога) Член домена Чл$н даденз ^eskit.com Рис. 6-15. Связи сайтов в среде Двух доменов в трех сайтах Служба каталогов Active Directory 280 ЧАСТЬ На рис. 6-15 видно что, если SEA-DC-Q1 сконфигурировать как сервер глобально го каталога, с точки зрения репликации ничего не изменится, потому что этот кон троллер является полномочным для домена noam.reskit.com и должен содержать полный раздел каталога только этого домена. Как сервер глобального каталога, SEA-DC-01 должен содержать только частичную реплику домена reskit.com. В дан ном сценарии SEA-DC-01 будет получать изменения от NYC, но DFW-DC-01 не сможет выполнить репликацию от SEA-DC-01, потому что SEA-DC-01 содержит только частичную реплику раздела reskil.com.
Мост связей сайтов в среде двух доменов в разных сайтах На рис. 6-16 транзитивные связи сайтов отключены, а добавление моста содержа щего связи SEAЧDFW и NYCЧSEA изменит правила для возможных партнеров по репликации, которых может выбрать КС С. Мост предоставляет КСС маршрут от DFW к NYC, по которому создается объект подключения, позволяющий провести репликацию, даже если в SEA нет контроллера домена для того же раздела домена.
Изменения в схеме и конфигурации реплицируются по этим подключениям, Контроллер SEA-DC-Qt (не-серйер;
Шэбального каталога) "Чяв№-|ЕШеш Noam.reskit.com Связь сайтов SEA-DFW Связь сайтов NYC Ч SEA Стоимость Ч 5 Стоимость Ч Мост связей сайтов NYC-SEA-DFW Контроллер DFW-DC-01. Контроллер NYC-DG-Q (сервер глобального каталога) {сервер глобального';
кашшга^ домена Reskit.eom Член домена Reskit.com Рис, 6-16. Мост связей сайтов, объединяющий связи SEAЧ DFW и SEAЧNYC По умолчанию псе связи сайтов определены как транзитивные и не требуют опре деления мостов. В отсутствие моста КСС все равно создает объекты подключений между сайтами. Такая репликация наиболее эффективна и основана на заданной стоимости для каждой связи сайтов. Однако при наличии моста объекты-подклю чения отражают прямое подключение между контроллером домена одного сайта и контроллером домена сайта, с которым нет прямой связи сайтов.
Подробнее о сетевой маршрутизации - в книге Межсетевое взаимодействие. Ресур сы Microsoft Windows 2000 Server (Русская Редакция*, 2001) и в книге Microsoft Windows 2000 Server Deployment Planning Guide (Microsoft Press, 2000).
КСС и создание топологии КСС -- это встроенный процесс, выполняющийся на всех контроллерах домена, и представляет собой динамически подключаемую библиотеку (DEL). КСС измени Репликация Active Directory ГЛАВА ет данные в локальном каталоге в соответствии с общесистемными изменениями, которые становятся известны КСС через изменения данных в Active Directory. КС С генерирует и поддерживает топологию репликации внутри и между сайтами, КСС выполняет две основные функции:
Х конфигурирует подключения для репликации (объекты-подключения) между контроллерами домена. Каждый объект-подключение соответствует входящей связи с партнером по репликации. Внутри сайта каждая КСС формирует свои подключения. Для репликации между сайтами одна служба КСС в каждом сай те формирует все подключения между сайтами;
Х преобразует объекты-подключения, которые представляют входящую реплика цию на локальный контроллер домена, в соглашения репликации, которые и используются механизмом репликации.
По умолчанию КСС проверяет и модифицирует топологию репликации Active Directory каждые 15 минут, чтобы обеспечить распространение данных напрямую либо транзитивно, по мере необходимости создавая и удаляя объекты-подключе ния. КСС распознает изменения, произошедшие в среде, и гарантирует, что кон троллер домена не будет потерян в топологии репликации.
Служебные программы поддержки КСС Хотя результат работы КСС выражается в автоматическом создании объектов-под ключений и видим в консоли Active Directory Sites and Sendees, по существу нет при ложений с пользовательским интерфейсом для прямого управления работой КСС.
Большинством задач репликации, касающихся КСС, можно управлять средствами консоли Active Directory Sites and Services (Active Directory Ч сайты и службы).
Подробнее о служебных программах (не консолях ММС), используемых для углуб ленного управления и диагностики Ч в главе 10 Выявление и устранение непола док, а также восстановление Active Directory.
Консоль Active Directory Sites and Services Эта консоль - самый главный инструмент администратора для управления репли кацией. Он применяется для создания объектов-подключений и связей сайтов, ис пользуемых КСС для репликации. Репликация внутри сайта выполняется полнос тью автоматически и обычно не требует вмешательства. Повысить эффективность репликации между сайтами можно, изменив параметры в объектах связей сайтов, как описано выше.
Подробнее о процедурах управления репликацией средствами консоли Active Directory Sites and Services Ч в справочной системе Windows 2000 Server.
Консоль Event Viewer КСС информирует администратора о своей работе посредством регистрации собы тий и журналах событий, которые можно анализировать в консоли Event Viewer (Просмотр событий).
Вот примеры событий, записанных КСС в журнал:
Х событие 1009 (Уведомления): The consistency checker has started updating the replication topology for this server (механизм проверки согласованности начал обновление топологии репликации этого сервера);
Служба каталогов Active Directory 282 ЧАСТЬ Х событие 1013 (Уведомления): The replication topology update task terminated normally (обновление топологии репликации завершилось нормально);
Х событие 1265 (Предупреждения): The attempt to establish a replication link with parameters
В КСС, как и в остальных подсистемах Active Directory, уровень регистрации со бытий регулируется. По умолчанию в журнал заносятся только наиболее важные события. Повысить уровень детализации в журнале событий можно, изменив зна чение параметра Replication Events в разделе реестра HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics. Повышение уровня дета лизации позволяет получить более четкое представление о поведении КСС в раз ных ситуациях. Однако уровень детализации выше 2 назначать не рекомендуется:
журнал захлебнется в избыточных сообщениях, что снизит быстродействие КСС, Повышение уровня регистрации полезно для поиска и устранения неполадок, но не рекомендуется для обычной работы. I [одробнее о модификации реестра для по вышения уровня регистрации в главе 10 Выявление и устранение неполадок и восстановление Active Directory. Подробнее о консоли Event Viewer Ч справоч ной системе Microsoft Windows 2000 Server.
Объекты, необходимые КСС для построения топологии Для создания эффективной топологии служба КСС должна обладать сведениями о том, какие серверы имеются в каждом сайте. Необходимая для КСС информация хранится в нескольких объектах:
Х в объектах-серверах всем контроллерам доменов соответствуют объекты-сер веры в разделе конфигурации сайта;
Х в объекте NTDS Settings Ч у каждого объекта-сервера, представляющего кон троллер домена, есть дочерний объект XTDS Settings, указывающий, что на кон троллере домена установлена служба Active Directory. Чтобы сервер учитывал ся в топологии репликации, он должен обладать объектом NTDS Settings.
Наличие этих объектов также определяет сайт, в котором должен располагаться контроллер домена. В частности, составное имя объекта NTDS Settings содержит сайт, к которому относится контроллер домена. Если сервер физически располо жен в одном сайте, но сконфигурирован в другом сайте Active Directory, для со ставления топологии КСС использует информацию Active Directory. Таким обра зом, неверная конфигурация серверов в сайтах может повлиять на пропускную спо собность сети.
Этапы формирования топологии Топология формируется в два этапа. На первом КСС оценивает текущую тополо гию, определяет, были ли сбои репликации с существующими подключениями и строит новые подключения, необходимые для завершения создания топологии реп ликации. На втором этапе КСС реализует, или преобразует, решения, выработан ные на первом этапе в соглашения между партнерами репликации.
ГЛАВА 6 Репликация Active Directory Первый этап: оценка существующей топологии и формирование объектов подключений Топология оценивается путем чтения объектов-подключений. Для каждого такого объекта КСС считывает объект NTDS Settings контроллера-источника (он опреде лен в значении атрибута fromServer объекта-подключения), чтобы определить, ка кие разделы каталога у контроллеров-приемников общие с контроллером-источни ком. Атрибут hasMasterNCs (где NC означает naming context Ч контекст имено вания*, синоним раздела каталога) объекта NTDS Sellings содержит' сведения о полных разделах каталога, хранимых на этом контроллере домена. Атрибут hasPartialReplicaNCs содержит данные о частичных репликах разделов каталога (разделы глобального каталога), которые хранятся на данном контроллере. Для каждого раздела каталога, общего для двух контроллеров домена и соответствую щего полным и частичным характеристикам источника репликации, КСС создает (или обновляет) соглашение о репликации.
Примечание Внутри сайта все процессы КСС формируют объекты-подключения для репликации внутри сайта. В среде с несколькими сайтами в каждом сайте есть только одна КСС, которая формирует все объекты-подключения для репликации между сайтами.
Второй этап: преобразование подключений На втором этапе псе КСС обрабатывают объекты подключения и преобразуют их в соглашения о подключении между парами контроллеров домена. В определенные интервалы Active Directory р е п л и ц и р у е т общие разделы каталога между партнера ми по репликации. Сведения о таких соглашениях репликации не представлены в административных программах. Они используются только механизмом репликации для выделения разделов каталога, реплицируемых с данного сервера.
Предположим, что Вы определили объект-подключение между двумя контролле рами разных доменов, при этом пи один из них не является сервером глобального каталога. На втором этапе, КСС обнаружит только два общих раздела для этих кон троллеров Ч разделы схемы и конфигурации. Если Вы создаете объект-подключе ние, который связывает контроллеры домена в одном домене, то реплицироваться будут по крайней мере три раздела Ч схемы, конфигурации и домена, С другой стороны, если объект-подключение создается между двумя контроллера ми домена серверами глобального каталога, то частичные реплики всех разделов каталога в лесе будут реплицироваться между этими двумя контроллерами, Интервал запуска КСС КСС оценивает топологию репликации в определенные интервалы времени, кото рые можно изменять.
По умолчанию КСС запускает первую проверку топологии черен пять минут после старта контроллера домена. Этот нмгериал можно изменить настройкой параметра Repl topology update delay (sees) в разделе реестра HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\NTDS\Parameters. Значение этого парамет ра Ч время т* секундах между моментом запуска Active Directory и моментом нача ла работы КСС, значение по умолчанию Ч 300 секунд (5 минут), а тип данных Ч REG DWORD.
Служба каталогов Active Directory 284 ЧАСТЬ По умолчанию во время работы служб КСС проверяет топологию каждые 15 минут и вносит необходимые изменения. Администратор может изменить эту периодич ность, изменив параметр Repl topology update period R разделе реестра HKEY_mCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters, Значение этого параметра Ч время в секундах между обновлениями топологии КСС значение но умолчанию 900 секунд (15 минут), а тип данных Ч REG_DWORD.
Внимание! Не модифицируйте реестр самостоятельно (с помощью редактора реес тра) Ч делайте это лишь в крайнем случае, когда другого выхода нет. В отличие от инструментов управления редактор реестра обходит стандартные средства защиты, призванные не допускать ввода конфликтующих значений параметров, а также спо собных снизить быстродействие системы или разрушить ее. Не исключено, что по следствия прямого редактирования реестра окажутся не такими, как Вы ожидали, и, возможно, Вам придется переустанавливать Windows 2000. Для настройки и кон фигурирования Windows 2000 рекомендуется использовать Control Panel (Панель управления) или Microsoft Management Console (Консоль управления Microsoft).
Перед изменением реестра советуем делать резервную копию. Подробнее о редакти ровании параметров реестра в справочной системе редактора реестра. Подробнее о реестре Ч R техническом руководстве Technical Reference Microsoft Windows Professional Resource Kit (файл Regentry.chm).
Автоматическое формирование топологии репликации внутри сайта Во время создания топологии внутри сайта КСС преобразует топологию и форми рует ее Ч преобразует (лтранслирует*) информацию, предоставленную алгоритмом, а затем создает (формирует) объекты-подключения, которые реализуют топологию, предписанную трансляцией. В общем виде преобразование и формирование топо логии выполняется в следующей последовательности:
Х КСС на каждом контроллере домена выполняет алгоритм, определяющий топо логию репликации внутри своего сайта. Все серверы одного сайта обладают оди наковой информацией о взаимных отношениях, то есть создают одинаковую то пологию;
Х КСС создает объекты-подключения для серверов, от которых контроллер домена получает данные (серверы-источники) в соответствии с созданной топологией;
Х полученное в итоге множество всех объектов подключения является требуемой топологией.
Топология формируется и оптимизируется для сокращения числа переходов (hops) путем перечисления и сортировки контроллеров домена, хранящих реплики одно го и того же раздела каталога.
Принудительное формирование топологии Топология репликации внутри сайта генерируется автоматически. Формирование топологии происходит по расписанито, которое определяет частоту запусков КСС, Чтобы запустить ее вручную, щелкните правой кнопкой мыши объект NTDS Settings, затем перейдите к подменю All Tasks (Все задачи) и щелкните команду Check Replication Topology (Проверка топологии репликации).
ГЛАВА б Репликация Active Directory Формирование упрощенной кольцевой топологии В самом общем виде процесс создания топологии для репликации ннутри сайта выполняется в следующей последовательности:
Х КОС формирует список всех серверов в сайте, которые хранят раздел катало]'а;
Х найденные серверы соединяются в кольцевую структуру;
Х для каждой пары соседних серверов в кольце КСС создает объект-подключение, если оно еще не существует.
Такой простой способ позволяет создать топологию, устойчивую к сбоям отдель ных серверов. Если контроллер домена недоступен, то он не включается в кольцо, которое формируется по списку серверов, потому что недоступен соответствующий объект NTDS Settings. Впрочем, такая топология без дополнительных изменений поддерживает не более семи серверов. При большем числе контроллеров в кольце образуется более трех переходов.
Самый простой пример - семь или меньше контроллеров домена в одном сайте показан на рис. 6-17. Даже если один или все эти контроллеры Ч серверы глобально го каталога, то даже если КСС работает на этих компьютерах, дополнительных под ключений не требуется. Реплицировать необходимо лишь разделы каталога схемы и конфигурации. Такая топология формируется в первую очередь и обеспечивает дос таточное количество подключений для репликации всех разделов каталога.
Сайт Seattle Домен Reskit.com Разделы схемы и конфигурации Легенда.;
Раздел домена Рис. 6-17. Простая кольцевая топология, не требующая оптимизации Служба каталогов Active Directory 286 ЧАСТЬ Так как кольцевая топология создается для каждого раздела каталога, она может выглядеть по-другому, если в сайте имеются контроллеры другого домена.
На рис. 6-18 показана топология для контроллеров двух доменов в одном сайте, в котором нет серверов глобального каталога.
Сайт Seattle Домен Reskit.ccm Домен Noam.reskit.eom Разделы схемы и конфигурации Легенда Ч 'Х Раздел домена Reskit.com & Раздел домена Noam.reskit.com Рис. 6-18. Кольцевая топология для двух доменов в сайте без сервера глобального каталога Примечание Примеры на рис. 6-18 и рис. 6-19 предоставлены только для демонст рации схемы создания подключений службой, и не следует их рассматривать как рекомендации по конфигурированию сайтов. Сервер глобального каталога необхо дим для входа в домен и поэтому целесообразно создать в сайте по крайней мере один такой сервер. Если глобальный каталог недоступен в сайте, но есть в удален ном сайте, он также может использоваться для входа. Если в сайте нет глобального каталога, процесс входа выполняется па основе квитированной информации о вхо де в домен. (Подробнее о входе в домен при поддержке глобального каталога - в главе 1 Логическая структура Active Directory).
Расширенная кольцевая топология Если серверов больше семи, КОС оценивает количество подключений так, чтобы при возникновении изменения на одном контроллере для его репликации на лю бой другой контроллер требовалось не более трех переходов. То есть изменения должны пройти не более чем три перехода, до того как достигнут другого контрол Репликация Active Directory ГЛАВА б лера домена, который уже получил изменения по другому пути. Эти оптимизирую щие подключения создаются в случайном порядке и не обязательно па каждом тре тьем контроллере домена.
В сайте на рис. 6-19 пет сервера глобального каталога;
все контроллеры домена рас положены в одном домене, но добавлены дополнительные серверы, нуждающиеся в оптимизирующих подключениях. Хотя контроллер А и контроллер В и распола гаются в одном домене и сайте, их отделяет более трех переходов. Оптимизирую щее подключение для разделов домена, схемы и конфигурации, которое можно со здать от контроллера А к контроллеру В, для наглядности изображено на рисунке одной прямой линией: на самом лелс эти разделы реплицируются раздельно, как это показано между смежными партнерами по репликации. В данной ситуации воз можны и другие дополнительные оптимизирующие подключения, Сайт Seattle Контролпе? домена в Три перехода Домен Reskit.com Контроллер домена А швшф Разделы схемы и конфигурации Легенда 'Хm^KiF Раздел домена ЧХЧ-$*- Одно оптимизиоующее подключение для разделов домена, схемы и конфигурации Рис. 6-19. Оптимизирующее подключение для десяти контроллеров одного домена в одном сайте На рис. 6-20 показаны подключения, необходимые между контроллером Ч серве ром глобального каталога Ч и тремя другими доменами, к которым он не относит ся. При добавлении в сайт сервера глобального каталога требуются дополнитель ные подключения для репликации копий разделов каталога в домен, к которому сервер глобального каталога не относится. Поскольку в домене reskit.com только 7 серверов, в топологии репликации для раздела каталога reskit.com оптимизиро вать подключения не требуются. Однако сервер глобального каталога является не Служба каталогов Active Directory 288 ЧАСТЬ точником для каждого из разделов домена в лесе, и в этом примере служба КС С создала объекты-подключения для репликации от контроллера домена для каждо го раздела домена внутри сайта. Везде, где реплицируется раздел домена КСС так же использует подключение для репликации разделов схемы и конфигурации.
Примечание Объекты-подключения генерируются независимо для разделов конфи гурации и схемы (одно подключение) и для отдельных разделов домена, если толь ко не существует подключения от того же источника к контроллерам-приемникам для того же раздела каталога;
в таком случае одно и то же подключение использу ется для обоих разделов (дублирующее подключение не создается).
Сайт Seattle Домен Reskit.com Ч Домен Avionics.com Домен Aequited.com :
Домен Suppller.com Разделы схемы и конфигурации Легенда Раздел домена Reskit.com Подключения к разделам доменов в глобальном каталоге Рис. 6-20. Оптимизирующие подключения в сайте с четырьмя доменами и сервером глобального каталога Оптимизация кольцевой топологии внутри сайта При /добавлении подключений для оптимизации кольцевой топологии в первую очередь решается вопрос: каково минимальное количество подключений п при дан ном наборе узлов, при котором между любыми двумя серверами не больше трех переходов?
При известном п топология формируется в определенной последовательности.
Если у локального сервера нет п дополнительных подключений:
Х в качестве серверов-источников в сайте произвольно выбираются п серверов;
Х для каждого из этих серверов создается объект-подключение.
Репликация Active Directory ГЛАВА При таком способе минимальное расстояние не длиннее трех переходов. Кроме того, сеть хорошо масштабируема, так как при увеличении количества серверов ста рые оптимизированные подключения остаются полезными и не удаляются. Также каждый раз при добавлении от 9 до 11 серверов удаляется произвольный объект подключение и добавляется новый, в идеале с одним из новых серверов в качестве источника. При этом обеспечивается равномерное распределение дополнительных подключений во всей сети.
Исключение недоступных серверов Обнаружив, что какой-то контроллер домена потерпел сбой и стал недоступным, КСС автоматически перестраивает топологию репликации.
Критерий недоступности сервера зависит от того, находится ли сервер в сайте или нет. Прежде чем КСС признает контроллер домена недоступным, он должен пре высить пороги количества неудачных попыток и времени отсутствия на связи:
Х контроллер-приемник должен сделать п неудачных попыток реплицировать ин формацию с данного контроллера;
Х при репликации между сайтами по умолчанию п = 1;
т при репликации внутри сайта существует различие между б л и ж а й ш и м и со седями в кольцевой топологии (в кольце) и оптимизирующими подключе ниями:
для ближайших соседей по умолчанию п = 0 (то есть после неудачной по пытки сразу опрашивается новый сервер);
для оптимизирующих подключений по умолчанию п = 1 (то есть новый сер вер опрашивается после второй неудачной попытки);
Х должно пройти некоторое время после последней удачной репликации:
Х для репликации между сайтами время по умолчанию Ч 2 часа;
Х при репликации внутри сайта существует различие между ближайшими со седями (в кольце) и оптимизирующими подключениями:
для ближайших соседей время по умолчанию Ч 2 часа;
для оптимизирующих подключений время по умолчанию Ч 12 часов.
Для изменения порогов исключения серверов нужно изменить параметры реестра в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ NTDS\Parameters, с типом данных REG_DWORD. Далее описаны эти параметры.
Репликация между сайтами:
Х параметр IntersiteFailuresAllowed Ч число неудачных попыток, значение по умолчанию Ч 1;
Х параметр MaxFailureTimeForlntersiteLink (sees) время отсутствия связи в секундах, значение по умолчанию - 7 200 (2 часа).
Оптимизирующие подключения в пределах сайта:
Х параметр NonCriticalLinkFailuresAllowed количество неудачных попыток, значение по умолчанию 1;
Х параметр MaxFailureTimeForNonCriticalLink - время отсутствия связи в секун дах, значение по умолчанию Ч 43 200 12 часов.
Служба каталогов Active Directory 290 ЧАСТЬ Ближайшие соседи:
параметр CriticalLinkFailuresAHowed - количество неудачных попыток, значе Х ние по умолчанию Ч 0;
Х MaxFailureTimeForCriticalLink Ч время отсутствия связи в секундах, значение по умолчанию Ч 7 200 (2 часа).
Внимание! Не модифицируйте реестр самостоятельно (с помощью редактора реес тра) делайте это лишь в крайнем случае, когда другого выхода пет. Б отличие от инструментов управления редактор реестра обходит стандартные средства защиты, призванные не допускать ввода конфликтующих значений параметров, а также спо собных снизить быстродействие системы или разрушить ее. Не исключено, что по следствия прямого редактирования реестра окажутся не такими, как Вы ожидали, и, возможно. Вам придется переустанавливать Windows 2000. Для настройки и кон фигурирования Windows 2000 рекомендуется использовать Control Panel (Панель управления) или Microsoft Management Console (Консоль управления Microsoft), Перед изменением реестра советуем делать резервную копию. Подробнее о редакти ровании параметров реестра Ч в справочной системе редактора реестра. Подробнее о реестре Ч в техническом руководстве Technical Reference Microsoft Windows Professional Resource Kit (файл Regentry.chm).
Когда проблемный контроллер дометта вновь начнет отвечать, КСС при следующем запуске автоматически восстановит топологию репликации к состоянию, которое имело место до отказа.
Полная оптимизация кольцевой топологии Чтобы максимально оптимизировать топологию, надо добавить дополнительные подключения, обработать недоступные серверы и использовать механизмы регули рования роста;
при этом создаются и добавляются объекты-подключения R соот ветствии с существующими условиями.
Примечание Объекты-подключения с недоступными серверами не удаляются, так как такое состояние считается временным.
Процесс оптимизации топологии реализуется согласно следующим принципам:
Х сортировка серверов обеспечивает достижение всеми серверами одинаково оп тимального положения в топологии;
Х при формировании внутрисайтоной топологии никогда не создаются и не уда ляются объекты, не являющиеся непосредственными потомками объекта NTIXS Settings для локального контроллера домена.
Автоматическое создание межсайтовой топологии Формирование топологии репликации между сайтами сложнее, чем внутри сайта, по тому что, кроме прочих, Windows 2000 поддерживает репликацию по протоколу SMTP.
Поэтому, если при создании внутрисайтовой топологии КСС репликация возможна между любыми двумя серверами, то в межсайтовой топологии такое предположение неверно.
Репликация Active Directory ГЛАВА 6 Роль генератора межсайтовой топологии Основная концепция формирования внутрисайтовой такова: каждый сервер выпол няет свою задачу по формированию топологии всего сайта. Аналогичным образом формирование топологии между сайтами зависит от формирования ка каждом сай те своей части леса межсайтовой топологии. Для решения этой задачи в каждом сайте один из контроллеров домена выполняет роль генератора межсайтовой топо логии. КСС на этом контроллере отвечает за создание подключений между контрол лерами доменов своего и других сайтов, в том числе объектов-подключений для входящей репликации для всех серверов-плацдармов локального сайта.
Если после анализа топологии генератор межсайтовой топологии обнаружит, что его сайт Чединственный, он не будет выполнять никаких действий, так как в такой конфигурации невозможны никакие подключения между сайтами.
Различия в формировании топологии внутри и между сайтами Подключения между плацдармами для межсайтовой репликации и подключения для внутрисайтовой репликации формируются по-разному.
Формируя внутрисайтовую топологию на контроллере домена, КСС создает допол нительные объекты-подключения на локальном компьютере в Active Directory только при необходимости. Эти изменения распространяются на другие компьюте ры в ходе обычного процесса репликации. Контроллеры домена используют этот же алгоритм для вычисления топологии репликации. В состоянии равновесия меж ду контроллерами доменов каждый из них выбирает один и тот же вариант топо логии.
В каждом сайте служба КСС, выполняющая роль генератора топологии (независи мо от домена), отвечает за пересмотр внутрисайтовой топологии и создание объек тов-подключений входящей репликации для серверов-плацдармов в своем сайте.
Принимая решение об изменении объекта-подключения па одном из серверов-плац дармов сайта, генератор межсайтовой топологии вносит соответствующие измене ния в свою копию Active Directory. Эти изменения распространятся на все серве ры-плацдармы сайта в ходе обычной репликации. В процессе изучения топологии после внесения этих изменений КСС на сервере-плацдарме преобразует эти объек ты-подключения в соглашения с партнерам по репликации, которые Active Directory использует для репликации данных с удаленных плацдармов.
Выбор серверов-плацдармов Когда КСС создаст межсайтовую топологию для всех разделов каталога, сервер].!
каждого сайта оцениваются не предмет выполнения функций плацдармов. Основ ные серверы-плацдармы (если таковые сконфигурированы) являются первыми кан дидатами для выбора. В противном случае кандидатами на роль ссриера-плацдар ма становятся все контроллеры домена в сайте, которые хранят соответствующий раздел каталога и способны поддерживать определенный транспорт. В любом слу чае плацдармом становится первый контроллер домена, удовлетворяющий всем требованиям. Все основные серверы-плацдармы в одном сайте, сконфигурирован ные для одного транспорта, равноправны. В равновесном состоянии раздела кон фигурации и при схожих требованиях генератор межсетевой топологии выбирает н каждом сайте один и тот же плацдарм. Например, если определенный сервер-плац дарм (заданный или выбранный автоматически) поддерживает репликацию по про 292 ЧАСТЬ 1 Служба каталогов Active Directory токолу IP и содержит требуемый раздел каталога, он выбирается серверами-плац дармами других сайтов, которым нужны данные этого раздела.
Если для сайта указаны основные серверы-плацдармы и все они недоступны, их функции не передаются другим контроллерам домена, даже если те способны вы полнять эту роль. Это же справедливо и в тех случаях, когда основные серверы плацдармы не заданы и вес контроллеры домена, способные выполнять эту роль, недоступны.
Владелец роли генератора межсайтовой топологии Роль генератора межсайтовой топологии передается в ходе обычной работы Active Directory. Первоначально генератором межсайтовой топологии становится первый контроллер домена в сайте. Роль не меняется при добавлении новых контроллеров домена, пока текущий генератор не станет недоступным.
^ Определение владельца роли генератора межсайтовой топологии в сайте 1. В окне консоли Active Directory Sites and Services (Active Directory - сайты и службы) щелкните значок сайта.
2. В области сведений (это правая панель) щелкните правой кнопкой объект NTDS Site Settings и в контекстном меню выберите команду Properties (Свойства).
Имя генератора топологии отображено в поле Server (Сервер) в области Inter Site Topology Generator (Автоматическая генерация топологии между сайтами).
Примечание Вы не вправе сменить генератор межсайтовой топологии.
Оповещение о владельце роли генератора межсайтовой топологии Генератор межсайтовой топологии оповещает с 30-минутными интервалами другие контроллеры домена о своей роли, записывая атрибут interSiteTopologyGenerator в объект NTDS Settings для объекта контроллера домена в разделе конфигурации каталога.
Когда атрибут inter SiteTopology Generator передается другим контроллерам домена в ходе репликации, КСС па каждом компьютере проверяет наличие этого атрибута.
Если в течение 60 минут обновления этого атрибута не происходит, назначается новый генератор топологии.
Создание нового генератора межсайтовой топологии Когда требуется создать новый генератор межсайтовой топологии, каждый контрол лер домена запрашивает список серверов сайта по возрастанию. Роль генератора берет на себя следующий сервер в списке. Он записывает атрибут interSiteTopology Generator и инициирует необходимые для КСС процессы по управлению объектами входя щих подключений для серверов-плацдармов.
Когда на сайте появляются два контроллера в роли генератора топологии, возмож на ситуация в которой оба сервера создают объекты-подключения входящей реп ликации. Однако после репликации все контроллеры получат уведомление о но вом генераторе, после чего КСС на генераторе скорректирует топологию.
Генератор межсайтовой топологии и измененные подключения Возможна ситуация, когда администратор одновременно изменяет объект-подклю чение на одном из контроллеров домена и КСС на другом контроллере до репли ГЛАВА 6 Репликация Active Directory кации первого изменения. Перезапись изменения выполняется на локальном или на удаленном сайте. По умолчанию КСС запускается каждые 15 минут. Если изме нение объекта подключения не передано на другой контроллер домена до запуска КСС на нем, КСС может изменить тот же объект. В этом случае объектом подклю чения владеет КСС, как автор последнего записанного изменения.
Чтобы редактируемый объект не был переписан КСС, следует вносить изменения на компьютере, выполняющем роль генератора топологии на том сайте, где нахо дится изменяемый объект.
Механизм безопасности репликации Механизм безопасности репликации необходим для того, чтобы не обладающая до статочными правами программа не могла принимать данные репликации, ведь по лучатели изменений имеют доступ к общим секретам. Также нельзя допускать, что бы такая программа действовала в качестве источника репликации, так как это по зволит ей вносить свои (неправомочные) изменения в каталог. Поэтому необходи ма взаимная проверка подлинности партнеров при репликации, а также управле ние доступом к источнику репликации. Технология безопасности репликации за висит от применяемого транспорта.
Безопасность транспорта RPC Взаимная проверка подлинности выполняется по протоколу Kerberos v5 либо по про токолу NTLM, если партнером является контроллер домена Microsoft Windows NT 4.0.
При авторизации для доступа к источнику репликации используется разрешение DS-Replicatkm-Get-Changes (Репликация изменений каталога). Разрешения опре делены в записях управления доступом (access control entry, АСЕ) дескрипторов безопасности корневого объекта в разделе каталога. По умолчанию это разрешение получают члены групп Enterprise Domain Controllers (Контроллеры домена пред приятия) и Domain Admins (Администраторы домена), оно требуется для запуска мастера установки Active Directory (Dcpromo.exe).
Подробнее о проверке подлинности в Active Directory - в главе 11 Проверка под линности;
об авторизации в Active Directory Ч в главе 12 Управление доступом*;
о мастере установки Active Directory - в главе 2 Хранение данных в Active Directory.
Безопасность транспорта ISM Механизм безопасности и шифрования, применяемый службой ISM, похож на ис пользуемый в Secure/Multipurpose Internet Mail Extensions (S/MIME), который является стандартом передачи двоичных данных через Интернет. При использова нии S/MIME отправитель всегда добавляет собственный сертификат с путем сер тификации, восходящим к корневому центру сертификации. Запросы к источнику репликации подписываются, по не шифруются. Запрос не содержит секретных дан ных, и контроллер домена не требует знания сертификатов других контроллерои домена. Ответы получателю репликации подписываются и удостоверяются серти фикатом локального контроллера домена, а также сертификатом, который прове ряющий включает в запрос.
Такая проверка подлинности возможна, потому что все сертификаты, используемые при репликации в Active Directory [то есть сертификаты Domain Controller (Коп Служба каталогов Active Directory 294 ЧАСТЬ троллер домсна)|, содержат атрибут altSubjectName, который содержит значение атрибута objectGuid объекта компьютера владельца сертификата. Сопоставление атрибута objectGuid для сервера способен выполнить любой контроллер домена, так как требуемая информация хранится в разделе конфигурации.
При авторизации контроллер-приемник проверяет действительность сертификата (в том числе удостоверяется, что выпустивший его центр сертификации является доверенным), после чего он извлекает значение атрибута objectGuid отправителя и пытается по нему определить GU1D объекта сервер в своем лесе. Если операция успешна, дополнительно проверяется, что отправитель -- контроллер домена с Active Directory (сервер-отправитель должен иметь дочерний объект NTDS Settings, соответствующего класса, созданный самой службой каталогов). Таким образом, полный доступ к репликации получают все контроллеры доменов Active Directory леса, причем только к контроллерам доменов Active Directory.
Подробнее о сертификатах Ч в главе 16 Службы сертификации и инфраструктура открытого ключа в Windows 2000;
об аутентификации Ч в главе 11 Проверка под линности;
об авторизации в главе 12 Уирагуление доступом.
Дополнительные методы управления репликацией Репликация Active Directory выполняется автоматически и безаварийно без адми нистративного вмешательства. Исключение составляет конфигурирование сайтов и их связей. Однако при определенных условиях требуется тонкая настройка, вы ходящая далеко за рамки обычной настройки системы. Подробнее об управлении репликацией и устранении неполадок в главе 10 Выявление и устранение непо ладок и восстановление Active Directory.
Взаимная репликация Репликация между сайтами выполняется по запросу (request-pull): получатель за прашивает изменения источника согласно расписанию. С другой стороны, репли кация внутри сайта выполняется по алгоритму лизвещение запрос (notify-pull) (источник извещает об изменениях получателя и получатель запрашивает их у ис точника). Чтобы репликация проходила в обоих направлениях, обе стороны долж ны уметь инициировать процесс.
Когда репликацию между сайтами может инициировать лишь одна сторона, напри мер при коммутируемом доступе через провайдера, разрешается установить флаг на объекте-подключении (в атрибуте объекта связь сайтов) для обеспечения взаим ной репликации (reciprocal replication). Она выполняется в следующей последонатель ности: контроллер домена, работающий через провайдера, после подключения запра шивает изменения, инициируя репликацию;
получив изменения, он уведомляет парт нера о своих изменениях, который в свою очередь запрашивает изменения у контрол лера с коммутируемым доступом. Таким образом выполняется двусторонняя репли кация посредством одного исходного подключения, открытого по коммутируемому каналу, созданному в одностороннем порядке одним из контроллеров.
Общий случай применения взаимной репликации Ч обмен данными между голов ным офисом компании и ее филиалом. В этой схеме филиал соединяется через сво его провайдера и создает туннельное ТР-подключение, или VPN-соединение, с сле дующем порядке:
1. филиал соединяется с поставщиком услуг Интернета;
Репликация Active Directory ГЛАВА 6 2. филиал устанавливает туннельную связь с центральным офисом компании;
3. филиал инициирует репликацию, запрашивая изменения у контроллера в цент ральном офисе компании;
4. завершив получение данных репликации, филиал немедленно уведомляет о сно их собственных обновлениях;
5. центральный контроллер запрашивает изменения у филиала;
6. филиал реплицирует изменения в центральный офис.
В этом случае необходима взаимная репликация, так как центральный офис не мо жет заставить провайдера позвонить в филиал, а значит, и инициировать подклю чение. Только филиал инициирует связь с центральным офисом. Если взаимная репликация разрешена, то после установления VPN-подключения филиал может инициировать репликацию своих данных на центральный контроллер.
Чтобы разрешить взаимную репликацию между двумя сайтами, требуется изменить атрибут options соответствующего объекта связь сайтов. Когда этот атрибут задан, КСС создает объект-подключение для этой связи со всеми соответствующими пара метрами. Чтобы разрешить взаимную репликацию, применяется консоль ADSI Edit.
^ Разрешение взаимной репликации между двумя сайтами 1. В консоли ADSI Edit раскройте контейнер Configuration.
Раскройте контейнер Sites, перейдите в контейнер Inter-Site Transports и вы 2.
берите папку CN=IP (для подключений по SMTP взаимную репликацию задать нельзя).
3. Щелкните правой кнопкой мыши объект связи сайтов, для которого нужно раз решить взаимную репликацию и выберите команду Properties (Свойства).
4. Б поле Select a property to view выберите options.
Если поле Value(s) в окне Edit Attribute содержит запись
Attribute введите 2. Если Value(s) уже содержит значение, необходимо в это поле поместить результат операции поразрядное ИЛИ, примененной к пре жнему значению и двойке. Например, если значение поля Value(s) равно 1, вы числяем (0001 ' 0010), получается 0011. Введите десятичное значение результа та в поле Edit Attribute;
в пашем примере это 3.
6. Щелкните ОК.
Уведомление об изменениях Уведомление об изменениях (change notification) - это механизм, посредством кото рого контроллер домена извещает партнера по репликации о наличии изменении, Репликация внутри сайта происходит в ответ на изменения;
когда на контроллере домена происходят изменения, он извещает своего партнера по репликации, чтобы тот запросил информацию об изменениях. Изменив состояние атрибута, контрол лер домена отправляет уведомление партнеру по репликации в течение определен ного времени после изменения.
Уведомление об изменении внутри сайта Для изменений внутри сайта имеется таймер задержки, который определяет ин тервал между моментом изменения и моментом, когда сервер извещает об этом Служба каталогов Active Directory 296 ЧАСТЬ партнеров по репликации. Этот интервал предназначен для сокращения трафика репликации. Когда контроллер домена выполняет изменение (исходное или выз ванное репликацией) в разделе каталога, он запускает таймер и по истечении ин тервала задержки уведомляет всех своих партнеров по репликации (для данного раздела каталога внутри сайта) обо всех своих изменениях на данный момент вре мени. Если партнер не занят запросом на изменения от другого партнера, он запра шивает изменение у известившего сервера.
Стандартное время задержки Ч 300 секунд (5 минут). Оно определено в параметре Replicator notify pause after modify (sees) в разделе реестра HKEY_LOCAL_MACHlNE\SYSTEM\CurrentControlSet\Services\NTDS\ Parameters.
При необходимости это значение разрешается изменить.
Примечание При маленьком значении этого параметра Вы получите слишком мно го уведомлений, что снизит производительность.
Контроллер домена не уведомляет всех своих партнеров по репликации одновре менно. Делая паузы между уведомлениями, он распределяет во времени нагрузку по ответу на запросы партнеров. Но умолчанию эта пауза составляет 30 секунд и определена в параметре Replicator notify pause between DSAs (sees) в разделе ре естра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\ Parameters.
Внимание! Не модифицируйте реестр самостоятельно (с помощью редактора реес тра) Ч делайте это лишь в крайнем случае, когда другого выхода нет. В отличие от инструментов управления редактор реестра обходит стандартные средства защиты, призванные не допускать ввода конфликтующих значений параметров, а также спо собных снизить быстродействие системы или разрушить се. Не исключено, что по следствия прямого редактирования реестра окажутся не такими, как Вы ожидали, и, возможно, Вам придется переустанавливать Windows 2000. Для настройки и кон фигурирования Windows 2000 рекомендуется использовать Control Panel (Панель управления) или Microsoft Management Console (Консоль управления Microsoft).
Перед изменением реестра советуем делать резервную копию. Подробнее о редакти ровании параметров реестра в справочной системе редактора реестра. Подробнее о реестре в техническом руководстве Technical Reference Microsoft Windows Professional Resource Kit (файл Regentry.chm).
Уведомление об изменении между сайтами По умолчанию изменения реплицируются между сайтами по расписанию, а не ког да они происходят. Поэтому наибольшая задержка во всем лесе Ч это сумма мак симальных задержек по самым длинным путям в каждом разделе каталога, В особых случаях возможно сконфигурировать уведомление об изменениях для подключений между сайтами. Это выполняется средствами консоли ADSI Edit.
^ Разрешение уведомлений об изменении между сайтами 1. В консоли ADSI Edit раскройте узел Configuration.
2. Раскройте контейнер Sites, перейдите в контейнер Inter-Site Transports и вы берите CN=IP (режим уведомлений невозможен для связей но SMTP).
ГЛАВА б Репликация Active Directory 3. Щелкните правой кнопкой мыши объект связи сайтов, для которых включается уведомление, и в контекстном меню выберите команду Properties (Свойства).
4. В окне Select a property to view выберите options.
5. Если поле Value(s) в окне Edit Attribute содержит запись
в нашем примере это 3.
6. Щелкните ОК.
Разрешение уведомления об изменениях касается всех изменений. Если такое разре шение задано, то изменения происходят в удаленном сайте с той же частотой, что и в исходном, в том числе изменения, вызывающие неотложную (urgent) репликацию.
Примечание Не задавайте уведомления об изменениях для коммутируемых IP-под ключений или SMTP-подключений.
Неотложная репликация Неотложная репликация (urgent replication) реализована как немедленное уведом ление по протоколу RPC/IP партнеров по репликации об изменениях па контрол лере домена. Она использует обычные уведомления об изменениях, но они отправ ляются немедленно в ответ на определенное событие, а не после обычного 5-ми нутного интервала. Таким образом, если уведомление об изменениях разрешено между сайтами, между ними выполняется и неотложная репликация.
События, вызывающие неотложную репликацию Определенные события на контроллерах домена всегда вызывают неотложную реп ликацию в Active Directory внутри сайта, а также между сайтами, для которых раз решены уведомления об изменениях.
Немедленная репликация между контроллерами под управлением Windows 2000 в одном сайте вызывается:
Х блокированием учетной записи, запрещающим пользователю вход в систему после определенного числа неудачных попыток;
Х изменением секрета LSA (Local Security Authority) Ч безопасной формы хране ния персональных данных в LSA;
Х сменой хозяина относительных идентификаторов (relative identifier, RID), ко торый является единственным контроллером в домене, выделяющем относи тельные идентификаторы остальным контроллерам в домене.
Неотложная репликация изменений, вызванная блокировкой учетной записи Блокировка учетной записи Ч это функция системы безопасности, позволяющая ограничить число неудачных попыток проверки подлинности, после которого дан ная учетная запись отключается, а также период блокировки записи.
В Windows 2000 блокировка учетной записи неотложно реплицируется на компью тер, выполняющий роль эмулятора PDC, а затем:
298 ЧАСТЬ 1 Служба каталогов Active Directory Х на контроллеры домена в том же домене и в том же сайте, что и эмулятор PDC;
Х на контроллеры домена в том же домене и в том же сайте, что и контроллер, заблокировавший учетную запись;
Х на контроллеры того же домена, расположенные в сайтах, для которых настрое но уведомление об изменениях (а следовательно, и неотложная репликация) с сайта, в котором находится эмулятор PDC или контроллер, заблокировавший учетную запись.
Кроме того, когда происходит сбой проверки подлинности на контроллере домена, отличном от эмулятора PDC, он повторяется на самом эмуляторе РОС. Поэтому при превышении количества неудачных попыток эмулятор PDC блокирует учет ную запись раньше, чем другой контроллер. Подробнее о том, как компьютер, вы полняющий роль эмулятора PDC, управляет изменением паролей и блокировкой учетных записей Ч в главе 7 Управление операциями одиночного хозяина.
Управление неотложной репликацией Далее перечислены некоторые рекомендации, которые могут оказаться полезными при принятии решения о разрешении уведомлений об изменениях между сайтами для поддержки неотложной репликации.
Х Если неотложную репликацию следует выполнять во всей сети, поместите все контроллеры данного домена в один сайт (иногда это неосуществимо).
Х Если неотложную репликацию следует выполнять во всей сети, но нежелатель но отказываться от преимуществ привязки компьютеров к сайтам, создайте не сколько сайтов и включите уведомление об изменениях для всех связей сайтов.
Х По умолчанию блокировка учетной записи вызывает неотложную репликацию в сайте, содержащем контроллер домена, управляющий проверкой подлиннос ти, и в сайте, содержащем PDC.
Принудительная репликация между двумя серверами Для запуска принудительной репликации с сервера-приемника используется объект подключение. В консоли Active Directory Sites and Services щелкните правой кноп кой мыши объект-подключение и в контекстном меню щелкните команду Replicate Now (Реплицировать сейчас). Подробнее о настройке принудительной репликации между серверами Ч в справочной системе Microsoft Windows 2000 Server;
о допол нительных средствах принудительной репликации Ч в главе 10 Выявление и уст ранение неполадок, а также восстановление Active Directory.
Репликация изменений пароля Репликация изменений паролей отличается от обычной и неотложной репликации.
Изменение пароля приводит к определенной проблеме в случае задержки реплика ции: допустим пароль пользователя изменен на контроллере А, а затем этот пользо ватель пытается войти в систему и пройти проверку подлинности на контроллере В.
Если пароль не успеет реплицироваться с контроллера А на контроллер В, попыт ка не удастся. В Active Directory эта проблема решена следующим образом: все из менения паролей немедленно направляются на единый контроллер в лесе, выпол няющий роль эмулятора PDC.
Если в.лесе только один контроллер домена Windows 2000, роль эмулятора PDC возлагается на него. Эмулятор моделирует поведение основного контроллера до Репликация Active Directory ГЛАВА 6 мена под управлением Microsoft Windows NT 3.x или 4.0. В Windows NT 4.0 един ственный контроллер домена, принимающий изменения паролей. это основной контроллер домена. Если проверка подлинности не удается на резервном контрол лере, запрос направляется сразу на основной контроллер, который гарантированно содержит правильный пароль.
В Windows 2000 при изменении пароля пользователя па каком-либо контроллере домена этот контроллер пытается изменить соответстиующуго реплику на компью тере, исполняющем роль эмулятора PDC. Изменение на самом эмуляторе PDC выполняется немедленно, независимо от расписаний уведомлений между сайтами.
Новый пароль затем распространяется на остальные контроллеры домена путем обычной репликации внутри сайта. Не ли пользователь проходит проверку подлин ности на контроллере, не имеющем нового пароля, то этот контроллер не сразу от кажет в доступе из-за несовпадения пароля, а сначала обратится к эмулятору PDC для проверки данных пользователя. Таким образом, пользователь войдет в систе му, даже если контроллер, на котором выполняется аутентификация, еще не полу чил новый пароль.
Если по какой-либо причине немедленное обновление на PDC невозможно, изме нение пароля реплицируется обычным порядком.
Клиенты под управлением Windows NT 4.0 или Microsoft Windows 9х без установ ленного клиента системы каталогов (Directory Services Client Update Pack) все да пытаются соединиться с эмулятором PDC. Если же клиент поддерживает взаимо действие со службой каталогов, то он соединяется с любым из контроллеров доме на, а тот уже Ч с эмулятором PDC.
Примечание Можно настроить контроллер домена так, чтобы он не обращался к РОС, если обладатель роли эмулятора PDC не находится в данном сайте. Для это го параметру AvoidPdcOnWan в разделе реестра IIKEY_LOCALMACIIINE\ СиrrentControlSet\Services\Netlogon\Parameters\ следует присвоить значение 1. В этом случае изменения пароля передаются на эмулятор PDC в ходе обычной реп ликации.
Создание дополнительных объектов-подключений Служба КСС создает топологии с минимальной задержкой репликации, устойчи вые к сбоям и не требующие модификации. Добавление подключений не рекомен дуется, потому что дополнительные подключения постепенно снижают способность КСС автоматически выбирать наилучшие конфигурации. К тому же возникает си туация, когда надо постоянно оценивать, какой выигрыш дают созданные вручную подключения репликации.
Добавление подключений не обязательно снижает задержку репликации. Задерж ки внутри сайта обычно связаны не с выбором топологии службой КСС, а с други ми факторами. К ним относятся:
Х сбои ключевых контроллеров домена, таких, как эмулятор PDC, серверы гло бального каталога или серверы-плацдармы;
Х большая вычислительная нагрузка на контроллеры домена, в результате чего они не it состоянии своевременно реплицировать информацию (то есть их слишком мало);
Служба каталогов Active Directory 300 ЧАСТЬ Х неполадки в сети;
Х неполадки сервера DNS;
Х нетипично много изменений в каталогах, Такие проблемы не решаются созданием подключений вручную, и добавление та ких подключений не снизит задержки репликации. Настройка расписания и сто имости репликации по межсайтовой связи - лучший способ влияния на тополо гию внутрисайтовой репликации.
КСС автоматически создает подключения для обеспечения постоянной связи в ка талоге, даже если возникают непредвиденные сбои и отказы. Создавать подключе ния вручную приходится, лишь когда автоматически создаваемые КСС подключе ния не связывают контроллеры домена, которые желательно соединить. Например, если нужно создать временное подключение для принудительной репликации с определенного сервера, создайте для этого сервера в консоли Active Directory Sites and Services соответствующий объект-подключение.
Примечание Цена дополнительных подключений по сравнению с конфигурацией по умолчанию Ч это дополнительные такты процессора, операции чтения с диска, а также дополнительный сетевой трафик, создаваемый репликацией.
Необходимость в дополнительных подключениях между контроллерами домена внутри сайта или между ними возникает в следующих ситуациях:
Х если нужно уменьшить число переходов между контроллерами домена внутри сайта. По умолчанию каждое изменение не должно проходить более трех пере ходов от того места, где оно произошло, до другого контроллера домена в дан ном сайте. Для уменьшения количества переходов до двух или одного добавля ют дополнительные подключения;
Х при сбоях связи между контроллерами домена в разных сайтах иногда требуют ся дополнительные подключения для обхода неисправного сервера (серверов).
КСС создает такие подключения в подобных случаях, но этот итерационный процесс вызывает дополнительную задержку репликации.
Если создается подключение вручную, близкое к тому, которое создала бы КСС, служба КСС не будет создавать своего подключения, но и не удалит или не изме нит созданное Вами. (Подробнее о создании объекта-подключения Ч в справочной системе Microsoft Windows 2000 Server.) Вот некоторые рекомендации по улучшению производительности КСС в больших сетях:
Х уменьшите количество сайтов, насколько возможно;
Х увеличьте объем оперативной памяти на контроллерах домена;
Х если возможно, сбросьте флажок Bridge all sites links (Установить мост для всех связей сайтов);
Х в крайнем случае выключите автоматическое создание топологии между сайта ми и создайте соответствующие подключения вручную.
Подробнее об управлении репликацией с помощью дополнительных подключений и рекомендациях по использованию КСС на Web-странице Web Resources по адресу ссылка Microsoft Knowledge Base (выполните поиск но ключевому слову Q244368).
ГЛАВА Управление операциями одиночного хозяина Операции одиночного хозяина (Flexible Single-Master Operations, FSMO) использу ются в Active Directory для предотвращения конфликтов обновления, когда невоз можно применение стандартного механизма разрешения конфликтов. Планирова ние управления FSMO-ролями позволяет сделать каталог Active Directory более доступным.
В этой главе Основные сведения Роли одиночных хозяев операций Размещение ролей хозяина операций Устранение неполадок хозяина операций Управление доступом к назначению ролей Особенности работы хозяев операций Основные сведения В Active Directory разрешается изменять данные любого контроллера домена, спо собного принимать подключения клиентов, даже если временно нет соединения с самим доменом. Такое обновление называется обновлением с несколькими хозяева ми (multimaster update). После восстановления сетевого подключения обновления распространяются по всей иерархии леса. Таким образом, если два пользователя внесут конфликтующие изменения, реплицируются оба набора обновлений. Впро чем, механизм разрешения, конфликтов (conflict resolution) позволяет в любой си туации синхронизировать реплики на всех контроллерах.
Тем не менее обычно лучше предотвращать конфликты, а не устранять их. Напри мер, при наличии па разных контроллерах домена конфликтующих версий схемы Служба каталогов Active Directory 302 ЧАСТЬ можно воспользоваться стандартными методами разрешения конфликтов Active Directory. Б большинстве случаев в процессе разрешения конфликта вносятся из менения, сделанные тем контроллером, который последний записывал и обновлял данные. Однако, поскольку схема обновляется нечасто и ее согласованность очень важна, лучше предотвратить конфликт и tie полагаться на обычные механизмы его устранения.
Для предотвращения конфликтов Active Directory обновляет схему в режиме оди ночного хозяина, то есть обновления выполняет единственный контроллер домена в лесе Ч хозяин схемы. При необходимости администратор перемешает роль хозя ина схемы от контроллера к контроллеру;
тем не менее в каждый момент времени лишь один контроллер выполняет роль хозяина схемы.
Роль хозяина схемы Ч пример FSMO-роли, также называемой ролью одиночного хозяина операций или просто хозяина операций. В Microsoft Windows 2000 Server есть и другие роли хозяина операций, ответственные за внесение в каталог измене ний определенного типа. Только контроллер домена, являющийся хозяином роли, вправе вносить соответствующие коррективы.
В небольших системах с Active Directory с одним контроллером домена вопрос о ролях хозяина операций не возникает. При развертывании нескольких контролле ров домена все намного сложнее, поэтому Вам надо четко понимать:
Х какие контроллеры домена должны выполнять роли хозяев операций;
Х какие функции будут утеряны при недоступности контроллера Ч хозяина опе раций;
Х что следует предпринять для восстановления служб, когда одиночный хозяин операций недоступен длительное время.
В следующем разделе мы обсудим каждую из ролей одиночного хозяина операций, дадим ответы на поставленные вопросы, а также расскажем, как управлять досту пом к назначению ролей.
Роли одиночных хозяев операций В Active Directory существует пять ролей одиночного хозяина операций: хозяин схемы, хозяин именования доменов, хозяин относительных идентификаторов, эму лятор основного контроллера домена и хозяин инфраструктуры. Роли хозяина схе мы и хозяина именования доменов уникальны в пределах леса. Это означает, что в лесе возможен только один хозяин схемы и один хозяин именования доменов. Ос тальные роли должны быть уникальны в домене, то есть в каждом домене в составе леса определен один хозяин относительных идентификаторов (relative identifier, RID), один эмулятор основного контроллера домена (primary domain controller.
PDC) и один д-о.адин инфраструктуры (infrastructure master). Таким образом, в лесе с одним доменом можно назначить пять ролей хозяина операций, а в лесе с несколь кими доменами ролей будет больше, поскольку в каждом домене имеется свой хо зяин RID. эмулятор PDC и хозяин инфраструктуры.
Допустим, что в лесе Reskit.com три домена:
Х Reskit.com Ч корневой домен;
Х Na.reskit.com Ч североамериканский домен;
Х Eur.rcskit.com Ч европейский домен.
ГЛАВА 7 Управление операциями одиночного хозяина Таким образом, в домене Reskit.com будет одиннадцать ролей хозяина операции:
Х хозяин схемы (лес): Reskit.com;
Х хозяин именования доменов (лес): Reskit.com;
Х хозяин RID (домен): Reskit.com;
Х хозяин RID (домен): Na.reskit.com;
Х хозяин RID (домен): Eur.reskit.com;
Х эмулятор PDC (домен): Reskit.com;
Х эмулятор PDC (домен): Na.reskit.com;
Х эмулятор PDC (домен): Eur.rebkit.com;
Х хозяин инфраструктуры (домен): Reskit.com;
Х хозяин инфраструктуры (домен): Na.reskit.com;
Х хозяин инфраструктуры (домен): Eur.reskit.com.
Контроллер любого домена в составе леса в состоянии выполнять уникальную в пределах этого леса роль;
роль, уникальную в отдельном домене, разрешается вы полнять лишь контроллеру этого домена. Таким образом, один контроллер домгна способен совмещать до пяти уникальных ролей хозяина операций. В нашем приме ре 11 ролей можно назначить от трех до одиннадцати контроллерам.
При создании контроллера первого домена Windows 2000 в лесе мастер установки Active Directory назначает ему все пять ролей, а при создании контроллера нового домена Windows 2000 в существующем лесе - три уникальных роли хозяина опе раций домена.
В домене смешанного режима (поддерживающего контроллеры под управлением Windows 2000/NT 4.0/NT 3.51) выполнять роли хозяина операций способны лишь контроллеры домена под управлением Windows 2000, Хозяин схемы Хозяин схемы Ч это единственный контроллер домена, обладающий правом изме нять схему каталога. Эти обновления в дальнейшем реплицируются на все осталь ные контроллеры доменов в лесе.
Как уже упоминалось, хозяин схемы это роль уровня леса, так как в лесе суще ствует лишь одна схема - независимо от количества его доменов. Чтобы изменить схему, надо обязательно подключиться к хозяину схемы данного леса. При необхо димости роль хозяина схемы передается другому контроллеру домена.
Управляют ролью хозяина схемы средствами оснастки Active Directory Schema (Схема Active Directory). Чтобы проверить подключение оснастки Active Directory Schema к хозяину схемы, щелкните в дереве консоли узел схемы правой кнопкой мыши и выберите в контекстном меню команду Operations Master (Хозяин опера ций). Совпадающие значения параметров Current Focus (Текущее местоположение) и Current Operations Master (Текущий хозяин операций) свидетельствует о том, что оснастка подключена к хозяину схемы. Чтобы получить возможность изменять схему, следует установить флажок The Schema may be modified on this server (Схе ма может быть изменена на этом контроллере домена).
При попытке изменить схему средствами оснастки Active Directory Schema на кон троллере домена, не являющемся хозяином схемы, Вы получите малоинформатив Служба каталогов Active Directory 304 ЧАСТЬ ное сообщение attempted schema modification failed (модифицировать схему не удалось).
Подробнее об использовании оснастки Active Directory Schema, роли хозяина схе мы и расширении схемы - в главе 4 Схема Active Directory.
Хозяин именования доменов Хозяин именования доменов Ч это единственный контроллер домена, обладающий правом:
Х добавлять в лес новые домены;
Х удалять существующие домены из леса;
Х добавлять/удалять объекты -- перекрестные ссылки на внешние каталоги.
Добавлять или удалять домены леса разрешается, только подключившись к хозяи ну именования доменов. Если хозяин именования домена недоступен, эти опера ции выполнить нельзя. При необходимости роль хозяина именования домена пере дается другому контроллеру домена.
Существует несколько способов добавления домена в лес. Они перечислены далее.
Х Мастер Active Directory Installation Wizard (Мастер установки Active Di rectory). В процессе создания первого контроллера нового домена мастер обра щается к хозяину именования домена по протоколу RPC (Имейте в виду, что для создания домена необходимы соответствующие разрешения доступа).
В случае недоступности хозяина именования доменов система возвратит следу ющее сообщение об ошибке:
Active Directory Installation Failed The operation has failed because <причина_отказа> To perform the requested operation, the Directory Service needs to contact the domain naming master (server server05.reskit.com). The attempt to contact it failed.
The error was: "The specified server cannot perform the requested operation."
В этом примере имя хозяина именования доменов Ч server05.re.skit.com.
Х Команда Precreate в разделе Domain Management служебной программы Ntdsutil с последующим использованием мастера установки Active Directory.
Ntdsutil позволяет подключиться к хозяину именования доменов для создания объекта -- перекрестной ссылки, задающей имя нового домена. Этот объект раз мещается в контейнере Partitions раздела конфигурации. После репликации пе рекрестной ссылки по всему лесу выполняется мастер установки Active Di rectory, и создается новый домен с уже существующим именем. В этом случае мастер установки Active Directory не обращается к хозяину именования доме нов. Для создания нового домена необходимы соответствующие разрешения.
Вот пример сообщения программы Ntdsutil при попытке подключения к недо ступному хозяину именования доменов (команды, которые вводит пользователь, выделены курсивом):
C:\>ntdsutil ntdsutil: domain management domain management: connections server connections: connect to server05.reskit.com ГЛАВА 7 Управление операциями одиночного хозяина binding to serverOS.reskit.com.,.
DsBindW error Ox6ba(The RFC server is unavailable.) Хозяин относительных идентификаторов Создать в домене новый объект Ч участник безопасности (лпользователь, груп па или компьютер) довольно просто. Однако когда объектов создастся несколь ко сотен, контроллер домена обязательно средствами RPC обращается к контрол леру Ч хозяину относительных идентификаторов (R1D) этого домена за новой пор цией (пулом) относительных идентификаторов. Если пул относительных иденти фикаторов контроллера домена пуст и хозяин RID недоступен, создать новые объекты Ч участники безопасности в данном контроллере не удастся. Если в этом случае Вы попопытаетесь сделать это средствами оснастки Active Directory Users and Computers (Active Directory Ч пользователи и компьютеры), то получите сле дующее сообщение:
Active Directory Service The object James Smith could not be created.
The problem encountered was:
The directory service has exhausted the pool of relative identifiers, В данном примере система не в состоянии создать объект-пользователь с именем James Smith, так как пул RID исчерпан.
При перемещении объектов между доменами с помощью служебной программы Movctree обязательно подключение к хозяину RID в домене-источнике (то есть к точке, откуда перемещается объект). В противном случае перемещение объектов невозможно, при этом система возвращает малоинформативное сообщение об ошибке Movetree tailed.
Подробнее об относительных идентификаторах - и главе 12 Управление досту пом.
Эмулятор основного контролера домена В каждом домене Windows NT 3.51 или Windows NT 4.0 имеется основной контрол лер домена, ответственный за:
Х обработку операций по изменению паролей, выполняемых пользователями и компьютерами;
Х репликацию обновлений на резервные контроллеры домена;
Х роль основного обозревателя домена (Domain Master Browser).
Windows 2000 взаимодействует с рабочими станциями, рядовыми серверами и кон троллерами доменов под управлением Windows NT 3.51 и Windows NT 4.0, поэто му для совместимости со старыми системами в среде Windows 2000 один из кон троллеров эмулирует основной контроллер домена Windows NT, то есть выполняет роль эмулятора PDC.
В большинстве случаев обновление Active Directory выполняется по механизму репликации с несколькими хозяевами. Это означает, что недоступность эмулятора PDC в среде Windows 2000 не так критична, как в среде Windows NT, когда стано вятся недоступны перечисленные выше службы. Вот что при этом происходит:
Х при попытке изменить пароль пользователю рабочей станции под управлением Windows NT 3.51, Windows NT Workstation 4.0, Windows 95/98 без установлен Служба каталогов Active Directory 306 ЧАСТЬ ного клиента Active Directory возвращается примерно такое сообщение: Unable to change password on this account. Please contact your system administrator* (Не возможно изменить пароль для данной учетной записи. Свяжитесь с вашим си стемным администратором);
Х при попытке запуска User Manager на резервном контроллере под управлением Windows NT 3.51 или Windows NT 4.0 в домене смешанного режима пользова тель получит сообщение domain unavailable (домен недоступен), а если дис петчер User Manager уже запущен, Ч то сообщение RFC server unavailable (недоступен сервер RPC). При попытке создать учетную запись командой net user/add выводится сообщение could not find domain controller for this domain (не найден контроллер данного домена). При запуске Server Manager система выводит сообщение Cannot find the primary domain controller for <имя_доме~ на>. You may administer this domain, but certain domainwide operations will be disabled (He найден основной контроллер домена <имя_домена>. Вы можете управлять доменом, но некоторые функции уровня домена будут недоступны).
После обновления до Windows 2000 или путем установки (на системах под управ лением Windows NT Workstation 4.0, Windows 95 и Windows 98) клиента Active Directory система перестает полагаться на PDC и ведет себя следующим образом:
Х клиенты изменяют пароли не на эмуляторе PDC, а на любом контроллере домена;
Х после обновления всех резервных контроллеров домена до Windows 2000 основ ной контроллер больше не получает запросы на репликацию от систем под уп равлением Windows NT 3.51 и Windows NT 4.0;
Х для поиска сетевых ресурсов клиенты используют Active Directory. Служба об зора сети Windows NT Computer Browser им больше не требуется.
Даже после обновления всех систем до Windows 2000 контроллер домена, испол няющий роль эмулятора PDC, по-прежнему поддерживает следующие функции:
Х изменение паролей, выполняемые другими контроллерами, передаются на PDC;
Х если из-за неверно указанного пароля проверка подлинности (аутентификация) на других контроллерах домена терпит неудачу, запрос на проверку передается эмулятору PDC, и лишь после этого возвращается отказ в аутентификации.
Проверка подлинности окажется успешной, если эмулятор PDC вовремя полу чил последние обновления паролей;
Х в случае успешной проверки подлинности на данном контроллере домена вслед за неуспешной контроллер сообщает об этом эмулятору PDC.
Таким образом, когда эмулятор PDC недоступен, возрастает число звонков от пользователей, испытывающих проблемы с сетевым входом. Подробнее об обнов лении доменов Windows NT 3.51 и Windows NT 4.0 Ч в книге Microsoft Windows 2000 Server Deployment Planning Guide (Microsoft Press, 2000).
Хозяин инфраструктуры Предположим, Вы добавили пользователя в группу в том же домене средствами ос настки Active Directory Users and Computers (Active Directory -- пользователи и ком пьютеры). He отключаясь от этого контроллера домена, раскройте узел группы - Вы увидите список ее членов и в том числе только что добавленного пользователя. Пе Управление операциями одиночного хозяина ГЛАВА рсименивав объект пользователь (то есть, изменив его атрибут сп) и затем прове рив список членов группы. Вы увидите, что имя пользователя изменилось.
Когда пользователь и группа размещены в разных доменах, новое имя пользовате ля отобразится в группе не сразу: какое-то время в оснастке Active Directory Users and Computers па вкладке Members (Члены группы) диалогового окна свойств группы в поле Name (Имя) будет отображаться старое имя пользователя. Это есте ственная задержка, присущая распределенной системе с независимо функциониру ющими сайтами.
За обновление междомснных ссылок группа Ч пользователь при переименова нии членов группы отвечает хозяин инфраструктуры. Он изменяет эти ссылки ло кально, а затем реплицирует внесенные изменения на остальные контроллеры до мена. Если хозяин инфраструктуры недоступен, обновления откладываются.
Подробнее о просмотре состава групп Ч в справочной системе Windows 2000 Server.
Размещение ролей хозяина операций При установке Windows 2000 назначает роли хозяев операций контроллерам доме на самостоятельно. Это годится для леса, содержащего несколько контроллеров домена, относящихся к одному сайту. В лесе с большим числом контроллеров или с несколькими сайтами необходимо спланировать размещение ролей хозяина опе раций в соответствии с топологиями сети и репликации, Планирование размещения хозяев операций Планирование размещения ролей лучше выполнять отдельно для каждого домена.
Если в домене только один контроллер, то ему принадлежат все роли в домене. В ином случае следует выбрать два контроллера -- прямых партнеров репликации, входящих в состав хорошо организованной сети. Для доменов смешанного режима рекомендуется, чтобы эти контроллеры находились в одном сайте. Подробнее об этом Ч в разделе Особенности работы хозяев операций далее в этой главе.
Поиск партнеров репликации Для поиска прямых партнеров репликации контроллера домена применяется осна стка Active Directory Sites and Services (Active Directory Ч сайты и службы). Что бы выбрать контроллер домена, перейдите к контейнеру Sites и найдите сайт, к ко торому относится данный контроллер. Затем в контейнере Servers перейдите к объекту сервер контроллера домена. Раскройте этот объект и щелкните объект NTDS Settings. В области сведений отобразится список объектов подключений.
Атрибут From-Server (С сервера) каждого такого объекта указывает па прямого партнера репликации контроллера домена.
Выбор контроллеров домена Если два выбранных контроллера домена прямых партнеров репликации распо ложены в одном сайте, между ними существует надежная связь. Если же они отно сятся к разным сайтам, рекомендуется соединить эти сайты сетью, обеспечивающей возможность репликации постоянно, а не только в определенные часы.
Один из выбранных контроллеров можно назначить хозяином операций, а другой Ч резервным хозяином операций. Резервный хозяин операций используется при от Служба каталогов Active Directory 308 ЧАСТЬ казе основного (подробнее Ч в разделе Устранение неполадок хозяина операций далее в этой главе).
Назначение ролей в домене В небольших доменах следует назначать роли хозяина относительных идентифи каторов и эмулятора PDC контроллеру домена, исполняющему роль хозяина опе раций. В домене очень большого размера следует снизить пиковые нагрузки на эму лятор PDC, назначив данные роли разным контроллерам, каждый из которых яв ляется прямым партнером репликации резервного хозяина операций. Следует со хранять эти роли на одном контроллере, пока вследствие увеличения нагрузки на хозяина операций не потребуется разделить эти роли.
Роль хозяина инфраструктуры следует назначить контроллеру домена, не являю щемуся глобальным каталогом, но имеющему хорошую связь с сервером глобаль ного каталога (из любого домена). Оптимальное расположение мастера инфраструк туры - в одном сайте с глобальным каталогом. Такой основной хозяин инфраструк туры используется, пока вследствие увеличения нагрузки на контроллер не потре буется разделить эти роли.
Примечание Роль хозяина инфраструктуры должен выполнять контроллер домена, не являющийся сервером глобального каталога, иначе междоменные ссылки на объекты в данном домене обновляться не будут. Если все контроллеры домена серверы глобального каталога, роль хозяина инфраструктуры можно назначать любому из них.
Назначение ролей в лесе После планирования всех ролей для каждого домена, следует распланировать роли в лесе. Роли хозяина схемы и хозяина именования доменов следует всегда назна чать одному контроллеру домена. Для лучшей производительности эти роли сле дует назначать контроллеру домена, имеющему надежную связь с компьютерами администраторов или группы, ответственных за обновления схемы и создание но вых доменов. Этот контроллер домена должен быть сервером глобального катало га, поскольку это необходимо хозяину именования доменов. Чтобы упростить уп равление, обе упомянутые роли можно назначить основному хозяину операций, являющемуся сервером глобального каталога, Планирование развития В общем случае при росте леса не требуется изменять расположение ролей хозяев операций. Но если планируется понизить роль контроллера домена до рядового сервера, статус сервера глобального каталога до контроллера домена или изменить пропускную способность сети, то следует пересмотреть план и соответственно из менить назначения ролей хозяев операций.
Перемещение хозяев операций Этот процесс подразумевает передачу роли с одного контроллера домена на другой при содействии текущего владельца роли. Для внедрения плана назначения ролей Вам придется переместить каждую роль из стандартного местоположения в нуж ное Вам. В зависимости от перемещаемой роли, данная операция выполняется сред ствами одной из трех оснасток Active Directory:
Управление операциями одиночного хозяина ГЛАВА 7 Х для перемещения роли хозяина схемы нужна оснастка Active Directory Schema (Схема Active Directory);
Х для перемещения роли хозяина именования доменов применяется оснастка Active Directory Domains and Trusts (Active Directory Ч домены и доверие);
Х для перемещения уникальных ролей домена Ч оснастка Active Directory Users and Computers (Active Directory Ч пользователи и компьютеры).
Для передачи роли в дереве консоли соответствующей оснастки щелкните правой кнопкой мыши контроллер домена, который получит роль, и выберите в контекст ном меню команду Operations Master (Хозяин операций). Для уникальных ролей домена перейдите на вкладку, соответствующую конкретной перемещаемой роли.
В окне свойств отображаются следующие элементы: Current Focus (Текущее мес тоположение) Ч контроллер домена, к которому в данный момент подключена ос настка, Current Operations Master (Текущий хозяин операций) Ч контроллер до мена, которому в настоящее время принадлежит роль хозяина схемы и состояние подключения текущего владельца роли. Щелкните кнопку Change (Сменить) и за тем - ОК.
Если текущий владелец роли доступен, перемещение выполняется в течение не скольких секунд. Если этого не произошло, значит, контроллер домена недоступен.
В этом случае попробуйте устранить неполадку (о том, как это сделать, в следу ющем разделе).
Подробнее о процедурах перемещения ролей хозяина операций Ч в справочной системе Windows 2000 Server.
Средства оснасток Active Directory позволяют получить сведения о ролях контрол леров домена. Для этого выберите соответствующую оснастку Active Directory [на пример, о роли хозяина RID Вы найдете сведения в консоли Active Directory Users and Computers (Active Directory пользователи и компьютеры)], щелкните в де реве консоли корневой узел оснастки правой кнопкой мыши и в контекстном меню выберите команду Operations Master (Хозяин операций). В диалоговом окне Ope rations (Хозяин операций) отображается имя и состояние контроллера домена, к которому в данный момент подключена оснастка.
Устранение неполадок хозяина операций Когда хозяин операций недоступен, прежде всего следует определить причину и время, необходимое для ее устранения.
Если сбой непродолжителен, обычно достаточно подождать, пока хозяин операций станет доступен.
Если Вы предполагаете, что простой будет долгим, лучше передать роль хозяина операций другому контроллеру домена. Под принудительным перемещением рпли (seizure) подразумевается ее передача новому хозяину безотносительно наличия и доступности текущего владельца роли. Такую операцию рекомендуется выполнять в крайнем случае. Решение зависит от конкретной роли и времени, в течение кото рого эта роль остается недоступной.
Неполадки эмулятора РОС Отказ контроллера домена Ч эмулятора PDC, влияет на работу всех пользовате лей и администраторов. В частности, конечные пользователи компьютеров под Служба каталогов Active Directory 310 ЧАСТЬ управлением Windows NT Workstation 3.51, Windows NT 4.0, Windows 95 или Windows 98 без установленного клиента Active Directory не смогут изменить свой пароль, не обращаясь к эмулятору PDC. Но истечении срока действия пароля вход в систему пользователям будет запрещен. Поэтому, если эмулятор PDC стал недо ступным, следует немедленно передать его роль другому контроллеру.
Если эмулятор PDC недоступен длительное время и в его домене есть клиенты, не поддерживающие Active Directory, передайте роль эмулятора PDC резервному хо зяину операций.
Обычное и принудительное перемещение ролей выполняется средствами одного и того же пользовательского интерфейса, однако при принудительном перемещении требуется дополнительное подтверждение. Подтверждайте передачу роли, только если Вы уверены, что эмулятор PDC будет долгое время недоступен. Когда перво начальный эмулятор PDC станет доступным, верните роль се прежнему владельцу.
Неполадки хозяина инфраструктуры Временная недоступность хозяина инфраструктуры незаметна для пользователей, Ее не заметят и администраторы сети, если только они не выполняют переимено вание или перемещение множества учетных записей. В большинстве случаев вре менный отказ хозяина инфраструктуры пе требуется устранять в экстренном по рядке.
При длительном отсутствии хозяина инфраструктуры следует передать его роль.
Для этого рекомендуется выбрать контроллер домена, не являющийся глобальным каталогом, но надежно соединенный с сервером глобального каталога (в любом до мене). Желательно, чтобы этот контроллер домена располагался в том же сайте, что и текущий сервер глобального каталога. Близость нового хозяина инфраструктуры к предыдущему хозяину значения не имеет. Выбрав контроллер, передайте ему роль хозяина инфраструктуры.
Обычное и принудительное перемещение ролей выполняется средствами одного и того же пользовательского интерфейса, однако при принудительном перемещении требуется дополнительное подтверждение. Подтверждайте передачу роли, только если Вы уверены, что хозяин инфраструктуры останется недоступным долгое вре мя. Когда первоначальный хозяин инфраструктуры станет доступным, верните роль се прежнему владельцу.
Неполадки других хозяев операций Неполадка хозяина схемы, хозяина именования доменов или хозяина RID обычно не отражается на конечных пользователях и не мешает администрированию. В большинстве случаев эта неполадка не требует немедленного устранения.
Тем не менее при длительном отсутслчши хозяина операций его роль следует пере дать резервному контроллеру домена. Однако следует иметь в виду, что передача любой из этих ролей Ч радикальное решение, которое рекомендуется только при неустранимом отказе хозяина операций, например, когда контроллер физически уничтожен и его нельзя восстановить с архивной копии.
При перемещении ролей хозяина схемы, хозяина RID или хозяина именования до менов другому контроллеру следует позаботиться, чтобы прежний владелец роли ни в коем случае не стал доступен снова. Перед принудительным перемещением роли убедитесь, что этот контроллер домена надежно отключен от сети.
Управление операциями одиночного хозяина ГЛАВА 7 База данных контроллера, которому передается роль, должна полностью соответ ствовать текущему состоянию сети с учетом обновлений, выполненных предыду щим владельцем роли. Из-за задержки репликации, возможно, это будет не так.
Чтобы проверить состояние обновлений для контроллера домена, воспользуйтесь служебной программой командной строки Repadmin (из комплекта ресурсов), ис пользуемой для диагностики репликации. Repadmin хранится на установочном ком пакт-диске Windows 2000 Server. Она позволяет определить наличие на контролле ре домена самых последних обновлений. Подробнее об использовании Repadmin Ч в главе 10 Выявление и устранение неполадок, а также восстановление Active Directory и в справочной системе средств поддержки Windows 2000 Support Tools, Рассмотрим пример использования программы Repadmin для проверки наличия на контроллере домена последних обновлений. Предположим, что контроллер server05 Ч это хозяин RID домена reskit.com, serverlO Ч резервный хозяин опера ций, a server 12 - второй из двух контроллеров домена reskit.com. Выполняются сле дующие команды:
С:\>repadmln /showvector ac=reskit,dc=com serverlO. reshit.com New-York\server05 л USN San-Francisco\server12 e USN C:\>repadmln /showvector dc=reskit,ac=com server12.reskit.com New-York\server05 9 USN Chicago\serveMO e USN Примечание Команды, которые вводит пользователь, выделены курсивом.
Для пас важны лишь строки, относящиеся к серверу serverOS. Степень обновления сервера serverlO по сравнению с server05 (servcr05 й USN 2604) больше, чем ана логичное обновление serverl2 по сравнению с server05 (server05 СФ USN 2590). Это означает, что серверу serverlO можно без проблем передать роль хозяина RID, ра нее принадлежащую серверу server05. Если степень обновления сервера serverlO была бы меньше, чем у server! 2, следовало бы подождать, пока данные на сервере serverlO обновятся в процессе стандартной репликации, или сделать это посред ством принудительной репликации командой Repadmin /sync /force.
Определив, что владелец роли содержит самые последние обновления, надо прину дительно переместить роль хозяина операций, запустив служебную программу ко мандной строки Ntdsutil:
:\>ntdsutil ntdsutil: roles fsmo maintenance: connections server connections: connect to server10.reskit.com binding to serverlO. reskit,com...
Connected to server10.reskit.com using credentials of locally logged on user server connections: quit fsrno maintenance: seize RID master Server "server10.reskit.com" knows about 5 roles Schema - CN=NTDS Settings,CN=server04,CN=Servers, CN=New-York,CN=Sites,CN=Configuration,DC=reskit,DC=com Domain - CN=NTDS Settings,CN=server04,CN=Servers, CN=New-York,CN=Sites,CN=Configuration,DC=reskit,DC=com PDC - CN=NTDS Settings,CN=server10,CN=Servers, Служба каталогов Active Directory 312 ЧАСТЬ CN=Chicago,CN=Sites,CN=Configuration,DC=reskit,DC=com RID - CN=NTDS Settings,CN=server10,CN=Servers, CN=Chicago,CN=Sites,CN=Configuration, DC=reskit,DC=com Infrastructure - CN=NTDS Settings,CN=server12,CN=Servers, CN=San-Francisco,CN=Sites,CN=Configuration,DC=reskit,DC=com fsmo maintenance: quit ntdsutil: quit C:\> Примечание Команды, которые вводит пользователь, выделены курсивом.
Подробнее об использовании Ntdsutil Ч в справочной системе средств поддержки Windows 2000 Support Tools и в приложении В Ntdsutil.exe Ч служебная програм ма диагностики Active Directory.
Назначение ролей средствами Ntdsutil Служебная программа Ntdsutil позволяет передавать и принудительно перемещать роли хозяев операций. Использование этой программы, возможно, покажется Вам удобнее, чем средства служебных программ с графическим интерфейсом, так как вводить команды иногда проще и быстрее, чем работать с несколькими окнами, Принудительное перемещение ролей хозяина схемы, хозяина именования доменов и хозяина R1D выполняется только средствами Ntdsutil. Программа сначала пыта ется договориться по-хорошему и передать роль от текущего хозяина. Если же существующий хозяин операций недоступен, Ntdsutil принудительно присваивает роль новому владельцу.
Для просмотра справочной информации о Ntdsutil введите в приглашении этой программы знак вопроса (?). Ниже приведен пример передачи роли хозяина име нования доменов (команды, которые вводит пользователь, выделены курсивом):
G:\>ntdsutil ntdsutil: ?
? - Print this help information Authoritative restore - Authoritatively restore the DIT database Domain management - Prepare for new domain creation Files - Manage NTDS database files Help - Print this help information IPDeny List - Manage LDAP IP Deny List LDAP policies - Manage LDAP protocol policies Metadata cleanup - Clean up objects of decommissioned servers Popups Is - (en/dis)able popups with "on" or "off" Quit - Quit the utility Roles - Manage NTDS role owner tokens Security account management - Manage Security Account Database -Duplicate SID Cleanup Semantic database analysis - Semantic Checker ntdsutil: roles fsmo maintenance: ?
7 - Print this help information Connections - Connect to a specific domain controller Help - Print this help information Quit - Return to the prior menu ГЛАВА 7 Управление операциями одиночного хозяина Seize domain naming master - Overwrite domain role on connected server Seize infrastructure master - Overwrite infrastructure role on connected server Seize PDC - Overwrite PDC role on connected server Seize RID master - Overwrite RIO role on connected server Seize schema master - Overwrite schema role on connected server Select operation target - Select sites, servers, domains, roles and Naming Contexts Transfer domain naming master - Make connected server the domain naming master Transfer infrastructure master - Make connected server the infrastructure master Transfer PDC - Make connected server the PDC Transfer RID master - Make connected server the RID master Transfer schema master - Make connected server the schema master fsmo maintenance: connections server connections: ?
? - Print this help information Clear creds - Clear prior connection credentials Connect to domain Xs - Connect to DNS domain name Connect to server %s - Connect to server, DNS name or IP address Help - Print this help information Info - Show connection information Quit - Return to the prior menu Set creds %s Ks %s - Set connection creds as domain, user, pwd Use "NULL" for null password server connections: connect to server reskitl Binding to reskitl...
Connected to reskitl using credentials of locally logged on user server connections: quit fsnto maintenance;
transfer domain naming master Server "reskitl" knows about 5 roles Schema - CN=NTDS Settings,CN=RESKIT1,CN=Servers.CN=Washington,CN=Sites,CN=Configuration,DC=reskit,OC=con Domain - CN=NTDS Settings,CN=RESKIT1,CN=Servers,CN=Washington,CN=Sites,CN=Configuration,DC=reskit,DC=com PDC - CN-NTDS Settings,CN=RESKIT1,CN=Servers,CN=Washington,CN=Sites,CN=Configuration,DC=reskit,DC=com RID - CN=NTDS Settings,CN=RESKIT1,CN=Servers,CN=Washington,CN=Sites,CN=Configuratlon,DC=reskit,DC=com Infrastructure - CN=NTDS Settings,CN=RESKIT1,CN=Servers,CN=Washington,CN=Sites,CN=Configuration,DC=reskit,DC=com fsmo maintenance: quit ntdsutll: quit Disconnecting from reskitl...
C:\> В этом примере после ввода знака вопроса (?) Ntdsutil выводит список доступных команд и их описание. Для передачи роли надо цвести команду roles, позволяю щую перейти в меню fsmo maintenance. Повторно набрав знака вопроса (?), Бы по лучите список команд этого данного раздела. Прежде чем перемещать роль хозяи на операций, Вам следует командой connect to server подключиться к контролле ру домена, которому предполагается передать роль (в нашем примере Ч reskitl).
Затем, выполнив командой quit переход обратно в меню управления хозяевами опе раций, введите команду transfer domain naming master. Откроется окно с предло Служба каталогов Active Directory 314 ЧАСТЬ жением подтвердить передачу роли хозяина именования доменов (в протоколе ра боты программы не показано).
Примечание Для выполнения команд с помощью Ntdsutil необходимы соответству ющие разрешения. Подробнее об управлении полномочиями по назначению ролей хозяина операций Ч в следующем разделе.
Кроме того, программа Ntdsutil позволяет узнать, какой компьютер является теку щим хозяином операций. Для этого в меню Roles введите команду Select Operation Target, а затем - команду List roles for connected server. Программа предоставит сведения обо всех текущих хозяевах операций.
Подробнее об использовании Ntdsutil - в справочной системе средств поддержки Windows 2000 Support Tools и в приложении В Ntdsutil.exe Ч служебная програм ма диагностики Active Directory Управление доступом к назначению ролей В Active Directory хозяевам операций присваивается атрибут FSMO-Role-Owner схемы Active Directory. Отображаемое имя LDAP данного атрибута fsmoRoleOwner. Атрибут FSMO-Role-Owner Ч однозначный и содержит ссылку па объект NDTS-DSA, представляющий конкретный контроллер домена. Вот пример составного имени такого объекта NTDS-DSA:
CN=NTDS Settings,CN=RESKIT1,CN=Servers,CN=Washington,CN=Sites,CN=Configuration,DC=reskit, DOcom где RESKIT1 - имя контроллера домена Reskit.com в сайте Washington.
В принципе, атрибуту FSMO-Role-Ownership любого объекта каталога можно за дать значение, но в Active Directory это делается только для специально выделен ных объектов Ч по одному на каждую роль в каталоге. Этот объект называется лобъектом роли. Значение атрибута FSМО-Role-Ownership объекта роли Ч это имя контроллера домена, исполняющего соответствующую роль. Далее перечисле ны составные имена объектов ролей:
Х хозяин схемы:
CN^Schema^N^onfiguratton.-CKOpHeao^OMe^ (корень раздела схемы);
Х хозяин именования доменов:
CN=PartitionshCN=Configuration,
Х хозяин RID:
CN=RID Manager$,СН=Зузет,<имя_домена> (в разделе домена);
Х эмулятор РОС:
<имя_домена> {в разделе домена);
Х хозяин инфраструктуры:
CN=Infrestructure,<имя_домена> (в разделе домена).
Например, в лесе Reskit.com, объединяющем домены Reskit.com, Na.reskit.com и Eur.reskit.com, существует одиннадцать объектов ролей со следующими составны ми именами:
Управление операциями одиночного хозяина ГЛАВА Х хозяин схемы в лесе Reskit.com:
CN=Schema,CN-Configuration,DC=reskit,DC=com;
Х хозяин именования доменов в лесе Reskit.com:
CN=Partitions,CN=Configuration,DC=reskit,DC=com;
Х хозяин относительных идентификаторов в домене Reskit.com:
CN=RID Managers, CN=Systefn,DC=reskit,DC=com;
Х хозяин относительных идентификаторов в домене Na.reskit.com:
CN-RID Manager$,CN=System,DC=na,DC=reskit,DC=com;
Х хозяин относительных идентификаторов в домене Eur.reskit.com:
CN=RID Manager$,CN=System,DC=eur,DC=reskit,DC=com;
Х эмулятор PDC в домене Reskit.com:
DC=reskit,DC=com;
Х эмулятор PDC в домене Na.reskit.com:
DC=na,DC=reskit,DC=com;
Х эмулятор PDC в домене Eur.reskit.com:
DC=eur,DC=reskit,DC=com;
Х хозяин инфраструктуры в домене Rcskit.com:
CN=Infrastructure,DC=reskit,DC=com;
Х хозяин инфраструктуры в домене Ka.reskit.com:
CN=Infrastructure,DC=na,DC=reskit,DC=com;
Х хозяин инфраструктуры в домене Eur.reskit.com:
CN=Infrastructure,DC=eur,DC=reskit,DC=com.
Примечание Значение атрибута FSMО-Role-Owner объекта, не являющегося объек том роли, никак не влияет на работу Active Directory Управление передачей ролей Как мы уже говорили, передача роли хозяина операций выполняется при наличии и совместна с текущим владельцем. Для передачи роли оба контроллера домена дол жны быть доступны и соединены между собой по сети.
Перемещение роли управляется специальным разрешением, определенным для объекта роли на хозяине операций, которому эта роль передается. Для каждой роли существуют свои индивидуальные разрешения, и они предоставляются определен ным группам администраторов:
Х хозяин схемы Ч разрешение Change Schema Master (Смена хозяина схемы) по умолчанию предоставляется группе Schema Admins (Администраторы схемы);
Х хозяин именования доменов Ч разрешение Change Domain Master (Смена хозя ина операций домена) но умолчанию предоставляется группе Enterprise Admins (Администраторы предприятия);
Служба каталогов Active Directory 316 ЧАСТЬ Х хозяин относительных идентификаторов Ч разрешение Change RID Master (Смена хозяина RID) no умолчанию предоставляется группе Domain Admins (Администраторы домена);
Х эмулятор PDC Ч разрешение Change PDC (Смена РОС) по умолчанию предос тавляется группе Domain Admins;
Х хозяин инфраструктуры Ч разрешение Change Infrastructure Master (Смена хо зяина инфраструктуры) по умолчанию предоставляется группе Domain Admins.
Попытка передать роль при отсутствии соответствующих разрешений вызовет ошибку.
При необходимости разрешается сменить группу администраторов, обладающую правом на перемещение определенной роли. Например, можно создать новую груп пу с именем Domain Naming Role Admins*, обладающую исключительным разре шением на передачу роли хозяина именования доменов. Создайте эту группу и в окне программы ADSI Edit найдите объект роли хозяин именования доменов, откройте окно свойств этого объекта, удалите разрешение Change Domain Master (Смена хозяина операций домена) для группы Enterprise Admins (Администрато ры предприятия) и добавьте аналогичное разрешение для группы Domain Naming Role Admins. Таким образом, удается четко контролировать группу администрато ров, обладающих разрешением на перемещение роли хозяина именования доменов.
Определив, кто имеет разрешение на передачу роли, Вы никак не повлияете на то, кто имеет, право использовать эту роль. В этом примере члены группы Domain Naming Admins могут передавать роль хозяина именования доменов, но им не раз решено создавать объекты перекрестных ссылок эта операция разрешена только группе Enterprise Admins.
Подробнее о назначении разрешений управления доступом в главе 12 Управле ние доступом и в справочной системе Windows 2000 Server.
Примечание В корректно настроенном каталоге право на перемещение ролей хозя ев операций должна иметь лишь небольшая группа администраторов.
Управление принудительным перемещением ролей Как мы говорили в предыдущих разделах, принудительное перемещение роли это ее передача новому хозяину безотносительно наличия и доступности текущего вла дельца роли. Обычно такую операцию рекомендуется выполнять в исключитель ных случаях, хотя иногда без этого не обойтись.
Для управления принудительным перемещением ролей используются описанные выше разрешения управления обычной передачей ролей, а также разрешение Write fsmoRoleOwner property (Запись fsmoRoleOwner), определенное для объекта роли на новом хозяине. Для принудительного перемещения роли необходимы оба эти разрешения Ч на смену выбранной роли и на запись атрибута fsmoRoleOwner. По умолчанию разрешение на запись fsmoRoleOwner предоставляется тем же группам, что и разрешение на смену хозяина операций.
Размещение ролей с помощью сценариев Как обычное, так и принудительное перемещение ролей хозяина операций разре шается выполнять программно средствами сценариев на языке Microsoft Visual Basic Script.
ГЛАВА 7 Управление операциями одиночного хозяина Перемещение ролей с использованием сценариев В Active Directory передача роли хозяина операций выполняется как LDAP-onepa ция по обновлению корневого операционного атрибута rootDSE на контроллере до мена, которому передается роль. Каждой роли соответствует свой атрибут rootDSK:
Х becomeSchemaMaster;
Х become DomainMaster;
Х become RidMaster;
Х becomePdc;
Х becomelnfmstructureMaster.
Подробнее об атрибуте rootDSE Ч в главе 2 Хранение данных в Active Directory*..
Например, выполнение на контроллере домена с помощью команды Cscript следу ющего сценария вызывает перемещение роли хозяина именования доменов па этпт контроллер:
Set dse = GetObject("LDAP://localnost/RootDSE") dse.Put "becomeDomainMaster", dse.Setlnfo Принудительное перемещение ролей с использованием сценариев В Active Directory принудительное перемещение роли хозяина операций выполня ется как LDAP-операция по обновлению атрибута FSMO-Role-Owner объекта роли па контроллере домена, которому передается роль. Например, выполнение на кон троллере домена с помощью команды Cscript следующего сценария приведет к при нудительному перемещению на этот контроллер роли хозяина именования доме нов. При неудаче перемещения роли система выведет сообщение об ошибке.
Dim dse, roleObject, ntdsDsa Set dse = GetObject("LDAP://localhost/RootDSE") Set roleObject = 6etObject( "LDAP://localhost/" & "CN=Partitions," & dse.GetC'configurationNamingContext")) Set ntdsDsa = dse.Get("dsServiceName") roleObject.Put "fSMORoleQwner", ntdsDsa roleObject.SetInfo Подробнее о сценариях Microsoft Visual Basic Script Ч в справочной системе Windows 2000 Resource Kit Tools на компакт-диске Windows 2000 Resource Kit.
Особенности работы хозяев операций В этом разделе мы приводим вопросы, которые возникают чаще всего. Ответы на них помогут Вам глубже понять, как осуществляется управление хозяевами операций.
Х Почему при создании большого числа объектов Ч участников безопасности хозя ин RID обязательно должен быть доступным?
При создании участника безопасности контроллер домена присваивает ему иден тификатор безопасности (security identifier, SID) Windows NT. Последний состо ит из SID домена, одинакового для всех создаваемых в домене идентификаторов безопасности, и RID, уникального для каждого S1D, создаваемого в домене.
Служба каталогов Active Directory 318 ЧАСТЬ У каждого контроллера домена Windows 2000 имеется пул RID, из которого выделяются относительные идентификаторы создаваемым им участникам безо пасности. Кроме того, у домена имеется пул RID, никогда не выделявшихся кон троллерам домена. Если количество RID в пуле контроллера домена меньше определенного значения, он в фоновом режиме запрашивает дополнительные RID. Эти запросы направляются хозяину относительных идентификаторов до мена, в ответ последний перемещает дополнительные RID из пула домена и в пул относительных идентификаторов контроллера, сделавшего запрос.
Почему перемещение объектов в другие домены возможно лишь с хозяина RID до мена ?
В Active Directory разрешается перемещать объекты между доменами. При этом объект обязательно перемещать с контроллера хозяина RID домена. Это по зволяет предотвратить создание в разных доменах двух объектов с одинаковым идентификатором, что возможно при перемещении объекта одновременно с двух контроллеров домена в два разных домена.
Почем// нельзя совмещать на одном компьютере хозяин инфраструктуры и сер вер глобального каталога?
Если объект на одном контроллере домена ссылается на объект, расположенный на другом контроллере, ссылка представляется в виде записи, содержащей GUID, SID (для ссылки на участника безопасности) и составное имя объекта, на который ссылаются. При перемещении этого объекта между доменами его SID изменяется, a GUID Ч нет;
составное имя изменяется в любом случае.
Хозяин инфраструктуры домена периодически проверяет свою реплику данных каталога на наличие ссылок на объекты, отсутствующие на контроллере доме на. Сведения о составном имени и SID объектов, на которые указывают ссылки, запрашиваются па сервере глобального каталога. При изменении этой инфор мации хозяин инфраструктуры вносит соответствующие изменения в свою ло кальную реплику и реплицирует новые значения на другие контроллеры своего домена.
При совмещении на одном компьютере хозяина инфраструктуры и сервера гло бального каталога первый не сможет ничего обновить, так как глобальный ката лог не хранит ссылки на объекты на других компьютерах. Это связано с тем, что на сервере глобального каталога хранятся частичные реплики всех объектов леса, Почему обязательно совмещать хозяин именования доменов и сервер глобальной) каталога?
Создавая новый объект домен, хозяин именования доменов должен убедить ся, что не существует других объектов (лдомен или других) с указанным име нем. Для этого он размещается на сервере глобального каталога, содержащем частичные реплики всех объектов леса.
Что нужно учесть при назначении ролей в доменах смешанного режима?
В доменах смешанного режима, содержащих резервные контроллеры, резервный хозяин эмулятора PDC надо разместить в одном сайте с текущим эмулятором PDC. Таким образом, не придется выполнять процедуру полной синхронизации с резервными контроллерами домена в случаях, когда роль эмулятора PDC при нудительно перемещается на резервный хозяин операций.
ГЛАВА 7 Управление операциями одиночного хозяина Чти делать при -неудачном перемещении роли?
При перемещении роли сначала обновляется текущий, а затем Ч новый владе лец роли. Если на втором этапе произойдет сбой, роль новый владелец не полу чит. Возможны два варианта завершения перемещения роли:
Х выполнить перемещение повторно;
Х подождать, пока в базу данных нового владельца реплицируются обновления.
сделанные на текущем владельце роли (это не потребует Вашего участия, однако такое перемещение роли займет намного больше времени), Что происходит с ролями хозяев операций при архивировании и восстановлении?
При архивировании контроллера домена его роли также архивируются. Поэто му при восстановлении контроллера с архива восстанавливаются и принадле жавшие ему на момент архивирования роли.
Что происходит с ролями хозяина операций при понижении роли контроллера домена до рядового сервера (то есть при удалении с него Active Directory)?
При удалении Active Directory с контроллера домена, исполняющего роль хозя ина операций, контроллер пытается лизбавиться от своих ролей. Для каждой выполняемой им роли он находит другой подходящий контроллер домена и пе редает ему роль. Если какую-нибудь из ролей передать не удастся, удаление Active Directory выполнено не будет.
Не следует полагаться на стандартные процедуры перемещения ролей при уда лении Active Directory с контроллера домена. Лучше всего до начала удаления самостоятельно переместить все роли на другие контроллеры домена.
ГЛАВА Наблюдение за производительностью в Active Directory Наблюдение за службой каталогов Active Directory позволяет проверить, как она выполняет возложенные на нее задачи. Например, для обеспечения оптимальной производительности необходим контроль получения всеми сетевыми серверами реаликативных изменений каталогов и своевременного обновления реплик. Для мониторинга репликации и других целей используются оснастки консоли Microsoft Management Console (ММС), служебные программы командной строки из комплек та ресурсов Microsoft Windows 2000 Server и сценарии Microsoft Visual Basic.
В этой главе Средства оценки производительности Счетчики системного монитора Средства оценки производительности Для наблюдения за многими процессами службы каталогов Active Directory можно комбинировать оснастки ММС и средства наблюдения системы (в том числе и про граммы командной строки), а также сценарии Visual Basic. В частности, эти сред ства позволяют наблюдать за топологией репликации, работой системы доменных имен (Domain Name System, DNS), задержкой репликации, временем соединения и выделением относительных идентификаторов (Relative ID, RID).
Оснастки ММС В консоли ММС системы Windows 2000 имеется множество оснасток. Ссылки на них Вы найдете в подменю Administrative Tools (Администрирование) основного меню Start (Пуск). Оснастка Microsoft Active Directory Sites and Services (Active Directory - сайты и службы) позволяет просматривать сайты и относящуюся к ним информацию, а также изучать и изменять топологию репликации. Оснастка Per formance (Производительность) позволяет оценивать работу и производительность Наблюдение за производительностью в Active Directory ГЛАВА 8 Active Directory в графическом виде на основе выбранных показателей, называе мых счетчиками. Показания этих счетчиков можно наблюдать в реальном времени или регистрировать в журнале, а потом распечатать эти данные для дальнейшего изучения. И наконец, оснастка Event Viewer (Просмотр событий) позволяет про сматривать файлы журналов и сообщения об ошибках, возвращенные приложени ями.
Оснастка Performance Оснастка Performance (Производительность) позволяет наблюдать за работой ло кальных и удаленных компьютеров в любой точке сети и подводить итог работы аа заданные интервалы времени. В ней имеется ряд счетчиков для наблюдения за ис пользованием ресурсов в реальном времени, кроме того, ее средствами можно со хранять результаты в файле для последующего анализа и сравнения с ранее запи санными данными. Обладая необходимыми разрешениями. Вы можете наблюдать за использованием ресурсов на других серверах под управлением Windows 2000.
Средствами этой оснастки выполняется оценка базовой производительности (base line) системы и настройка регистрации в журнале событий о превышении заддн ных базовых параметров.
Ярлык оснастки Performance* расположен в меню Administrative Tools (Админис трирование), а сама оснастка содержит два инструмента - System Monitor (Сис темный монитор) и Performance Logs and Alerts (Оповещения и журналы произво дительности).
Подробнее о средствах наблюдения производительности - в книге Сопровожде ние сервера. Ресурсы Microsoft Windows 2000 Server (Русская Редакция, 2001).
Раздел System Monitor Компонент System Monitor (Системный монитор) позволяет в реальном времени просматривать данные о производительности в виде диаграмм или отчетов, сохра нять собранные данные в файлы и оповещать о важных событиях в системе. Эти данные описаны как объекты производительности, которые обычно называются так же, как компонент, генерирующий данные. Например, объект Processor (Процессор) представляет собой набор данных производительности процессоров в локальной системе. Для наблюдения за работой Active Directory предусмотрена специальная NTDS.
группа объектов производительности Для наблюдения за динамикой работы объектов производительности в оснастке System Monitor применяют счетчики для измерения количественных показателей работы объектов производительности. Например, если необходимо узнать, получа ет и применяет ли сервер обновления в ходе репликации каталога, добавьте в осна стку один или несколько счетчиков для объекта NTDS. Средства System Monitor позволяют просматривать информацию счетчиков. Подробнее об использовании System Monitor Ч в справочной системе системного монитора.
Например, при настройке и проверке своевременности репликации между всеми серверами сети применяется счетчик DRA Pending Replication Synchronizations (Ожидающих синхронизации репликации DRA) из объекта NTDS для проверки количества не обработанных синхронизации каталогов, расположенных в очереди * В русской Персии Windows 2000 Server этот ярлык называется Системный монитор. Ч перев.
Служба каталогов Active Directory 322 ЧАСТЬ данного сервера. Этот счетчик наглядно отображает скорость обработки объектов сервером, помогая проверить корректность выполнения сервером репликации.
Pages: | 1 | ... | 5 | 6 | 7 | 8 | 9 | ... | 18 | Книги, научные публикации