С. Реймер, М.

Малкер
Active Directory для Windows Server 2003. Справочник администратора/Пер, с англ. — М.: «СП
ЭКОМ», 2004.— 512 с: ил.

Оглавление
Введение.
Структура книги.
Соглашения, используемые в этой книге.

Часть I. Краткий обзор службы каталога Active Directory Windows Server 2003.
Глава 1. Концепции Active Directory.
Глава 2. Компоненты службы каталога Active Directory.
Глава 3. Active Directory и доменная система имен.
Глава 4. Репликация Active Directory и сайты.

Часть II. Реализация службы Active Directory Windows Server 2003.

Глава 5. Проектирование структуры Active Directory.
Глава 6. Установка Active Directory.
Глава 7. Переход к Active Directory.

Часть III. Администрирование службы каталога Active Directory Windows Server 2003.
Глава 8. Защита Active Directory.
Глава 9. Делегирование администрирования службы Active Directory.
Глава 10. Управление объектами Active Directory.
Глава 11. Введение в групповые политики.
Глава 12. Использование групповых политик для управления программным
обеспечением.
Глава 13. Использование групповых политик для управления компьютерами.

Часть IV. Обслуживание Active Directory Windows Server 2003.

Глава 14. Мониторинг и обслуживание Active Directory.
Глава 15. Восстановление службы каталога в случае сбоя.
Введение
Добро пожаловать в технический справочник по Active Directory для Microsoft Windows Server
2003, являющийся источником информации, которая потребуется вам для проектирования и
реализации службы каталога Active Directory в системе Windows Server 2003. Служба каталога
Active Directory первоначально была выпущена с системой Microsoft Windows 2000. Большинство
концепций Active Directory, реализованных в системе Windows 2000, сохранились и в системе
Windows Server 2003, кроме того, появилось много усовершенствований. Эта книга содержит все,
что вы должны знать об Active Directory, включая детальную техническую информацию и
руководство, предназначенное для планирования, реализации и управления службой Active
Directory в вашей организации. Другими словами, эта книга является универсальным
справочником, содержащим все, чтобы заставить Active Directory работать на вас.

Структура книги
Технический справочник по Active Directory для Microsoft Windows Server 2003 составлен так, чтобы
наиболее понятно описать и объяснить технологии Active Directory. Многие компании не
реализовали Active Directory в системе Windows 2000, поэтому книга не предполагает наличие
глубоких знаний Active Directory у читателей. Книга начинается с описания основ службы
каталога и объяснения того, как служба каталога реализована в Active Directory. Затем
рассказывается, как работает Active Directory, как ее использовать и как управлять ею в вашей
среде.
Книга разделена на четыре части, усложняющиеся по мере накопления вами знаний. В части I
дается краткий обзор терминов Active Directory и концепций. В части II объясняется планирование
и проектирование, необходимые для развертывания Active Directory в вашей среде. После
развертывания службы Active Directory ей нужно управлять, поэтому в части III уточняются
детали, касающиеся управления службой Active Directory, и делается сильный акцент на
безопасность Active Directory и групповых политик. Часть IV, заключительный раздел книги,
посвящена обслуживанию Active Directory.
Часть I, «Краткий обзор службы каталога Active Directory Windows 2003», содержит введение в
концепции и компоненты Active Directory системы Windows Server 2003. Эта версия Active
Directory является последним вариантом службы каталога, поставляемой компанией Microsoft.
Active Directory обеспечивает мощную службу каталога, предназначенную для управления
пользователями, группами и компьютерами, и пред-
лагает безопасный доступ к сетевым ресурсам. Чтобы использовать ее наиболее эффективно, вы
должны понять концепцию Active Directory и принципы ее работы. Эти основы изложены в части
I, которая включает следующие главы.
• В главе 1, «Концепции Active Directory», предлагается краткая история служб каталога,
которые компания Microsoft поставляла как часть операционных систем Windows 2000 и
Windows NT. Далее подробно обсуждаются преимущества Active Directory по сравнению с
предыдущими службами каталога. В этой главе вы найдете также краткий обзор
нововведений, появившихся в системе Windows Server 2003 в дополнение к тем, которая
имелись в Windows 2000.
• В главе 2, «Компоненты Active Directory», дается детальное описание концепций и
компонентов, составляющих Active Directory. В этой главе вы найдете описание
физических компонентов Active Directory, таких как контроллеры домена и схема Active
Directory, и логических компонентов Active Directory, таких как домены, деревья и леса.
• В главе 3, «Active Directory и система доменных имен», приводится описание принципов
функционирования Active Directory. Служба Active Directory глубоко интегрирована с
доменной системой имен (DNS - Domain Name System), и если вы неправильно реализуете
 свою инфраструктуру службы DNS, вы никогда не сможете создать устойчиво
функционирующую службу Active Directory. Глава начинается с краткого обзора
концепций DNS, затем описывается интеграция между Active Directory и DNS, далее
объясняется, как лучше всего реализовать DNS, чтобы обеспечить функционирование
службы разрешения имен, необходимой для работы Active Directory.
• В главе 4, «Репликация Active Directory и сайты», продолжается описание принципов
работы Active Directory. Чтобы понять, как работает Active Directory, нужно знать, как
контроллеры домена Active Directory реплицируют информацию друг у друга. По
умолчанию Active Directory создает устойчивую и избыточную топологию репликации,
также имеются опции, предназначенные для создания оптимальной конфигурации
репликации для вашей компании.
Как только вы изучите основные концепции и компоненты Active Directory, ваш
следующий шаг будет состоять в реализации службы Active Directory в вашей
организации. Часть II, «Реализация Active Directory Windows Server 2003», обеспечит вас
необходимой информацией. Первый шаг в реализации Active Directory состоит в создании
проекта структуры для вашей организации. Такие структурные элементы, как лес, домен,
сайт и организационная единица (OU - Organizational Unit), уникальны для каждой
компании, поэтому создание правильного проекта службы для вашей среды требует
существенных знаний и усилий. Как только проект Active Directory для Windows Server
2003 будет создан, вы можете приступать к установке Active Directory. Многие компании,
реализующие Active Directory для Windows Server 2003, переносят ее с предыдущей версии
службы каталога, особенно часто с версии Microsoft Windows NT 4. Поскольку Active
Directory для Windows Server 2003 отличается от службы каталога Windows NT, то это
перемещение может вызвать сложности. В части II эти темы представлены в следующих
главах.
• В главе 5, «Проектирование структуры Active Directory», дается краткий обзор процесса
проектирования, подготавливающего вашу реализацию Active Directory. Эта глава ведет
вас через весь процесс создания собственного проекта: от нисходящего проектирования к
разработке структуры службы Active Directory. В этой главе обсуждаются все компоненты
вашего проекта, начиная с того, сколько лесов вам следует развертывать, заканчивая тем,
как создавать свою структуру OU.
• В главе 6, «Установка Active Directory», описаны процедуры, необходимые для
инсталляции Active Directory. Она посвящена установке контроллеров домена Active
Directory и включает обсуждение некоторых новых опций, предназначенных для
осуществления этой инсталляции.
• В главе 7, «Переход к Active Directory», приводится информация, необходимая для
модернизации предыдущей службы каталога от Microsoft к Active Directory для Windows
Server 2003. Обновление происходит сложнее, если модернизируется служба каталога
Windows NT, нежели Active Directory системы Windows 2000. Поэтому в данной главе
содержатся, главным образом, вопросы обновления службы каталога от Windows NT к
Active Directory Windows Server 2003, а также модернизации Active Directory Windows
2000.
После развертывания Active Directory вы должны управлять ею так, чтобы обеспечить
максимальную выгоду своей компании. В части III, «Администрирование службы каталога
Active Directory Windows Server 2003», описываются многие административные процессы,
которые вы будете использовать. В части III имеются две основных темы: безопасность и
управление доменом с помощью групповых политик. Вы узнаете, как работает защита в
Active Directory, как можно воспользоваться инфраструктурой безопасности для
делегирования административного управления в пределах вашей структуры Active
Directory. Далее следует обсуждение групповых политик. Одно из основных преимуществ
Active Directory по сравнению с предыдущими службами каталога состоит в том, что она
содержит мощные инструментальные средства для управления рабочими станциями вашей
компании. Централизованное администрирование рабочих станций может сильно
упростить управление сетью и привести к существенному уменьшению затрат на
обслуживание сети. Групповые политики - это основные инструментальные средства,
которые вы будете использовать для управления рабочими станциями вашей сети. Часть III
включает следующие главы.
 • Глава 8, «Защита Active Directory», начинается с описания концепций, лежащих в основе
безопасности Active Directory Windows Server 2003. Основное внимание в этой главе
уделено протоколу Kerberos, который является заданным по умолчанию опознавательным
протоколом в Active Directory.
• В главе 9, «Делегирование администрирования Active Directory», более широко
обсуждается система безопасности Active Directory, подробно описываются способы
делегирования административных разрешений в пределах своего домена. Active Directory
обеспечивает администраторов многими уровнями административных разрешений, а
также позволяет предоставлять административные разрешения только в определенной
части домена. В главе описывается, как реализовать эту функциональность в Active
Directory.
• В главе 10, «Управление объектами Active Directory», вы познакомитесь с управлением
объектами Active Directory: учетными записями пользователей и групп, которые всегда
были частью службы каталога. Active Directory Windows Server 2003 содержит и другие
объекты, такие как inetOrgPerson, универсальные группы, принтеры и общие папки.
• В главе 11, «Введение в групповые политики», дается краткий обзор групповых политик.
Рассказывается о создании и конфигурировании групповых политик, об их применении в
рамках Active Directory, дается основная информация, которая требуется для понимания
следующих двух глав, содержащих конкретные примеры того, что можно делать с
помощью групповых политик.
• В главе 12, «Использование групповых политик для управления программным
обеспечением», уточняется один из способов использования групповых политик. С
помощью групповых политик вы можете инсталлировать программное обеспечение на
компьютерах клиентов и управлять им. Во многих компаниях управление программным
обеспечением представляет собой сложную, отнимающую много времени задачу.
Групповые политики могут использоваться для автоматизации этой задачи, и в данной
главе показано, как это сделать.
• Глава 13, «Использование групповых политик для управления компьютерами»,
посвящается вопросам использования групповых политик для управления компьютерами
клиентов. Групповые политики имеют много опций, предназначенных для управления
рабочими столами, включая блокирование некоторых компонентов рабочих столов,
конфигурирование защиты рабочих станций и ограничение типов приложений, которые
может выполнять пользователь. В главе показывается, как реализовать все эти
возможности.
Последняя часть книги содержит информацию, необходимую для обслуживания
инфраструктуры Active Directory после ее развертывания. Для этого нужно
профилактически отслеживать состояние компонентов Active Directory. Часто в процессе
мониторинга вы можете увидеть первые предупреждения о том, что что-то идет не так, как
надо. Поскольку это происходит независимо от того, как тщательно вы управляете средой,
необходимо иметь план восстановления Active Directory на случай ее отказа. Часть IV,
«Обслуживание службы каталога Active Directory Windows Server 2003», включает
следующие главы.
• В главе 14, «Мониторинг и обслуживание Active Directory», содержится подробная
информация о том, как осуществлять мониторинг Active Directory, включая вопросы
контроля функционирования службы каталога Active Directory и ее репликации. В этой
главе также имеется информация, касающаяся вопросов обслуживания базы данных Active
Directory.
• В главе 15, «Восстановление системы в случае сбоя», содержится информация,
необходимая для создания резервной копии и восстановления Active Directory. Active
Directory является критической службой вашей сети, и вы должны уметь восстановить ее
после любой поломки, которая может влиять на вашу реализацию службы каталога.
Все разделы этой книги посвящены процессу проектирования, развертывания, управления и
обслуживания Active Directory. Однако технический справочник по Active Directory Microsoft
Windows Server 2003 - это, прежде всего, справочник. Если вам надо познакомиться с
определенной темой, вы можете сразу читать соответствующую главу без необходимости читать
предыдущие главы. В некоторых случаях для понимания темы может потребоваться базовая
информация. Например, обсуждение в главе 5 лесов, доменов, организационных единиц и сайтов
предполагает, что вы понимаете эти концепции так, как они представлены в главе 2. Чтобы
понять, как используются групповые политики для развертывания программного обеспечения (см.
главу 12), вы должны понимать компоненты групповой политики, которые обсуждаются в главе
11.

Соглашения, используемые в этой книге

Повсюду в книге вам встретятся специальные разделы, выделяющиеся из основного текста. Эти
разделы привлекают ваше внимание к темам, имеющим специальный интерес и важность, или к
проблемам, с которыми вы обязательно столкнетесь в процессе развертывания службы.
Примечание. Оно используется для выделения текста, который подчеркивает важность
определенной концепции или обращает внимание на специальный случай.
Дополнительная информация. Когда имеется дополнительный материал по теме, находящийся в
других разделах этой книги или во внешних источниках, таких как интернет-сайты или статьи, то
ссылки на эти дополнительные источники помещаются в раздел дополнительной информации.
Предостережение. В этом разделе описываются ситуации, когда ваши действия или их отсутствие
могут повлечь за собой неприятности. Обратите серьезное внимание на эти разделы, потому что
они могут оградить вас от многих неприятностей.
Наилучшая практика. Достижение наивысшего качества развертывания и наиболее устойчивого
функционирования службы каталога часто связано со знанием некоторых деталей. В этих разделах
вы найдете эти знания.
Планирование. Бывают ситуации, когда небольшие запланированные предосторожности стоят
многих часов поиска неисправностей и простоя системы. Такие ситуации описываются в разделах
планирования.
Совет. В этих разделах вам даются советы, касающиеся эконо мии времени или стратегических
действий.
Практический опыт. Со многими проблемами можно легко справиться, если вы знаете, как это
сделать. В этом разделе идет обсуждение таких проблем, и предлагаются сценарии их решения.
Часть I. Краткий обзор службы
каталога Active Directory Windows
Server 2003
Active Directory Microsoft Windows Server 2003 является последней версией службы каталога,
разработанной в компании Microsoft. Служба Active Directory обеспечивает мощный сервис для
управления пользователями, группами и компьютерами, а также предлагает безопасный доступ к
сетевым ресурсам. Чтобы использовать эту службу наиболее эффективно, вы должны понять
основные концепции Active Directory и то, как она работает. Это является целью первой части
данной книги. В главе 1, «Концепции службы каталога Active Directory», вы познакомитесь с тем,
что может делать для вас Active Directory Windows Server 2003. Главы 1 и 2 дают детальное
описание концепций и компонентов, которые составляют Active Directory. Active Directory тесно
интегрирована с доменной системой имен (DNS - Domain Name System), поэтому в главе 3
объясняется эта интеграция и то, почему так важно правильно спроектировать вашу DNS перед
началом реализации службы Active Directory. И в заключение, чтобы понять, как работает Active
Directory, вы должны знать, как контроллеры домена Active Directory реплицируют информацию
друг у друга. Глава 4 объясняет, как работает репликация и как ее можно оптимизировать.

Глава 1. Концепции Active Directory

Операционная система Microsoft Windows Server 2003 содержит самую последнюю реализацию
службы каталога, разработанную компанией Microsoft - Active Directory. Впервые появившись в
Microsoft Windows 2000, служба каталога Active Directory, выпущенная с Windows Server 2003,
была усовершенствована, а ее качество улучшено.
Примечание. В этой книге использование термина «Windows Server 2003» относится к тем
членам семейства продуктов Microsoft Windows Server 2003, которые поддерживают службу
каталога Active Directory: Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise
Edition; Windows Server 2003, Datacenter Edition.
Если вы читаете книгу в своем местном книжном магазине, задаваясь вопросом о новых функциях
Active Directory в Windows Server 2003, то эта глава познакомит вас с ними. Здесь дается также
краткий обзор ключевых функций Active Directory и объясняется, зачем нужно реализо-вывать эти
функции в среде предприятия, управляемого Windows Server 2003. Если вы решили реализовать
службу Active Directory или уже поддерживаете инфраструктуру Active Directory, остальная часть
этой книги даст вам ответы на многие ваши вопросы об этом продукте. Она предоставит
информацию, необходимую для планирования, реализации и сопровождения инфраструктуры
вашей службы Active Directory. Давайте начнем.

Эволюция службы каталога от Microsoft

Active Directory является последней версией службы каталога для операционной системы
Microsoft Windows. Служба Active Directory впервые появилась в Windows Server 2000, и она
является компонентом Windows Server 2003. Потребность в службе каталога в вычислительной
среде компьютеров Microsoft выросла в результате быстрого распространения персональных
компьютеров на рабочих местах. По мере увеличения количества компьютеров, входящих в
рабочую среду корпораций, растет потребность в том, чтобы связать их для совместного
использования ресурсов и дать возможность пользователям взаимодействовать в почти реальном
времени. Но когда компания совместно использует ре-
сурсы, доступные в сети, требуется также каталог (или справочник) пользователей и системы,
предназначенный для назначения ресурсам пользовательских разрешений.

Менеджер LAN для операционных систем OS/2 и MS-DOS

В1987 году первая служба каталога, разработанная для поддержки вычислительной среды
компьютеров Microsoft (операционные системы OS/2 и MS-DOS), основывалась на сетевой
операционной системе Microsoft LAN Manager. Служба каталога системы LAN Manager
обеспечивала основные функциональные возможности для совместного использования файлов и
ресурсов печати, а также для пользовательской защиты, но она не годилась для сред большого
предприятия. Эта служба плохо масштабировалась и не поддерживала доверительные отношения.
Чтобы обратиться к общедоступным ресурсам, сетевые пользователи должны были входить на
каждый домен отдельно.

Windows NT и SAM
Войдите в Microsoft Windows NT 3.1 Advanced Server. Платформа Windows NT Server предлагает
устойчивую 32-битную вычислительную среду с привычным внешним видом и «ощущением»
популярной операционной системы Microsoft Windows for Workgroups, предназначенной для
настольных компьютеров. Сердцем Windows NT NOS (Network Operating System — сетевая
операционная система) является база данных SAM (Security Accounts Management - управление
безопасными учетными записями). Она представляет центральную базу данных учетных записей,
включающую все учетные записи пользователей и групп в домене. Эти учетные записи
используются для управления доступом к совместным ресурсам, принадлежащим любому серверу
в домене Windows NT.
База данных SAM оставалась главной службой каталога для нескольких вариантов систем
Microsoft Windows NT NOS, включая систему Windows NT 3.5 и систему Windows NT Server 4.
База данных SAM масштабировалась намного лучше, чем предыдущая архитектура службы
каталога из-за введения междоменных доверительных отношений. Доверительные отношения в
Windows NT были важны для преодоления других ограничений службы каталога Windows NT.
Однако база данных SAM имела несколько ограничений, включающих недостаток объема и
плохие возможности доступа. База данных SAM имела практическое ограничение размера в 40
Мб. В терминах пользователя, группы и компьютерных объектов это ограничение проявлялось в
том, что количество объектов учетных записей не могло превышать 40000. Чтобы масштабировать
вычислительную среду за пределы этого
ограничения, сетевые администраторы должны были добавить больше доменов к своим средам.
Организации также разбивались на несколько доменов, чтобы достигнуть административной
автономии, чтобы каждый администратор мог иметь полный контроль над своим собственным
доменом. Поскольку все администраторы домена Windows NT 4 имеют, по существу,
неограниченные административные привилегии, создание отдельных доменов было единственным
методом установления границ администрирования. Однако в пределах домена все
администраторы имели полный контроль над серверами и службами, которые на них
выполнялись. Создание дополнительных доменов не было привлекательным методом, поскольку
каждый новый домен требовал дополнительных серверных аппаратных средств, что приводило к
увеличению административных накладных расходов. По мере роста количества доменов в
организации обеспечение уверенности относительно доверительных отношений, которые делали
возможным пользовательскую идентификацию для доступа к ресурсам внешних доменов, также
приводило к росту накладных расходов. Чтобы справиться с этой растущей сложностью доменов и
доверительных отношений, сетевые администраторы реализовывали одну из четырех доменных
моделей: отдельный домен (single domain), домен с одним хозяином (master domain), домен с
несколькими хозяевами (multiple master domain, или multimaster) и отношения полного доверия
(complete trust). Эти доменные модели показаны на рисунке 1-1.
Рис. 1 -1. Четыре доменные модели, используемые в Windows NT 4

При поддержке этих доменных моделей самые большие административные хлопоты состояли в
необходимости создания и сопровождения большого количества доверительных отношений. Это
было не просто, потому что все доверительные отношения между доменами Windows NT 4
должны были создаваться с двух сторон, т.е. в обоих доменах на концах доверительных
отношений. В сценариях, предполагающих нескольких администраторов домена, это требовало
координации и взаимодействия, что не является характерной чертой работы сетевых
администраторов. Кроме того, доверительные отношения в домене Windows NT были не особенно
устойчивы. Из-за применения метода однозначно определяемой аутентификации между парой
компьютеров, который использовался для поддержания доверительных отношений в Windows NT,
эти доверительные отношения часто были недоступны.
Второе ограничение на базу данных SAM состояло в возможностях доступа. Единственным
методом доступа, применявшимся при взаимодействии с базой данных SAM, была сама NOS. Этот
метод ограничивал программируемый доступ и не обеспечивал конечным пользователям легкого
доступа для поиска объектов. Все запросы на чтение, создание или изменение объектов SAM
должны были инициироваться с использованием одного из нескольких инструментальных
средств, включенных в интерфейс пользователя (UI - User Interface) Windows NT 4, таких как User
Manager For Domains (Администрирование доменов) или Server Manager (Администрирование
серверов). Это ограничило полезность базы данных SAM в качестве службы каталога и внесло
вклад в потребность найти замену службе каталога Windows NT в будущих версиях систем
Windows-NOS. Такая служба каталога начала обретать форму на рабочих столах команды
разработчиков Microsoft Exchange Server.

Windows 2000 и Active Directory

Так как база данных SAM не была легко доступной с внешней стороны самой NOS, она не
подходила для поддержки сетевых приложений типа Exchange Server. Когда была выпущена
четвертая версия Exchange Server, она имела свою собственную службу каталога - Exchange
Directory. Служба Exchange Directory была предназначена для поддержки вычислительной среды
больших предприятий, в более поздних версиях она основывалась на открытых стандартах
интернета. Поддержка открытых стандартов подразумевала, что Exchange Directory удовлетворяла
спецификации облегченного протокола службы каталогов (LDAP) семейства протоколов TCP/IP
(Протокол для взаимодействия сетей в интернете) и была легко доступна программно.
Разрабатывая следующую версию NOS-систем Windows, компания Microsoft рассматривала
службу каталога Exchange Server в качестве модели для будущей реализации службы каталога.
Дополнительная выгода от развития сетевой службы каталога на базе существующей служ-
бы каталога Exchange Server состояла в том, что в будущих выпусках Exchange Server могла бы
быть общая платформа службы каталога, которая обслуживала бы и сетевую среду, и среду
Exchange Server. Эта цель была достигнута с выпуском Windows 2000.
Устойчивая служба каталога Active Directory, которая скромно начиналась как служба каталога
Exchange Server версии 4, была в итоге выпущена с Windows 2000. Служба Active Directory
заменила базу данных SAM в качестве службы каталога для сетевых сред от Microsoft. Эта новая
реализация службы каталога была направлена на преодоление ограничений службы Windows NT 4
SAM и обеспечивала дополнительные выгоды сетевым администраторам. Главная выгода Active
Directory в реализации Windows 2000 состоит в том, что она масштабируема. Новый файл базы
данных учетных записей может достигать 70 Тб, что является весомым усовершенствованием по
сравнению с лимитом SAM в 40 Мб. Число объектов, которые могут быть сохранены в Active
Directory, превышает один миллион.
Фактически Active Directory была реализована в испытательной среде в модели отдельного
домена, содержащей более ста миллионов объектов. В качестве демонстрации масштабируемости
корпорация Compaq Computer Corporation, теперь входящая в состав корпорации Hewlett-Packard,
успешно объединила в модели отдельного домена сводные каталоги домашних телефонных
номеров для всех пятидесяти штатов Соединенных Штатов Америки. Списки, представляющие
два самых больших штата, были загружены дважды, чтобы увеличить объем до размера,
превышающего сто миллионов объектов. Если Active Directory может хранить, управлять и быстро
отвечать на запросы для каждого домашнего номера телефона в Соединенных Штатах, то она
может также масштабироваться до размеров организаций больших предприятий.
Такой огромный прогресс в допустимом объеме означает, что сетевые администраторы больше не
должны делить свои среды на несколько доменов, чтобы обойти ограничения размеров службы
каталога. Результат состоит в уменьшении количества доменов, серверных аппаратных средств и
уменьшении объема сетевого администрирования, то есть появляются три неотразимых причины
для реализации службы Active Directory. Сложные доменные модели, которые преобладали в
Windows NT 4, теперь могут быть объединены в меньшее количество доменов с помощью
организационных единиц (OU - organizational unit), предназначенных для группировки
содержимого ресурсного или регионального домена Windows NT 4. На рисунке 1-2 показана
типичная модель отдельного домена системы Windows 2000.
Другое важное преимущество службы Active Directory состоит в ее доступности.
Архитектура Active Directory разработана на открытых стандартах интернета, таких как LDAP и
пространство имен Х.500. Active Directory
также доступна этим открытым стандартам программно. Администраторы могут управлять
своими реализациями службы Active Directory, используя LDAP-совместимые инструментальные
средства, такие как Active Directory Service Interface (ADSI) Edit и Ldp.exe (LDAP-совмес-тимый
инструмент администрирования службы Active Directory). Так как служба Active Directory открыта
для LDAP, она может управляться программно. В результате сетевые администраторы могут
писать сценарии задач управления типа пакетного импорта пользовательских объектов, которые
требуют много времени, если выполняются через графический интерфейс пользователя (GUI).

Рис. 1 -2. Модель отдельного домена системы Windows 2000

Домены Windows Server 2003 и Active Directory
Самая последняя, улучшенная и усовершенствованная, версия Active Directory, представленной в
Windows 2000, является компонентом всех членов семейства Windows Server 2003 за исключением
Web Edition, которая не нуждается в компоненте Active Directory и не реализует его. Служба
Active Directory семейства Windows Server 2003 предлагает сетевым администраторам
масштабируемость, возможности доступа и функциональность, необходимые для управления
инфраструктурой службы каталога вычислительной среды современных предприятий. Наши
представления о том, что должна выполнять служба каталога, значительно расширились со
времени компьютеров с MS-DOS, связанных сетью под управлением LAN Manager, и Active
Directory является идеальным инструментом, удовлетворяющим этим представлениям. Далее в
этой главе объясняется, каким образом Active Directory выполняет свою роль в центре среды
Windows Server 2003, и какие новые функции появились в этом выпуске.

Открытые стандарты службы Active Directory

Чтобы удовлетворить растущие запросы службы каталога в неизменно плюралистической
вычислительной среде современного предприятия, Microsoft должен был включить открытые
вычислительные стандарты в свои NOS и в свою реализацию службы каталога. Представляется
все более вероятным, что, в конечном счете, серверное пространство средних и больших
организаций будет содержать разнообразные системы NOS, выполняющиеся на различных типах
серверных аппаратных средств. Серверное пространство может включать серверы Windows и
Novell Netware, выполняющиеся на платформах Intel, UNIX-платформы, выполняющиеся на базе
аппаратных средств RISC (компьютеры с сокращенным набором команд), и серверы рабочих
групп семейства Linux, выполняющиеся на любых платформах, к которым могут приложить руки
администраторы. Для реализации этих систем NOS должны взаимодействовать с помощью общего
языка или языков. Потребность в общих языках является основой для вычислительной техники
открытых стандартов. Вместо напряженных усилий, прилагаемых в рамках старой парадигмы
однородной серверной среды, использующей закрытые (лицензированные) реализации службы
каталога, вычислительная среда современных предприятий стремится быть объединенной сетевой
службой.
В следующих двух разделах рассматривается пара открытых стандартов, на которых основана
Active Directory: иерархия пространства имен Х.500 и протокол LDAP.

Иерархии Х.500
Стандарт пространства имен Х.500 (namespace) определяет то, как объекты сохраняются в Active
Directory. Пространство имен Х.500 представляет собой иерархическую структуру имен, которая
идентифицирует уникальный путь к контейнеру службы каталога. Он обеспечивает также
уникальный идентификатор для каждого объекта в этом контейнере. Используя имя в стандарте
Х.500 или идентификатор объекта (OID -Object Identifier), все объекты во всех структурах службы
каталога могут быть уникально идентифицированы. Служба каталога Active Directory основана на
стандарте Х.500, и Microsoft включил в нее все основные (или оригинальные) заданные
стандартом классы.
Этот пространство имен можно представлять или в точечной (dotted), т.е. числовой нотации, или в
строковой (string). Например, идентификатор Х.500 OID, равный 2.5.4.10, является эквивалентом
атрибута Organization-Name (Название организации) (с отображаемым LDAP-именем - «о»).
Числовое представление класса этого объекта уникально
идентифицирует его в пределах иерархии Х.500, и таким образом объект становится уникальным.
Объекты Active Directory могут быть также уникально идентифицированы с помощью строковой
нотации Х.500, известной также как каталог взаимодействия открытых систем (OSI - Open Systems
Interconnection). В строковой нотации пользовательский объект может быть представлен как:
cn=Karen Friske, cn=Users, dc=Contoso, dc=com
Чтобы удовлетворить требованию уникальности в пространстве имен Х.500, в контейнере Users
(Пользователи) в домене Contoso.com может быть только одно имя Karen Friske. Однако могут
существовать другие учетные записи пользователя Карен Фриск в организации Contoso. Имя
Х.500 включает название контейнера, в котором найдена учетная запись пользователя (типа OU), и
дает возможность названию учетной записи пользователя быть уникальной. Строковое
представление пространства имен Х.500 определено в документе Request for Comments (RFC)
1779, который доступен на сайте http://www.faqs.org/rfcs/rfcl779.html.
Чтобы посмотреть идентификатор Х.500 OID, можно использовать или оснастку (snap-in) Active
Directory Schema (Схема Active Directory), или оснастку ADSI Edit (Редактор ADSI). Чтобы
посмотреть идентификатор Х.500 OID для атрибута Organization-Name, откройте контейнер схемы
с помощью ADSI Edit и прокрутите вниз до названия атрибута: CN=Organization-Name. На
рисунке 1-3 показан идентификатор attributelD (имя Х.500) атрибута http://Organization-Name.

Рис. 1 -3. Свойства атрибута Organization-Name, отображаемые с помощью ADSI Edit

Гетерогенные сетевые среды

Должным образом спроектированная и сконструированная гетерогенная сетевая среда невидима
для конечных пользователей. Другими словами, пользователи не должны замечать, что сетевые
услуги, на которые они полагаются в своей работе, выполняются на разнообразных серверных
платформах. Они должны иметь возможность использовать общий набор инструментальных
средств и приложений для взаимодействий как в частной, так и в общественной сети (интернет).
Одним из ключевых моментов в реализации невидимой гетерогенной сетевой среды является
выбор центральной службы каталога, которая поддерживает единую регистрацию, например,
службы Active Directory Windows Server 2003. В противном случае пользователи должны
обеспечивать верительные грамоты учетной записи для каждой операционной системы, к которой
они хотят обратиться. Типичными примерами гетерогенной вычислительной среды являются:
• операционные системы для настольных компьютеров семейства Windows, выполняющие
разнообразные совместимые приложения, которые все дают одно и то же впечатление и
ощущение от своей работы, и поэтому не требуют, или требуют в незначительной степени,
переподготовки для своего использования;
• сетевые операционные системы семейства Windows или Novell, выполняющиеся на
серверных аппаратных средствах Intel или в гибридной среде с одним поставщиком NOS
для службы каталога и другим - для серверов приложений и членов системы. Для
традиционной модели обработки данных типа клиент-сервер, популярной в современных
отделах корпоративных информационных технологий (IT), предпочтительны основные
системы NOS. Выбирая версию этих операционных систем так, чтобы она удовлетворяла
открытым стандартам, можно получить успешную гетерогенную среду обработки данных.
Windows 2000 Active Directory, Windows Server 2003 Active Directory, Novell Directory
Services в системе Novel Netware 5 и более поздние основаны на архитектуре открытого
стандарта для инфраструктур службы каталога;
• доменная система имен (DNS) под UNIX, протокол DHCP (Dynamic Host Configuration
Protocol - протокол динамической конфигурации хоста), брандмауэр/прокси
 (firewall/proxy) или сервер NAT (Network Address Translation - преобразование сетевых
адресов), выполняющийся на серверных аппаратных средствах RISC. Некоторые (или все)
виды обеспечения интернет-взаимодействий на предприятии могут поддерживаться UNIX-
серверами. Так как службы интернета выполнены в открытом стандарте, то нет никакого
основания требовать, чтобы службы, поддерживающие доступ к интернету, имели
определенный тип;
• файлы под Linux или прикладной сервер, выполняющийся на сервере с младшей моделью
Intel или RISC. Среда Linux, часто развертываемая в объеме, нужном для разработки или
тестирования, предлагает возможный маршрут для обеспечения сетевых услуг, не
являющихся критически важными и ответственными. Такая Linux-среда была бы доступна
тем, кто использует Windows-приложения через протокол SMB (Server Message Block -
блок серверных сообщений). Конечный пользователь не осознавал бы, что эти ресурсы
находятся не на Windows-сервере.

Облегченный протокол службы каталогов (LDAP)

Протокол LDAP является как протоколом доступа, так и моделью службы каталога в Active
Directory Windows Server 2003. Как информационная модель иерархия имен LDAP подобна
иерархии имен каталогов X.500/OSI. Как программный интерфейс приложения (API) LDAP
реализован в Active Directory Windows Server 2003 в Wldap32.dll. Active Directory полностью
поддерживает доступ к каталогу, используя собственные запросы LDAP или используя интерфейс
ADSI СОМ (Component Object Model — модель компонентных объектов). Как протокол доступа
LDAP определен в комплекте TCP/IP для доступа к данным, находящимся в LDAP-совместимых
каталогах. Как открытый стандарт LDAP облегчает обмен данными между платформами с
различными службами каталога, о чем говорится далее в разделе «Ключевые функции и
преимущества службы Active Directory» в этой главе.
Представление иерархии имен LDAP для учетной записи пользователя, приведенной в примере
ранее, дается как:
LDAP: // cn=Karen Friske, cn=Users, dc=Contoso, dc=com
Используя это соглашения об именах, администраторы могут более точно ссылаться на объекты и
обращаться к объектам в пределах службы LDAP-совместимого каталога. LDAP-протокол и
модель каталога (но не синтаксис именования) определен документом RFC 1777, который
доступен на сайте http://www.faqs.org/rfcs/rfcl777.html.
Для администрирования службы Active Directory, совместимой с LDAP, используйте LDAP-
чувствительный инструмент администрирования типа Ldp.exe, который является частью пакета
Suptools.msi, расположенного в папке Support\Tools компакт-диска продукта Windows Server 2003.
Используя Ldp.exe, вы можете связаться или подключиться к службе Active Directory по ее номеру
UDP (User Datagram Protocol — пользовательский протокол данных) порта и показать
отображаемое LDАР-имя каждого атрибута, класса и объекта. Чтобы подключиться к Active
Directory, используя Ldp.exe, и отобразить атрибуты пользовательских объектов, свяжитесь с
Active Directory, используя UDP порта 389, раскройте контейнер или организационную единицу, а
затем дваж-
ды щелкните на определенном названии учетной записи пользователя. На рисунке 1-4 показана
учетная запись пользователя с именем Karen Friske, которую можно увидеть через инструмент
Ldp.exe.
Рис. 1-4. Учетная запись пользователя Karen Friske, отображаемая в Ldp.exe

Ключевые функции и преимущества службы

Active Directory
Вы можете спросить: «Зачем мне нужна служба Active Directory?». Если вы заинтересованы в
выполнении наиболее сильно интегрированной службы каталога для Windows Server 2003, то
Active Directory является логичным выбором. Другая очень популярная причина, подталкивающая
к реализации службы Active Directory, состоит в поддержке Microsoft Exchange Server 2000.
Exchange Server 2000 полагается на Active Directory для своей службы каталога, поэтому многие
администраторы реализуют Active Directory, чтобы модернизироваться до Exchange Server 2000. В
этом разделе описано несколько ключевых функций и преимуществ службы Active Directory
Windows Server 2003.

Централизованный каталог
Active Directory является единственной централизованной службой каталога, которая может быть
реализована в пределах предприятия. Это упрощает сетевое администрирование, поскольку
администраторы не должны соединяться с несколькими каталогами, чтобы выполнять управление
учетными записями. Другая выгода от использования централизованного каталога состоит в том,
что он может также использоваться другими приложениями, такими как Exchange Server 2000. Это
упрощает полное сетевое администрирование, так как используется единая служба каталога для
всех приложений.

Единая регистрация
В определенном месте леса (forest - логический компонент реализации Active Directory) Windows
Server 2003 пользователи могут войти в сеть с помощью идентификации основных
пользовательских имен (UPN -User Principal Name), например, mike@contoso.com. После
успешной идентификации им будет предоставлен доступ ко всем сетевым ресурсам, для которых
им было дано разрешение, без необходимости регистрироваться снова на различных серверах или
доменах. Имя UPN является обязательным атрибутом объекта учетной записи пользователя в
Active Directory, и оно устанавливается по умолчанию в Active Directory, когда создается новая
учетная запись пользователя.

Делегированное администрирование
Одно из ограничений базы данных Windows NT 4 SAM состояло в том, что административные
права были доступны только в виде «все или ничего». Чтобы дать пользователю любую степень
административных прав требовалось, чтобы вы сделали пользователя членом группы Domain
Admins. Этот уровень административных прав давал пользователю, по существу, безграничную
власть в пределах домена, включая право удалять других пользователей из группы Domain
Admins. Такой метод делегирования административных функций не был безопасным. С другой
стороны, Active Directory предоставляет администраторам возможность делегировать
административные права. Используя мастер Delegation Of Control Wizard (Делегирование
управления) или устанавливая определенные разрешения на объекты Active Directory,
администраторы могут предлагать тонко настроенные административные права. Например, вы
можете назначить определенной учетной записи пользователя административное право
сбрасывать пароли в домене, но не создавать, удалять или как-либо изменять пользовательский
объект.

Интерфейс общего управления

Есть несколько способов, которыми вы можете получить выгоду от интеграции между Active
Directory и операционной системой. Один из путей состоит в использовании интерфейса общего
управления — консоли управления Microsoft (ММС — Microsoft Management Console). При
взаимодействии с Active Directory через графический интерфейс пользователя ММС все
инструментальные средства управления дают согласующееся друг с другом впечатление и
ощущение от их использования. Для Active Directory эти средства включают Active Directory Users
And Computers (Active Directory: пользователи и компьютеры), Active Directory Domains And
Trusts (Active Directory: домены и доверительные отношения) и Active Directory Sites And Services
(Active Directory: сайты и службы). Оснастки ММС функционируют так же, как все другие
средства администрирования Windows Server 2003, например, оснастки DHCP и DNS.

Интегрированная безопасность
Служба Active Directory работает рука об руку с подсистемой безопасности Windows Server 2003
при аутентификации безопасных пользователей и обеспечении защиты общедоступных сетевых
ресурсов. Сетевая защита в сети Windows Server 2003 начинается с аутентификации во время
регистрации. Операционная система Windows Server 2003 поддерживает два протокола для
сетевой идентификации внутри и между доменами Windows Server 2003: протокол Kerberos v5 и
протокол NT LAN Manager (NTLM). Протокол Kerberos является заданным по умолчанию
аутентификационным протоколом для клиентов, вошедших в систему с клиентских компьютеров,
работающих под управлением операционных систем Windows 2000 Professional или Microsoft
Windows XP Professional. Пользователи, вошедшие в систему с клиентских компьютеров низкого
уровня (Windows NT 4, Microsoft Windows 98 или более ранних операционных систем)
используют для сетевой аутентификации протокол NTLM. Протокол NTLM также используется
клиентами систем Windows XP Professional и Windows 2000, когда они входят на сервера,
работающие под управлением Windows NT 4, или на автономные компьютеры с системами
Windows 2000 или Windows Server 2003.
Служба Active Directory также является важной составляющей частью в модели управления
доступом Windows Server 2003. Когда безопасный пользователь входит в домен Windows Server
2003, подсистема защиты вместе с Active Directory создает лексему доступа, которая содержит
идентификатор защиты (SID - Security Identifier) учетной записи пользователя, а также
идентификаторы SID всех групп, членом которых является данный пользователь. Идентификатор
SID является атрибутом пользовательского объекта в Active Directory. Затем лексема доступа
сравнивается с дескриптором защиты на ресурсе, и, если устанавливается соответствие, то
пользователю предоставляется требуемый уровень доступа.

Масштабируемость
Поскольку организация постепенно растет в процессе бизнеса, либо это происходит быстро, через
ряд слияний с другими компаниями и в результате приобретений, служба Active Directory
спроектирована масштабируемой, для того чтобы справляться с этим ростом. Вы можете
расширить размер доменной модели или просто добавить больше серверов, чтобы приспособиться
к потребностям увеличения объема.
Любые изменения в инфраструктуре Active Directory должны быть тщательно реализованы в
соответствии с проектом Active Directory, который предусматривает такой рост. Отдельный домен,
представляющий самый маленький раздел инфраструктуры Active Directory, который может
реплицироваться на единственный контроллер домена, может поддерживать более одного
миллиона объектов, так что модель отдельного домена подходит даже для больших организаций.
Нововведения в службе Active Directory
Windows Server 2003
В дополнение к ключевым функциям Active Directory, упомянутым выше, имеются несколько
новых функций, которые добавлены к службе Active Directory в Windows Server 2003. В
следующем разделе дается краткий обзор нововведений операционной системы Windows Server
2003. Более полно они рассматриваются в следующих главах.

Усовершенствования в оснастке Active Directory Users And

Computers
Имеется два приятных изменения в оснастке Active Directory Users And Computers (Active
Directory: пользователи и компьютеры). В Windows Server 2003 эта оснастка позволяет
администратору сохранять запросы. Администраторы могут делать поиск в каталоге по
определенному атрибуту, сохранять запрос, а затем выполнять его снова в будущем для анализа
или поиска неисправностей. Например, администратор может сохранять результаты поиска
любого пользовательского объекта, который имеет пароль с неограниченным временем действия
(Account Options: Password Never Expires - опции учетной записи: пароль с неограниченным
временем действия), а затем периодически пользоваться этим поиском, чтобы следить за наличием
такого пароля, представляющего потенциальный риск для безопасности.
Оснастка Active Directory Users And Computers позволяет администратору редактировать
несколько пользовательских объектов одновременно. В примере, упомянутом выше, после того,
как администратор сделал поиск учетных записей пользователей, имеющих пароли с
неограниченным временем действия, все эти учетные записи можно открыть и изменить этот
атрибут для всех учетных записей одновременно.

Функциональные уровни
Active Directory Windows Server 2003 вводит функциональные уровни домена и леса, которые
обеспечивают обратную совместимость для доменов, содержащих низкоуровневые контроллеры
домена. Имейте в
виду, что вы должны будете поднять функциональный уровень домена или леса, чтобы
реализовать многие другие изменения в Active Directory для Windows Server 2003. Многие из
новых функций требуют сетевой среды, в которой все контроллеры домена имеют операционную
систему Windows Server 2003.
Примечание. Низкоуровневым контроллером домена является любой контроллер домена в домене
Windows Server 2003, который имеет любую более раннюю версию NOS, например, Windows NT 4
или Windows 2000.
Функциональный уровень домена и леса, заданный по умолчанию, — «Windows 2000» (для
домена — «Windows 2000 mixed»). Это означает, что при установке Active Directory
конфигурируется так, чтобы использовались только те новые функции, которые могут
поддерживаться комбинацией контроллеров домена с Windows Server 2003 и Windows Server 2000.
Чтобы воспользоваться преимуществами новых функций службы Active Directory, уровень
функциональных возможностей должен быть поднят к уровню контроллеров домена Windows
Server 2003 как можно скорее, т.е. в домене не должно остаться ни одного контроллера домена, на
котором выполняются системы Windows 2000 или Windows NT 4.
Примечание. Функциональные уровни Active Directory в Windows Server 2003 тесно связаны с
настройками mixed-mode (смешанный режим) и native-mode (основной режим) домена в Windows
2000. С выпуском операционной системы Windows Server 2003 появилась возможность иметь на
предприятии другую платформу службы каталога Microsoft Active Directory, поэтому настройки
домена вобрали в себя новые дополнительные свойства Active Directory. Концепции
функциональных возможностей домена и режима домена по существу одинаковы. Для получения
дополнительной информации об уровнях функциональных возможностей см. табл. 2-1 и 2-2.

Переименование домена
Active Directory теперь поддерживает переименование существующих доменов в пределах леса
при сохранении глобально уникального идентификатора (GUID — Globally Unique Identifier) и
идентификатора защиты (SID - Security Identifier) домена. Есть несколько сценариев, в которых
это свойство полезно, включая слияние двух организаций, имеющих отдельные инфраструктуры
Active Directory, которые хотят объединиться под одним именем домена, отражающим их внешнее
зарегистрированное пространство имен. Переименование доменов не является тривиальной IT-
процедурой. Это действие разрушительно с точки
зрения доступа к сети, для завершения операции каждый контроллер домена и каждый сервер
домена должны быть перезагружены.

Разделы приложений каталога

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

Дополнительный контроллер домена, инсталлированный с

резервных средств хранения информации
Эта новая функция является усовершенствованием к процессу инсталляции Active Directory. В
системе Windows 2000 при установке дополнительного контроллера домена могло потребоваться
очень много времени (от нескольких часов до нескольких дней) на завершение начальной
репликации разделов каталога, особенно для больших разделов каталога или для контроллеров
домена, соединенных медленными линиями связи. Процесс инсталляции Active Directory для
Windows Server 2003 теперь поддерживает создание разделов каталога из недавней резервной
копии данных System State (Состояние системы) с другого контроллера домена Windows Server
2003. Так как к данным каталога обращаются с местного диска, а не через репликацию по сети,
этот процесс сильно ускоряется.

Дезактивация объектов схемы

В Windows Server 2003 сетевые администраторы имеют возможность «дезактивировать», или
выключить, классы, схемы и атрибуты. В результате вы можете переопределять атрибуты и
классы вместо необходимости создавать новый атрибут или класс в случае ошибки в определении
какого-либо постоянного свойства. Предположим, что администратор решает расширить схему,
чтобы включить в нее атрибут «Размер обу-
ви» объекта класса «Пользователь», и неосторожно устанавливает определение атрибута на integer
(целое число). Получив отказ, администратор решает, что это должно быть строковое (string)
значение, чтобы включать и размер, и ширину. Путем дезактивации атрибутов схемы
первоначальный атрибут можно выключить и создать новый атрибут с тем же именем «Размер
обуви» и с соответствующим определением. Без этой возможности администратор должен был бы
создать новый атрибут с уникальным названием и целиком отказаться от атрибута «Размер
обуви». В качестве подстраховки, чтобы предотвратить случайную дезактивацию, изменения,
произведенные дезактивацией объектов схемы, являются обратимыми.

Отключение сжатия трафика репликации между различными

сайтами
В Active Directory Windows Server 2003 так же, как в Windows 2000, трафик межсайтовой
репликации по умолчанию сжат. Наряду с тем, что это сжатие оптимизирует пропускную
способность сети между сайтами, оно накладывает дополнительную нагрузку на процессоры
контроллера домена, которые обрабатывают сжатие и распаковку. Поскольку теперь сжатие
трафика репликации можно выключать (только между различными сайтами), администраторы
могут уменьшать нагрузку на процессор. Это происходит за счет увеличения нагрузки на
пропускную способность сети, но в средах с высокой сетевой пропускной способностью эта
альтернатива может заслуживать внимания.

Для входа в систему не нужен доступ к глобальному каталогу

При входе в домен, находящийся в основном режиме Windows 2000 (native-mode), необходимо
вступить в контакт с сервером глобального каталога (GC - Global Catalog) для обработки
универсального группового членства пользователя. Эта групповая информация требуется для того,
чтобы создать лексему доступа пользователя. Для избежания ситуаций, в которых
пользовательские входы в систему отклоняются из-за выключенной связи с GC, обычная практика
при проектировании Active Directory состоит в размещении глобальных каталогов в тех местах,
которые соединены с основной сетью менее надежными сетевыми связями. Теперь контроллеры
домена Windows Server 2003 можно сконфигурировать так, чтобы информация универсального
группового членства кэшировалась, и пользовательские входы в систему могли быть обработаны
без контакта с GC. В результате не требуется, чтобы каждое удаленное место расположения
компании имело GC-каталог. Кроме того, при отсутствии GC-каталога на каждом удаленном сайте
трафик репликации по сетевым соединениям, связывающим эти сайты, уменьшается.

Усовершенствование репликации группового членства

В системе Windows 2000 единственное изменение, сделанное в одном члене группы, вызывало
необходимость репликации всех членов группы, чтобы синхронизировать изменения с другими
контроллерами домена. Для очень больших групп при этом использовалась значительная часть
пропускной способности сети и имелась потенциальная возможность потери данных члена
группы, если случалось так, что членство в группе изменялось на нескольких контроллерах
домена. На функциональном уровне леса Windows Server 2003 репликация изменений группового
членства касается теперь только измененного члена.

Усовершенствование UI-селектора объектов

Селектор объектов (object picker) представляет собой функцию интерфейса пользователя (UI),
которая используется для выбора объектов учетных записей при администрировании Active
Directory. Например, при добавлении учетных записей пользователя к глобальной группе
используется UI-селектор объектов для того, чтобы выбрать учетную запись пользователя,
которую вы хотите включить в группу. В прошлых выпусках этот интерфейс обеспечивал простое
представление каталога, которое невозможно было прокручивать для просмотра. Текущая версия
этого интерфейса включает расширенные функции запросов, которые позволяют делать поиск в
каталоге на уровне атрибута и которые могут перенести сферу действия на определенное
организационное подразделение. Результаты этого усовершенствования состоят в улучшении
поиска, а также в уменьшении сетевого трафика, связанного со службой каталога. Более того, UI-
селектор объектов доступен любой новой оснастке ММС, в которой требуется выбирать объекты
из Active Directory.

Механизм удаления неактивных объектов

Удаление неактивных объектов представляет собой процесс, в результате которого объекты-
памятники (tombstone) удаляются из тех контроллеров домена, которые были недоступны для
репликации после процесса сборки мусора. Объект-памятник представляет собой маркер,
который указывает на то, что объект был удален. «Сборка мусора» — это процесс, с помощью
которого объекты, отмеченные как объекты-памятники, удаляются изо всех реплик базы данных
Active Directory по всему домену. Процесс удаления этих неактивных объектов используется в
таких ситуациях, в которых удаление маркеров-памятников в разделе каталога домена
выполняется после того, как контроллер домена находился в автономном режиме или был
недоступен по другим причинам. Прежде не существовало никакого процесса, предназначенного
для очищения системы от таких «потерянных» маркеров-памятников, в резуль-
тате чего база данных каталога могла вырастать до таких размеров, что это влияло на
производительность процесса репликации. Это также означало, что на разных контроллерах
домена существовали несогласованные копии разделов каталога.

Поддержка класса inetOrgPerson

Active Directory Windows Server 2003 теперь поддерживает класс inetOrgPerson в том виде, в каком
он определен в документе RFC 2798, который доступен на сайте
http://www.faqs.org/rfcs/rfc2798.html. Это дополнение к основной схеме дает возможность
администратору Active Directory перемешать объекты inetOrgPerson из других LDAP-катало-гов, а
также создавать объекты inetOrgPerson в среде Active Directory Windows Server 2003.

Резюме
В этой главе вы узнали, как за эти годы развивалась служба каталога Microsoft по мере развития
сетевой среды обработки данных, на которую она опирается. Начиная с выпуска системы Windows
2000, в качестве службы каталога в ядре NOS Windows использовалась Active Directory. В этой
главе было дано краткое введение в платформу службы каталога и объяснено, как ее конструкция
удовлетворяет запросам современной сетевой среды обработки данных. Были обсуждены
ключевые функции, показывающие выгоды от использования Active Directory, и в заключение дан
краткий обзор ее новых функций.
Глава 2. Компоненты службы каталога Active
Directory
Служба каталога Active Directory Microsoft Windows Server 2003 существует на двух уровнях:
физическом и логическом. В терминах физической структуры Active Directory представляет собой
файл, расположенный на жестком диске сервера и на жестком диске каждого контроллера домена,
который содержит эту службу. Логическая структура Active Directory представляет собой
контейнеры, которые используются для хранения объектов службы каталога (разделов каталога,
доменов и лесов) на предприятии. Разделы каталога, домены и леса в виде байтов информации
хранятся в физических компонентах службы каталога. В этой главе вы узнаете о физическом
проявлении службы каталога Active Directory. Затем вы познакомитесь с логической структурой
реализации службы Active Directory. Хорошее понимание физической структуры службы каталога
важно, но знание логической структуры является непременным условием успешной реализации и
управления инфраструктурой вашей службы. Именно с логической структурой службы каталога
вы будете ежедневно взаимодействовать.

Физическая структура службы Active Directory

Физическое проявление службы Active Directory состоит в наличии отдельного файла данных,
расположенного на каждом контроллере домена в домене. Физическая реализация службы Active
Directory описывается местоположением контроллеров домена, на которых расположена служба.
При реализации службы Active Directory можно добавлять столько контроллеров доменов, сколько
необходимо для поддержания служб каталога в данной организации. Имеется пять определенных
ролей, которые может играть каждый из контроллеров домена. Они известны как роли хозяина
операций (operations master roles). Еще одна роль, которую может выполнять любой отдельный
контроллер домена в домене, связана с глобальным каталогом (GC — Global Catalog). В этом
разделе мы рассмотрим хранилище данных службы Active Directory и контроллеры домена, на
которых оно расположено.

Хранилище данных каталога

Все данные базы данных службы Active Directory хранятся в отдельном файле Ntds.dit на
контроллере домена. Этот файл данных по умолчанию находится в папке %SystemRoot%\NTDS,
расположенной на контроллере домена. В нем хранится вся информация каталога,
предназначенная для данного домена, а также данные, являющиеся общими для всех контроллеров
домена в данной организации.
Вторая копия файла Ntds.dit находится в папке %SystemRoot%\ System32. Эта версия файла -
поставляемая копия (копия, заданная по умолчанию) базы данных каталога, она используется для
установки службы Active Directory. Этот файл копируется на сервер во время установки Microsoft
Windows Server 2003, чтобы сервер можно было назначать контроллером домена без
необходимости обращаться к инсталляционной среде. Во время выполнения мастера инсталляции
Active Directory (Dcpromo.exe) файл Ntds.dit копируется из папки System32 в папку NTDS. Затем
копия, сохраненная в папке NTDS, становится действующей копией хранилища данных каталога.
Если это не первый контроллер домена в домене, то файл будет обновлен из других контроллеров
домена через процесс репликации.

Контроллеры домена
По определению любой компьютер, на котором выполняется Windows Server 2003, и который
поддерживает копию базы данных службы Active Directory, является контроллером домена. Все
контроллеры домена создаются равными за несколькими исключениями, которые будут
рассмотрены далее в этой главе. При использовании процесса репликации с несколькими
хозяевами домена (multimaster), описанного в гл. 4, каждый контроллер домена в домене
поддерживает новейшую копию базы данных домена и способен создавать изменения в ней.
В дополнение к контроллерам домена, которые содержат службу Active Directory, имеется
несколько контроллеров домена специального назначения, которые требуются службе Active
Directory для выполнения определенных функций. Они являются серверами глобального каталога
(GC) и хозяевами операций (operations masters).

Серверы глобального каталога

На сервере глобального каталога находится глобальный каталог (GC). Он является частичной,
предназначенной только для чтения копией всех контекстов именования домена (NC - Naming
Context) в лесу. Каталог GC содержит основной, но неполный набор атрибутов для каждого
объекта леса в каждом домене NC. Данные каталога GC получают из всех разделов каталога
доменов в лесу, они копируются с использованием стандартного процесса репликации службы
Active Directory.
Совет. Будет ли атрибут скопирован в каталог GC, определяется схемой. Администраторы могут
конфигурировать дополнительные атрибуты, которые будут реплицироваться в каталог GC,
используя меню Active Directory Schema (Схема Active Directory), встроенное в консоль
управления ММС. Чтобы добавить атрибут к каталогу GC, выберите опцию Replicate This Attribute
To The Global Catalog (Копировать этот атрибут в глобальный каталог) на самом атрибуте. В
результате значение параметра атрибута isMemberOfPartialAttributeSet будет установлено на true
(истина). Вы можете добавлять атрибут к глобальному каталогу, если ожидаете, что
пользователям потребуется искать этот объект в лесу. Редко упоминаемые атрибуты обычно не
добавляются к каталогу GC.
Первый контроллер домена, установленный в домене, автоматически является контроллером
глобального каталога. Дополнительные контроллеры домена можно назначить как GC, выбирая
опцию Global Catalog Server (Сервер глобального каталога) в инструменте администрирования
Active Directory Sites And Services (Сайты и службы Active Directory). Это делается с целью
оптимизации входа в систему. Как используется каталог GC в процессе входа в систему, описано
далее в этом разделе. В главе 5 дается более подробная информация о количестве GC-серверов,
которое потребуется при развертывании, и о том, где их следует располагать.
Вы можете задаться вопросом, зачем вообще нужны GC-серверы. Во-первых, они используются
для поиска в Active Directory. Без каталога GC поиск по запросам, полученным контроллером
домена, который не обладает запрошенным объектом, приведет к тому, что он переправит запрос
на контроллер домена другого домена. Поскольку GC-каталог содержит полный список всех
объектов леса (и не содержит атрибуты объекта), GC-сервер может ответить на любой запрос,
используя атрибут, который копировался в GC-каталог, без необходимости передавать его
другому контроллеру домена. Запрос, который послан GC-серверу, является LDAP-запросом
(Lightweght Directory Access Protocol — облегченный протокол службы каталогов), использующим
порт 3268 (заданный по умолчанию порт GC-каталога).
Во-вторых, GC-серверы необходимы для обработки пользовательских входов в систему. Обычно
каждый раз, когда пользователь входит в домен, выполняется обращение к GC-каталогу. Это
происходит потому, что контроллеры домена, не являющиеся глобальными, не содержат никакой
информации об универсальном членстве группы. (Универсальные группы имеются только в
доменах, обладающих функциональным уровнем Microsoft Windows 2000 или Windows Server
2003. Функциональные уровни используются в Windows Server 2003, чтобы разрешить функ-
ции службы Active Directory всем контроллерам домена, которые могут их поддерживать.)
Универсальные группы могут содержать учетные записи пользователей и групп из любого домена
определенного леса. Так как универсальное групповое членство распространяется на лес, то
групповое членство может быть разрешено только тем контроллером домена, который имеет
информацию каталога на уровне леса, т.е. информацию глобального каталога (GC). Чтобы
сгенерировать точную лексему защиты для пользователя, запрашивающего идентификацию,
требуется контактировать с GC-каталогом для определения универсального группового членства
пользователя.
Примечание. Windows Server 2003 поддерживает новую функцию кэширования универсального
группового членства, которая дает возможность входить в сеть Windows Server 2003 без
контакта с GC-каталогом. Универсальное групповое членство кэши-руется на контроллерах
домена, не являющихся контроллерами GC, если эта опция разрешена, а пользователь впервые
пытается войти в систему. Как только эта информация попадает в GC-каталог, она
кэшируется на неограниченное время на контроллере домена сайта и периодически обновляется
(по умолчанию каждые 8 часов). Включение этой функции приводит к ускорению входа в систему
пользователей с удаленных сайтов, так как для аутентификации контроллеру домена не
требуется обращения к GC-каталогу. Чтобы включить опцию универсального группового
членства на сайте, откройте оснастку Active Directory: Sites And Services (Сайты и службы
Active Directory) и выберите нужный сайт в дереве консоли. Щелкните правой кнопкой мыши на
панели деталей NTDS Site Settings (Параметры настройки сайта NTDS), затем выберите
Properties (Свойства). На вкладке Properties выберите опцию Enable Universal Group Membership
Caching (Разрешить кэширование универсального группового членства), а затем укажите сайт, с
которого будет обновляться кэш. По умолчанию сайт обновит информацию с самого близкого
сайта, который имеет глобальный каталог GC.

Функциональные уровни
В Windows Server 2003 каждому лесу и каждому домену в пределах леса может быть назначен
определенный функциональный уровень. Функциональные уровни используются для того, чтобы
разрешать функции, которые реализованы на комбинациях операционных систем. Когда для
домена устанавливается функциональный уровень, то он применяется только к данному домену.
Если не определено иначе, домены создаются на функциональном уровне mixed (смешанный)
системы Windows 2000; леса создаются на функциональном уровне Windows 2000.
В таблице 2-1 показаны функциональные уровни доменов и операционные системы,
поддерживаемые на контроллерах домена.

Табл. 2-1. Функциональные уровни домена

Функциональный уровень Операционные системы,
домена поддерживаемые на контроллерах
данного домена
Windows 2000 mixed Windows NT 4, Windows 2000,
(смешанный) (значение ро Windows Server 2003.
умолчанию)
Windows 2000 native (основной) Windows 2000, Windows Server 2003.

Windows Server 2003 interim Windows NT 4, Windows Server 2003.

(промежуточный) Windows Server 2003.
Windows Server 2003

В таблице 2-2 показаны функциональные уровни леса и операционные системы, поддерживаемые

на контроллерах домена в лесу.

Табл. 2-2. Функциональные уровни леса

Функциональные уровни леса Операционные системы,
поддерживаемые на контроллерах
данного домена в лесу
Windows 2000 (значение по Windows NT 4, Windows 2000,
умолчанию) Windows Server 2003.

Windows Server 2003 interim Windows NT 4, Windows Server 2003.

(промежуточный) Windows Server 2003.
Windows Server 2003

Прежде чем повышать функциональный уровень леса до уровня Windows Server 2003, проверьте,
всем ли доменам леса установлен функциональный уровень Windows 2000 native или Windows
Server 2003. Домены, функциональный уровень которых установлен на Windows 2000 native, будут
автоматически подняты до функционального уровня Windows Server 2003, а уровень леса - до
уровня Windows Server 2003. После того как это произойдет, к данному домену (лесу) могут быть
добавлены только контроллеры домена, работающие на том же функциональном уровне
операционной системы. Поднятый функциональный уровень домена или леса нельзя понизить.
Итак, глобальный каталог (GC) используется для того, чтобы облегчить пользовательский вход в
систему, допуская использование основ-
ных имен пользователя (например, usernarae@contoso.com). Каталог GC понимает основные имена
пользователя (UPN - User Principal Names), потому что он содержит информацию о каждом
пользователе в каждом домене леса. Контроллеры домена, не имеющие каталога GC, не обладают
этими данными, они не способны подтвердить подлинность пользовательского входа в систему,
если он задается в таком формате.

Хозяева операций
Active Directory разработана как система репликации с несколькими хозяевами. Для этого
требуется, чтобы все контроллеры домена имели разрешения делать запись в базу данных
каталога. Эта система удовлетворительно работает для большинства операций каталога, но для
некоторых операций требуется наличие единственного официального (authoritative) сервера.
Контроллеры домена, выполняющие определенные роли, известны как хозяева операций; все они
выполняют роли FSMO (Flexible Single Master Operations — гибкие операции с одним хозяином).
Существует пять ролей хозяев операций в Active Directory:
• хозяин схемы;
• хозяин именования доменов;
• хозяин относительных идентификаторов RID;
• хозяин эмулятора PDC (Primary Domain Controller — основной контроллер домена);
• хозяин инфраструктуры.
Первые две роли устанавливаются для леса в целом. Это означает, что задается только один
хозяин схемы и один хозяин именования доменов для каждого леса. Следующие три роли
функционируют в пределах домена, т.е. задается только одна из этих ролей для каждого домена
леса. Когда вы установите Active Directory и создадите первый контроллер домена в лесу, ему
будут назначены все эти пять ролей. Если вы добавите домены к лесу, то первый контроллер
домена в каждом новом домене возьмет на себя свои прошлые три роли хозяина операций. По
мере добавления контроллеров домена вы передадите некоторые из этих ролей другим
контроллерам домена. Как передавать роли другим контроллерам домена, описано далее в этой
главе.

Хозяин схемы
Хозяин схемы является единственным контроллером домена, который имеет разрешение делать
записи в схему каталога. Чтобы сделать любое изменение в схеме каталога, администратор (он
должен быть членом группы безопасности Schema Admins — Администраторы схемы) должен
связаться с хозяином схемы. Если модификация схемы предпринята на контроллере домена, не
являющемся хозяином схемы, она окончится неудачей. После того как было сделано изменение,
модификации схемы копируются на остальные контроллеры домена в лесу.
По умолчанию первый контроллер домена, установленный в лесу (контроллер домена для
корневого домена леса) принимает роль хозяина схемы. Эта роль может быть передана другому
контроллеру в любое время с помощью оснастки Active Directory Schema (Схема Active Directory)
или с помощью утилиты командной строки Ntdsutil. Хозяин схемы идентифицирован значением
атрибута fSMORoleOwner в контейнере схемы.

Хозяин именования доменов

Хозяин именования доменов представляет собой контроллер домена, на котором можно добавлять
новые домены к лесу или удалять существующие. Администраторы должны связываться с
хозяином именования доменов, чтобы добавить или удалить домен. Если хозяин именования
доменов недоступен, любая попытка добавить домен к лесу или удалить его потерпит неудачу.
Домены добавляются к лесу одним из способов, которые требуют подключения удаленного
вызова процедуры (RPC) к домену, исполняющему роль хозяина именования доменов. Наиболее
распространенный метод создания нового домена состоит в выполнении Dcpromo.exe в командной
строке, которая запускает мастер инсталляции Active Directory. Во время этого процесса вы
получаете возможность установить первый контроллер домена в новый домен. Dcpromo.exe
войдет в контакт с хозяином именования домена для того, чтобы сделать это изменение. Если
хозяин операции именования доменов недоступен, то создание домена окончится неудачей.
Добавить новый домен можно также с помощью утилиты Ntdsutil. Эта утилита создает объект
перекрестной ссылки в контейнере разделов в разделе конфигурации каталога, который затем
реплицируется на все контроллеры домена в лесу. Далее создание домена можно выполнять с
помощью Dcpromo.exe без необходимости входить в контакт с хозяином именования доменов.

Хозяин относительных идентификаторов

Хозяин относительных идентификаторов (RID) - это роль хозяина операций в пределах домена.
Она используется для управления RID-пулом, предназначенным для создания новых участников
безопасности в пределах домена, таких как пользователи, группы и компьютеры. Каждый
контроллер домена производит блок относительных идентификаторов (RID), использующихся для
построения идентификаторов защиты (SID), которые однозначно идентифицируют участников
безопасности в домене. Блок доступных идентификаторов RID называется RID-пулом. Когда
количество доступных RID-идентификаторов в RID-пуле на любом контроллере домена в домене
начинает истощаться, делается запрос на другой RID-блок у хозяина RID-идентификаторов.
Работа хозяина RID-идентификаторов заключается в выполнении таких запросов и обеспечении
того, чтобы никакой RID-идентификатор не был выделен более одного раза. Этот процесс
гарантирует каждой учетной записи в домене уникальную защитную особенность.
Если хозяин RID-идентификаторов в течение какого-то времени недоступен, процесс создания
новых учетных записей на определенных контроллерах домена может быть прерван. Механизм
запроса новых блоков RID-идентификаторов разработан таким образом, чтобы опустошения пула
не происходило, ведь запрос делается раньше, чем все имеющиеся в RID-пуле идентификаторы
будут розданы. Однако если хозяин RID-идентификаторов находится в автономном режиме, и
контроллер домена, запрашивающий новый блок, исчерпает остаток RID-идентификаторов,
создание учетной записи окончится неудачей. Чтобы снова сделать возможным создание учетных
записей, необходимо или вернуть обладателя роли хозяина RID-идентификаторов в
интерактивный режим, или эта роль должна быть передана другому контроллеру домена в данном
домене.

Хозяин эмулятора PDC

Роль эмулятора PDC требуется для того, чтобы Windows Server 2003 мог сосуществовать с
контроллерами домена, на которых выполняются более ранние версии, чем Windows 2000. В
домене, работающем на функциональном уровне Windows 2000 mixed (смешанный), контроллер
домена с Windows Server 2003 действует как основной контроллер домена (PDC) для всех
низкоуровневых (Microsoft Windows NT версий 4 или 3.51) резервных контроллеров домена (BDC
— Backup Domain Controller). В такой среде требуется эмулятор PDC для обработки изменений
пароля, реплицирования изменений домена на BDC-домены и выполнения службы главного
браузера домена (Domain Master Browser Service). Если эмулятор PDC недоступен, все события,
связанные со службами, инициированными низкоуровневыми клиентами, окончатся неудачей.
В доменах, имеющих функциональный уровень Windows 2000 native (основной) или Windows
Server 2003, эмулятор PDC используется для обслуживания модификаций пароля. Все изменения
пароля, сделанные на других контроллерах домена в домене, посылаются эмулятору PDC. Если на
контроллерах домена, не являющихся эмуляторами PDC, пользовательская идентификация терпит
неудачу, идентификация повторяется на эмуляторе PDC. Если эмулятор PDC принимал недавнее
изменение пароля к этой учетной записи, идентификация пройдет успешно.

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

Передача ролей хозяина операций

Роли хозяина операций могут передаваться другому домену для оптимизации функционирования
контроллера домена или для замены контроллера домена, если держатель роли стал недоступен.
Процесс передачи роли хозяина операций зависит от передаваемой роли. Существуют следующие
инструментальные средства для передачи ролей хозяина операций:
• хозяин схемы - оснастка Active Directory Schema;
• хозяин именования доменов — инструмент администрирования Active Directory Domains
And Trusts (Домены и доверительные отношения Active Directory);
• хозяин RID, эмулятора PDC и инфраструктуры — инструмент администрирования Active
Directory Users And Computers (Пользователи и компьютеры Active Directory).
Для передачи роли хозяина операций должна функционировать связь с обоими контроллерами
домена: текущим и предлагаемым держателем роли. В случае отказа сервера текущий держатель
роли может быть недоступен для осуществления передачи роли. В этом случае роль может быть
захвачена. Захватывать роль хозяина операций следует только в случае крайней необходимости,
если указано, что контроллер домена, держатель этой роли, будет недоступен в течение
длительного периода времени. Подробнее о захвате ролей хозяина операций см. гл. 15.

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

Компоненты схемы
Схема состоит из объектов классов и атрибутов. Объект класса определяет то, какие новые
объекты могут быть созданы в каталоге. Для каждого создаваемого в каталоге объекта сначала
должен быть определен класс. Пример объекта класса — класс User (Пользователь). Все новые
пользовательские объекты, созданные в Active Directory, являются экземплярами класса User.
Схема определяет и то, какая информация может сохраняться для каждого класса объекта. Эта
информация определяется в схеме как атрибут объекта. Объект некоторого класса может
содержать значения для всех атрибутов, определенных для этого класса, а также для всех
родительских классов этого класса. Например, учетная запись пользователя может иметь
определенные значения атрибутов для всех объектов в классе User, так же как и для класса
organizationalPerson, являющегося родительским классом класса User. При создании нового
пользовательского объекта вы можете включать информацию, касающуюся этого пользователя и
определяемую в схеме, в качестве атрибута всех классов, к которым этот новый пользовательский объект
будет принадлежать.
Тип данных, которые могут храниться в Active Directory для каждого атрибута, определен в схеме как
синтаксис атрибута. Если пользовательский класс содержит атрибут, названный display Name, синтаксис
для этого атрибута определяется как строковое значение, которое может быть любым алфавитно-цифровым
символом. Значение каждого атрибута должно удовлетворять требованиям синтаксиса этого атрибута.
Схема Active Directory поддерживает наследование объектов класса. Все объекты схемы организованы в
иерархическом порядке в контексте именования. Благодаря этому любой объект класса способен
унаследовать все характеристики объекта своего родительского класса. Например, класс Computer
(Компьютер) фактически является дочерним классом от класса User (Пользователь), и поэтому класс
Computer наследует все атрибуты, связанные с классом User. В этом случае класс Computer ассоциируется с
атрибутами, специфическими для этого класса. С помощью оснастки Active Directory Schema вы можете
увидеть организацию наследования объектов класса и иерархию объектов класса. На рисунке 2-1 показан
класс Computer (Компьютер). Обратите внимание, что он является дочерним по отношению к классу User,
который является дочерним классом класса organizationalPerson, и т.д. Эта система наследования
значительно облегчает администраторам создание новых классов объектов, потому что они не должны
определять каждый атрибут, связанный с новым классом, а могут просто унаследовать все объединения
атрибутов подходящего родительского класса.
Рис. 2-1. Объект класса Computer (Компьютер), отображаемый оснасткой Active Directory Schema

Модификация схемы
Схема Active Directory содержит большинство постоянно используемых классов и атрибутов,
необходимых для реализации службы каталога предприятия. Эти атрибуты и классы определяются
как объекты Category 1 (Категория 1), или основные объекты схемы. Для поддержки классов и
атрибутов, определяемых клиентом, при разработке схемы Active Directory закладывались
возможности ее расширения. Другими словами, она может быть изменена для включения новых
объектов классов и атрибутов, в которых, возможно, нуждается организация. Объекты схемы,
которые создаются позднее, определяются как объекты Category 2 (Категория 2). Схему обычно
расширяют для того, чтобы она удовлетворяла потребностям приложений, пользующихся
поддержкой Active Directory. Хорошим примером такого приложения является Microsoft Exchange
Server 2000, для поддержки которого при конфигурировании Active Directory было сделано более
тысячи дополнений к схеме.
Кроме использования приложений, пользующихся поддержкой Active Directory, администраторы
могут расширять схему другими методами. Это можно сделать в пакетном режиме с помощью
средств администрирования с командной строкой, включая инструменты LDAP Data Interchange
Format Directory Exchange (LDIFDE) и Comma Separated Value Directory Exchange (CSVDE). Схема
может быть расширена программно, используя Active Directory Service Interfaces (ADSI) и
сценарии Microsoft Visual Basic.
Дополнительная информация. Для получения дополнительной информации об
инструментах LDIFDE или CSVDE напечатайте название команды в командной строке для
вызова онлайновой подсказки. Для получения дополнительной информации об ADSI и ADSI
Edit обратитесь к комплекту разработки программного обеспечения Microsoft Windows
Platform (SDK), который можно загрузить или заказать на компакт-диске на сайте http://
www.microsoft.com/msdownload/platformsdk/sdkupdate.Чacть ADSI Platform SDK можно
просмотреть интерактивно на сайте http://msdn.microsoft.com/library/default.asp?url=/library/
en-us/netdir/adsi/directory_services.asp.
Схема может быть изменена через интерфейс пользователя Windows Server 2003 с помощью
оснастки Active Directory Schema. Сначала нужно зарегистрировать оснастку, выполнив команду
Regsvr32 Schmmgmt.dll из командной строки. Для изменения схемы вы должны быть членом
глобальной группы Schema Admins (Администраторы схемы). Чтобы понять, как работает
изменение схемы, представьте себе, что организации необходимо сохранять записи о датах, когда
служащие приступили к работе, т.е. сохранять дату начала работы служащего как ат-
рибут пользовательского объекта в Active Directory. Чтобы этот атрибут был доступен при
создании каждого нового пользовательского объекта, он сначала должен быть определен в схеме.
С помощью оснастки Active Directory Schema вы можете добавить новый атрибут к схеме и
связать его с объектом класса User. Для этого выполните следующие шаги.
1. Откройте оснастку Active Directory Schema (Схема Active Directory).
2. Выберите папку Attributes (Атрибуты) на панели дерева.
3. В меню Action (Действие) щелкните на Create Attribute (Создать атрибут).
 4. В окне предупреждения Schema Object Creation (Создание объекта схемы) щелкните на
Continue (Продолжить).
5. В диалоговом окне Create New Attribute (Создание нового атрибута) введите информацию
в раздел Identification (Идентификация):
• Common Name (обычное имя);
• LDAP Display Name (отображаемое LDAP-имя);
• Unique X500 Object ID (уникальный идентификатор объекта Х500);
• Description (описание).
6. В разделе Syntax And Range (Синтаксис и диапазон) внесите информацию в поля:
• Syntax (синтаксис);
• Minimum (минимум);
• Maximum (максимум).
7. Выберите, будет ли новый атрибут многозначным (Multi-Valued) атрибутом.
Подробная информация, касающаяся содержания каждого поля, становится доступной при выборе
соответствующего текстового поля и нажатии клавиши F1.

Получение идентификатора Х500 Object ID

Иногда два приложения могут попытаться сделать несовместимые модификации в схеме. Чтобы
решить эту проблему, каждый класс и атрибут в Active Directory могут быть идентифицированы
уникальным идентификатором объекта (OID — Object Identifier) для гарантии того, что другой
объект схемы не использует тот же самый OID. Организация, планирующая создание новых OID,
должна зарегистрироваться в Международной организации по стандартизации (ISO — International
Standards Organization) или в Американском национальном институте стандартов (ANSI - American
National Standards Institute). При регистрации организация стандартов выделит вам часть
пространства OID, которое затем можно расширять для удовлетворения своих потребностей.
Например, компании может быть предоставлено число типа 1.2.840.ХХХХ. Оно организовано в
иерархическом порядке и содержит следующие части:
• 1 - ISO;
• 2-ANSI;
• 840 - Соединенные Штаты Америки;
• ХХХХ — уникальное число, идентифицирующее вашу компанию.
Как только вы получили это число, можно управлять своей собственной частью иерархии.
Например, если вы создаете новый атрибут с именем Employee Start Date (Дата начала работы
служащего), ему можно назначить число типа 1.2.840.ХХХХ.12.
Пусть OID для контакта в Active Directory задан в виде 1.2.840.113556.1.5.15. Первые три части
числа выделены для ISO, ANSI и США соответственно. Число 113556 ANSI предоставил
компании Microsoft, которая назначила 1 - на Active Directory, 5 — на классы Active Directory, 15 -
на класс Contact (Контакт).
Комплект ресурсов Microsoft Windows Server 2000 Resource Kit содержит инструмент по имени
OIDGen, который можно использовать для создания уникальных идентификаторов OID для
классов или атрибутов объекта без необходимости регистрировать OID. Этот инструмент не
должен использоваться, если схема будет развертываться вне вашей организации. Для внешнего
развертывания Microsoft предлагает сгенерировать и зарегистрировать ваш новый OID.
Подробности см. на сайте http://msdn.microsoft.com/certification/ad-registration.asp.
На рисунке 2-2 показано создание нового атрибута с помощью оснастки Active Directory Schema
(Схема Active Directory).
Рис. 2-2. Создание нового атрибута схемы

Примечание. Добавление нового атрибута к схеме не подразумевает, что атрибут будет

автоматически доступен из любого средства администрирования. Инструментальные средства
администрирования, подобные Active Directory Users And Computers (Пользователи и компьютеры
Active Directory), показывают только некоторые атрибуты для каждого класса и не показывают
атрибуты, которые добавляете вы. Если вы хотите, чтобы новый атрибут появился в
инструменте администрирования, нужно изменить существующий инструмент или создать ваш
собственный. О том, как изменять и создавать инструментальные средства
администрирования, см. в разделе Directory Services (Службы каталога) документа Platform SDK
на сайте http:// msdn.microsoft.com/library/default.asp?url=/library/en-us/
netdir/ad/extending_the_user_interface_for_directory_objects.asp.

Дезактивация объектов схемы

Расширение схемы не является сложной операцией, но перед ее осуществлением необходимо
провести предварительное планирование, ведь все изменения схемы являются необратимыми.
Объекты не могут быть удалены из схемы. Если вы сделаете ошибку при расширении схемы, вы
можете отключить (дезактивировать) объект. В Windows Server 2003 дезактивированные объекты
схемы могут снова использоваться при необходимости, а новые объекты схемы могут создаваться
с тем же самым именем, которое имел дезактивированный объект.
Есть несколько моментов, которые надо иметь в виду при дезактивации класса схемы и объектов
атрибутов. Сначала вы можете дезактивировать только классы и атрибуты, которые вы специально
создавали, т.е. объекты Category 2. Вы не можете дезактивировать объекты Category 1 или базовую
схему. Нельзя отключить атрибут, являющийся членом класса, который не дезактивирован. Это
ограничение предотвращает ошибки в создании новых экземпляров недезактивированного класса,
если становится нужен дезактивированный атрибут.
Чтобы дезактивировать объект атрибута или класса Category 2, установите булевое значение
атрибута isDefunct объекта схемы на true (истина). Это можно выполнить, используя инструмент
ADSI Edit (Редактирование ADSI) или оснастку Active Directory Schema (Схема Active Directory).
На рисунке 2-3 показано, какие флажки параметров установки надо очистить для дезактивации
атрибута EmployeeStartDate, созданного в примере, представленном ранее.
После того как объект схемы был дезактивирован, он считается несуществующим. Сообщения об
ошибках в случае попытки создания нового экземпляра несуществующего класса или атрибута те
же самые, которые появляются, если класс или атрибут схемы не существуют. Единственное
действие, которое можно выполнить с дезактивированным
объектом схемы, состоит в его повторной активации. Для этого просто установите атрибут
isDefunt на false (ложь). После активации несуществующего объекта схемы его можно снова
использовать для создания новых экземпляров класса или атрибута. Процесс
дезактивации/активации не влечет за собой никаких неблагоприятных последствий.
Рис. 2-3. Использование оснастки Active Directory Schema (Схема Active Directory) для дезактивации
атрибута схемы

Логическая структура Active Directory

После того как вы установили Active Directory в свою сетевую среду и начали реализовывать
проект службы, подходящий для ваших деловых целей, вы будете работать с логической
структурой Active Directory. Она является моделью службы каталога, которая определяет каждого
участника безопасности на предприятии, а также организацию этих участников. База данных
Active Directory содержит следующие структурные объекты:
• разделы;
• домены;
• деревья доменов;
• леса;
• сайты;
• организационные единицы.
Далее представлено введение в эти компоненты и концепции доверительных отношений, которые
используются для выдачи разрешений на доступ участников безопасности к ресурсам,
хранящимся в различных доменах. В главе 5 вы узнаете, как эти структурные компоненты
используются для достижения определенных целей (например, защита доступа к ресурсам) и
оптимизации производительности сети. Сами участники безопасности (пользователи, группы и
компьютеры) в этой главе не обсуждаются.

Разделы Active Directory

Как вы уже знаете, база данных Active Directory хранится в файле на жестком диске каждого
контроллера домена. Она разделена на несколько логических разделов, каждый из которых хранит
различные типы информации. Разделы Active Directory называются контекстами именования (NC -
naming contexts). Просмотреть их можно с помощью инструмента Ldp.exe или ADSI Edit (рис. 2-4).
Рис. 2-4. Просмотр разделов Active Directory с помощью инструмента ADSI Edit

Раздел домена каталога

В разделе домена происходит большая часть действий. Он содержит всю информацию домена о
пользователях, группах, компьютерах и контактах: все, что можно просмотреть с помощью
инструмента администрирования Active Directory Users And Computers (Пользователи и
компьютеры Active Directory).
Раздел домена автоматически реплицируется на все контроллеры в домене. Информация, которая
в нем содержится, требуется каждому контроллеру домена для подтверждения подлинности
пользователей.

Раздел конфигурации каталога

Раздел конфигурации содержит информацию о конфигурации леса, например, информацию о
сайтах, связях сайта и подключениях репликации. В нем хранят информацию многие прикладные
программы. Приложения Exchange Server 2000, Microsoft Internet Security And Acceleration (ISA)
Server помещают свою конфигурационную информацию в раздел конфигурации каталога Active
Directory, а не в свою собственную службу каталога. Когда вы устанавливаете первый ISA-сервер
в свою организацию, вы можете сконфигурировать массив, который будет хранить всю
конфигурационную информацию ISA в Active Directory. Затем легко устанавливаются
дополнительные ISA-серверы, использующие эту же конфигурацию, которая читается из службы
Active Directory.
Раздел конфигурации каталога имеет свои копии повсюду в пределах леса. Каждый контроллер
домена содержит перезаписываемую копию раздела конфигурации, и изменения в этот раздел
каталога могут быть внесены с любого контроллера домена в организации. Это означает, что
конфигурационная информация реплицируется на все контроллеры домена. Когда репликация
полностью синхронизирована, каждый контроллер домена в лесу будет иметь одну и ту же
конфигурационную информацию.

Раздел схемы каталога

Раздел схемы содержит схему для всего леса. Как вы уже знаете, схема представляет собой набор
правил о том, какие типы объектов можно создавать в Active Directory, а также правила для
каждого типа объектов. Раздел схемы реплицируется на все контроллеры домена в лесу. Однако
только один контроллер домена, хозяин схемы, хранит перезаписываемую копию раздела схемы
каталога. Все изменения к схеме осуществляются на контроллере - хозяине схемы, а затем
реплицируются на другие контроллеры домена.
Раздел глобального каталога
Раздел глобального каталога GC не является разделом в полном смысле. Он хранится в базе
данных подобно другому разделу, но администраторы не могут вводить информацию в него
напрямую. Раздел GC предназначен только для чтения на всех GC-серверах, он построен из
содержимого баз данных домена. Каждый атрибут в схеме имеет булевое значение с именем
isMemberOf Partial Attributes et. Если оно установлено на true (истина), атрибут копируется в
каталог GC.

Разделы приложений каталога

Последний тип раздела в службе Active Directory Windows Server 2003 - это раздел приложений
каталога. Только один тип раздела приложений каталога создается в Active Directory по
умолчанию — это раздел, предназначенный для службы сервера доменной системы имен (DNS -
Domain Name System). При установке первой интегрированной (integrated) зоны Active Directory
создаются прикладные разделы каталога ForestDnsZones и DomainDnsZones. Раздел приложений
каталога может хранить любой тип объекта Active Directory, кроме участников безопасности.
Кроме того, разделы приложений каталога создаются для управления процессом репликации
данных, и ни один из объектов раздела приложений каталога не может реплицироваться в раздел
GC.
Разделы приложений каталога используются для хранения специфической информации, связанной
с приложениями. Выгода от их использования состоит в том, что имеется возможность управлять
репликацией информации в раздел. Для слишком динамичной информации необходимо управлять
репликами, чтобы ограничить количество трафика сети. При создании раздела приложений
каталога вы можете указать, какие контроллеры домена будут получать реплику раздела.
Контроллеры домена, которые получают реплику раздела приложений, могут находиться в любом
домене или сайте леса.
Схема именования прикладных разделов каталога идентична другим разделам каталога Active
Directory. Например, DNS-имя для конфигурационного раздела каталога в лесу Contoso.com -
dc=Configuration, dc=Contoso, dc=com. Если вы создаете раздел приложений каталога по имени
AppPartitionl в домене Contoso.com, его DNS-имя будет dc=AppPartitionl, dc=Contoso, dc=com.
Разделы приложений каталога достаточно гибки по отношению к месту создания, или, более
точно, к контексту именования. Например, можно создать дополнительный раздел приложений
каталога в разделе AppPartitionl. Это приведет к тому, что раздел будет иметь имя
dc=AppPartition2, dc=AppPartitionl, dc=Contoso, dc=com. Возможно создание раздела приложений
каталога с DNS-именем, не смежным ни с одним доменом в лесу. Вы можете создать раздел
приложений в домене Contoso.com, который имеет DNS-имя dc=AppPartition, таким образом,
будет создано новое дерево в лесу.
Примечание. Выбор DNS-имени для пространства имен приложения никак не влияет на
функциональные возможности раздела приложений. Единственное различие будет состоять в
конфигурировании LDAP-клиента, который обращается к разделу. Разделы приложений
каталога предназначены для доступа LDAP, поэтому клиент должен быть сконфигурирован так,
чтобы делать поиск на сервере в правильном пространстве имен.
Создание раздела приложений каталога усложняется необходимостью обслуживания разрешений
на доступ к объектам раздела. Для заданных по умолчанию разделов Active Directory разрешения
назначаются автоматически. При создании объекта в разделе каталога домена
группе Domain Admins (Администраторы домена) автоматически назначаются полные разрешения
на доступ к объекту. При создании объекта в разделе конфигурации или в разделе схемы каталога
разрешения назначаются для учетных записей пользователей и групп, принадлежащих корневому
домену леса. Поскольку прикладной раздел каталога может быть создан в любом разделе домена
каталога или как отдельное дерево в лесу, то заданный по умолчанию путь назначения разрешений
не применяется. Назначить группе Domain Admins полное управление объектами в разделе
несложно, остается неясным то, какой домен является заданным по умолчанию. Поэтому разделы
приложений каталога всегда создаются со ссылкой на домен, содержащий дескрипторы защиты.
Этот домен становится заданным по умолчанию, он используется для назначения разрешений на
доступ к объектам в разделе приложений каталога. Если раздел приложений каталога создается в
разделе домена каталога, то родительский домен используется в качестве домена, содержащего
дескрипторы защиты, и создается наследование разрешений. Если раздел приложений каталога
создает новое дерево в лесу, то корневой домен леса используется в качестве домена, содержащего
дескрипторы защиты.
Совет. Обычно разделы приложений каталога создаются в процессе инсталляции приложения,
для которого требуется использование раздела каталога. Инсталляционная процедура
приложения должна разрешать создание дополнительных реплик на других контроллерах домена.
Вы можете создать каталог приложений с помощью утилиты Ntdsutil, но в среде предприятия
это обычно не используется. Процедуры управления разделами приложений каталога описаны в
справке Windows Server 2003 Help And Support Center (Центр справки и поддержки Windows Server
2003). Для получения детальной информации о разделах приложений каталога, о том, как
обращаться к ним программно, сделайте поиск фразы «Using application directory partitions» на
сайте msdn.microsoft.com.
Как только раздел приложений каталога с несколькими репликами создан, управление
репликацией раздела осуществляется так же, как для других разделов. Дополнительную
информацию о репликации Active Directory см. в гл. 4.

Домены
Домен является основным строительным блоком в модели службы Active Directory. Устанавливая
Active Directory на своем компьютере, работающем под управлением Windows Server 2003, вы
создаете домен. Домен служит в качестве административной границы, он определяет и грани-
цу политик безопасности. Каждый домен имеет, по крайней мере, один контроллер домена
(оптимально иметь два или более).
Домены Active Directory организованы в иерархическом порядке. Первый домен на предприятии
становится корневым доменом леса, обычно он называется корневым доменом или доменом леса.
Корневой домен является отправной точкой для пространства имен Active Directory. Например,
первый домен в организации Contoso — Contoso.com. Первый домен может быть назначенным
(dedicated) или неназначенным (non-dedicated) корневым доменом. Назначенный корневой домен,
называемый пустым корнем, является пустым доменом-заменителем, предназначенным для
запуска Active Directory. Этот домен не будет содержать никаких реальных учетных записей
пользователя (группы) и использоваться для назначения доступа к ресурсам. Единственные
учетные записи, которые содержатся в назначенном корневом домене — это учетные записи
пользователей и групп, заданных по умолчанию, таких как учетная запись Administrator
(Администратор) и глобальная группа Domain Admins (Администраторы домена). Неназначенный
корневой домен - это домен, в котором создаются учетные записи фактических пользователей и
групп. Причины выбора назначенного или неназначен-ного корневого домена леса обсуждаются в
гл. 5.
Остальные домены на предприятии существуют или как равные по положению (peers) по
отношению к корневому домену, или как дочерние домены. Равные по положению домены
находятся на том же иерархическом уровне, что и корневой домен. На рисунке 2-5 показана
модель доменов, равных по положению.

Рис. 2-5. Домены Active Directory, организованные как равные по положению

Общепринято, что домены, устанавливаемые вслед за корневым доменом, становятся дочерними
доменами. Дочерние домены используют одно и то же пространство имен Active Directory
совместно с родительским доменом. Например, если первый домен в организации Contoso назван
Contoso.com, то дочерний домен в этой структуре может называться NAmerica.Contoso.com и
использоваться для управления всеми участниками безопасности организации Contoso,
находящимися в Северной Америке. Если организация достаточно большая или сложная, то могут
потребоваться дополнительные дочерние домены, например, Sales.NAmerica.Contoso.com. На
рисунке 2-6 показана родительско-до-черняя иерархия домена для организации Contoso.
Рис. 2-6. Родительско-дочерняя модель домена для корпорации Contoso

Деревья доменов
Домены, которые создаются в инфраструктуре Active Directory после создания корневого домена,
могут использовать существующее пространство имен Active Directory совместно или иметь
отдельное пространство имен. Чтобы выделить отдельное пространство имен для нового домена,
нужно создать новое дерево домена. Независимо от того, используется ли единственное
пространство имен или несколько, дополнительные домены в том же самом лесу функционируют
совершенно одинаково. Создание дополнительных деревьев доменов связано исключительно с
организационными проблемами и проблемами именования, оно никак не затрагивает
функциональные возможности. Дерево доменов содержит, по крайней мере, один домен. Даже
организация с единственным доменом имеет дерево доменов. Использование нескольких деревьев
вместо дочерних доменов влияет на конфигурацию DNS, об этом вы узнаете в гл. 3.
Дерево доменов образуется в том случае, когда организация создает домен вслед за созданием
корневого домена леса (forest root domain), но не хочет использовать существующее пространство
имен. В случае Contoso, если существующее дерево доменов использует пространство имен
Contoso.com, может быть создан новый домен, который использует совершенно другое
пространство имен, например, Fabrikam.com. Если в дальнейшем потребуется создание доменов,
чтобы удовлетворить потребностям единицы Fabrikam, они могут создаваться как дочерние от
дерева доменов Fabrikam. На рисунке 2-7 показана схема организации Contoso с несколькими
доменными деревьями.

Рис. 2-7. Корпорация Contoso с несколькими доменными деревьями

Леса
Лес представляет самую дальнюю репликацию и является границей безопасности для
предприятия. Все домены и доменные деревья существуют в пределах одного или несколько лесов
Active Directory. Лес является общим для всех контроллеров домена в лесу. Общими
компонентами могут быть:
• Общая схема. У всех контроллеров домена в лесу имеется одна и та же схема.
Единственный способ развертывания двух различных схем в одной организации состоит в
том, чтобы развертывать два отдельных леса.
• Общий раздел конфигурации каталога. Все контроллеры домена в лесу имеют один и
тот же конфигурационный контейнер, который используется для репликации в пределах
леса. Раздел конфигурации каталога интенсивно используется приложениями,
поддерживающими службу Active Directory (Echange Server 2000 и ISA).
• Общий глобальный каталог GC. Он содержит информацию обо всех объектах в лесу.
Это делает поиск любого объекта более эффективным и дает возможность пользователям
входить на любой домен леса, используя свои имена UPN.
• Общий набор администраторов в пределах леса. В корневом домене для леса создаются
две группы безопасности (security groups). Им предоставляются такие разрешения,
которыми не обладают никакие другие пользователи. Группа Schema Admins является
единственной группой, которая имеет право изменять схему, а группа Enterprise Admins
(Администраторы предприятия) является единственной группой, которая имеет право
выполнять действия на уровне леса, такие как добавление или удаление доменов из леса.
Группа Enterprise Admins автоматически добавляется к каждой местной группе
Administrators (Администраторы) на контроллерах домена в каждом домене леса.
• Общая конфигурация доверительных отношений. Все домены в лесу автоматически
сконфигурированы так, чтобы доверять всем другим доменам леса. Более подробно о
доверительных отношениях рассказано в следующем разделе.
На рисунке 2-8 показан лес Contoso.

Доверительные отношения
По умолчанию домен является границей доступа к ресурсам в организации. Имея
соответствующие разрешения, любой участник безопасности (например, учетная запись
пользователя или группы) может обращаться к любому общедоступному ресурсу в том же самом
домене. Для получения доступа к ресурсам, которые находятся за пределами домена,
используются доверительные отношения службы Active Directory. Доверительные отношения
представляют собой опознавательную связь между двумя доменами, с помощью которой
участники безопасности могут получать полномочия на доступ к ресурсам, расположенным на
другом домене. Есть несколько типов доверительных отношений, включающих:
• транзитивные доверительные отношения;
• односторонние доверительные отношения;
• доверительные отношения леса;
 • доверительные отношения области.

Транзитивные доверительные отношения

Все домены дерева поддерживают транзитивные двухсторонние доверительные отношения с
другими доменами в этом дереве. В примере, рассмотренном выше, когда домен
NAmerica.Contoso.com создается как дочерний домен корневого домена Contoso.com,
автоматически создаются двухсторонние доверительные отношения между доменами
NAmerica.Contoso.com и Contoso.com. Через доверительные отношения любой пользователь в
домене NAmerica.Contoso.com может обращаться к любому ресурсу в домене Contoso.com, на
доступ к которому есть разрешение. Аналогично, если в домене Contoso.com имеются какие-либо
участники безопасности (как в неназначенном корневом домене), им можно давать доступ к
ресурсам домена NAmerica.Contoso.com.
В пределах леса доверительные отношения устанавливаются или как родительско-дочерние
доверительные отношения, или как доверительные отношения корня дерева (tree root). Примером
родительско-дочер-них доверительных отношений являются отношения между доменами
NAmerica.Contoso.com и Contoso.com. Доверительные отношения корня дерева - это отношения
между двумя деревьями в лесу, например, между Contoso.com и Fabrikam.com.
Все доверительные отношения между доменами леса являются транзитивными. Это означает, что
все домены в лесу доверяют друг другу. Если домен Contoso.com доверяет домену
NAmerica.Contoso.com и домен Europe.Contoso.com доверяет домену Contoso.com, то
транзитивность указывает на то, что домен Europe.Contoso.com также доверяет домену
NAmerica.Contoso.com. Поэтому пользователи в домене NAmerica. Contoso.com могут обращаться
к ресурсам, имеющимся в домене Europe.Contoso.com, и наоборот. Свойство транзитивности
доверительных отношений применимо к доверительным отношениям корня дерева. Домен
NAmerica.Contoso.com доверяет домену Contoso.com, и домен Contoso.com доверяет домену
Fabrikam.com. Поэтому домен NAmerica. Contoso.com и домен Fabrikam.com также имеют
транзитивные доверительные отношения друг с другом.

Односторонние доверительные отношения

В дополнение к двухсторонним транзитивным доверительным отношениям, которые
устанавливаются при создании нового дочернего домена, между доменами леса могут быть
созданы односторонние доверительные отношения. Это делается для того, чтобы разрешить
доступ к ресурсам между доменами, которые не состоят в прямых доверительных отношениях.
Односторонние доверительные отношения также исполь-
зуются для оптимизации производительности работы между доменами, которые связаны
транзитивными доверительными отношениями. Эти односторонние доверительные отношения
называются укороченными доверительными отношениями (shortcut trusts). Укороченные
доверительные отношения нужны в том случае, когда требуется частый доступ к ресурсам между
доменами, которые удаленно связаны через дерево домена или лес. Примером этому является лес
Contoso, изображенный на рисунке 2-9.

Рис. 2-9. Доверительные отношения в лесу Contoso

Если группа безопасности в домене Sales.Europe.Contoso.com часто обращается к общему ресурсу
в домене Research.NAmerica.Contoso.com, то при наличии только транзитивных доверительных
отношения между доменами пользователи в домене Sales.Europe.Contoso.com должны
подтверждать подлинность в каждом домене дерева, расположенном между ними и доменом,
который содержит ресурс. Такая организация работы неэффективна, если часто возникает
потребность доступа к этим ресурсам. Укороченные доверительные отношения являются прямыми
односторонними доверительными отношениями, которые дадут возможность пользователям в
домене Sales.Europe.Contoso.com эффективно подтверждать подлинность в домене
Research.NAmerica.Contoso.com без необходимости пересекать все дерево каталога, чтобы туда
добраться. На рисунке 2-10 показаны эти прямые доверительные отношения. Если возникает
потребность установить такие же доверительные отношения в другом направлении, можно создать
прямые доверительные отношения между этими двумя доменами, взаимно изменив их роли.
(Такие двойные прямые доверительные отношения кажутся транзитивными
отношениями, но эти исключительные доверительные отношения не простираются за пределы
этих двух доменов).

Доверительные отношения леса

Доверительные отношения леса являются новой функцией в Windows Server 2003. Они
представляют собой двухсторонние транзитивные доверительные отношения между двумя
отдельными лесами. С помощью доверительных отношений леса участнику безопасности,
принадлежащему одному лесу, можно давать доступ к ресурсам в любом домене совершенно
другого леса. Кроме того, пользователи могут входить на любой домен обоих лесов, используя
одно и то же имя UPN.

• Доверительные отношения леса не являются транзитивными по отношению к другим

лесам. Например, если Forest 1 имеет доверительные отношения леса с Forest2, и Forest2
имеет доверительные отношения леса с Forest3, то Forestl не имеет автоматических
доверительных отношений леса с Forest3.
• Доверительные отношения леса делают возможной только идентификацию между лесами,
они не обеспечивают другие функциональные возможности. Например, каждый лес будет
иметь уникальный каталог GC, схему и раздел конфигурации каталога. Информация
между этими двумя лесами не копируется, доверительные отношения леса просто делают
возможным назначение доступа к ресурсам между лесами.
• В некоторых случаях вам потребуется установить доверительные отношения между всеми
доменами одного леса и всеми доменами другого леса. Для этого вы можете устанавливать
односторонние, не транзитивные доверительные отношения между индивидуальными
доменами в двух отдельных лесах.
На рисунке 2-11 показаны доверительные отношения леса компании Contoso.
Рис. 2-11. Доверительные отношения леса компании Contoso соединяют домены Contoso.com и
NWTraders.com, находящиеся в разных лесах

Доверительные отношения области

Последний тип доверительных отношений — это доверительные отношения области (Realm
Trusts). Они устанавливаются между доменом или лесом Windows Server 2003 и не Windows-
реализацией области Kerberos v5. Защита Kerberos основана на открытом стандарте, имеются
другие сие-
темы сетевой защиты, основанные на протоколе Kerberos. Доверительные отношения области
можно создать между любыми Kerberos-облас-тями, которые поддерживают стандарт Kerberos v5.
Доверительные отношения области могут быть односторонними или двухсторонними, их можно
также сконфигурировать как транзитивные и не транзитивные.

Сайты
Все логические компоненты Active Directory, обсуждаемые до сих пор, практически не зависят от
физической инфраструктуры сети. Например, при проектировании структуры домена для
корпорации вопрос о том, где расположены пользователи, является не самым важным. Все
пользователи в домене могут находиться в единственном офисном строении или в офисах,
расположенных по всему миру. Независимость логических компонентов от сетевой
инфраструктуры возникает вследствие использования сайтов в Active Directory.
Сайты обеспечивают соединение между логическими компонентами Active Directory и физической
сетевой инфраструктурой. Сайт представляет область сети, где все контроллеры домена связаны
быстрым, недорогим и надежным сетевым подключением. В большинстве случаев сайт содержит
одну или более подсетей с протоколом интернета (IP), связанных локальной сетью (LAN) или
быстродействующей глобальной сетью (WAN), подключенных к остальной части сети через более
медленные WAN-подключения.
Основная причина для создания сайтов состоит в том, чтобы иметь возможность управлять любым
сетевым трафиком, который должен использовать медленные сетевые подключения. Сайты
используются для управления сетевым трафиком в пределах сети Windows Server 2003 тремя
различными способами.
• Репликация. Одним из важнейших способов, которым сайты пользуются для
оптимизации сетевого трафика, является управление трафиком репликации между
контроллерами доменов и GC-серверами. В пределах сайта любое изменение, сделанное в
каталоге, будет копироваться в течение приблизительно пяти минут. Графиком
репликации между сайтами можно управлять так, чтобы репликация происходила во время
нерабочих часов. По умолчанию трафик репликации между сайтами сжат для сохранения
пропускной способности сети, в пределах сайта трафик репликации не сжимается. (В главе
4 представлена более детальная информации относительно различий между
внутрисайтовой и межсайтовой репликациями.)
 • Идентификация. Когда пользователь входит в домен Windows Server 2003 с клиента, на
котором работает система Windows 2000 или Microsoft Windows XP Professional,
компьютер клиента пробует подключить контроллер домена, находящийся в том же самом
сайте, где находится клиент. В главе 3 будет обсуждаться, как каждый контроллер домена
регистрирует записи указателя служб (SRV), специфические для сайта. Когда компьютер
клиента пытается найти контроллер домена, он всегда запрашивает записи сайтов у DNS-
серверов. Это означает, что трафик входа клиента в систему останется в пределах сайта.
Если домен работает на функциональном уровне Windows 2000 native (основной) или
Windows Server 2003, то клиент будет пытаться найти каталог GC во время входа в
систему. Если на сайте имеется GC-сервер, клиент соединится с этим сервером. (Роль
сайтов в поиске контроллеров домена подробно обсуждается в гл. 3.)
Примечание. Клиентские компьютеры, на которых работает система Windows NT 4 SP6a,
могут регистрироваться на контроллерах домена Active Directory, если они установили службу
Directory Services Client (Клиент служб каталога), которая доступна для загрузки на сайте
http://www.microsoft.com/ windows2000/server/evaluation/news/bulletins/ adextension.asp. Для тех
клиентов, которые не были модернизированы с Windows 95 или Windows 98, программное
обеспечение Directory Services Client доступно на компакт-диске Windows Server 2000.
• Сетевые службы, учитывающие наличие сайтов. Третий способ, который позволяет
сайтам сохранять высокую пропускную способность, состоит в ограничении клиентских
подключений к сайту только теми приложениями и службами, которые учитывают
наличие сайтов. Например, используя распределенную файловую систему (DFS -
Distributed File System), вы можете создавать несколько реплик папки на различных сайтах
в сети. Поскольку система DFS спроектирована так, что она учитывает конфигурацию
сайта, компьютеры клиента всегда пробуют обратиться к DFS-реплике на своем
собственном сайте, прежде чем использовать связи WAN-сети, чтобы получить доступ к
информации на другом сайте.
Каждый компьютер в сети Windows Server 2003 будет назначен сайту. Когда служба Active
Directory устанавливается в среде Windows Server 2003, создается заданный по умолчанию сайт,
называемый Default First Site Name (заданное по умолчанию имя первого сайта), и все компьютеры
леса будут назначены этому сайту, если не создается дополнительных сайтов. Когда создаются
дополнительные сайты, они связываются с подсетями IP. Когда сервер, на котором выполняется
система Windows Server 2003, становится контроллером домена, то он автоматически назначается
тому сайту, который назначен IP-адресу компьютера. При необходимости контроллеры домена
можно перемещать между сайтами с помощью инструмента администрирования Active Directory
Sites And Services (Active Directory: Сайты и службы).
Клиентские компьютеры определяют свои сайты в первый раз, когда они запускаются и входят в
домен. Поскольку компьютер клиента не знает, какому сайту он принадлежит, то он соединяется с
любым контроллером домена в домене. В процессе входа в систему контроллер домена сообщит
клиенту, какому сайту он принадлежит, и клиент будет кэши-ровать эту информацию для
следующего входа в систему.
Примечание. Если контроллер домена или компьютер клиента имеют IP-адрес, который не
связан с определенным сайтом, то этот компьютер будет приписан в сайт Default First Site
Name. Каждый компьютер, который является частью домена Windows Server 2003, должен
принадлежать сайту.
Как уже было сказано выше, нет прямой связи между сайтами и другими логическими
концепциями Active Directory. Один сайт может содержать более одного домена, и один домен
может принадлежать нескольким сайтам. На рисунке 2-12 показано, что сайт Seattle содержит два
домена: Contoso.com и NAmerica.Contoso.com. Домен NWTraders.com распределен между
несколькими сайтами.
Примечания. Сайты подробно обсуждаются в других главах. В главе 3 детализируется роль DNS
и сайтов для клиентских входов в систему. Глава 4 посвящена роли сайтов в репликации и тому,
как создавать и конфигурировать сайты. В главе 5 дается детальная информация по
проектированию оптимальной конфигурации сайта для леса Active Directory.

Организационные единицы
Путем реализации нескольких доменов в лесу в виде одного или нескольких деревьев служба
Active Directory Windows Server 2003 может масштабироваться так, чтобы обеспечить услуги
каталога для сети любого размера. Многие из компонентов Active Directory, такие как глобальный
каталог и автоматические транзитивные доверительные отношения, предназначены для того,
чтобы сделать использование и управление каталогом предприятия эффективным, независимо от
того, насколько большим становится каталог.
Организационные единицы (OU - Organizational Unit) предназначены для того, чтобы облегчить
управление службой Active Directory. OU используются для того, чтобы сделать более
эффективным управление единственным доменом, вместо того чтобы иметь дело с управлением
несколькими доменами службы Active Directory. OU служат для создания иерархической
структуры в пределах домена. Домен может содержать сотни тысяч объектов. Управление таким
количеством объектов без использования определенных средств организации объектов в
логические группы затруднено. Организационные единицы выполняют именно эти функции. На
рисунке 2-13 показан пример структуры OU в корпорации Contoso.

Рис. 2-13. Пример структуры организационных единиц

OU являются контейнерами объектов, содержащими несколько типов объектов службы каталога:

• компьютеры;
• контакты;
 • группы;
• inetOrgPerson;
• принтеры;
• пользователи;
• общедоступные папки;
• организационные единицы.
Организационные единицы используются для группировки объектов в административных целях.
Они могут делегировать административные права и управлять группой объектов как отдельным
подразделением.

Использование организационных единиц для делегирования

административных прав
Организационные единицы могут использоваться для делегирования административных прав.
Например, пользователю могут быть даны права на выполнение административных задач в
определенной OU. Это могут быть права высокого уровня, когда пользователь имеет полный
контроль над подразделением, или очень ограниченные и специфические (например, только
возможность сбрасывания паролей пользователей в этом подразделении). Пользователь, который
имеет административные права на доступ к организационной единице, по умолчанию не имеет
никаких административных прав вне OU.
Организационные единицы имеют гибкую структуру назначения прав на доступ к объектам
внутри OU. Во многих диалоговых окнах Windows и во вкладках Properties (Свойства) они
называются разрешениями. Сама организационная единица OU имеет список управления
доступом (ACL — Access Control List), в котором можно назначать права на доступ к этой OU.
Каждый объект в OU и каждый атрибут объекта имеет ACL-список. Это означает, что вы можете
очень точно контролировать административные права, данные кому-либо в этом подразделении.
Например, вы можете дать группе Help Desk (Справочная) право изменять пароли пользователей в
OU, не изменяя любые другие свойства учетных записей пользователя. Можно дать отделу Human
Resources (Отдел кадров) право изменять личную информацию, касающуюся любой учетной
записи пользователя в любом OU, но не давать им никаких прав на другие объекты.

Использование организационных единиц для управления группами

объектов
Одной из функций OU является объединение объектов в группы так, чтобы этими объектами
можно было одинаково управлять. Если вы хотите одинаково управлять всеми компьютерами в
отделе (например, вводя ограничения на то, какие пользователи имеют право входа в
операционную систему), вы можете сгруппировать компьютеры в OU и
установить разрешение Logon Locally (Локальный вход в систему) на уровне OU. Это разрешение
будет установлено для всех компьютеров в данной OU. Другим примером группировки объектов в
административных целях является ситуация, когда совокупность пользователей нуждается в
одинаковой стандартной конфигурации рабочего стола компьютера и одинаковом наборе
приложений. В этом случае пользователи объединяются в одну OU, и используется групповая
политика (group policy) для конфигурирования рабочего стола и управления инсталляцией
приложений.
В многих случаях объекты в OU будут управляться через групповую политику. Group Policy
Object Editor (Редактор объектов групповой политики) представляет собой инструмент, который
может использоваться для управления рабочей средой каждого пользователя. Групповые политики
могут использоваться для блокировки пользовательских рабочих столов, для придания им
стандартного вида, обеспечения сценариев входа в систему и выхода из нее, перенаправления
папок. В таблице 2-3 дается краткий список типов параметров настройки, доступных в редакторе
Group Policy Object Editor.
Табл. 2-3. Типы параметров настройки групповой политики
Типы параметров Пояснение
настройки
Administrative Используется для управления параметрами,
templates связанными с системным реестром, для
(Административные конфигурирования параметров настройки
шаблоны) приложений и пользовательского рабочего стола,
включая доступ к компонентам операционной
системы, к панели управления и конфигурацию
автономных файлов.
Security Используется для управления локальным
(Безопасность) компьютером, доменом и параметрами настройки
сетевой защиты, включая управление
пользовательским доступом к сети,
конфигурирование политик учетных записей и
управление правами пользователей.
Software installation Используется для централизованного управления
(Установка установкой программного обеспечения.
программного
обеспечения)
Scripts (Сценарии) Используется для определения сценариев,
которые могут выполняться при запуске или
выключении компьютера, при входе пользователя
в систему и выходе из нее.
Folder redirection Используется для хранения некоторых папок
(Перенаправление пользовательского профиля на сетевом сервере.
папки) Папки My Documents (Мои документы) выглядят
так, будто они хранятся локально, но фактически
они хранятся на сервере, где к ним можно
обращаться с любого компьютера в сети.

Групповые политики чаще назначаются на уровне OU. Это облегчает задачу управления
пользователями, так как можно назначить один объект групповой политики (GPO — Group Policy
Object), например, политику инсталляции программного обеспечения организационной единице,
которая затем распространится на всех пользователей или компьютеры в OU.
Предостережение. Организационные единицы не являются участниками безопасности. Их нельзя
использовать для назначения разрешений на ресурс так, чтобы затем пользователи всей OU
автоматически наследовали эти разрешения. OU используются для административных целей. Для
предоставления доступа к ресурсам необходимо использовать группы.

Резюме
В этой главе вы рассмотрели основные физические и логические компоненты службы Active
Directory Windows Server 2003. Валено иметь представление о физических компонентах, особенно
управляя базами данных и схемой, размещая контроллеры домена. Но все-таки большая часть
работы в Active Directory будет связана с логическими компонентами. Далее вы познакомитесь с
логической структурой службы Active Directory.
Глава 3. Active Directory и доменная система
имен
Служба каталога Active Directory Microsoft Windows Server 2003 при поиске ресурсов в сети
полностью полагается на доменную систему имен (DNS). Без надежной инфраструктуры DNS
контроллеры домена в сети не смогут делать реплики друг с друга, клиенты Microsoft Windows
2000 и Microsoft Windows XP Professional не смогут входить в сеть, а серверы, на которых
выполняется приложение Microsoft Exchange Server 2000, не смогут посылать электронную почту.
По существу, если ваша реализация службы DNS нестабильна, то сеть Windows Server 2003 не
будет работать. Это значит, что для управления средой Active Directory вы должны иметь глубокое
знание концепций DNS и ее реализации в Windows Server 2003.
Данная глава начинается с краткого обзора DNS как службы. Далее подробно рассказывается,
почему Active Directory зависит от DNS, и как работает процесс разрешения имен. Затем речь идет
о службе DNS в системах Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise
Edition; Windows Server 2003, Datacenter Edition. В операционной системе Windows Server 2003
доменная система имен имеет свойства, которые делают весьма привлекательным развертывание
Active Directory.
Примечание. Версия Windows Server 2003, Web Edition не требует и не поддерживает службу
Active Directory.

Краткий обзор DNS

DNS является службой разрешения имен. Если вы пытаетесь найти сервер в интернете, более
вероятно, что вы помните его имя, например, www.microsoft.com, чем IP-адрес, который может
выглядеть как 207.46.230.219. Однако вашему компьютеру для соединения с Web-сайтом Microsoft
требуется знать его IP-адрес. Служба DNS выполняет этот перевод. Вы сообщаете своему
браузеру имя компьютера, с которым вы хотели бы соединиться, a DNS превращает это имя в
правильный IP-адрес.
Примечание. Поскольку доменная система имен важна для работы Active Directory, вы должны
ознакомиться с концепциями службы DNS и знать, как она реализована. Если вы не знакомы с
DNS, вам следует просмотреть некоторые ресурсы, имеющиеся на веб-сайте Microsoft по адресу
http://msdn.microsoft.com/ library/en-us /dns/dns_concepts. asp.

Иерархическое пространство имен

DNS использует иерархическое пространство имен для поиска компьютеров. На рисунке 3-1
показан пример организации пространства имен. Корневой домен обозначается точкой («.»). Он
представляет собой верхний уровень DNS, остальное пространство имен располагается ниже. На
следующем уровне под корневым доменом располагаются домены первого уровня, включая семь
основных (generic) доменных имен (com, edu, mil, net, org), около двухсот сокращений названий
стран (са, uk, fr, br), семь новых доменов (biz, info, pro и т.д.), которые были введены в 2001 году.

Рис. 3-1. Иерархическое пространство имен DNS

Под доменами верхнего уровня расположены домены второго уровня, которые обычно относятся
к названиям компаний и должны быть зарегистрированы властями интернета. Ниже доменов
второго уровня располагаются поддомены. Поддомены обычно относятся к отделам или
подразделениям в пределах компании. Эти поддомены регистрируются и управляются с DNS-
серверов, которые содержат информацию о доменах второго уровня.
Другим способом представления иерархического пространства имен является полностью
определенное имя домена (FQDN — Fully Qualified Domain Name), например,
www.NAmerica.Contoso.com. FQDN представ-
ляет собой полное имя, которое можно использовать для идентификации определенного
компьютера в пределах всего пространство имен DNS. Чтобы понять, как FQDN идентифицирует
компьютер в пространстве имен DNS, прочтите его справа налево. Справа находится точка («.»),
которая идентифицирует корневой домен, она предшествует имени домена первого уровня. За ней
следуют домен com первого уровня, домен Contoso второго уровня и поддомен NAmerica. Слева в
имени FQDN находится www - имя определенного компьютера.

Распределенная база данных

Поскольку DNS использует иерархическое пространство имен, то достаточно просто
сконфигурировать его как распределенную базу данных. Прежде чем в интернете была реализована
доменная система имен, вся информация, необходимая для разрешения имен, хранилась в
единственном файле. Поскольку количество хостов в интернете увеличилось до сотен тысяч
компьютеров, то управление одним файлом стало непрактичным. Была разработана система DNS,
использующая распределенную базу данных. Использование распределенной базы данных
означает, что информация DNS хранится на многих компьютерах во всем мире (в случае
интернета) и повсюду в вашей сети (в случае внутренней сети). Каждый DNS-сервер обслуживает
только одну маленькую часть базы данных DNS. Вся база данных разделена на зонные файлы на
основе имен доменов. Зонные файлы распределены между несколькими серверами. К примеру,
существует около дюжины серверов, которые содержат зонные файлы для корневого домена. Они
хранят информацию о DNS-cep-верах, которые несут зонную информацию для доменов высшего
уровня. Корневые серверы не содержат всю информацию о доменах высшего уровня, но они
знают, какие серверы имеют эту информацию.
DNS-серверы, хранящие информацию о доменах высшего уровня, содержат также информацию о
том, на каких серверах находятся зонные файлы для доменов следующего уровня. Например,
сервер может содержать зонные файлы для домена сот, т.е. этот сервер знает обо всех доменах
второго уровня, которые зарегистрированы с доменом сот, но он может не знать отдельные
детали о домене второго уровня. Сервер домена высшего уровня знает, какой компьютер на
следующем уровне содержит детали, касающиеся домена второго уровня, и так продолжается до
самого низа пространства имен DNS. Сервер, ответственный за домен com, может иметь домен
Contoso, зарегистрированный как домен второго уровня. Этот сервер может передавать любые
запросы на информацию о домене Contoso на сервер, который содержит зонные файлы для
Contoso.com.
Использование метода распределенной базы данных означает, что никакому серверу в интернете
не требуется иметь всю информацию DNS. Большинство серверов хранят информацию о
некоторой части дерева,
но когда приходит запрос, который они не могут выполнить, им известно, какой DNS-сервер
хранит необходимую информацию. DNS-серверы используют делегированные записи,
ретрансляторы (forwarders) и корневые ссылки для определения того, какой DNS-сервер имеет
необходимую информацию. Эти темы будут обсуждаться далее в главе.

Процесс разрешения имен

Иерархическое пространство имен DNS и распределенная база данных используются тогда, когда
клиент пробует найти IP-адрес ресурса в интернете. Используя пример из предыдущего раздела
(см. рис. 3-1), предположим, что клиент DNS (назовем его преобразователем), расположенный в
какой-то точке земного шара, хочет соединиться с веб-сервером, имеющим адрес
www.NAmerica.Contoso.com. Для получения IP-адреса выполняются следующие действия.
1. Клиент-преобразователь посылает рекурсивный запрос об IP-адресе на свой
сконфигурированный DNS-сервер (обычно это DNS-сервер провайдера службы
 интернета). Рекурсивный запрос может иметь только два возможных ответа: IP-адрес,
запрашиваемый клиентом, или сообщение об ошибках, указывающее, что информация не
может быть найдена.
2. Если DNS-сервер провайдера имеет необходимую информацию в своем кэше, то он
возвращает IP-адрес пользователю. Если нужной информации нет, то он пробует найти
информацию, посылая итерационный запрос на другой сервер. Ответом на итерационный
запрос может быть или разрешенное имя, запрашиваемое клиентом, или переадресация на
другой DNS-сервер, который сможет выполнить запрос. В нашем примере DNS-сервер
провайдера посылает итерационный запрос корневому серверу об IP-адресе, который
соответствует www.NAmerica.Contoso.com.
3. Корневой сервер не может ответить на запрос, но в ответ он присылает список серверов,
ответственных за домен высшего уровня сот. Этот процесс предоставления списка
альтернативных DNS-серверов для дальнейшего контакта называется направлением
(referral). DNS-сервер интернет-провайдера посылает итерационный запрос одному из этих
серверов с просьбой об IP-адресе.
4. Сервер сот дает в ответ список серверов, которые являются ответственными за домен
Contoso.com. Далее DNS-сервер провайдера посылает запрос DNS-серверу Contoso.com,
который дает в ответ имена DNS-серверов, управляющих доменом NAmerica.Contoso.com.
5. DNS-сервер NAmerica.Contoso.com содержит всю информацию об этом домене, и он
посылает DNS-серверу провайдера IP-адрес нужного хоста.
6. DNS-сервер провайдера отвечает на рекурсивный запрос, который он получил от клиента-
преобразователя, и посылает IP-адрес запрошенного Web-сервера.
7. Компьютер клиента соединяется с www.NAmerica.Contoso.com.
8. Этот процесс происходит очень быстро и может не включать некоторые шаги. Когда DNS-
сервер разрешает любой тип имени, он сохраняет эту информацию в кэше в течение
определенного периода. Если кто-то искал этот же сайт раньше в этот день и DNS-сервер
провайдера разрешил это имя, то он просмотрит свой кэш и даст ответ немедленно.
9.
Записи ресурсов
Текущие записи, хранящиеся в зонных файлах DNS, называются записями ресурсов (RR —
Resource Records). Записи ресурсов содержат текущую информацию о домене. Вы можете создать
двадцать два различных типа записей ресурсов на DNS-сервере системы Windows Server 2003.
Наиболее распространенные записи ресурсов перечислены в таблице 3-1.

Табл. 3-1. Наиболее распространенные записи ресурсов в доменной системе имен Windows Server
2003
Название Пояснение
Start of Authority Идентифицирует основной сервер имен для
(SOA) - начало зоны, устанавливает параметры, заданные по
полномочий умолчанию для зонной передачи, параметры
длительности хранения зонной информации и
время жизни (TTL — Time to Live) (см. рис. 3-2).
Host (A) - хост Идентифицирует IP-адрес для определенного
имени хоста. Это та запись, которую DNS-cep-
вер возвращает в процессе разрешения имен.
Mail Exchanger (MX) - Идентифицирует серверы передачи интернет-
коммутатор сообщений. Используется другими серверами
электронной почты передачи интернет-сообщений для поиска
аналогичных серверов в домене.
Name Server (NX) - Идентифицирует все серверы имен для домена.
сервер имен
Pointer (PTR) - Идентифицирует имена хостов, отображаемых на
указатель определенных IP-адресах. Хранится в зоне
обратного просмотра.
Canonical Name Идентифицирует псевдоним другого хоста в
(CNAME) - домене. Применяется в том случае, когда
каноническое имя несколько имен хоста используют один и тот же
Service Locator (SRV) IP-адрес.
- указатель служб Идентифицирует службу, которая имеется в
домене. Active Directory широко использует
записи SRV для поиска контроллеров домена.

Рис. 3-2. Запись SOA для домена Contoso.com

Совет. На рисунке 3-2 показана запись SOA в инструменте администрирования DNS. Записи DNS
могут быть сохранены в стандартном текстовом формате. Например, стандартная запись хоста для
сервера по имени Webl.Contoso.com может быть записана как Webl.Contoso.com IN A
192.168.1.100.

DNS-домены, зоны и серверы

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

Сравнение доменов и зон

Одна из проблем терминологии, которая может затруднять понимание, состоит в различии между
доменами и зонами. С одной стороны, это различие состоит в том, что домен представляет часть
пространства имен DNS, а зоны — это информация об этой части пространства имен. Например,
компания может владеть именем домена второго уровня Contoso.com. Это означает, что компания
владеет одной частью полного пространства имен DNS, т.е. это их домен. Когда компания
реализует DNS-серверы для домена, то вся информация о домене DNS будет храниться на одном
или нескольких DNS-серверах. Эта информация включает все записи ресурсов всех компьютеров в
домене DNS. Она является зонной информацией и хранится в зонных файлах на серверах DNS.
Существует два различных типа зонных файлов в DNS: зоны прямого просмотра и зоны
обратного просмотра. Зона прямого просмотра используется для разрешения имен хоста к IP-
адресам. Эти функциональные возможности обеспечивают записи хоста (А). Зона прямого
просмотра может включать записи SOA и NS, а также записи MX, CNAME и SRV. Зона прямого
просмотра используется всякий раз, когда клиент-преобразователь делает запрос DNS-серверу,
чтобы найти IP-адрес сервера в сети.
Зоны обратного просмотра выполняют противоположную функцию. Она используется тогда,
когда IP-адрес хоста известен, а имя хоста не известно. Зона обратного просмотра также имеет
записи SOA и NS, остальная часть записей - это записи PTR. Формат записи PTR подобен записи
хоста, но он обеспечивает ответ для обратного поиска. Для получения дополнительной
информации о записях см. табл. 3-1.
Имя зоны прямого просмотра является именем домена. Имя зоны обратного просмотра определить
более трудно, потому что она использует IP-адрес подсети, а не имя домена, в качестве границы
зоны. Когда вы создаете зону обратного просмотра, вы должны дать ей имя, основанное на IP-
адресе подсети. Например, если вы создаете зону обратного просмотра для подсети 192.168.1.0, то
зонное имя будет L168.192.in-addr.arpa. Имя in-addr.arpa специально зарезервировано в DNS для
ссылок на зоны обратного просмотра. Первая часть зонного имени является сетевым адресом,
записанным в обратном порядке. Если вы создаете зону обратного просмотра для подсети класса
В (150.38.0.0), имя зоны обратного просмотра будет 38.150.in-addr.arpa.

Основные серверы имен

Основным сервером имен (Primary Name Server) является единственный сервер, имеющий
перезаписываемую копию зонных файлов (зона на основном сервере имен называется основной
зоной - primary zone). Это означает, что DNS-администратор должен иметь доступ к основному
серверу имен всякий раз, когда нужно внести какие-либо изменения в зонную информацию. После
того как внесены изменения, эти данные автоматически копируются на дополнительные серверы
имен с помощью процесса, который называется зонной передачей.

Дополнительные серверы имен

Дополнительный сервер имен (Secondary Name Server) имеет копию зонных файлов, которая
предназначена только для чтения. Единственный способ обновления зонной информации
дополнительного сервера имен состоит в зонной передаче с основного сервера имен. В ранних
версиях DNS каждая зонная передача была полной зонной передачей, т.е. все содержимое зонного
файла DNS передавалось с основного сервера имен на дополнительный. Документ Request for
Comment 1995 (Запрос на комментарии) представил более эффективный механизм зонной
передачи, называемый добавочной зонной передачей (incremental zone transfers), в котором на
дополнительный сервер копируются только изменения, сделанные в зонных файлах с момента
последней передачи. Другое усовершенствование представлено в документе Request for Comment
1996. Это механизм уведомлений, который позволяет основному серверу предупреждать
дополнительные серверы имен о том, что были сделаны изменения к зонным файлам. Без опции
уведомления дополнительный сервер имен будет контактировать с основным сервером только
через интервалы времени, определенные в записях SOA для каждой зоны.
Примечание. DNS-сервер Windows Server 2003 поддерживает как добавочную зонную передачу,
так и уведомления. Он также поддерживает интегрированные (integrated) зоны Active Directory,
в которых регулярная зонная передача заменена репликацией Active Directory.

Кэширующие серверы имен

Третий тип сервера имен - это сервер, который только кэширует информацию (caching-only). Он
не управляет зонными файлами, а только кэширует любые разрешения имен, которые он
выполнял. Кэширующий сервер часто используется в удаленных офисах, подключенных к
большому офису с ограниченной пропускной способностью. Поскольку кэширующий сервер не
имеет никаких зонных файлов, то и трафик зонной передачи DNS через медленное сетевое
подключение отсутствует. Кэширующий сервер должен конфигурироваться так, чтобы он
переправлял все DNS-запросы на сервер, расположенный в главном офисе компании. Поскольку
кэширующий сервер разрешает DNS-запросы, то он кэширует информацию в течение некоторого
времени (по умолчанию -1 час). Это означает, что любой местный DNS-запрос той же самой
информации может быть разрешен в местном масштабе.
Примечание. Все DNS-серверы Windows Server 2003, включая основной и дополнительные серверы
имен, кэшируют информацию, но они не называются кэширующими (caching-only) серверами.
Различие между этими серверами и только кэширующими серверами состоит в том, что
последний не имеет никакой зонной информации.

Зоны полномочий
Чтобы полностью понимать DNS, вы должны познакомиться с зонами полномочий (zones of
authority) и полномочными (authoritative) серверами имен. Каждый основной и дополнительный
серверы имен являются полномочными для своего домена. Например, если DNS-сервер содержит
зонные файлы для домена Contoso.com, то этот сервер является
полномочным сервером имен для этого домена. Как полномочный сервер имен он не будет
отправлять никаких запросов о хостах этой зоны другим DNS-серверам. Многие компании
устанавливают конфигурацию DNS-сервера так, как показано на рисунке 3-3. В этом сценарии
имеются два основных DNS-сервера, сконфигурированные для домена Contoso.com. DNS1
содержит запись хоста для сервера по имени Webl.Contoso.com, a DNS2-cepBep этой записи не
имеет. Когда клиент соединяется с DNS1, он сможет разрешить IP-адрес для Webl. Когда клиент
соединяется с DNS2 и запрашивает IP-адрес для Webl, сервер ответит, что хост не может быть
найден. Поскольку DNS2 сервер является полномочным для домена Contoso.com, он не будет
отправлять запросы серверу DNS1. Его поведение заложено в проекте и, как показывает
обсуждение примера в разделе «Практический опыт», это дает определенное преимущество в
безопасности.

Рис. 3-3. Множество полномочных DNS-серверов

Практический опыт. Использование нескольких полномочных серверов для

одной зоны
Иногда возникает ситуация, когда компания имеет два DNS-сервера, являющимися
полномочными для одного домена, и интернет-имя DNS компании и ее внутреннее
имя DNS идентичны (как показано на рис. 3-3). Сервер DNS1 находится с
внутренней стороны брандмауэра, а сервер DNS2 - с его внешней стороны. Сервер
DNS2 используется для разрешения DNS-запросов клиентов интернета, в то время
как DNS1 используется для внутренних клиентов и для SRV-записей Active Directory.
Поскольку оба сервера полномочны для одной и той же зоны (Contoso.com), они не
будут отправлять запросы об этом домене друг другу.
В этом случае необходимо поддерживать уникальную зонную информацию на
каждом DNS-сервере. Внешний DNS-сервер, вероятно, будет иметь относительно
маленький зонный файл, состоящий из веб-серверов и МХ-записей, которые
должны быть доступны из интернета. Внутренний DNS-сервер будет иметь намного
больший зонный файл, содержащий все записи контроллера домена, все
внутренние записи сервера и, возможно, записи хоста для всех клиентских
компьютеров в сети. Единственное дублирование между двумя зонными файлами
может состоять из некоторых внешних записей DNS. Например, когда внутренние
клиенты соединяются с www.Contoso.com, вы можете потребовать, чтобы они
соединялись с тем же внешним веб-сервером, к которому обращаются интернет-
клиенты. Для этого нужно включить запись хоста для вебсервера в зонный файл на
DNS1. Если вы не сделаете этого, то внутренние клиенты не смогут соединяться с
веб-сервером.
Делегированные зоны
Поскольку система DNS использует иерархическое пространство имен, должен существовать
механизм соединения разных уровней иерархии. Например, если клиент соединяется с сервером,
который является полномочным для домена первого уровня сот, и запрашивает сервер в домене
Contoso.com, corn-сервер должен уметь определять, какой сервер имен является полномочным для
домена Contoso.com. Это возможно при помощи записей делегирования (delegation records).
Запись делегирования представляет собой указатель на домен низшего уровня, который
идентифицирует сервер имен для домена низшего уровня. Например, на рисунке 3-4 показано, что
DNSl.Contoso.com является полномочным сервером имен для домена Contoso.com. DNS2 и DNS3
являются полномочными серверами имен для домена NAmerica.Contoso.com. Сервер DNS1
считается полномочным для домена NAmerica.Contoso.com, но он не имеет всех записей ресурса
дочерних доменов. Однако сервер DNS1 использует запись делегирования, указывающую на
DNS2 и DNS3 как на серверы имен для дочернего домена. Когда клиент соединяется с сервером
DNS1, запрашивая информацию об NAmerica.Contoso.com, сервер перешлет клиента на сервера
имен дочернего домена.

Ретрансляторы и корневые ссылки

Второй способ соединения различных уровней иерархии системы DNS состоит в использовании
корневых ссылок и ретрансляторов. В большинстве случаев ретрансляторы и корневые ссылки
используются низкоуровневыми серверами пространства имен DNS для поиска информации,
находящейся на высокоуровневых серверах DNS-иерархии. Ретрансляторы и корневые ссылки
используются DNS-сервером для поиска информации, которая отсутствует в их собственных
зонных файлах. Например, DNS-сервер может быть полномочным только для домена Contoso.com.
Когда он получит запрос от клиента, запрашивающего разрешение имени в домене Fabrikam.com
(см. рис. 3-1), DNS-сервер Contoso.com должен иметь какой-то способ поиска этой информации.

Рис. 3-4. Делегированные зоны

Одним из способов конфигурирования сервера для этих целей является использование

ретрансляторов. Ретранслятор (forwarder) - это просто другой DNS-сервер, который используется
определенным DNS-сервером, когда он не может разрешить запрос. Например, полномочный
сервер имен для Contoso.com может получить рекурсивный запрос для домена Fabrikam.com. Если
DNS-сервер Contoso был сконфигурирован с ретранслятором, то он отправит рекурсивный запрос
ретранслятору, запрашивая эту информацию. Ретрансляторы часто используются во внутренней
сети организации. Организация может иметь несколько DNS-серверов, главной задачей которых
является внутреннее разрешение имен. Пользователям внутри организации может потребоваться
разрешение IP-адресов интернета. Это можно выполнить, сконфигурировав все внутренние DNS-
серверы так, чтобы они могли разрешать адреса интернета. Более распространенным вариантом
является конфигурирование внутренних DNS-серверов с ретранслятором, указывающим на DNS-
сервер, являющийся ответственным за разрешение имен интернета. Этот вариант показан на
рисунке 3-5. Все внутренние DNS-серверы отправляют любой запрос для неполномочной зоны на
один DNS-сервер, который разрешает интернет-адреса. Если DNS-сервер сконфигурирован с
несколькими ретрансляторами, то он будет отправлять запросы всем ретрансляторам по порядку,
прежде чем попытается использовать любой другой способ разрешения IP-адресов.

Рис. 3-5. Использование ретрансляторов для разрешения имен в Интернете

Второй метод, который может применить DNS-сервер при ответе на запросы для тех зон, для
которых он не является полномочным, состоит в использовании корневых ссылок. Когда вы
устанавливаете DNS-сервер Windows Server 2003, имеющий доступ к интернету, он автоматически
конфигурируется со стандартным списком корневых серверов. Корневые серверы - это серверы,
которые являются полномочными для корня в пространстве имен интернета. Если DNS-сервер
получает запрос о зоне DNS, для которой он не является полномочным, сервер посылает
итерационный запрос одному из корневых серверов. Итерационные запросы будет
инициироваться до тех пор, пока нужное имя не будет разрешено или пока сервер не подтвердит,
что оно не может быть разрешено.
Примечание. Корневые серверы, которые автоматически указываются на DNS-сервере при его
конфигурировании, копируются из файла Cache.dns, который поставляется с файлами установки
DNS-сервера.
Вы можете добавлять дополнительные DNS-серверы к списку корневых ссылок, включая в него
DNS-серверы, имеющиеся в вашей внутренней сети.
По умолчанию DNS-серверы Windows Server 2003 используют ретрансляторы и корневые ссылки,
когда они пытаются разрешать имена. Если сервер конфигурирован с ретрансляторами, он сначала
отправит рекурсивные запросы всем ретрансляторам. Если ни один из ретрансляторов не может
обеспечить необходимую информацию, то DNS-cep-вер начнет посылать повторяющиеся запросы
серверам, сконфигурированным как корневые ссылки. В некоторых случаях необходим DNS-
сервер, использующий только ретрансляторы и не использующий корневые ссылки. Чтобы
сконфигурировать такой сервер, выберите опцию Do Not Use Recursion For This Domain (He
использовать рекурсию для этого домена) на вкладке Forwarders (Передатчики) в окне Properties
(Свойства) DNS-сервера. После этого DNS-сервер сначала будет пытаться разрешить любые
запросы с помощью своей местной зонной или кэ-шированной информации, посылая рекурсивные
запросы каждому из своих ретрансляторов. Если ретрансляторы не смогут обеспечить
необходимую информацию, DNS-сервер не будет использовать другие средства, чтобы найти эту
информацию. Он сообщит клиенту, что хост не может быть найден.
Примечание. В системе DNS Windows Server 2003 возможности традиционных ретрансляторов
расширены за счет реализации условных ретрансляторов. Эта тема подробно рассматривается в
разделе «Условная ретрансляция» далее в этой главе.
Динамическая система DNS
В прошлом сложность работы с DNS состояла в том, что вся зонная информация должна была
вводиться вручную. До выхода документа RFC 2136 не существовало никакого способа
автоматического обновления зонной информации DNS-сервера. В документе RFC 2136 описано,
как DNS-серверы должны быть сконфигурированы, чтобы автоматически принимать обновления к
записям ресурсов в зонных файлах. Эта опция называется динамической службой DNS (DDNS).
DNS-серверы Windows Server 2003 поддерживают динамическую службу DNS. По умолчанию все
клиенты Windows 2000 и Windows XP Professional, а также Windows 2000 Server; Windows 2000
Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows
Server 2003, Enterprise Edition и Windows Server 2003, Datacenter Edition автоматически обновляют
свои записи ресурсов в DNS. Windows 2000 и контроллеры домена Windows Server 2003
автоматически регистрируют SRV-записи на DNS-серверах, которые используются для поиска
контроллеров домена. DNS-серверы Windows Server 2003 будут
также принимать динамическую регистрацию записей с серверов динамической конфигурации хостов
(DHCP). DHCP-сервер Windows Server 2003 может конфигурироваться для автоматического обновления
DNS-записей для любого из его клиентов, включая Microsoft Windows 95, Microsoft Windows 98, Microsoft
Windows Me или Microsoft Windows NT.
Одна из проблем динамической системы DNS связана с безопасностью. Без какого-либо контроля над тем,
кому позволено обновлять записи ресурсов DNS, любой, имеющий доступ к вашей сети, потенциально
может создать запись ресурса в ваших зонных файлах DNS, а затем использовать эту запись для
переадресации сетевого трафика. Чтобы решить эту проблему в системе DNS Windows Server 2003
существуют безопасные обновления. Безопасные обновления имеются только в интегрированных зонах
Active Directory. С помощью безопасных обновлений вы можете управлять тем, кому дается право
регистрировать и обновлять DNS-записи. По умолчанию члены группы Authenticated Users
(Уполномоченные пользователи) имеют право обновлять свои записи в системе DNS. Вы можете изменить
это, изменяя список управления доступом ACL (ACL - Access Control List) для DNS-зоны.
Динамическая система DNS уменьшает объем работы, который должен делать администратор DNS. Далее
вы узнаете, что Active Directory Windows Server 2003 требует присутствия SRV-записи каждого контроллера
домена в зонной информации, поэтому поддержка динамических обновлений является важным свойством
DNS-системы Windows Server 2003.

DNS и Active Directory Windows Server 2003

Active Directory не сможет функционировать без надежной конфигурации DNS. Контроллеры домена не
смогут находить друг друга для репликации доменной информации, клиенты с системами Windows 2000 и
Windows XP Professional будут очень медленно искать контроллеры домена для входа в систему. Без
надежной DNS любые другие службы, которым требуется Active Directory, не смогут работать. Например,
Exchange Server 2000 хранит всю свою конфигурационную информацию в Active Directory, поэтому если
серверы, на которых выполняется Exchange Server 2000, не смогут найти контроллер домена при запуске,
они не смогут запустить большинство служб Exchange Server 2000.
Совет. Клиенты, на которых выполняются системы Windows 95, Windows 98, Windows Me и
Windows NT не полагаются на DNS в поиске контроллеров домена с Windows Server 2003. Они
используют для поиска имена NetBIOS, а службу имен интернета для Windows (WINS - Windows
Internet Naming Service) - для разрешения имен NetBIOS к IP-адресам. По умолчанию Windows
Server 2003 поддерживает низкоуровневых клиентов, регистрируя необходимые имена NetBIOS с
помощью WINS.

Служба DNS Locator

Служба DNS Locator (Указатель DNS) очень важна для Active Directory, потому что DNS
обеспечивает информацию, которая необходима клиентам для поиска контроллеров домена в сети.
Далее детально рассматривается процесс, которым пользуется клиент для поиска контроллеров
домена.
Примечание. В Windows NT вход в систему домена был основан на именах NetBIOS. Каждый
контроллер домена регистрировал имя NetBIOS Domainname с <1С> в качестве шестнадцатого
символа имени в сети и в службе WINS. Когда клиент пробовал войти в сеть, он пытался найти
серверы, которые имели зарегистрированное имя контроллера домена. Если клиент не находил ни
один из этих серверов, то он не мог войти в систему. Записи SRV на Windows Server 2003
используются для поиска контроллеров домена клиентами, на которых выполняются системы
Windows 2000 и Windows XP Professional. Без записей SRV эти клиенты не смогут войти на домен
Windows Server 2003.

Записи ресурсов DNS, зарегистрированные контроллером домена Active

Directory
Чтобы облегчить нахождение контроллеров домена, Active Directory использует указатель служб
(service locator) или записи SRV. Записи SRV - это новый тип DNS-записи, описанный в документе
RFC 2782, он используется для идентификации услуг в TCP/IP-сети. На примере одной из записей,
используемых службой Active Directory, показано, как каждая запись SRV использует
стандартный формат (см. табл. 3-2).
_ldap._tcp.contoso.com. 600 IN SRV 0 100 389 dc2.contoso.com

Табл. 3-2. Компоненты записи SRV

Компонент Пример Объяснение
Служба _ldap Служба, которую идентифицирует запись.
Дополнительные службы включают
_kerberos, _kpassword и _gc.
Протокол _tcp Протокол, используемый для этой службы.
Может быть протоколом TCP или
протоколом пользовательских датаграмм
(UDP).
Имя contoso.com Имя домена, на который ссылается запись.

Время 600 Заданное по умолчанию «время жизни»

жизни (TTL записи (в секундах).
- Time to
Live)
Класс IN Стандартный DNS-класс интернета.
Запись SRV Идентифицирует запись как запись SRV.
ресурса
Приоритет 0 Идентифицирует приоритет записи для
клиента. Если существует несколько SRV-
записей для одной и той же службы,
клиенты будут сначала пытаться
соединиться с сервером, имеющим самый
низкий приоритет.
Вес 100 Механизм балансировки нагрузки. Если
существует несколько SRV-записей для
одной и той же службы, и приоритет всех
записей одинаков, клиенты чаще выбирают
записи с более высокими весами.

Порт 389 Порт, используемый этой службой.

Адресат dc2.contoso.co Хост, который обеспечивает службу,
m идентифицированную записью.

По сути, информация в этой записи говорит, что если клиент ищет сервер облегченного протокола
службы каталогов (LDAP) в домене Contoso.com, он должен соединиться с dc2.contoso.com.
Контроллеры домена в домене Windows Server 2003 регистрируют много SRV-записей в системе
DNS. Следующий список включает все записи, зарегистрированные первым сервером леса.
contoso.com. 600 IN A 192.168.1.201
_ldap._tcp.contoso.com. 600 IN SRV 0 100 389 dc2.contoso.com.
_ldap._tcp.Default-First-Site-Name._sites.contoso.com. 600 IN SRV 0 100 389
dc2.contoso.com.
_ldap._tcp.pdc._msdcs.contoso.com. 600 IN SRV 0 100 389 dc2.contoso.com.
_ldap._tcp.gc._msdcs.contoso.com. 600 IN SRVO 100 3268 dc2.contoso.com.
_ldap._tcp. Default-First-Site-Name._sites._gc._msdcs.contoso.com. 600 IN SRV 0
 100 3268 dc2.contoso.com.
_ldap._tcp.64c228cd-5f07-4606-b843-d4fd114264b7.domains._msdcs.contoso.com.
600 IN SRV 0 100 389 dc2.contoso.com.
gc._msdcs.contoso.com. 600 IN A 192.168.1.201
175170ad-0263-439f-bb4c-89eacc410ab1._msdcs.contoso.com. 600 IN CNAME
dc2.contoso.com.
_kerberos._tcp.dc._msdcs.contoso.com. 600 IN SRVO 100 88 dc2.contoso.com.
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.contoso.com. 600 IN
SRV 0 100 88 dc2.contoso.com.
_ldap._tcp.dc._msdcs.contoso.com. 600 IN SRV 0 100 389 dc2.contoso.com.
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.contoso.com. 600 IN SRV 0
100 389 dc2.contoso.com.
_kerberos._tcp.contoso.com. 600 IN SRV 0 100 88 dc2.contoso.com.
_kerberos._tcp.Default-First-Site-Name._sites.contoso.com. 600 IN SRV 0 100 88
dc2.contoso.com.
_gc._tcp.contoso.com. 600 IN SRV 0 100 3268 dc2.contoso.com.
_gc._tcp.Default-First-Site-Name._sites.contoso.com. 600 IN SRVO 100 3268
dl2.contoso.com.
_kerberos._udp.contoso.com. 600 IN SRV 0 100 88 dc2.contoso.com.
_kpasswd._tcp.contoso.com. 600 IN SRV 0 100 464 dc2.contoso.com.
_kpasswd._udp.contoso.com. 600 IN SRV 0 100 464 dc2.contoso.com.
DomainDnsZones.contoso.com. 600 IN A 192.168.1.201
_ldap._tcp.DomainDnsZones.contoso.com. 600 IN SRV 0 100 389 dc2.contoso.com.
_ldap._lcp.Default-First-Site-Name._sites.DomainDnsZones.contoso.com. 600 IN
SRV 0 100 389 dc2.contoso.com.
ForestDnsZones.contoso.com. 600 IN A 192.168.1.201
_ldap._tcp.ForestDnsZones.contoso.com. 600 IN SRV 0 100 389 dc2.contoso.com.
_ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.contoso.com. 600 IN
SRV 0 100 389 dc2.contoso.com.
Примечание. Если на котроллере домена установлена система Windows Server 2003, все эти
записи записываются в файл по имени Netlogon.dns, расположенный в папке %systemroot%\
system32\config. Если вы не хотите допускать динамические обновления на DNS-серверах, вы
можете импортировать эти записи в зонные файлы DNS.
Первая часть SRV-записи идентифицирует службу, на которую указывает запись SRV.
Существуют следующие службы:
• _ldap Active Directory является службой каталога, совместимой с LDAP-протоколом, с
контроллерами домена, функционирующими как LDAP-серверы. Записи _ldap SRV
идентифицирует LDAP серверы, имеющиеся в сети. Эти серверы могут быть
контроллерами домена Windows Server 2003 или другими LDAP-серверами;
• _kerberos - основной опознавательный протокол для всех клиентов Windows 2000 и
Windows XP Professional. SRV-записи _kerberos идентифицируют все ключевые центры
распределения (KDC - Key Distribution Centers) в сети. Они могут быть контроллерами
домена с Windows Server 2003 или другими KDC-серверами;
• _kpassword — идентифицирует серверы изменения паролей kerberos в сети (это или
контроллеры домена с Windows Server 2003 или с другими системами изменения пароля
kerberos);
• _gc - специфическая запись, относящаяся к функции глобального каталога в Active
Directory. Сервер глобального каталога выполняет множество важных функций в Active
Directory.
Многие из SRV-записей содержат идентификатор сайта в дополнение к компонентам,
перечисленным в таблице 3-2. Сайт используется в Active Directory для идентификации одной или
более IP-подсетей, которые связаны через высокоскоростные сетевые подключения. Одно из
преимуществ использования сайтов состоит в том, что сетевые клиенты всегда будут пробовать
войти на контроллер домена, который находится на том же самом сайте, что и клиент. Записи
сайта нужны компьютерам для поиска контроллеров домена, расположенных в том же самом
сайте, где находится клиент. Подробности механизма, который используется клиентом для поиска
информации, касающейся сайта, обсуждаются в следующем разделе.
Другим необходимым компонентом SRV-записей является значение _msdcs, которое имеется во
многих записях. Некоторые службы, предусмотренные записями SRV, не относятся к службам,
разработанным компанией Microsoft. Например, могут встретиться LDAP или kerberos-cep-веры в
реализациях, не принадлежащих Microsoft. Эти серверы также могут регистрировать записи SRV
на сервере DNS. Контроллеры домена с Windows Server 2003 регистрируют как основные (generic)
записи (например, _ldap._tcp.contoso.com), так и записи, содержащие ссылку на _msdcs. Они
ссылаются только на роли, определенные продуктами Microsoft, т.е. на Windows Server 2003 или
на контроллеры домена Windows 2000. Записи идентифицируют основную функцию каждого
сервера: gc (глобальный каталог), dc (контроллер домена) или pdc (основной эмулятор
контроллера домена).
Другая зарегистрированная запись содержит глобальный уникальный идентификатор (GUID -
globally unique identifier) домена. Запись GUID домена используется для поиска контроллеров
домена в случае его переименования.
Примечание. Имеются записи, расположенные ниже поддоме-нов ForestDnsZones и
DomainDnsZones. О них более подробно вы узнаете в разделе «Раздел приложений каталога»
этой главы.

Поиск контроллера домена службы Active Directory

Контроллеры домена, на которых выполняется Windows Server 2003, регистрируют некоторые
(или все) записи, описанные выше. Эти записи играют важную роль, когда клиент, на котором
выполняется система Windows 2000 или Windows XP Professional, пытается войти в домен. Далее
описаны действия, которые выполняются при входе клиента в домен.
1. Во время входа пользователя компьютер клиента выполняет удаленный вызов процедуры
(RPC) запроса местной сетевой службе входа в систему, которая инициирует сеанс входа в
систему. Являясь частью RPC-запроса, клиент посылает такую информацию, как имя
компьютера, имя домена и имя сайта, службе Net Logon (Вход в сеть).
2. Служба входа в сеть использует службу указателя доменов (domain locator), чтобы вызвать
API-функцию DsGetDcName (), передающую одно из значений параметра флага,
перечисленных в таблице 3-3.

Табл. 3-3. Значения параметра флага DsGetDcName

Значения флага DsGetDcName Требуемая запись DNS

DS_PDC_REQUIRED
DS_GC_SERVER_REQUIRED
DS_KDC_REQUIRED
DS_ONLY_LDAP_NEEDED
_ldap._tcp.pdc._msdcs.domainname
_ldap._tcp.sitename._sites.gc.
_msdcs.Forestrootdomainname
_kdc._tcp.sitename._sites.dc
._msdcs.domainname
_ldap._tcp.sitename._sites._
msdcs.domainname

Примечание. Почти всегда функция DsGetDcName включает параметр sitename. Для всех
запросов, кроме запроса DS_PDC_REQUIRED, клиент делает начальный запрос, используя
параметр сайта. Если DNS-сервер не отвечает на запрос, клиент пошлет тот же самый запрос
без параметра сайта. Например, если запрос DS_KDC_REQUIRED не выполнен, клиент пошлет
запрос на запись _kdc._tcp.dc._msdcs.forestrootdomain. Это может случиться, если клиент
находится на сайте, который не распознан серверами DNS. Клиент может также передать
параметр DomainGUID вместо имени домена с помощью функции DsGetDcName (). В этом
случае клиент запрашивает запись _ldap._tcp.domainGUID.domains._msdcs.forestname. Это
случится только в том случае, если домен был переименован.
3. DNS сервер возвращает запрошенный список серверов, рассортированный согласно
приоритету и весу. Затем клиент посылает LDAP запрос, используя UDP-порт 389 по
каждому из адресов записи в том порядке, как они были возвращены. После отсылки
каждого пакета клиент ждет в течение 0,1 с, если никакого ответа не получено, он
посылает пакет следующему контроллеру домена. Клиент продолжает этот процесс до тех
пор, пока не получит допустимый ответ или не перепробует все контроллеры домена.
4. Когда контроллер домена ответит клиенту, клиент проверяет ответ, чтобы удостовериться,
что он содержит запрошенную информацию. Если информация имеется, клиент начинает
процесс входа в систему с контроллера домена.
Клиент кэширует информацию контроллера домена, чтобы в следующий раз, когда ему
потребуется обратиться к Active Directory, не нужно было снова проходить процесс обнаружения.
Как клиент определяет, какому сайту он принадлежит
Наличие специфических для сайта записей важно для эффективной работы Active Directory,
потому что поле деятельности клиента ограничено определенным сайтом. Например, в процессе
входа в систему клиент всегда пробует соединиться с контроллером домена, расположенном в
своем сайте, прежде чем соединяться с любыми другими сайтами. Как же клиент узнает, какому
сайту он принадлежит?
Информация сайта для леса хранится в разделе конфигурации ката-, лога в Active Directory, она
копируется на все контроллеры домена в лесу. Список IP-подсетей, которые связаны с
определенным сайтом, включается в конфигурационную информацию. Когда клиент впервые
входит в Active Directory, первый ответивший контроллер домена сравнивает IP-адрес клиента с
IP-адресом сайта. Часть ответа контроллера домена клиенту составляет информация сайта,
которую клиент затем кэширует. Любые последующие попытки входа в систему будут включать
информацию сайта клиента.
Если клиент переместился между сайтами (например, портативный компьютер может быть
подсоединен к сети в другом городе), он все еще посылает информацию сайта как часть входа в
систему. DNS-сервер ответит с записью контроллера домена, который находится в запрашиваемом
сайте. Однако если на основе нового IP-адреса клиента контроллер домена решит, что клиент не
находится на первоначальном сайте, он пошлет новую информацию сайта клиенту. Затем клиент
выполнит кэширование новой информации и попытается найти контроллер домена в правильной
подсети.
Если клиент не находится ни в одном из сайтов, которые определены в Active Directory, то он не
сможет выполнять запросы на специфическую для сайта информацию о контроллерах домена.

Интегрированные зоны Active Directory

Одно из самых больших преимуществ выполнения DNS в операционной системе Windows Server
2003 заключается в использовании интегрированных зон (integrated zones) Active Directory.
Интегрированные зоны Active Directory дают множество преимуществ.
• Зонная информация больше не хранится в зонных файлах на жестком диске DNS-сервера,
она хранится в базе данных Active Directory. Это обеспечивает дополнительную защиту.
• Процесс зонной передачи заменен репликацией Active Directory. Поскольку зонная
информация хранится в Active Directory, то данные копируются через нормальный процесс
репликации Active Directory. Это означает, что репликация происходит на уровне
атрибутов так, что копируются только изменения зонной информации. Трафик репликации
между сайтами можно сильно сжать, увеличив пропускную способность. Использование
интегрированной зоны Active Directory дает возможность использовать разделы
приложений для тонкой настройки репликации информации DNS.
• Интегрированные зоны дают возможность конфигурирования DNS-сервера с несколькими
хозяевами. Без Active Directory DNS может поддерживать только один основной сервер
имен для каждого домена. Это означает, что все изменения в зонной информации должны
быть сделаны на основном сервере имен, а затем переданы на дополнительные серверы
имен. С интегрированными зонами Active Directory каждый DNS-сервер имеет
перезаписываемую копию доменной информации, так что изменения зонной информации
могут быть сделаны в любом месте в организации. Информация затем копируется на все
другие серверы DNS.
Интегрированные зоны предлагают опцию безопасных обновлений. Если зона является
интегрированной зоной Active Directory, вы можете сконфигурировать ее так, чтобы использовать
только безопасные обновления. Это означает, что вы имеете больше контроля над тем, какие
пользователи и компьютеры обновляют записи ресурсов в Active Directory.
Самым большим недостатком интегрированной зоны Active Directory является необходимость
установки DNS на контроллере домена Windows Server 2003, что создает дополнительную
нагрузку на него.
Совет. Возможно соединение интегрированных зон Active Directory с дополнительными.
Например, можно иметь три контроллера домена в центральном месте и несколько отдаленных
офисов, в которых отсутствует контроллер домена. Если вы хотите иметь DNS-сервер в
отдаленном офисе, вы можете установить DNS на сервере, на котором выполняется система
Windows Server 2003, а затем сконфигурировать дополнительную зону на сервере DNS. Тогда
дополнительный сервер будет принимать зонные передачи от интегрированной зоны Active
Directory.
Когда зона сконфигурирована как интегрированная зона Active Directory, вы может просматривать
информацию DNS в Active Directory
(см. рис. 3-6). Для этого запустите консоль управления Microsoft (MMC -Microsoft Management
Console) и убедитесь, что оснастка Active Directory Users And Computers (Пользователи и
компьютеры Active Directory) была добавлена к консоли. Выберите папку Active Directory Users
And Computers (Пользователи и компьютеры Active Directory) из меню View (Вид), выберите
Advanced Features (Дополнительные свойства). Откройте папку с именем домена, затем откройте
папку System (Система), затем - папку Microsof tDNS. Зонная информация для всех
интегрированных зон Active Directory перечислена в каждой зонной папке.

Рис. 3-6. Просмотр информации интегрированной зоны Active Directory

Практический опыт. Разрешение имен DNS без усовершенствованной

службы DNS Windows Server 2003
Корпорация, состоящая из четырех различных компаний, каждая из которых была
независимой до момента слияния, планировала развертывание Active Directory в
системе Windows 2000 Advanced Server. Каждая компания настаивала на поддержке
собственного пространства имен в пределах одного леса; это означало, что должен
быть развернут лес с назначенным (dedicated) корневым доменом и четырьмя
доменами компании (см. рис. 3-7). Все компании были расположены в разных
городах в Канаде.

Рис. 3-7. Проект леса Active Directory с несколькими деревьями

Поскольку смежного пространства имен для всей компании не существовало,

нормальный процесс делегирования дочерних доменов не применялся. Процесс
конфигурирования ретрансляторов и корневых ссылок также оказался
неэффективным, потому что не является достаточно отказоустойчивым. Например,
если кому-то из Contoso.com требовалось найти ресурс в домене Fabrikam.com,
клиент должен был запрашивать DNS-сервер Contoso. Поскольку сервер не был
 полномочным сервером для домена Fabrikam, он должен был разрешить имя,
используя корневую ссылку или ретранслятор. Если DNS-сервер Contoso был
сконфигурирован с ретранслятором на DNS-сервер в домене Fabrikam, имя могло
быть разрешено. Однако эта запись ретранслятора не могла использоваться для
разрешения компьютерных имен в домене TailspinToys.com или во внутренней сети.
Использование системы DNS Windows 2000 предложило несколько путей решения
этой проблемы (см. ниже), но ни один из них не был достаточно
удовлетворительным.
• Создание дополнительной зоны на каждом сервере DNS для каждого из
других доменов привело бы к возрастанию трафика зонной передачи.
• Создание дополнительной зоны для каждого домена компании на серверах
DNS в корневом домене и конфигурирование всех DNS-серве-ров домена
так, чтобы они направляли запросы к серверам DNS корневого домена,
создало бы существенную нагрузку на серверах DNS корневого домена.
Кроме того, поскольку все серверы DNS корневого домена были
расположены в одном центре данных, разрешение имен привело бы к
возрастанию сетевого трафика из других офисов.
Ни одно из этих решений не идеально. Операционная система Windows Server 2003
предлагает три варианта решения. В них используются условная переадресация,
сокращенные зоны (stub zones) и разделы приложений каталога.

Совершенствование DNS
Большинство опций DNS, которые обсуждались до этого, доступны в Windows 2000. В
операционной системе Windows Server 2003 имеется, по крайней мере, три существенных
улучшения DNS. Описание практического опыта (см. выше) иллюстрирует одну из типичнейших
трудностей в конфигурировании DNS большой корпорации, с которой сталкивались
администраторы до выхода операционной системы Windows Server 2003.

Условная переадресация
Условная переадресация (conditional forwarding) значительно увеличивает возможности процесса
переадресации. До выхода Windows Server 2003 в процессе переадресации нельзя было делать
различий, основанных на именах домена. Когда клиент-преобразователь делал запрос, на который
сервер не мог ответить с помощью своего кэша или зонных файлов, сервер посылал рекурсивный
запрос по своему списку конфигурированных ретрансляторов. Не было возможности
сконфигурировать ретранслятор так, чтобы он был чувствителен к специфике домена. Условная
переадресация обеспечивает как раз такой тип осмысления: DNS-cep-вер может теперь передавать
запросы домена на различные серверы DNS, учитывая имя домена.
Например, компания, о которой шла речь выше, имеет пять деревьев в единственном лесу. При
репликации контроллеры домена должны суметь найти контроллеры домена в других доменах.
Пользователи также часто путешествуют между компаниями. Они должны иметь возможность
входить на свой домашний домен независимо от того, с какой сетью они связаны физически.
Существует также значительное количество ресурсов, сконфигурированных для совместного
использования между компаниями. Эти требования подразумевают, что информация DNS должна
быть общедоступной для разных доменов.
С помощью Windows Server 2003 серверы DNS в каждом домене могут быть сконфигурированы с
условным ретранслятором, переадресующим запросы на один или более серверов DNS в других
доменах. Когда один из серверов DNS разрешает имя из другого домена, он может использовать
только тот ретранслятор, который сконфигурирован для этого домена. Например, когда клиент в
домене Contoso.com должен найти ресурс в домене Fabrikam.com, он делает запрос DNS-серверу
домена Contoso.com. DNS-сервер проверяет свои зонные файлы, чтобы определить, является ли он
полномочным сервером для этого домена, а затем проверяет свой кэш. Если он не сможет
разрешить имя с помощью этих источников, он проверит список ретрансляторов. Один из
ретрансляторов определен для домена Fabrikam.com, так что DNS-сервер Contoso.com пошлет
рекурсивный запрос только этому серверу DNS. Если нет никаких условных ретрансляторов для
домена Fabrikam.com, сконфигурированных на сервере DNS Contoso.com, то он отправит запрос
любому ретранслятору, который сконфигурирован без каких-либо определенных параметров
настройки домена, а затем попробует использовать корневые ссылки.
Предостережение. Обратите внимание, что DNS-сервер проверяет свои собственные зонные
файлы, прежде чем использовать ретрансляторы. Если DNS-сервер является полномочным
для данного домена, он не будет отправлять запрос условному ретранслятору.
Условная переадресация конфигурируется в окне Properties (Свойства) сервера в
административном инструменте DNS (см. рис. 3-8). С его помощью вы можете сконфигурировать
один или более контроллеров домена в качестве ретрансляторов для каждого имени домена. Если
вы конфигурируете несколько серверов DNS для имени домена, то DNS-сервер будет пытаться
использовать первый DNS-сервер в списке. Если этот сервер не отвечает в течение заданного
значения интервала тайма -ута, которое устанавливается на вкладке Forwarders (Ретрансляторы),
то сервер будет пробовать использовать следующий DNS-сервер из списка, пока не будут
запрошены все имеющиеся в списке DNS-серверы. Если никаких условных ретрансляторов,
сконфигурированных для имени домена, в списке нет, то сервер будет запрашивать серверы DNS,
определенные в опции All Other DNS Domains (Другие домены DNS).

Рис. 3-8. Конфигурирование условных ретрансляторов

При использовании условной переадресации DNS-сервер всегда будет пробовать найти

соответствие наиболее точному имени домена. На-
пример, если имеются условные ретрансляторы, сконфигурированные для Fabrikam.com и для
Europe.Fabrikam.com, а клиент делает запрос о сервере Webl.Europe.Fabrikam.com, то DNS-сервер
отправит запрос на DNS-сервер для Europe.Fabrikam.com.

Сокращенные зоны
Сокращенные зоны (stub zones) - это второе улучшение к службе DNS в Windows Server 2003. Они
предназначены для упрощения конфигурирования разрешения имен между несколькими
пространствами имен. Сокращенная зона подобна дополнительной зоне. При установлении
сокращенной зоны вы должны определить IP-адрес основного сервера имен для зоны. Тогда
сервер, владеющий сокращенной зоной, запрашивает зонную передачу у основного сервера имен.
Однако сокращенная зона отличается от дополнительной тем, что она содержит только записи
SOA, NS и записи хоста (А) для сервера имен домена, а не все записи зоны.
Это улучшает процесс разрешения имен без необходимости использовать дополнительные
серверы. Когда DNS-сервер сконфигурирован с сокращенной зоной, он не является полномочным
для домена. Он эффективен при поиске полномочного сервера имен для указанной зоны. С
помощью дополнительных зон DNS-сервер может найти полномочный сервер имен для зоны без
необходимости контактировать с серверами корневых ссылок. Обратите внимание, как
дополнительная зона может работать в лесу с одним деревом, т.е. с непрерывным пространством
имен (см. рис. 3-9). Без дополнительных зон в случае запроса клиента из NAmerica.Contoso.com IP-
адреса хоста в домене SAmerica.Contoso.com DNS сервер в NAmerica. Contoso.com проверяет свои
зонные файлы, кэш и ретрансляторы. Если ни один из этих источников не обеспечивает нужную
информацию, он посылает итерационный запрос серверу корневых ссылок. В этом случае DNS
сервер в корневом домене Contoso.com должен быть сконфигурирован как корневой сервер, чтобы
DNS-сервер домена NAmerica. Contoso.com послал запрос ему. Корневой сервер проверяет свои
записи делегирования и передает IP-адрес полномочного сервера имен домена
SAmerica.Contoso.com серверу имен NAmerica. Contoso.com. Затем сервер имен NAmerica.
Contoso.com запрашивает у одного из серверов DNS домена SAmerica. Contoso.com IP-адрес
сервера, который требуется клиенту.
Если имеется сокращенная зона, DNS-сервер домена NAmerica. Contoso.com не должен
соединяться с сервером DNS корневого домена. Ему не нужно использовать свои корневые
ссылки, чтобы найти сервер имен для домена SAmerica.Contoso.com. Когда клиент делает запрос,
сервер проверяет свои зонные файлы, находит сокращенную зону и посылает итерационный
запрос любому из серверов имен домена SAmerica. Contoso.com.
Использование сокращенной зоны особенно эффективно при наличии нескольких деревьев.
Возьмем предыдущий пример, в котором лес состоит из пяти деревьев. Использование записей
делегирования в корневой зоне в этом случае не работает, потому что домены не используют
общего пространства имен. Вы можете сконфигурировать сокращенную зону для каждого домена
на серверах DNS в других доменах. Если в этом случае какой-либо запрос DNS нуждается в
информации из другого домена, DNS-сервер может использовать информацию сокращенной зоны,
чтобы немедленно соединиться с сервером имен в другом домене.

Рис. 3-9. Конфигурация DNS с одним лесом без использования сокращенной зоны

Сокращенная зона поддерживает список серверов имен для делегированных зон. Когда вы
устанавливаете делегированный поддомен, вы должны ввести IP-адреса всех серверов имен в
делегированный домен. Если этот список серверов имен изменяется, например, один из серверов
имен удален из сети, вам придется вручную обновить запись делегирования. Вы можете
использовать сокращенную зону, чтобы автоматизировать процесс обновления списка серверов
имен. Чтобы сделать это в домене Contoso.com, вы можете сконфигурировать сокращенную зону
для домена NAmerica.Contoso.com на серверах DNS домена Contoso.com. Вы также можете
сконфигурировать запись делегирования в зоне Contoso.com, указывающую на сокращенную зону.
Когда записи сервера имен изменятся в дочернем домене, они будут автоматически обновлены в
сокращенной зоне. Когда серверы DNS Contoso.com будут использовать запись делегирования,
они получат ссылку на сокращенную зону, так что у них всегда будет доступ к обновленной
информации сервера имен.
Чтобы сконфигурировать сокращенную зону, используйте New Zone Wizard (Мастер новой зоны)
в инструменте администрирования DNS. Щелкните правой кнопкой мыши на Forward Lookup
Zones (Прямая зона просмотра) или на Reverse Lookup Zones (Обратная зона просмотра)) и
выберите New Zone (Новая зона). Появится опция создания сокращенной зоны (см. рис. 3-10).
Рис. 3-10. Создание новой сокращенной зоны

Раздел приложений каталога

Третье улучшение DNS, помогающее разрешению имен хоста между несколькими доменами,
состоит в использовании раздела приложений каталога.
DNS в Active Directory Windows Server 2003 использует раздел приложений каталога для
облегчения репликации информации DNS в лесу. При установке DNS, когда вы назначаете первый
сервер в лесу на роль контроллера домена, в Active Directory создаются два новых раздела
каталога. Это разделы DomainDnsZones и ForestDnsZones. (Их не видно ни в одном из обычных
инструментальных средств управления Active Directory, они отображаются при использовании
ADSI Edit или Ldp.exe; использование ADSI Edit показано на рисунке 3-11.) Каждый из этих
разделов хранит разную конфигурацию репликации. Раздел DomainDnsZones реплицируется на
все серверы DNS, выполняющиеся на контроллерах домена. Раздел ForestDnsZones реплицируется
на все серверы DNS, выполняющиеся на контроллерах домена в лесу. Вы можете хранить
информацию DNS в разделе каталога домена, т.е. она будет копироваться на все контроллеры
домена в домене.
Необходимо выбрать место хранения информации DNS при создании новой зоны (см. рис. 3-12) в
окне Zone Properties (Свойства зоны) в инструменте администрирования DNS. Имеются четыре
варианта хранения информации DNS.
• То All DNS Servers In The Active Directory Forest domainname (Ha все серверы DNS леса
Active Directory). Информация хранится в разделе ForestDnsZones, откуда копируется на
все серверы DNS контроллеров домена леса. Эта конфигурация задана по умолчанию для
зоны _msdcs в интегрированной зоне Active Directory.

Рис. 3-11. Раздел приложений каталога DNS в инструменте ADSI Edit

• То All DNS Servers In The Active Directory Domain domainname (Ha все серверы DNS в
домене Active Directory). Информация хранится в разделе DomamDnsZones, откуда
копируется на все серверы DNS, выполняющиеся на контроллерах домена. Это
конфигурация, принятая по умолчанию для интегрированной зоны Active Directory,
созданной в процессе обновления контроллера домена.
• То All Domain Controllers In The Active Directory Domain domainname (На все
контроллеры домена в домене Active Directory). Информация хранится в разделе домена
 каталога, откуда копируется на все контроллеры домена. Различие между этой опцией и
предыдущей состоит в том, что в этом случае все контроллеры домена получат
информацию, в то время как раздел DomamDnsZones реплицируется только на
контроллеры домена, являющиеся серверами DNS.
• То All Domain Controllers Specified In The Scope Of The Following Application Directory
Partition (На все контроллеры домена в пределах следующего раздела приложений
каталога). Эта опция доступна только в том случае, если вы создаете дополнительный
раздел приложений каталога с его собственной конфигурацией репликации. Информация
DNS будет копироваться на все контроллеры домена, которые имеют реплику этого
раздела.
Примечание. Раздел приложений каталога для DNS создается только в том случае, если выбрана
установка DNS при назначении первого контроллера домена или леса. Если вы хотите
воспользоваться преимуществами раздела приложений каталога для DNS после того, как
обновили контроллер домена, необходимо вручную создать раздел перед его использованием. Для
создания раздела применяется инструмент администрирования DNS или инструмент командной
строки DNSCMD. При использовании инструмента администрирования DNS щелкните правой
кнопкой мыши на имени сервера DNS и выберите Create Default Application Directory Partitions
(Создание заданных по умолчанию разделов приложений каталога). При использовании
инструмента DNSCMD откройте командную строку и напечатайте dnscmd DN S
servername/CreateBuiltin-DirectoryPartitions /forest. В результате будет создан раздел
ForestDnsZones. Чтобы создать раздел DomainDnsZones, используйте «/domain» в качестве
последнего параметра в команде. Поскольку эта команда изменяет раздел конфигурации
каталога в Active Directory, вы должны входить в систему как член группы Enterprise Admins
(Администраторы предприятия).

Рис. 3-12. Конфигурирование области репликации для зон DNS

Обычно заданная по умолчанию конфигурация зон не изменяется. При наличии нескольких

контроллеров домена в домене, причем только некоторые из них являются серверами DNS,
использование раздела DomainDnsZones уменьшает количество репликаций на контроллеры
домена, которые не являются серверами DNS. Зона _msdcs для каждого домена, которая включает
только информацию о серверах Active Directory в домене, хранится в разделе ForestDnsZones. Эта
информация реплицируется по всему лесу.

Резюме
Служба DNS является необходимой сетевой службой для сетей Windows Server 2003. Без нее
практически любой вход в систему и усилия по поиску расположения ресурсов потерпят неудачу в
Windows Server 2003. Как сетевой администратор вы должны стать экспертом по службе DNS. В
данной главе был дан краткий обзор того, как работает DNS в качестве сетевой службы в любой
среде, показана специфика интеграции DNS с Active Directory. Наиболее важным компонентом
интеграции является процесс поиска контроллера домена, при котором контроллеры домена в
Active Directory регистрируют записи SRV в DNS, а затем клиенты используют эти записи для
поиска контроллеров домена. Кроме того, было приведено описание некоторых улучшений DNS в
Windows Server 2003.
Глава 4. Репликация Active Directory и сайты
Каждая компания, реализующая службу каталога Active Directory Microsoft Windows Server 2003,
развертывает несколько контроллеров домена. Они могут располагаться в одном центре обработки
данных в главном офисе компании и связываться высокоскоростными сетевыми соединениями.
Они могут быть распределены по всему миру и использовать для связи глобальные сети (WAN).
Некоторые компании имеют единственный домен в лесу, другие компании - много доменов в
нескольких доменных деревьях в общем лесу.
Независимо от того, сколько контроллеров домена имеет компания и где они расположены,
контроллеры домена должны реплицировать информацию друг у друга. Если они не будут делать
этого, каталоги на контроллерах станут противоречивыми. Например, если на одном контроллере
домена будет создан пользователь и эта информация не скопируется на все другие контроллеры
домена, то этот пользователь сможет входить только на один контроллер домена.
Служба Active Directory использует модель репликации с несколькими хозяевами, в которой
изменения в каталоге могут быть сделаны на любом контроллере домена и скопированы на другие
контроллеры. В данной главе описывается процесс репликации в Active Directory. Глава
рассказывает о том, как работает репликация, как создается топология репликации, и как
контроллеры домена копируют информацию друг у друга.

Модель репликации Active Directory

В главе 2 говорилось о том, что Active Directory состоит из нескольких логических разделов.
Репликация информации между контроллерами домена с репликами всех разделов осуществляется
одинаково для всех разделов. Когда изменяется атрибут в разделе конфигурации каталога, он
реплицируется так же, как и в случае изменения атрибута любого другого раздела. Единственное
отличие состоит в списке контроллеров домена, которые получат копию реплицируемого
изменения. Репликация между контроллерами домена в одном и том же сайте обрабатывается
иначе, чем между контроллерами домена различных сайтов, но основная модель не изменяется. В
этом разделе описывается модель репликации, которая используется в Active Directory.
В отличие от модели репликации с единственным хозяином, которая используется в системе
Microsoft Windows NT, Active Directory использует модель репликации с несколькими хозяевами.
В Windows NT основной контроллер домена (PDC — Primary Domain Controller) является
единственным контроллером домена, который может принимать изменения информации домена.
После того как изменение сделано, оно реплицируется на все резервные контроллеры домена
(BDC — Backup Domain Controllers). Недостатком модели репликации с единственным хозяином
является то, что она не масштабируется для большой распределенной среды. Поскольку
изменения (например, пароля пользователя) могут выполняться только на контроллере PDC, это
может стать узким местом, если делаются сразу тысячи изменений. Контроллер PDC находится
только в одном месте компании, и любые изменения информации домена, расположенного в
удаленном месте, должны быть сделаны на этом контроллере PDC. Другая проблема заключается
в том, что контроллер PDC является единственной точкой отказа. Если он недоступен, никаких
изменений информации каталога сделать нельзя до тех пор, пока он не вернется в интерактивный
режим или пока другой BDC-контроллер не будет назначен на роль контроллера PDC.
В Active Directory изменения информации домена могут быть сделаны на любом контроллере
домена, т.е. каждый контроллер домена имеет перезаписываемую копию каталога, а контроллера
PDC не существует. Как только изменение было сделано, оно копируется на все другие
контроллеры домена. Такая модель репликации с несколькими хозяевами направлена на
повышение надежности и масштабируемости, ведь изменения в каталоге можно делать на любом
контроллере домена независимо от того, где он расположен. Поскольку все контроллеры домена
обеспечивают одни и те же службы, отказ одного их них не является критичным для всей системы.
Примечание. В главе 2 говорилось о том, что в Active Directory имеются определенные роли
хозяев операций, которые могут выполняться только одним контроллером домена. Эти роли
представляют собой критическую точку отказа системы, но их можно легко передавать на
другой контроллер домена.
Модель репликации, используемая в Active Directory, представляет модель с нежестким
согласованием, обладающую сходимостью. Репликация не является жестко согласованной, так как
контроллеры домена, содержащие реплику раздела, не всегда имеют идентичную информацию.
Например, если новый пользователь создан на одном из контроллеров домена, другие
контроллеры домена не получат эту информацию до следующего цикла репликации. Процесс
репликации всегда сходится, т.е. если система поддерживается в стационарном состоянии, без
внесения новых изменений к каталогу в течение некоторого времени, то все
контроллеры домена достигнут единообразного состояния и будут иметь идентичную информацию.
При репликации используется также процесс хранения и ретрансляции (store and forward). Это означает, что
контроллер домена может получать изменение к каталогу, а затем отправлять его на другие контроллеры
домена. Это выгодно в тех случаях, когда несколько контроллеров домена, находящихся в разных офисах
компании, соединены медленными WAN-соединениями. Изменение к каталогу может реплицироваться с
контроллера домена одного из сайтов на единственный контроллер домена второго сайта. Контроллер
домена, который получает обновление, может затем переправить изменения на другие контроллеры домена
во втором сайте. Контроллер домена, на котором были сделаны изменения каталога, не должен копировать
изменения непосредственно на все контроллеры домена, как это имеет место в модели репликации с
единственным хозяином.

Улучшение репликации Active Directory Windows

Server 2003
Модель репликации Active Directory Windows Server 2003, по существу, совпадает с той, которая
используется в системе Microsoft Windows 2000, но имеет ряд существенных улучшений.
• Частичная репликация атрибутов, имеющих несколько значений. В системе Windows 2000
атрибут являлся самой маленькой единицей репликации. В некоторых случаях изменение одного из
нескольких значений в атрибуте может создавать существенный трафик репликации. Типичный
пример такой ситуации связан с универсальным членством группы. Поскольку полный список
членства для универсальной группы является одним атрибутом, то добавление одного пользователя
к универсальной группе приводит к значительной репликации, особенно когда группа уже содержит
несколько тысяч членов. В Active Directory Windows Server 2003 атрибуты, имеющие несколько
значений, подобные членству группы, могут быть обновлены путем репликации только
модифицированного значения атрибута.
• Поддержка групп, содержащих более 5000 членов. В системе Windows 2000 группы не могут
содержать более 5000 членов из-за того, что репликации модификаций выполняется на уровне
атрибутов. Практический предел передачи изменений в базу данных каталога в одной транзакции
составляет 5000 значений. Этот предел определяет максимальное количество обновлений, которые
могут реплицироваться в процессе одной репликации. В Active Directory Windows Server 2003
поддержка модификаций только одного значения для объектов, имеющих несколько значений,
снимает эти ограничения.
Примечание. Описанные выше преимущества доступны только в том случае, если домен
работает на функциональном или на временном (interim) функциональном уровне Windows Server
2003. Функциональный уровень Windows Server 2003 доступен только тогда, когда на всех
контроллерах домена в лесу выполняется Windows Server 2003. Временный функциональный
уровень Windows Server 2003 доступен в том случае, когда лес содержит контроллеры домена, на
которых выполняются Windows Server 2003 и Windows NT. Для получения дополнительной
информации о функциональных уровнях см. гл. 7.
• Возможность отключать сжатие при репликации между сайтами. По умолчанию весь трафик
репликации между сайтами сжимается как для Active Directory Windows 2000, так и для Active
Directory Windows Server 2003. Это дает дополнительную нагрузку на процессор контроллера
домена. Однако при наличии достаточной пропускной способности между сайтами сжатие в Active
Directory Windows Server 2003 можно отключать.
• Возможность уведомлений для репликации между сайтами. По умолчанию репликация между
сайтами производится по графику с заданной частотой, сконфигурированной на связях сайта. В
Active Directory Windows Server 2003 имеется опция, позволяющая включать уведомления для
репликации между сайтами. Если уведомления включены, то сервер-плацдарм (bridgehead server)
того сайта, где произошло изменение, уведомляет об этом сервер-плацдарм сайта адресата, и
изменения передаются по связям сайта. Нотификация может значительно уменьшать время
ожидания репликаций между сайтами, но при этом значительно увеличивается сетевой трафик.
Примечание. Чтобы отключить сжатие или включить процедуру уведомлений для репликации
между сайтами, используется инструмент ADSI Edit для модификации атрибута Options
(Опции) объекта-соединения сайта (site link object) или объекта-связи (connection object). Чтобы
выключить сжатие, установите значение атрибута Options (Опции) равным четырем; чтобы
включить уведомления, установите это значение равным единице.
• Улучшенная генерация топологии между сайтами. В системе Windows 2000 размер организации
имел ограничение в 100 сайтов в лесу. Это ограничение связано со временем, которое требуется
службе КСС (Knowledge Consistency Checker — модуль проверки целостности сведений), для того
чтобы вычислить топологию маршрутизации для такого количества сайтов. Это ограничение в
Active Directory Windows Server 2003 снято.

Внутренняя и внешняя репликация между

сайтами
Одна из главных причин создания дополнительных сайтов в Active Directory состоит в том, чтобы
иметь возможность управления трафиком репликации. Поскольку предполагается, что все
контроллеры домена в пределах сайта связаны высокоскоростными соединениями, то репликация
между ними оптимизируется для получения максимальной скорости и уменьшения времени
ожидания. Однако если трафик репликации пересекает низкоскоростное соединение, то
сохранение пропускной способности сети становится серьезной проблемой. Создание нескольких
сайтов позволяет сохранять пропускную способность сети.
Совет. Если вы работали с Microsoft Exchange Server 5.5 или более ранней версией, различия
процессов репликации внутри и между сайтами вам знакомы. Служба Active Directory использует
многие принципы управления репликацией в Exchange Server 5.5.

Репликация внутри сайта

Основная цель репликации внутри сайта состоит в уменьшении времени ожидания репликации,
т.е. все контроллеры домена сайта должны обновляться настолько быстро, насколько это
возможно. Трафик внутренней репликации характеризуется следующим.
• Репликация происходит сразу после того, как произошло изменение информации Active
Directory. По умолчанию контроллер домена ожидает 15 с после того, как изменение было
сделано, а затем начинает копировать это изменение на другие контроллеры домена в
сайте. После завершения репликации с одним партнером контроллер домена ожидает 3 с, а
затем начинает репликацию с другим партнером. Ожидание в 15 с необходимо для
увеличения эффективности репликации в случае, если к информации раздела будут
сделаны дополнительные изменения. Продолжительность периода ожидания может быть
изменена через системный реестр Windows 2000 или Windows Server 2003 (обратитесь к
соответствующим разделам в комплекте ресурсов Resource Kits за подробностями). На
функциональном уровне Windows Server 2003 это значение можно изменить для каждого
раздела каталога, используя инструмент ADSI Edit.
• Трафик репликации не сжат. Поскольку все компьютеры в пределах сайта связаны
высокоскоростными соединениями, данные посылаются без сжатия. Сжатие данных
репликации добавляет дополнительную нагрузку на сервер контроллера домена. При
отсутствии трафика репликации производительность сервера сохраняется за счет
использования сети.
• Процесс репликации инициируется в соответствии с уведомлением, пришедшим от
контроллера-отправителя. После изменения в базе данных компьютер-отправитель
обновлений уведомляет контроллер домена адресата о том, что произошло обновление.
Контроллер домена адресата забирает изменения с помощью процедуры удаленного
вызова (RPC). После окончания репликации контроллер-отправитель уведомляет другой
контроллер домена адресата, который также забирает изменения. Этот процесс
продолжается до тех пор, пока все партнеры по репликации не будут обновлены.
• Трафик репликации посылается нескольким партнерам в течение каждого цикла
репликации. После любого изменения каталога контроллер домена будет копировать
информацию всем прямым партнерам по репликации; это могут быть все контроллеры
домена в сайте или только некоторые из них.
• Изменить трафик репликации в пределах сайта нетрудно. Можно сконфигурировать
объекты-связи вручную через инструмент администрирования Active Directory Sites And
Services (Сайты и службы Active Directory), изменить некоторые значения (например,
 начальное уведомление партнера по репликации) через системный реестр (обратитесь к
соответствующим разделам документа Resource Kits за подробностями) или через объект
Partition (Раздел), если ваш лес работает на функциональном уровне Windows Server 2003.
Но в большинстве случаев этого делать не придется.
•
Репликация между сайтами
Основная цель репликации между сайтами состоит в том, чтобы уменьшить нагрузку на сеть,
которая происходит из-за трафика репликации. Трафик репликации между сайтами
характеризуется следующим.
• Репликация инициируется согласно графику, а не тогда, когда сделаны изменения. Чтобы
управлять репликацией между сайтами, нужно сконфигурировать канал связи,
соединяющий эти сайты. Одной из опций является время, когда будут происходить
репликации. Другая опция устанавливает интервал, показывающий то, как часто будут
происходить репликации в течение намеченного времени. Если пропускная способность
сети, соединяющей офисы компании, ограничена, репликации может быть намечена на
нерабочие часы.
• Трафик репликации сжимается приблизительно на 10 - 15 процентов от первоначального
размера, если он составляет свыше 32 Кб. Чтобы сохранить пропускную способность сети,
серверы-плацдармы каждого сайта сжимают трафик за счет дополнительного
использования процессора.
• Для предупреждения контроллеров домена другого сайта об изменениях каталога
уведомления не используются. Вместо этого время репликации определяется по
расписанию.
• Подключения, которые выполняют репликацию между сайтами, могут использовать
протокол интернета (IP) или протокол электронной почты (SMTP). Протокол, который
используется при подключении, определяется пропускной способностью и надежностью
сети, которая связывает разные офисы компании.
• Трафик репликации посылается не партнерам по репликации, а через серверы-плацдармы.
Изменения каталога сайта реплицируются на единственный сервер-плацдарм (один на
каждый раздел каталога) этого сайта, а затем — на сервер-плацдарм другого сайта. Далее
изменения реплицируются с сервера-плацдарма второго сайта на все контроллеры домена
этого сайта.
• Вы можете легко изменять поток репликации между сайтами, изменяя практически
каждый компонент репликации.
Планирование. Ключевым моментом в проектировании Active Directory является планирование
количества сайтов и их месторасположения, конфигурирование подключений между сайтами,
которые должны оптимизировать пропускную способность сети при уменьшении времени
ожидания репликации. Опции конфигурирования подключений между сайтами обсуждаются
далее в этой главе, а проблемы, связанные с проектированием структуры сайта, — в главе 5.

Время ожидания репликации

Репликация в Active Directory Windows Server 2003 реализована таким образом, что копирование
на другие контроллеры домена изменений, сделанных на одном из контроллеров, может занимать
некоторое время. Эта временная задержка называется временем ожидания репликации (replication
latency). В большинстве случаев время ожидания репликации легко вычислить, особенно в
пределах сайта. Как уже говорилось, любое изменение, сделанное в базе данных каталога на
одном из контроллеров домена, будет копироваться партнерам по репликации приблизительно
через 15 с. Контроллер домена адресата задержит это изменение на 15 с, а затем передаст его
своим партнерам по репликации. Время ожидания репликации в пределах сайта приблизительно
равно 15-ти секундам, умноженным на количество ретрансляций, которые потребуются, прежде
чем информация достигнет всех контроллеров домена. Топология репликации в пределах сайта
никогда не требует более трех ретрансляций, так что максимальное время ожидания репликации в
пределах сайта составляет примерно 45 с.
Определить время ожидания репликации между сайтами несколько труднее. Прежде всего, вы
должны вычислить время ожидания репликации в пределах исходного сайта. Это то время,
которое потребуется для копирования изменений, сделанных на контроллере домена сайта-
источника, на сервер-плацдарм того же сайта. Как только информация достигнет сервера-
плацдарма сайта-источника, время, которое потребуется информации для попадания на сайт
адресата, определяется расписанием связи этого сайта и интервалом между репликациями. По
умолчанию репликации выполняются каждые 3 часа в течение дня. Если это значение не
изменено, то эти 3 часа можно добавить ко времени ожидания репликации. Когда информация
достигает сервера-плацдарма на сайте адресата, то к общему времени ожидания нужно добавить
еще и время ожидания репликации внутри сайта для сайта адресата. В некоторых случаях
полученное время ожидания может быть достаточно велико. Чтобы уменьшить его, необходимо
сократить интервал репликаций между сайтами до 15 минут (минимальное значение).
Управление временем ожидания репликаций предполагает балансирование между потребностью в
коротком времени ожидания и ограничением пропускной способности сети. Если требуется очень
короткое время ожидания, все контроллеры домена должны быть помещены в один и тот же сайт,
в этом случае оно будет равняться примерно 45 с для всех контроллеров домена. Однако если
офисы вашей компании соединены WAN-связями с ограниченной пропускной способностью, вам
потребуется несколько сайтов, и время ожидания репликаций увеличится.

Срочная репликация
Иногда время ожидания репликации может оказаться слишком большим, например, когда в
каталоге меняется атрибут, связанный с защитой. Для этих ситуаций Active Directory использует
срочную репликацию (urgent replication), при которой контроллер домена передает изменения
своим партнерам по репликации немедленно. Любой контроллер домена, получивший срочное
обновление, отправит изменение немедленно. Таким образом, все контроллеры домена в сайте
обновят информацию в течение нескольких секунд. Срочные репликации могут быть вызваны
следующими типами изменений.
• Изменение политики блокировки учетных записей для домена.
• Изменение политики паролей домена.
• Перемещение роли хозяина относительного идентификатора (RID) на новый контроллер
домена.
• Изменение безопасности локальных средств защиты (LSA - Local Security Authority),
например, когда изменяется пароль компьютера контроллера домена.
По умолчанию срочные обновления применяются только к внутренней репликации и не
применяются к репликации между сайтами. Политика применения срочных обновлений может
быть изменена путем разрешения уведомлений для репликации между сайтами.
Пользовательские изменения пароля реплицируются по другой модели. Когда пользователь
изменяет пароль на контроллере домена, это
изменение немедленно копируется прямо в PDC-эмулятор. Эта репликация пересекает границы
сайта и не использует серверы-плацдармы сайтов. Вместо этого контроллер домена, на котором
было сделано изменение, для обновления пароля использует RPC-подключение к PDC-эму-лятору.
Затем PDC-эмулятор обновляет все другие контроллеры домена через нормальный процесс
репликации. Если пользователь попытается войти на контроллер домена, который еще не получил
новый пароль, контроллер домена, прежде чем отклонить вход в систему, проверит PDC-эмулятор,
на предмет наличия обновлений, касающихся изменения пароля этого пользователя.

Генерация топологии репликации

Ключевым моментом репликации в Active Directory является создание топология репликации. По
умолчанию процесс создания топологии репликации обрабатывается автоматически службой
Active Directory. Можно сконфигурировать топологию репликации вручную, но в большинстве
случаев конфигурация, заданная системой по умолчанию, является наилучшим вариантом.

Проверка целостности сведений (Knowledge Consistency

Checker)
КСС (Knowledge Consistency Checker) — это процесс, который выполняется на каждом
контроллере домена, он ответствен за создание топологии репликации в пределах сайта и между
сайтами. Как только к лесу Active Directory добавляется второй контроллер домена, служба КСС
начинает создавать топологию репликации, которая является и эффективной, и терпимой к
ошибкам. По мере добавления к сайту других контроллеров домена или новых сайтов КСС
использует информацию о серверах, сайтах, связях сайта и расписаниях для создания оптимальной
топологии репликации. Служба КСС динамически анализирует изменения или отказы,
возникающие в пределах топологии репликации. Если один из контроллеров домена временно
находится в автономном режиме, то КСС пересматривает топологию репликации, чтобы обойти
неработающий контроллер домена. По умолчанию КСС каждого контроллера домена повторно
вычисляет топологию репликации каждые 15 минут. Имеется возможность в любое время
повторно вычислить топологию репликации с помощью инструмента администрирования Active
Directory Sites And Services (Сайты и службы Active Directory). Найдя сервер, на котором вы
хотите проверить топологию репликации, и щелкнув правой кнопкой мыши на NTDS Settings
(Параметры настройки NTDS) в контейнере сервера, выберите опцию All Tasks (Все задачи), затем
выберите Check Replication Topology (Проверить топологию репликации).

Объекты связи
При создании топологии репликации служба КСС создает ряд объектов связи (connection object),
которые хранятся в разделе конфигурации каталога Active Directory. Объекты связи являются
прямыми логическими соединениями между контроллерами домена, которые используются для
репликации информации каталога. Как уже говорилось, КСС создает топологию репликации,
которая является эффективной и терпимой к ошибкам. КСС строит столько объектов связи,
сколько для этого требуется.
Объекты связи всегда создаются как односторонние pull («тянущие») соединения между двумя
контроллерами домена, потому что нормальный процесс репликации является pull-операцией, в
которой контроллер-адресат запрашивает данные у контроллера-отправителя информации. В
большинстве случаев КСС строит два односторонних соединения между контроллерами домена
так, чтобы информация могла реплицироваться в обоих направлениях.
Примечание. С помощью инструмента Replication Monitor (Монитор репликации) вы можете
создать push («толкающую») репликацию для раздела каталога. Нормальный процесс репликации
всегда является pull-операцией. (Смотрите детали, касающиеся установки и использования
монитора репликации в разделе «Мониторинг и поиск неисправностей при репликации» далее в
этой главе.)
В большинстве случаев объекты связи, автоматически созданные КСС, оптимизированы, и вам не
нужно делать никаких изменений. Однако, в некоторых случаях вы, возможно, захотите их
изменить. Например, вы пожелаете, чтобы контроллеры домена хозяев операций всегда были
прямыми партнерами по репликации тех контроллеров домена, которых вы назначили резервными
хозяевами операций на случай отказа основного хозяина. Создавая соглашение о подключении, вы
можете гарантировать оптимальную топологию репликации для некоторого определенного набора
контроллеров домена.
Вы можете изменить заданные по умолчанию объекты связи двумя способами: изменяя некоторые
параметры настройки на объектах связи, созданных КСС, и добавляя новые объекты связи.

Изменение объекта связи, созданного КСС

Вы можете изменять график и контроллер-отправитель для объекта связи в пределах сайта, а
также транспортный протокол для межсайто-вых объектов связи. По умолчанию контроллеры
домена в пределах сайта каждый час проверяют всех своих партнеров по репликации, чтобы
удостовериться, что обновления не были пропущены. Этот график можно изменить так, чтобы
никогда не делать проверку, проверять каждые полчаса или каждые 15 минут. (Интерфейс связи
показан на рисунке 4-1.)
Когда вы производите изменения объекта связи, его имя <automatically generated> (автоматически
сгенерированный) заменяется на глобальный уникальный идентификатор объекта (GUID). После
изменения объекта вы можете его переименовать.
Рис. 4-1. Конфигурирование существующего объекта связи

Создание нового объекта связи

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

Топология репликации внутри сайта

Существует два варианта конфигурирования репликации между контроллерами домена в Active
Directory. В первом варианте используется модель остовного дерева (spanning tree), когда
создается топология репликации только с одним направлением репликации между контроллерами
домена. Каждый контроллер домена, на котором размещается раздел каталога, будет иметь только
одного партнера по репликации, передающего данные для этого раздела. Это гарантия того, что
никогда не возникнут связи, по которым информация будет пересылаться на определенный
контроллер домена более чем одним путем. Контроллеры домена никогда не получат одно и то же
обновление дважды, потому что оно прибывает только из одного источника. Основной недостаток
использования алгоритма spanning tree состоит в отсутствии избыточности. Если на одном из
контроллеров домена произойдет сбой, то может потребоваться некоторое время на повторное
вычисление пути репликации в обход неисправного контроллера.
Второй вариант создания топологии репликации должен включать избыточные связи. Основными
целями разработки топологии репликации Active Directory являются работоспособность и
устойчивость к отказам. Если отдельный контроллер домена недоступен для репликации,
репликации Active Directory не должна оканчиваться неудачей. Недостаток использования
избыточных связей состоит в том, что контроллер домена может получать одно и то же
обновление несколько раз, потому что каждый контроллер домена имеет несколько партнеров по
репликации. Чтобы избежать многократных модификаций одной и той же информации, при
репликации Active Directory используется демпфирование распространения.
Как только к организации добавляются контроллеры домена с репликами определенного раздела
Active Directory, KCC автоматически начинает создавать топологию репликации. Эта топология
образует кольцо репликации. На рисунке 4-2 показан пример простой сетевой структуры с тремя
контроллерами в одном домене и единственном сайте.
Рис. 4-2. Простое кольцо репликации

КСС создает кольцо репликации (см. рис. 4-2), в котором каждый контроллер домена
сконфигурирован с двумя входящими связями репликации. Если одна из связей недоступна, то
обновление может передаваться по другой связи. Кроме того, каждый контроллер домена
сконфигурирован как контроллер-источник для двух других контроллеров домена. Это создает
избыточное кольцо для каждого контроллера домена.
По мере увеличения количества контроллеров домена с репликой определенного раздела
становится важным второй принцип создания свя-
зей. Служба КСС всегда создает топологию репликации, в которой каждый контроллер домена в
сайте удален от любого другого контроллера домена не более чем на три ретрансляции (hop).
Когда количество контроллеров домена в сайте становится больше семи, создаются
дополнительные объекты связи для уменьшения потенциального числа ретрансляций до трех или
меньшего количества. Например, сайт на рисунке 4-3 имеет девять контроллеров домена. Он будет
иметь топологию репликации, включающую, по крайней мере, одну дополнительную связь.

Рис. 4-3. Кольцо репликации, включающее более семи контроллеров домена

Кольца репликации основываются на разделах каталога. Это означает, что КСС вычисляет кольцо
репликации для каждого раздела каталога. Например, организация имеет несколько доменов в
единственном сайте и раздел приложений каталога, который копируется на несколько
контроллеров домена в сайте. В этом случае конфигурация могла быть задана так, как показано на
рисунке 4-4. В предложенном сценарии (см. рис. 4-4) возможно создание колец репликации,
представленных в табл. 4-1.

Табл. 4-1. Кольца репликации в сложном сайте

Раздел каталога Партнеры по репликации
Раздел конфигурации Все контроллеры домена будут
каталога, раздел схемы включены в кольцо репликации для
каталога раздела конфигурации каталога и
раздела схемы каталога, потому что они
копируются на все контроллеры домена
данного леса.
Раздел каталога домена DCl.Contoso.com, DC2.Contoso.com,
Contoso.com DC3.Contoso.com, DC4.Contoso.com.
Раздел каталога домена DC5.Fabrikam.com, DC6.Fabrikam.com.
Fabrikam.com
Глобальный каталог (GC) DCl.Contoso.com, DC4.Contoso.com,
DC5.Fabrikam.com.
Раздел приложений каталога DC2.Contoso.com, DC6. Fabrikam.com.1.
AppPartitionl

Дополнительную информацию смотрите в примечании ниже.

Рис. 4-4. Кольца репликации, созданные для каждого раздела каталога

Примечание. Разделы приложений каталога DNS (ForestDnsZones и DomainDnsZones) также

включены в топологию репликации. Чтобы не усложнять сценарий, эти разделы на рисунке 4-4 не
обозначены и не приводятся в связанной с ним таблице. В главе 3 говорилось о том, что эти
разделы обрабатываются так же, как другие доменные разделы каталога. По этой же причине
на рисунке 4-4 не показана топология репликации глобального каталога GC. Процесс создания
кольца репликации GC немного отличается от репликации других разделов и будет описан далее.
Разделы репликации и топологию можно просмотреть с помощью инструмента Replication Monitor
(Монитор репликации). Монитор репликации — это одно из инструментальных средств
поддержки, которые помещены на компакт-диск Windows Server 2003. Чтобы установить
инструментальные средства поддержки, запустите файл Suptools.msi из каталога Support\Tools
компакт-диска Windows Server 2003. Чтобы запустить монитор репликации, в окне Run
(Выполнить) напечатайте replmon. На рисунке 4-5 показана конфигурация четырех серверов в
лесу, отображаемая с помощью монитора репликации.
Рис. 4-5. Использование монитора репликации для просмотра раздела репликации

Кольцо репликации - это логическая концепция, фактическая топология репликации,

реализованная с помощью объектов связи. В то время как для каждого раздела каталога создается
отдельное кольцо репликации, КСС не создает дополнительные объекты связи для каждого кольца
репликации. Вместо этого КСС, насколько возможно, повторно использует одни и те же объекты
связи для многих колец репликации. В
примере на рисунке 4-5 DCl.Contoso.com имеет объект связи с DC4.Fabrikam.com.
Один из способов просмотра свойства объекта связи состоит в использовании монитора
репликации. Чтобы рассмотреть свойства входящих связей сервера, добавьте сервер к
контролируемому списку серверов. Затем щелкните правой кнопкой мыши на имени сервера и
выберите Show Replication Topologies (Показать топологию репликации). Щелкните на View
(Вид), далее — на Connection Objects Only (Только объекты связи), а затем щелкните правой
кнопкой мыши на сервере и выберите Properties (Свойства). Вкладка Inbound Replication
Connections (Входящие связи репликации) показывает все входящие связи для контроллера
домена, а также разделы, реплицируемые через каждую связь. Как показано на рисунке 4-6, этот
объект связи используется для реплицирования глобального каталога (показан как раздел
Fabrikam.com), раздела схемы каталога и раздела конфигурации каталога. Всякий раз, когда это
возможно, КСС создает объект связи, пригодный для реплицирования нескольких разделов
каталога.
Рис. 4-6. Отдельный объект связи, использующийся для репликации нескольких разделов
каталога

Репликация глобального каталога

Глобальный каталог отличается от других разделов тем, что он составлен из баз данных доменов
целого леса. Каталог GC всех контроллеров домена предназначен только для чтения. Это означает,
что информация в GC не может быть изменена администратором напрямую. Глобальный каталог
GC представляет собой список всех атрибутов, переданных в него, атрибут
isMemberOfPartialAttributesSet которых установлен на true (истину).
Тот факт, что GC создан из баз данных доменов, затрагивает также кольцо репликации для GC.
Каждый GC-сервер должен получить GC-информацию от контроллеров домена всех доменов. На
рисунке 4-7 приведен пример компании, имеющей два домена с одним контроллером домена в
каждом; оба домена расположены в одном и том же сайте. Домен DCl.Contoso.com
сконфигурирован как сервер глобального каталога. GC-сервер является также единственным
контроллером домена для домена Contoso.com, поэтому он извлекает GC-информацию для
Contoso.com из своей собственной базы данных домена. Контроллер домена в домене
Fabrikam.com имеет единственную копию раздела каталога этого домена, поэтому
DCl.Contoso.com собирает GC-информацию для домена Fabrikam.com из DC2.Fabrikam.com. Для
извлечения информации из домена Fabrikam.com создан объект связи, направленный от
DC2.Fabrikam.com к DCl.Contoso.com. В дальнейшем эта связь может использоваться для
репликации GC-информации в DCl.Contoso.com.

Рис. 4-7. Пример простой репликации глобального каталога

На рисунке 4-8 показан более сложный пример создания GC и его репликации. В этом случае
сконфигурирован объект связи, направленный от контроллера домена каждого домена на каждый
GC-сервер. DCl.Contoso.com имеет входящий объект связи от контроллеров DC2.Contoso.com,
DC4.Fabrikam.com и DC6.NWTraders.com. Этот объект связи используется для создания
глобального каталога на DCl.Contoso.com. Все другие GC-серверы имеют подобный набор
объектов связи. Кроме того, создано также отдельное кольцо для репликации раздела GC между
всеми GC серверами.

Топология межсайтовой репликации

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

Рис. 4-8. Пример сложной GC-репликации

Подобный подход используется также при определении топологии репликации между сайтами, за
исключением того, что один контроллер домена в каждом сайте ответственен за разработку
топологии между сайтами. КСС одного из контроллеров домена в сайте обозначается как
генератор межсайтовой топологии (ISTG - Inter-Site Topology Generator) для сайта. Имеется
только один ISTG-контроллер на сайте, независимо от того, сколько доменов или других разделов
каталога находится в сайте. Контроллер ISTG ответственен за вычисление идеальной топологии
репликации для всего сайта. Этот процесс состоит из двух частей.
• Идентификация серверов-плацдармов (bridgehead server) для каждого раздела каталога,
имеющегося в сайте. При репликации между сайтами информация всегда посылается с
сервера-плацдарма одного сайта на сервер-плацдарм другого. Это означает, что по сетевой
связи между сайтами информация реплицируется только однажды.
• Создание объектов связи между серверами-плацдармами для гарантии репликации между
сайтами. Поскольку репликация конфигурируется между серверами-плацдармами, то в
пределах сайта отсутствуют избыточные объекты связи.
При добавлении к лесу нового сайта ISTG в каждом сайте определяет, какой раздел каталога в нем
имеется. Затем ISTG вычисляет новые объекты связи, которые потребуются для репликации
нужной информации с нового сайта. Кроме того, ISTG назначает один контроллер домена
сервером-плацдармом для каждого раздела каталога. ISTG создает необходимое соглашение связи
в своем каталоге, и эта информация копируется на сервер-плацдарм. Затем сервер-плацдарм
создает подключение для репликации с сервером-плацдармом удаленного сайта, и начинается
репликация.
На рисунке 4-9 показан пример топологии репликации, созданной между сайтами. В этом примере
лес содержит два сайта и два домена с несколькими контроллерами домена в каждом сайте.
Имеется также, по крайней мере, один GC-сервер в каждом сайте. Это означает, что каждый сайт
содержит раздел каталога для каждого из доменов, раздел GC, а также разделы схемы каталога и
конфигурации каталога. В каждом сайте требуется назначить по два сервера-плацдарма, потому
что каждый из этих разделов должен копироваться между сайтами. Один из серверов-плацдармов
в обоих сайтах должен быть контроллером домена в домене Contoso.com. Другой сервер-плацдарм
обоих сайтов должен быть контроллером домена в домене Fabrikam.com. В примере, показанном
на рисунке 4-9, контроллеры DCl.Contoso.com и DC6.Fabrikam.com являются также GC-серверами.
Это означает, что они станут серверами-плацдармами при репликации GC-информации между
сайтами. Поскольку раздел схемы и раздел конфигурации каталога являются общими для всех
контроллеров домена, то для репликации этих разделов может использоваться один из
существующих объектов связи.
Примечание. Приведенное обсуждение топологии репликации основано на заданном по
умолчанию поведении для контроллеров домена Active Directory. Администраторы могут
изменять это поведение, особенно для репликации между сайтами. Эти вопросы будут
обсуждаться далее в этой главе.

Рис. 4-9. Межсайтовые объекты связи

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

Типы обновлений
Существуют два типа обновлений информации Active Directory, касающейся определенного
контроллера домена. Первый тип обновлений - исходное обновление (originating update). Исходное
обновление выполняется при добавлении, изменении или удалении объекта на контроллере
домена. Второй тип обновлений - реплицируемое обновление (replicated update). Репликация
выполняется тогда, когда изменение, сделанное на одном контроллере домена, копируется на
другой контроллер домена. По определению исходное обновление, касающееся любого
конкретного изменения, только одно, оно выполняется на том контроллере домена, где было
сделано. Затем исходное обновление копируется на все контроллеры домена, которые имеют
реплику раздела Active Directory, затронутого обновлением.
Исходные обновления Active Directory происходят в следующих случаях:
• к Active Directory добавлен новый объект;
• из Active Directory удален существующий объект;
• атрибуты существующего объекта изменены. Эта модификация может включать
добавление нового значения атрибуту, удаление значения атрибута или изменение
существующего значения;
• объект Active Directory перемещен в новый родительский контейнер. Если изменяется имя
родительского контейнера, то каждый объект контейнера перемещается в
переименованный контейнер.
Все исходные обновления Active Directory являются элементарными операциями. Это означает,
что в процессе передачи модификация должна быть передана полностью, как целая транзакция, и
никакая ее часть не передается отдельно от других частей.

Репликация изменений
После передачи исходного обновления изменение должно реплицироваться на другие
контроллеры домена, которые содержат реплику этого раздела. В пределах сайта контроллер
домена, на котором произошло исходное обновление, ждет 15 с перед началом копирования
изменений своим прямым партнерам по репликации. Это ожидание предназначено для того, чтобы
несколько модификаций к базе данных можно было реплицировать одновременно, что
увеличивает эффективность репликации. Между сайтами исходное обновление будет
копироваться партнерам по репликации в соответствии с графиком, сконфигурированным на
связях сайта.
Для репликации изменений информации каталога контроллерам домена требуется механизм для
управления потоком репликации. Для оптимизации репликации Active Directory следует
пересылать только те изменения, которые должны реплицироваться между двумя контроллерами
домена. Контроллеры домена должны уметь определять эти изменения, если таковые вообще
имеются, а затем копировать только ту часть изменений, которая требуется. Для управления
репликацией каталога в Active Directory используются порядковые номера обновлений (USN -
update sequence number), значения уровня (high-watermark value), векторы новизны (up-to-dateness
vectors) и отметки об изменениях (change stamps). Эти компоненты обсуждаются далее.

Порядковые номера обновлений

Когда объект базы данных модифицируется, то изменению присваивается порядковый номер
обновления. Порядковые номера обновления (USN — update sequence number) являются
спецификой баз данных сервера. Например, если изменению номера телефона одного из
пользователей был назначен номер USN 5555, то следующее изменение базы данных, независимо
от изменяемого объекта, будет иметь номер USN 5556. Один номер USN назначается для каждого
совершенного изменения. Если в одной модификации
изменено несколько атрибутов (например, адрес, номер телефона и местоположение офиса), то
этой модификации назначается только один USN.
Существует три способа использования USN при выполнении модификаций. Во-первых,
локальное значение USN сохраняется вместе с атрибутом, который был модифицирован.
Локальное значение идентифицирует USN измененного атрибута. Во-вторых, USN используется
для атрибута uSNChanged объекта. Этот атрибут хранится с каждым объектом и идентифицирует
самый высокий USN для атрибутов данного объекта. Рассмотрим пример. Предположим, что был
изменен номер телефона пользователя, и этому изменению был назначен USN, равный 5556. И
локальный USN, и атрибут uSNChanged будут установлены на 5556. Если следующая
модификация, сделанная в каталоге на том же сервере, состоит в изменении адреса того же самого
пользователя, то местный USN на атрибуте адреса и атрибут uSNChanged для пользовательского
объекта будут изменены на 5557. Однако местный USN для атрибута номера телефона останется
равным 5556, потому что это USN для последней модификации этого конкретного атрибута.
Локальный USN и атрибут uSNChanged относятся как к исходным, так и к реплицируемым
обновлениям. В последнем способе USN используется как USN исходной модификации атрибута.
Это значение устанавливается только для исходных модификаций, оно копируется на все другие
контроллеры домена как часть репликации атрибутов. Когда на сервере изменяется номер
телефона пользователя, то USN этого изменения назначается равным исходному значению USN.
Когда измененный номер телефона копируется на другой контроллер домена, исходный USN
посылается вместе с модификацией, и это значение не изменяется на контроллере домена
адресата. Локальный USN и атрибут uSNChanged будут изменены на контроллере домена
адресата, но исходный USN не изменится до тех пор, пока сам атрибут не будет снова
модифицирован. Исходный USN используется для демпфирования распространения, которое
рассматривается далее в этой главе.

Значения уровней
Значения уровней (high-watermark values) используются для управления тем, какая информация
реплицируется между контроллерами домена. Каждый контроллер домена поддерживает свой
собственный набор уровней для каждого из своих прямых партнеров по репликации. Уровень -это
последнее значение uSNChanged, которое контроллер домена получил от определенного партнера
по репликации. Когда контроллер домена посылает модификацию партнеру по репликации,
значение uSNChanged посылается вместе с модификацией. Контроллер домена адресата сохраняет
его как значение уровня для партнера по репликации.
Значения уровней используются во время процесса репликации. Когда один контроллер домена
запрашивает обновление у другого контроллера домена, то контроллер-адресат посылает свое
значение уровня контроллеру-отправителю. Контроллер-отправитель использует значение уровня
контроллера-адресата для фильтрации всех потенциальных обновлений и посылает только те
изменения, которые имеют более высокое значение uSNChanged.
Примечание. Значение уровня поддерживается отдельно для каждого раздела каталога на
контроллере домена и для каждого прямого партнера по репликации.

Векторы новизны и демпфирование распространения

Векторы новизны (up-to-dateness vectors) также используются для управления тем, какая
информация должна копироваться между контроллерами домена. Векторы новизны используются
для отслеживания всех исходных модификаций, которые данный контроллер домена получил от
какого-либо контроллера домена. Например, изменен номер телефона пользователя на
контроллере домена DC1, и атрибуту назначен исходный USN, равный 5556. Когда этот атрибут
реплицируется на контроллер DC2, исходный USN копируется с обновленным атрибутом. Кроме
того, GUID контроллера DC1 реплицируется вместе с атрибутом. Когда DC2 получает это
обновление, он модифицирует свой вектор новизны, показывая, что самое последнее исходное
обновление, полученное от DC1, теперь равно 5556. Вектор новизны используется для
ограничения трафика репликации между контроллерами домена. Когда контроллер-адресат
запрашивает обновление у контроллера-отправителя, он включает в запрос свои векторы новизны.
Затем компьютер-отправитель использует эту информацию для фильтрации списка всех
возможных модификаций, которые он может послать контроллеру-адресату. Такой выбор важен,
когда имеется более двух контроллеров домена для данного раздела каталога. Например, если к
сценарию, описанному в предшествующем параграфе, добавить контроллер DC3, то изменение
номера телефона, сделанное на DC1, будет копироваться и на DC2, и на DC3. Теперь DC3 и DC2
будут иметь обновленный номер телефона, они изменят свои векторы новизны, показывая, что
самая последняя модификация, которую они оба получили от DC1, имела исходный USN 5556.
Приблизительно через 15 с после получения этой модификации DC2 уведомит DC3, что у него
есть обновленная информация. Когда DC3 будет запрашивать обновления каталога у DC2, он
включит свой вектор новизны в запрос. В этом случае DC2 определит, что вектор новизны
контроллера DC3 для DC1 уже имеет новейший исходный номер USN. Если модификация номера
телефона была единственным изменением, сделанным к каталогу в этот временной период, то
информация между контроллерами домена DC2 и DC3 реплицироваться не будет. Процесс
ограничения модификаций, посылаемых во время репликации, с помощью вектора новизны
называется демпфированием распространения. Как уже говорилось, служба КСС создает
избыточные репли-кационные связи между контроллерами домена. Одна из проблем, связанных с
этим, состоит в том, что одни и те же модификации могут посылаться контроллеру домена от
нескольких партнеров по репликации. Это ведет к увеличению трафика репликации, а также
потенциально приводит к ситуации, когда одна и та же модификация посылается неоднократно
всем контроллерам домена. Демпфирование распространения, использующее вектор новизны,
устраняет такую возможность.

Просмотр информации USN

Номера USN (update sequence number) для любого объекта можно просмотреть с помощью средств
администрирования, включенных в инструментальные средства поддержки Windows Server 2003.
Один из способов просмотра локального USN исходного контроллера домена, исходного USN и
отметки времени (time stamp) для любого атрибута состоит в использовании инструмента
командной строки Repadmin. (Полную инструкцию по установке Repadmin смотрите в разделе
«Мониторинг и поиск неисправностей репликации» далее в этой главе.) Напечатайте repadmin
/showmeta object distinguished name (отличительное имя объекта) в командной строке. Значения
uSNCreated и uSNChanged можно увидеть в ADSI Edit через свойства объекта. Чтобы получить
доступ к информации репликации через Ldp.exe, найдите объект, щелкните правой кнопкой мыши
на объекте, выберите Advanced (Расширенный), затем выберите Replication Metadata (Мета-данные
репликации). Значения USN также можно присмотреть через Монитор репликации (см. рис. 4-10).
Для этого добавьте сервер к списку мониторинга, а затем щелкните правой кнопкой мыши на
сервере и выберите Show Attribute Meta-Data For Active Directory Object (Показать метаданные
атрибута для объекта Active Directory). Введите мандат (credentials) для учетной записи с доступом
к Active Directory, а затем напечатайте отличительное имя объекта. Часть USN-информации
доступна также из обычных средств администрирования. Чтобы посмотреть текущие и исходные
значения USN для объекта в инструменте администрирования Active Directory Users And
Computers, включите Advanced Features (Расширенные функции) в меню View (Вид), а затем
обратитесь к вкладке Object (Объект) в окне Properties (Свойства) объекта.
Уровень и вектор новизны используются для ограничения трафика репликации. Значение уровня
представляет собой самое последнее изменение, которое контроллер домена получил от другого
контроллера домена, так что контроллер-отправитель не должен снова посылать это значение.
Вектор новизны содержит самые свежие обновления, которые были получены от других
контроллеров домена, содержащих реплику раздела, так что контроллер-отправитель не должен
посылать такие модификации каталога, которые контроллер-адресат уже получил от другого
партнера по репликации.

Рис. 4-10. Просмотр мета-данных репликации с помощью Replication Monitor (Монитор

репликации)

Отметки об изменениях и разрешение конфликтов

И последнее, что используется для управления репликацией между контроллерами домена, — это
отметка об изменении (change stamp). Всякий раз, когда атрибут модифицируется, эта
модификация помечается отметкой об изменении. Затем отметка об изменении посылается вместе
с модификацией, когда модификация копируется на другие контроллеры домена. Отметка об
изменениях используется для того, чтобы определить, какое изменение будет принято в случае
конфликта репликации. Отметка об изменениях состоит из трех компонентов.
• Номер версии. Он используется для отслеживания количества изменений, которые были
сделаны к атрибуту объекта. Когда объект создается, номер версии у всех атрибутов
устанавливается на 1, даже если поле атрибута оставлено пустым. Когда происходит
назначение «пустого» атрибута, значение номера версии остается равным 1. Однако когда
атрибут обновляется после начального изменения, номер версии каждый раз
увеличивается на единицу.
• Время последней записи. Оно используется для отслеживания времени, когда произошла
последняя модификация атрибута. Значение времени регистрируется на том сервере, где
атрибут был модифицирован, и копируется вместе с объектом на другие контроллеры
домена.
• Исходный сервер (Originating server). Этот компонент представляет собой GUID сервера, на
котором была применена последняя исходная модификация атрибута.
Эти три компонента формируют отметку об изменениях для каждой модификации атрибута. Когда атрибут
копируется на другой контроллер домена, эта информация копируется вместе с атрибутом. Если один и тот
же атрибут изменен на двух различных контроллерах домена одновременно, то отметка об изменениях
используется для определения того, какой атрибут будет принят в качестве заключительного изменения. В
случае конфликта решение относительно заключительного изменения делается в следующем порядке.
1. Номер версии. Всегда принимается изменение с самым высоким номером версии. Если изменение
на одном контроллере домена имеет номер версии 3, а изменение на другом контроллере домена -
номер версии 4, будет всегда приниматься изменение с номером версии 4.
2. Время последней записи. Если номера версий идентичны, то будет принято изменение с самым
недавним временем последней записи.
3. GXJID сервера. Если номера версий и времена последней записи идентичны, то используется
GUID базы данных сервера для определения того, какое изменение должно быть принято. Будет
принято изменение, прибывающее с сервера, имеющего более высокий GUID. Идентификаторы
GUID назначаются при добавлении контроллера домена к домену, a GUID назначается произвольно.
Практический опыт. Конфликты репликации
Некоторые сетевые администраторы, похоже, очень озабочены возможностью
возникновения конфликтов репликации и потенциальной потерей или перезаписью
данных. В большинстве компаний вероятность их возникновения невелика. Во-
первых, конфликты репликации касаются отдельных атрибутов. (Если номер
телефона пользователя изменяется на одном контроллере домена в то же самое
время, когда адрес пользователя изменяется на другом контроллере домена,
никакой конфликт не возникает.) Во-вторых, большинство компаний имеют
централизованный отдел, где делаются все изменения к учетным записям
пользователя, так что вероятность того, что два человека сделают различные
изменения к одному и тому же атрибуту одновременно, очень мала. Если
администрирование учетных записей пользователя делегировано на уровень
отдела, то каждый отдел делает изменения только к учетным записям пользователя
своего отдела. Таким образом, в большинстве компаний, использующих
структурированный способ работы с объектами Active Directory, конфликты
репликации происходят очень редко.
Служба Active Directory способна разрешать конфликты, которые создаются, когда один и тот же
атрибут объекта изменяется одновременно на двух контроллерах домена. Имеются два других
типа конфликтов, которые могут возникать.
• Добавление или изменение объекта на одном контроллере домена в то же самое
время, когда контейнерный объект этого объекта удаляется на другом контроллере
домена. Рассмотрим пример, в котором на одном контроллере домена был добавлен новый
пользователь к организационной единице (OU) Accounting (Бухгалтерия). В это же время
на другом контроллере домена другой администратор удаляет OU Accounting. В этом
случае объект, который был добавлен к удаленному контейнеру, будет перемещен в
контейнер Active Directory с именем LostAndFound.
• Добавление объектов с одним и тем же относительным отличительным именем
(relative distinguished name) в один и тот же контейнер. Такой конфликт возникает,
когда администратор на одном контроллере домена создает пользовательский объект с
относительным отличительным именем BDiaz в OU Accounting, в то же самое время на
другом контроллере домена пользователь, имеющий такое же относительное
 отличительное имя, перемещается в ту же самую OU или создается в той же самой OU. В
этом случае для определения того, какой объект будет сохранен, а какой переименован, в
модели разрешения конфликтов будет использоваться GUID, назначенный
модифицируемому каталогу. Объект, имеющий более высокий GUID, будет сохранен, а
объект с более низким GUID переименован на BDiaz#CNF:userGUID, где значок номера
(#) является символом дублирования. Если второй пользовательский объект потребуется,
то его можно будет переименовать.

Репликация удалений объектов

Репликация удалений объектов обрабатывается в Active Directory иначе, чем другие модификации
каталога. Когда удаляется учетная записи пользователя, она не уничтожается немедленно. Вместо
этого создается объект-памятник (tombstone). Объект-памятник является исходным объектом, у
которого атрибут isDeleted установлен на true (истина), а большинство атрибутов объекта удалено.
Сохранены только несколько атрибутов, типа GUID, SID, USN и отличительного имени, которые
требуются для идентификации этого объекта.
Объект-памятник затем копируется на другие контроллеры домена в домене. По мере того как
каждый контроллер домена получает модификацию, модификации, которые были сделаны на
исходном контроллере домена, применяются на всех остальных контроллерах. Объекты-
памятники остаются в базе данных домена в течение определенного периода времени,
называемого временем жизни объекта-памятника (tombstone lifetime). В конце времени жизни
объекта-памятника, установленного по умолчанию на 60 дней, каждый контроллер домена удаляет
его из своей копии базы
данных. Процесс удаления объектов-памятников из базы данных называется сборкой мусора
(garbage collection). По умолчанию интервал времени, через который производится сборка мусора,
для леса установлен на 12 часов. Каждые 12 часов выполняется процесс сборки мусора, и
удаляются все объекты-памятники, время жизни которых истекло.
В главе 1 говорилось о том, что служба Active Directory Windows Server 2003 обеспечивает
поддержку неактивных объектов в Active Directory. Неактивный объект (lingering object) — это
объект, который не был удален из контроллера домена, потому что контроллер находился в
автономном режиме или был не способен к репликации в течение всего времени жизни объекта-
памятника. Для удаления неактивных объектов используется инструмент Repadmin.
Совет. Время жизни объекта-памятника и интервал сборки мусора может быть изменен с
помощью ADSI Edit или Ldp.exe. Эти свойства сконфигурированы в объекте CN=Directory
Service,CN=Windows NT,CN=Services,CN = Configuration, DC=ForestRootDomain. Атрибуты
garbageCollPeriod и tombstoneLifetime определяют эти параметры настройки. В большинстве
случаев эти значения менять не требуется.

Конфигурирование репликации между сайтами

Причина создания нескольких сайтов в Active Directory заключается в необходимости управлять
трафиком репликации между несколькими офисами компании, особенно между теми, которые
соединены низкоскоростными WAN-соединениями. Конфигурация сайта для вашей компании
будет оказывать существенное воздействие на трафик репликации, идущий по сети.
Дополнительная информация. Сформулировать четкий критерий того, когда следует
создавать дополнительный сайт, трудно из-за большого количества переменных, которые
должны быть включены в этот критерий. В главе 5 приводится подробная информация о
создании дополнительных сайтов. В этой главе далее рассмотрены другие вопросы
построения Active Directory, которые нужно учитывать при проектировании топологии
сайта.
Как сказано в главе 2, сайт в Active Directory — это место, в котором все контроллеры домена
связаны друг с другом высокоскоростными соединениями. Одна из задач установки сети Active
Directory состоит в определении того, где следует провести границы сайта, а затем соединить
сайты вместе.
Создание дополнительных сайтов
Когда устанавливается Active Directory, создается единственный сайт с именем Default-First-Site-
Name (в дальнейшем сайт можно переименовать). Если не создается дополнительных сайтов, то
все последующие контроллеры домена будут добавляться к этому сайту по мере их установки.
Однако если ваша компания расположена в нескольких местах с ограниченной пропускной
способностью между ними, то вы наверняка захотите создать дополнительные сайты.
Дополнительные сайты создаются с помощью инструмента администрирования Active Directory
Sites And Services (Сайты и службы Active Directory). Чтобы создать новый сайт, щелкните правой
кнопкой мыши на контейнере Sites (Сайты), затем выберите New Site (Новый сайт). В списке Link
Name (Имя связи) вы должны выбрать ту связь сайта, которая будет использоваться для
соединения этого сайта с другими сайтами. Каждый сайт связан с одной или более подсетями IP в
Active Directory. Создайте дополнительные подсети в контейнере Subnets (Подсети) в инструменте
Active Directory Sites And Services и свяжите подсети с новым сайтом. Каждый сайт должен иметь,
по крайней мере, один контроллер домена и GC-сервер. Чтобы переместить существующий
контроллер домена в сайт, вы можете щелкнуть правой кнопкой мыши на объекте контроллера
домена в его текущем контейнере Servers (Серверы) и выбрать Move (Переместить). Затем вам
будет предложен выбор сайта, в который вы хотите переместить контроллер домена. Если вы
устанавливаете новый контроллер домена, то он будет автоматически расположен в том сайте, в
котором подсеть IP соответствует IP-адресу контроллера домена. Возможно создание сайта без
контроллеров домена, но этого делать не следует.

Связи сайта
Соединения Active Directory, которые связывают сайты вместе, называются связями сайта (Site
Links). При инсталляции Active Directory создается единственная связь сайта с именем
DEFAULTIPSITELINK. Если вы не создадите никаких дополнительных связей сайта прежде, чем
создадите дополнительные сайты, то каждый сайт включается в эту заданную по умолчанию связь
сайта. Если WAN-связи между офисами вашей компании одинаковы по пропускной способности и
стоимости, вы можете просто принять это заданное по умолчанию поведение. Если все сайты
соединены одной связью, трафик репликации между ними будет иметь одинаковые свойства. При
изменениях в связи сайта конфигурация репликации для всех сайтов будет изменена. Если вы
хотите иметь возможность по-разному управлять репликацией между сайтами, вы должны создать
дополнительные связи сайта и назначить им соответствующие сайты.
Создание связей сайта не заменяет работу ISTG. При этом происходит лишь создание
возможностей для работы ISTG. Как только связь сайта установлена, ISTG будет использовать ее
для создания необходимых объектов связи, предназначенных для репликации всех разделов Active
Directory между всеми сайтами.
Ниже приведены опции конфигурации для всех связей сайта.
• Стоимость (Cost) - это назначенное администратором значение, которое определяет
относительную стоимость связи сайта. Стоимость обычно отражает скорость сетевой
передачи и расходы, связанные с ее использованием. Стоимость становится важным
параметром, если в организации имеются избыточные связи сайта, т.е. более одного пути
для репликации между двумя сайтами. Во всех случаях в качестве пути репликации
выбирается маршрут самой низкой стоимости.
• График репликации (Replication schedule) — определяет, в какое время в течение дня
связь сайта доступна для репликации. Заданный по умолчанию график репликации
разрешает репликации в течение 24 часов в день. Однако если пропускная способность
пути к сайту ограничена, репликация может происходить только в нерабочие часы.
• Интервал репликации (Replication interval) - определяет интервалы времени, через
которые серверы-плацдармы проверяют появление модификаций каталога на серверах-
плацдармах других сайтов. По умолчанию интервал репликации для связей сайта
установлен на 180 минут. Интервал репликации применяется только в соответствии с
графиком репликации. Если график репликации сконфигурирован так, чтобы позволять
репликации с 22:00 до 5:00 по умолчанию, то серверы-плацдармы проверяют модификации
через каждые 3 часа в этом промежутке времени.
• Транспортные протоколы репликации (Replication transports). Для передачи
репликации связь сайта может использовать или RPC по IP, или SMTP. Дополнительную
 информацию смотрите в разделе «Протоколы транспортировки репликации» далее в этой
главе. Эти опции обеспечивают существенную гибкость в конфигурировании репликации
между сайтами. Однако существуют также некоторые ошибки, которых следует избегать.
Чтобы понять, как эти опции работают вместе, рассмотрите сеть компании, показанную на
рисунке 4-11.
В Active Directory Windows Server 2003 все связи сайта считаются транзитивными (transitive) по
умолчанию. Как показано на рисунке 4-11, Sitel имеет связи с сайтами Site2 и Site4, a Site2 имеет
связь с сайтами Site3 и Site5. Из-за транзитивной природы связей сайта это означает, что Sitel
может также реплицировать информацию напрямую с сайтами Site3 и Site5.
Стоимость связей сайта определяет путь, по которому будет происходить трафик репликации по
сети. Когда КСС создает топологию маршрутизации, он использует накопленную информацию о
стоимости всех связей сайта для вычисления оптимальной маршрутизации. В примере,
показанном на рисунке 4-11, есть два возможных маршрута между сайтами Sitel и Site5: первый
маршрут — через Site2, второй маршрут — через Site4. Стоимость передачи через Site2 - 300 (100
+ 200), стоимость передачи через Site4 — 700 (500 + 200). Это означает, что весь трафик
репликации будет направляться через Site 2, если это подключение функционирует.

Рис. 4-11. Конфигурация связи сайта

Когда трафик репликации проходит по нескольким связям сайта, графики связей сайта и
интервалы репликации объединяются для определения эффективного окна репликации и
интервала. Например, эффективная репликация между сайтами Site1 и Site3 будет происходить
только с 24:00 до 4:00 (это время перекрытия графиков) каждые 60 минут (интервал репликации
для связи Site2-Site3).
Примечание. Если графики связей сайта не перекрываются, то между несколькими сайтами
репликация все-таки возможна. Например, если связь Sitel-Site2 доступна с 2:00 до 6:00, а связь
Site2-Site3 доступна от 22:00 до 1:00, изменения каталога от сайта Sitel к сайту Site3 смогут
передаваться. Изменения будут посланы от сайта Sitel к Site2, а затем от сайта Site2 к сайту
Site3. Однако в этом случае время ожидания репликации составило бы почти целый день, потому
что изменения, реплицированные на Site2 в 2:00, не будут реплицироваться на Site3 до 22:00.

Мосты связей сайта

В некоторых случаях вы можете отменить транзитивный характер связей сайта и вручную
сконфигурировать мосты связей сайта (site link bridges). При конфигурировании мостов связей
сайта вы определяете, какие из связей сайта должны рассматриваться как транзитивные, а какие -
нет. Отмена транзитивного характера связей сайта может быть полезной, когда у вас нет
полностью трассированной сети, т.е. не все сегменты сети доступны (на-
пример, если для подключения к одной из частей сети вы используете модемную связь, или связь
осуществляется по запросам согласно графику). Мосты связей сайта могут также использоваться
для конфигурирования репликации в ситуациях, когда компания имеет несколько сайтов,
связанных с высокоскоростной базовой сетью, и несколько меньших сайтов, которые соединяются
с каждым крупным центром через медленные соединения. В этих случаях мосты связей сайта
можно использовать для более эффективного управления потоком трафика репликации.
Дополнительная информация. В главе 5 приводится подробная информация о том, когда и
как следует использовать мосты связей сайта.
При создании моста связей вы должны определить, какая связь сайта является частью моста.
Любые связи сайта, которые вы добавляете к мосту связей сайта, рассматриваются по отношению
друг к другу как транзитивные; связи сайта, не включенные в мост связей сайта, транзитивными
не являются. В примере, рассмотренном выше, мост связей сайта можно создать для связей,
соединяющих Site1, Site2, Site4 и Site5. Тогда все эти связи сайтов считались бы транзитивными,
что означает, что сервер-плацдарм сайта Sitel мог бы напрямую обмениваться репликами с
сервером-плацдармом сайта Site5. Но так как связь от сайта Site2 к сайту Site3 не включена в мост
связей, она не является транзитивной. Трафик репликации от сайта Site3 направляется к сайту
Site2, а оттуда к другим сайтам.
Чтобы выключить транзитивные связи сайта, очистите опцию Bridge All Site Links (Все сетевые
связи объединены в мост) на вкладке General (Общие) окна IP-Properties (Свойства IP). Объект IP
расположен в контейнере Inter-Site Transports (Средства передачи между сайтами) в инструменте
администрирования Active Directory Sites And Services. Будьте осторожны, выполняя это действие,
поскольку теперь вы должны будете сконфигурировать мосты связей сайта для всех сайтов, если
захотите установить транзитивные связи сайта.

Транспортные протоколы репликации

Active Directory Windows Server 2003 может использовать один из трех различных методов
транспортировки репликации.
• Использование RPC по IP при внутрисайтовой репликации. Все подключения репликации в
пределах сайта должны использовать подключение RPC no IP. Это подключение является синхронным,
т.е. контроллер домена может в каждый момент времени обмениваться репликой только с одним
партнером по репликации. RPC-подключение использует динамическое назначение портов (dynamic port
mapping). Первое RPC-подключение выполняется через порт преобразователя конечного узла RPC (RPC
endpoint mapper port) (IP порт 135). Это подключение применяется для определения порта, который
использует контроллер-адресат для репликации.
Совет. Если вы реплицируете информацию каталога через брандмауэр или используете
маршрутизаторы с включенной функцией фильтрации портов, вы можете определить номер
порта, используемый контроллерами домена для репликации. Чтобы сделать это, создайте ключ
системного реестра со значением типа DWORD и укажите любой допустимый номер порта:
HKEY_LO-CAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\ Parameters\TCP/IP Port.
• Использование RPC no IP при межсайтовой репликации. Это RPC-подключение
отличается от межсайтового подключения только тем, что по умолчанию весь трафик,
передаваемый между сайтами, сжат.
Примечание. Если вы рассмотрите два типа подключений RPC по IP в инструменте
администрирования Active Directory Sites And Services, то заметите, что они по-разному
идентифицированы в интерфейсе. RPC no IP в пределах сайта называется RPC, a RPC no IP
между сайтами называется IP.
• Использование SMTP при межсайтовой репликации. SMTP может оказаться хорошим
выбором в методике репликации, если вы не имеете постоянной и быстрой связи между
офисами компании. SMTP использует асинхронное подключение, т.е. контроллер домена
может выполнять репликации с несколькими серверами одновременно. Однако использование
SMTP имеет некоторые ограничения. Во-первых, SMTP может использоваться только для
репликации информации между контроллерами домена, расположенными в различных
доменах. С помощью протокола SMTP можно реплицировать только раздел конфигурации
каталога, раздел схемы каталога и раздел GC. Во вторых, репликация по протоколу SMTP
требует, чтобы компонент SMTP в информационных службах интернета (IIS) был установлен
на всех контроллерах домена, которые будут использовать SMTP для репликации. Третье
ограничение состоит в том, в организации необходимо установить Microsoft Certificate
Authority (MCA) (Полномочие на выдачу сертификатов). Сертификаты от МСА используются
для цифровых подписей к сообщениям SMTP, которые посылаются между контроллерами
домена.
Конфигурирование серверов-плацдармов
Как уже говорилось выше, репликация между сайтами выполняется через серверы-плацдармы. По
умолчанию генератор межсайтовой топологии (ISTG - Inter-Site Topology Generator)
автоматически идентифицирует сервер-плацдарм при вычислении топологии репликации между
сайтами. Чтобы узнать, какие контроллеры домена используются в качестве серверов-плацдармов,
можно использовать Replication Monitor
(Монитор репликации). Щелкните правой кнопкой мыши на имени сервера, который
контролируется монитором репликации, и выберите Show Bridgehead Servers (Показать серверы-
плацдармы). Вы можете выбрать серверы-плацдармы: только для сайта, которому принадлежит
данный сервер, или для всего предприятия. Вы можете также просмотреть серверы-плацдармы
через инструмент Repadmin. Откройте окно с командной строкой и напечатайте repadmin
/bridgeheads.
В некоторых случаях необходимо управлять тем, какие контроллеры домена будут использоваться
в качестве серверов-плацдармов. Работа сервера-плацдарма может добавлять существенную
нагрузку на контроллер домена, если имеется много изменений информации каталога и
установлено частое проведение репликации. Для конфигурирования серверов-плацдармов нужно
получить доступ к объектам в инструменте администрирования Active Directory Sites And Services,
щелкнуть правой кнопкой мыши на имени сервера, а затем выбрать Properties (Свойства) (см. рис.
4-12). Вы получите доступ к опции конфигурирования сервера как привилегированного (preferred)
сервера-плацдарма для передачи данных по SMTP или по IP.

Рис. 4-12. Конфигурирование привилегированного сервера-плацдарма

Преимущество конфигурирования привилегированных серверов-плацдармов состоит в гарантии

того, что серверами-плацдармами будут выбраны контроллеры домена, указанные вами. Если вы
захотите контролировать то, какие серверы используются в качестве серверов-плацдармов, вы
должны сконфигурировать привилегированный сервер-плацдарм для каждого раздела, который
нужно реплицировать в сайт. Например, если сайт содержит реплики раздела каталога домена
Contoso.com, раздела каталога домена Fabrikam.com, раздела GC и раздела приложений, вы
должны сконфигурировать, по крайней мере, один контроллер домена с репликой каждого из этих
разделов. Если вы этого не сделаете, то ISTG зарегистрирует
событие в журнале событий, а затем выберет привилегированный сервер-плацдарм для раздела.
Вы можете также сконфигурировать несколько привилегированных серверов-плацдармов, в этом
случае ISTG выберет в качестве сервера-плацдарма один из указанных серверов.
Конфигурирование привилегированных серверов-плацдармов ограничивает возможности ISTG
выбирать сервер-плацдарм, т.е. всегда будет выбираться сервер, который сконфигурирован как
привилегированный. Если этот сервер не будет работать и другие серверы не будут назначены в
качестве серверов-плацдармов для данного раздела каталога, то ISTG не будет выбирать другой
сервер-плацдарм, и репликации прекратятся до тех пор, пока сервер не будет снова доступен или
пока вы не переконфигурируете опцию привилегированных серверов-плацдармов. Если
привилегированный сервер-плацдарм не работает, вы можете или удалить этот сервер из
привилегированных и позволить ISTG самому назначать сервер-плацдарм, или выбрать другой
привилегированный сервер-плацдарм.
Предостережение. Если привилегированный сервер-плацдарм не работает, и вы решите его
переконфигурировать, то изменения нужно делать в обоих сайтах. Поскольку серверы-
плацдармы не функционируют, то никакая информация не будет реплицироваться между
сайтами до тех пор, пока конфигурационные изменения не будут сделаны в обоих сайтах.

Мониторинг и поиск неисправностей

репликации
Одно из наиболее полезных инструментальных средств, предназначенных для мониторинга и
поиска неисправностей репликации, — это Replication Monitor (Монитор репликации). Он
устанавливается как часть файла Suptools.msi из каталога Support\Tools с компакт-диска Windows
Server 2003. Чтобы запустить Replication Monitor, в командной строке напечатайте replmon.
Монитор репликации открывается с пустым инструментом управления. Перед началом работы
щелкните на Edit в строке меню, чтобы добавить один или более серверов к списку
контролируемых серверов. Как только серверы добавлены в список, вы можете управлять почти
всеми аспектами репликации Active Directory. Например, отслеживать текущее состояние
репликации, последнюю успешную репликацию или любые отказы при репликации; вынуждать
репликацию; вынуждать КСС к повторному вычислению топологии маршрутизации. Используя
инструмент мониторинга, вы можете контролировать репликации на всех контроллерах домена
вашей сети. Второй полезный инструмент мониторинга репликаций - Repadmin. Он также
устанавливается с помощью файла Suptools.msi. Чтобы запустить этот инструмент, в командной
строке напечатайте repadmin. Инструмент Repadmin обеспечивает такие же функциональные
возможное-
ти, как и Replication Monitor, но через интерфейс командной строки. Инструмент Repadmin
дополнительно позволяет изменять топологию репликации, добавляя объекты связи.
Примечание. Чтобы получить подробную информацию об использовании инструментов
Replication Monitor и Repadmin, откройте Help And Support Center (Центр информации и
поддержки). Далее в пункте Support Tasks (Задачи поддержки) щелкните на Tools (Сервис), а
затем щелкните на Windows Support Tools (Поддержка Windows). Вам будет представлен
алфавитный список всех инструментальных средств поддержки с информацией о том, когда
следует использовать каждый инструмент, а также инструкции о том, как им пользоваться.
Вы можете запускать инструментальные средства непосредственно из окна Help And Support
Center.
Существуют два стандартных средства администрирования серверов для мониторинга и поиска
неисправностей репликации. Первый инструмент -Event Viewer (Средство просмотра событий).
Журнал событий Directory Service (Служба каталога) — это один из журналов регистрации
событий, который добавляется ко всем контроллерам домена. Большая часть событий, связанных с
репликацией каталога, записывается в него, и это первое место, которое вы должны просмотреть
при возникновении сбоя при репликации. Инструмент администрирования Performance
(Производительность) полезен для контроля деятельности, связанной с репликацией, которая
происходит на сервере. Когда сервер назначается контроллером домена, то к списку счетчиков
производительности добавляется объект NTDS Performance. Счетчики производительности можно
использовать для контроля объема трафика репликации, а также другой деятельности, связанной с
Active Directory.
Совет. Если вы заметите отказы в репликации Active Directory между контроллерами домена,
то первое, что нужно проверить -это DNS. Без правильного функционирования инфраструктуры
DNS репликация не будет работать.

Резюме
Ключевым аспектом управления службой Active Directory Windows Server 2003 является
понимание того, как работает репликация. Устойчивая среда репликации необходима для
поддержания новейших копий всей информации каталога на всех контроллерах домена в лесу, что
необходимо для гарантии согласованного входа пользователей в систему и функционирования
поиска в каталоге. В этой главе было дано описание работы репликации каталога: создание
топологии репликации между контроллерами домена Active Directory в одном сайте и между
контроллерами домена, расположенными в разных сайтах, описание самого процесса репликации,
принципов ее оптимизации для уменьшения объема сетевого трафика.
Часть II. Реализация службы Active
Directory Windows Server 2003
Задача авторов при написании части I данной книги состояла в том, чтобы помочь вам понять
работу службы каталога Active Directory Microsoft Windows Server 2003. Часть II поможет вам
реализовать Active Directory. Первый шаг в этом направлении состоит в создании архитектуры
Active Directory для вашей организации. Структуры леса, домена, сайта и организационной
единицы (OU) уникальны для каждой компании, поэтому разработка правильного проекта для
вашей среды потребует знаний и усилий. В главе 5 приводится краткий обзор процесса
проектирования. Как только вы создадите свою модель Active Directory, можно начать ее
установку. Глава 6 содержит описание процедур, необходимых для развертывания Active
Directory. Многие компании, реализующие Active Directory Windows Server 2003, переходят к ней
от Microsoft Windows NT 4. Поскольку Active Directory Windows Server 2003 сильно отличается от
службы каталога Windows NT, этот переход достаточно сложен и является главной темой главы 7.

Глава 5. Проектирование структуры Active

Directory
Развертывание службы каталога Active Directory в Microsoft Windows Server 2003 требует
планирования и проектирования. Служба Active Directory может быть развернута в организации
любого размера, включая большие многонациональные корпорации с сотнями тысяч
пользователей и офисов по всему миру. Создание модели Active Directory для корпорации такого
размера требует больших усилий. Однако даже более мелкие компании извлекают значительную
выгоду от времени, потраченного на начальное проектирование.
В этой главе дается краткий обзор процесса планирования, через который вы должны пройти,
прежде чем начать развертывание Active Directory Windows Server 2003. Предполагается, что вы
работаете в большой корпорации, имеющей несколько подразделений и офисов. Если вы
работаете в более мелкой компании, многие из концепций, обсуждаемых здесь, будут применимы
и к ней.
Эта глава начинается с самого главного вопроса — сколько лесов требуется для вашей сети. Затем
обсуждается разбиение лесов на домены и планирование доменного пространства имен. Как
только вы разберетесь с доменами, вы должны создать структуру организационных единиц (OU)
для каждого домена, а затем сконфигурировать сайты.
Примечание. Проектирование инфраструктуры Active Directory Windows Server 2003
незначительно отличается от проектирования инфраструктуры Active Directory Microsoft
Windows 2000. Windows Server 2003 содержит некоторые нововведения по сравнению с Windows
2000, но основные концепции Active Directory не изменились. Поэтому в данной главе
предполагается, что в настоящее время у вас нет развернутой Active Directory Windows 2000, но
вы переходите к Active Directory от Microsoft Windows NT 4 или другой службы каталога.

Проектирование структуры леса

Самое главное решение, которое вы должны принять на раннем этапе разработки, - сколько лесов
вам потребуется. Развертывание единствен-
ного леса Active Directory означает, что будет возможно простое совместное использование
ресурсов и доступ к информации в пределах компании. Использование единственного леса для
большой корпорации требует высокой степени доверия между разнообразными и, возможно,
разъединенными деловыми подразделениями. В конечном счете, количество развертываемых
лесов зависит от того, что является наиболее важным для вашей компании: легкость совместного
использования информации в пределах всех доменов леса или поддержка полностью автономного
и изолированного управление частями структуры каталога.
Практический опыт. Участие бизнес-заказчиков в проектировании Active
Directory
Когда вы проектируете Active Directory для корпорации, важно вовлечь управление
компании в этот процесс. Пользователи-бизнесмены являются основными
потребителями услуг, которые обеспечивает инфраструктура информационных
технологий (IT), поэтому необходимо, чтобы ваш проект удовлетворял их
требованиям и имел поддержку со стороны руководства.
Степень участия деловых подразделений в проектировании сильно зависит от
компаний. Практически в каждой организации она выражается, по крайней мере, в
одобрении высокоуровневых задач проекта. Эти задачи касаются вопросов
доступности информации, безопасности, простоты управления и практичности.
Менеджеры обычно включаются в принятие решений, которые не могут быть
изменены сразу после развертывания. Среди этих решений — вопрос о том, сколько
лесов и доменов требуется сети и сколько должно быть развернуто доменных
пространств имен.

Леса и проект Active Directory

Лес Active Directory предназначен для того, чтобы быть отдельным самодостаточным модулем.
Внутри леса легко совместно использовать информацию и сотрудничать с другими
пользователями из того же самого подразделения. Однако действия одного человека могут
воздействовать на каждого члена леса. Проектируя самый высокий уровень инфраструктуры
Active Directory, вы должны решить, нужно ли вам развертывать один лес или несколько. Каждый
лес является интегрированным модулем, потому что он включает следующее.
• Глобальный каталог. Лес имеет один глобальный каталог (GC). Каталог GC облегчает поиск
объектов в любом домене леса и вход на любой домен леса независимо от того, на каком
домене зарегистрирована учетная запись пользователя.
• Раздел конфигурации каталога. Все контроллеры домена совместно используют один и тот
же раздел конфигурации каталога. Эта информация используется для оптимизации
репликации информации в пределах леса, для хранения приложений и информации Active
Directory, поддерживающей приложения, и для совместного использования информации с
помощью раздела приложений каталога.
• Доверительные отношения. Все домены в лесу связаны двухсторонними транзитивными
доверительными отношениями. Не существует никакой опции, позволяющей изменить это.
Примечание. Использования одного леса для облегчения сотрудничества можно рассмотреть на
примере Microsoft Exchange Server 2000. Граница леса является также границей организации в
Exchange Server 2000. Exchange Server 2000 хранит большую часть своей конфигурационной
информации в разделе конфигурации каталога, облегчая управление маршрутизацией сообщений в
пределах большой организации. Глобальный список адресов (GAL - Global Address List) состоит из
всех почтовых получателей в каталоге GC. Наличие единой организации Exchange Server 2000
желательно для большинства компаний. В пределах одной организации календарная информация
и общие папки доступны каждому, многие типы сотрудничества допускаются по умолчанию.
Как только вы развернете несколько лесов, многие из этих преимуществ будут потеряны или их
будет труднее конфигурировать.
В то время как служба Active Directory облегчает совместное использование информации, она
предписывает множество ограничений, которые требуют, чтобы различные подразделения в
компании сотрудничали различными способами. Эти ограничения включают следующее.
• Одна схема. Все домены в лесу используют одну схему. Это обстоятельство как будто
упрощает дело, но оно может быть одной из причин развертывания нескольких лесов в
корпорации. Если одно подразделение решает развертывать приложение, которое изменяет
схему, то это оказывает воздействие на все подразделения. Возможно, вам покажется, что
такое событие не будет иметь большого воздействия на всю службу, но оно может стать
непреодолимым, если двадцать подразделений решат, что им требуется развернуть
приложения, изменяющие схему. Каждая модификация схемы должна быть проверена для
гарантии того, что она не находится в противоречии с другими изменениями схемы. Это
потребует значительного времени и усилий.
 • Централизованное управление. Развертывание единственного леса означает, что
некоторые компоненты сетевого управления должны быть централизованы. Например,
единственная группа, обладающая правом изменять схему, — это группа Schema Admins
(Администраторы схемы). Единственная группа, обладающая правом добавлять и удалять
домены из леса, - это группа Enterprise Admins (Администраторы предприятия). Группа
Enterprise Admins автоматически добавляется к домену локальной группы Administrators
(Администраторы) на каждом контроллере домена в лесу. Для некоторых компаний этот
тип централизованной администрации неприемлем. Это относится к компаниям,
осуществляющим переход от Windows NT 4, которая не предписывают централизованное
управление между несколькими доменами.
• Политика управления изменениями. Поскольку изменения леса могут затрагивать
каждый домен и должны выполняться только централизованно, требуется четкая политика
управления изменениями.
• Доверенные администраторы. Развертывание одного леса требует определенной степени
доверия администраторам всех доменов. Любой администратор, обладающий правами
управления контроллером домена, может сделать такие изменения, которые затронут весь
лес. Это означает, что все администраторы доменов должны быть высоко доверенными
людьми.
Обдумывая вопрос, касающийся количества развертываемых лесов, вы должны оценить каждый
из этих факторов для определения своих собственных потребностей.

Один или несколько лесов

Как сказано выше, наиболее существенный вопрос, на который вам надо ответить при создании
вашего проекта, - будете ли вы иметь один лес или несколько лесов. Это решение должно быть
сделано перед началом развертывания, потому что после эту структуру очень трудно изменить. Не
существует одношагового процесса слияния лесов - вы должны переместить из старого леса все
объекты, которые нужны в новом лесу. Нет никакого простого способа разбить отдельный лес на
два. Вы должны создать отдельный лес, а затем перемещать объекты из одного леса в другой.
Почти все компании развертывают один лес. Для большинства компаний выгоды от
общедоступного каталога GC, встроенных доверительных отношений и общего раздела
конфигурации каталога более важны, чем поддержка полной независимости всех
административных ролей. При проектировании службы Active Directory ваш первый выбор
должен всегда состоять в развертывании одного леса. Предполагая это, будете готовы к тому, что,
возможно, вам придется поступить иначе.
Существуют очевидные ситуации, в которых несколько лесов являются наилучшим выбором для
компании.
• Некоторые компании не имеют высоких требований к сотрудничеству внутри компании. В
них подразделения работают независимо друг от друга, с небольшой потребностью обмена
информацией иначе, чем по электронной почте. Эти компании ничего не теряют,
развертывая несколько лесов.
• Некоторые компании требуют полного разделения сетевой информации. По юридическим
причинам или из соображений безопасности компании может потребоваться гарантия того,
что некоторая сетевая информация не будет доступна кому-либо за пределами данного
подразделения. По умолчанию информация одного леса невидима в другом лесу.
• Некоторым компаниям требуются несовместимые конфигурации схемы. Если две части
организации требуют уникальной схемы, потому что они развертывают приложения,
которые делают взаимно несовместимые изменения в схеме, то вы должны создавать
отдельные леса.
• Некоторые компании не могут договориться о централизованной политике
администрирования, о политиках для леса или об управлении изменениями схемы. В этом
случае нужно развернуть отдельные леса.
• Некоторые компании должны ограничить область доверительных отношений. В пределах
леса все домены совместно используют транзитивные доверительные отношения, и нет
никакой опции, которая позволяет нарушить их. Если ваша сетевая среда требует
конфигурации доверия, в которой не может быть двухсторонних транзитивных
 доверительных отношений между всеми доменами, вы должны использовать несколько
лесов.
Практический опыт. Вовлечение пользователей в проектирование леса
Немногие компании имеют технические причины для развертывания более одного
леса. Лес может содержать несколько доменов, в каждом из которых имеются сотни
тысяч объектов. Домены могут быть развернуты с несколькими пространствами
имен и с различным администрированием для каждого домена.
Однако как только вы представите сотрудникам, ответственным за принятие
решения в вашей организации, список требований для леса, например,
централизованное управление, общая схема или доверенные администраторы, вы
наверняка встретите сопротивление. Единственная серьезная причина, по которой
компании развертывают несколько лесов, — это политика компании или
неспособность различных отделов и подразделений выработать способ обращения
к централизованным компонентам управления лесом. В некоторых случаях
компания не может договориться о модификации леса или схемы. В других случаях
тот факт, что администратор одного домена может влиять на все другие домены
леса, означает, что один лес неприемлем. Это справедливо, когда множество
прежде независимых компаний должны теперь работать вместе из-за поглощения
или слияния компаний.
Отдельные леса могли бы быть хорошим выходом для некоторых из этих компаний,
но вы должны предупреждать ответственных за принятие решений о том, что они
потеряют, если будут настаивать на развертывании нескольких лесов.
Использование нескольких лесов означает, что каждый получает полную
автономию, а значит, будет гораздо труднее совместно пользоваться информацией
между деловыми подразделениями.
Для некоторых компаний развертывание нескольких лесов является привлекательным вариантом.
Однако это придает значительную сложность сетевой инфраструктуре. Возникает ряд проблем.
• Увеличение административных усилий, необходимых для управления сетью. По крайней
мере, один домен, а также конфигурация уровня леса должны управляться отдельно в
каждом лесу.
• Уменьшение способности пользователей к сотрудничеству. Один из примеров этого -
поиск ресурсов в сети. Пользователи не смогут искать GC-ресурсы в другом лесу и
должны быть обучены тому, как искать ресурсы, расположенные вне каталога GC.
• Дополнительные административные усилия, которые требуются для того, чтобы
пользователи могли обратиться к ресурсам другого леса. Администраторы должны
сконфигурировать доверительные отношения вместо использования встроенных. Если
какая-либо информация должна быть синхронизована между лесами, то это также надо
сконфигурировать.
Практический опыт. Административная автономия и административная
изоляция - за и против
Для некоторых компаний выбор между развертыванием одного или нескольких
лесов сведется к тому, нужна ли компании административная автономия или
административная изоляция между подразделениями. В Active Directory есть много
типов административной деятельности, включая конфигурирование служб каталога
(леса, размещения контроллеров домена, доменной системы имен) и управление
данными в службе каталога (объектами пользователей или групп, групповыми
политиками и т.д.)
Административная автономия означает, что вы имеете полный административный
контроль над некоторыми компонентами леса на уровне леса, домена или OU.
Однако это не подразумевает эксклюзивного управления. Например, вы имеете
возможность полностью управлять своим доменом, но группа Enterprise Admins
(Администраторы предприятия) также имеет административные разрешения на
управление вашим доменом.
Административная изоляция, с другой стороны, означает, что вы имеете
исключительный контроль над компонентом каталога. Если у вас административная
изоляция, то никто не сможет контролировать вашу часть леса, изменять
конфигурацию службы каталога или данные.
Служба Active Directory обеспечивает много способов достичь административной
автономии. Администраторы домена могут делать в нем все, что захотят.
Администраторам OU можно давать полные права создавать и управлять любыми
типами объектов в OU. Один лес в Active Directory проектируется для делегирования
администрирования и автономии.
Однако если вам требуется административная изоляция, единственный способ
достичь этого состоит в создании отдельных лесов. Причина этого частично связана
с тем, как разработана Active Directory. Группа Enterprise Admins автоматически
добавляется к местной группе Administrators каждого домена. Группа Domain Admins
(Администраторы домена) имеет полный административный контроль над каждым
объектом в домене и автоматически добавляется к группе Administrators на каждом
компьютере в домене. В то время как заданная по умолчанию конфигурация может
быть модифицирована, а группы могут быть удалены из административных групп
низшего уровня, администраторы более высокого уровня всегда могут
восстанавливать управление объектами низшего уровня. Это означает, что никакая
часть леса не является административно изолированной.
Другая причина того, что отдельный лес может быть необходим для
административной изоляции, состоит в возможности злонамеренных действий со
стороны администраторов в домене. Любой человек с административным доступом
к контроллеру домена может нарушить административную изоляцию любого другого
раздела в лесу. Администратор может устанавливать программное обеспечение на
контроллере домена, которое изменяет информацию каталога для всех доменов в
лесу. Администратор может изменять сёой собственный идентификатор защиты
(SID) так, чтобы казалось, что он является членом группы Enterprise Admins, а затем
использовать этот доступ, чтобы сделать изменения, касающиеся всего леса.
Аналогично, если пользователь может выключить и перезапустить контроллер
домена в режиме Directory Services Restore (Восстановление службы каталога), то
он сможет изменить информацию в Active Directory так, что это затронет весь лес.
Все контроллеры домена и разделы леса тесно связаны, и любое изменение,
сделанное на одном контроллере домена, будет реплицироваться на остальные
контроллеры домена. Нет никакой проверки законности реплицируемой
информации, есть только проверка при создании изменений к информации
каталога. Поэтому если злонамеренный администратор сумеет сделать изменение к
информации каталога, то все другие контроллеры домена получат реплицируемое
изменение без вопросов.
По этим причинам вы должны создать отдельные леса, если требуется
административная изоляция. В некоторых случаях вам может потребоваться полная
гарантия изоляции раздела каталога. В этом случае вы должны пойти на
увеличение административной работы и потерю простоты в сотрудничестве,
которые влечет за собой развертывание нескольких лесов.
Многие компании, однако, требуют административной автономии наряду с разумной
гарантией того, что администраторы из другого раздела леса не будут действовать
злонамеренно. Эта разумная гарантия может быть достигнута путем выполнения
следующих действий.
• Помещение только администраторов с высоким уровнем доверия в группы,
которые имеют административный контроль над контроллерами домена. Эти
группы включают группу Domain Admins (Администраторы домена), а также
локальные группы Administrators (Администраторы), Server Operators
(Операторы сервера) и Backup Operators (Операторы резервного
копирования). Административные задачи, которые не требуют доступа к
контроллерам домена, должны быть делегированы другим группам.
• Физическая защита контроллеров домена путем разрешения доступа к
серверам только администраторам, имеющим высокий уровень доверия.
• Аудит всех действий, выполняемых администраторами высокого уровня.
Администраторы высокого уровня должны входить в систему, используя
административную учетную запись, только при необходимости. Они должны иметь
обычные учетные записи пользователя для ежедневной работы.
Определение владельцев леса
Независимо от того, сколько развертывается лесов, для каждого леса вы должны
идентифицировать его владельцев. В технических терминах просто определить, кто является
владельцем леса. Группы Schema Admins (Администраторы схемы), Enterprise Admins
(Администраторы предприятия) и Domain Admins (Администраторы домена) в корневом домене
могут быть определены как владельцы леса, потому что они управляют теми изменениями,
которые могут быть сделаны в лесу. Это роли чисто технические, и люди в этих группах почти не
имеют окончательных полномочий на то, будут ли на самом деле сделаны модификации к лесу.
Например, группа Schema Admins может изменять схему, но член группы Schema Admins обычно
не имеет полномочий для принятия заключительного решения относительно того, будет ли запрос
на изменение схемы одобрен.
Владельцы леса должны обладать комбинацией технической компетенции и понимания бизнеса.
Они должны быть людьми, которые знают общие деловые требования организации и в то же
время понимают техническое значение выполнения всех этих требований. Владельцы леса могут
решить, что будет развернуто приложение, изменяющее схему, потому что оно принесет
значительную деловую пользу компании, а затем администратору схемы дают задание изменить
схему так, как это требуется.
В компании с несколькими деловыми подразделениями группа владельцев леса должна состоять
из представителей всех подразделений. Это важно для эффективного функционирования, т.е.
представители группы должны находиться на рабочем месте, чтобы группа могла быстро принять
решение о реализации изменений уровня леса. Если реализация глобальных изменений будет
занимать много времени, то отдельные подразделения могут пожалеть, что они вообще
согласились на развертывание единственного леса.

Политика управления изменениями леса

Первая задача для владельцев леса состоит в определении политики управления изменениями
леса. Это политика определяет то, какие изменения могут быть сделаны к конфигурации уровня
леса и при каких обстоятельствах. Существует два типа изменений леса: изменения схемы и
изменения раздела конфигурации каталога (например, добавление или удаление доменов и
разделов приложений каталога, изменение конфигурации сайта).
Политика управления изменениями леса также определяет процедуры тестирования, одобрения и
реализации любых изменений леса. Это важно для изменений схемы, поскольку их нелегко
восстановить, поэтому любое изменение схемы должно быть совместимо со всеми другими
изменениями. Политика управления изменениями леса должна определить процедуру
тестирования изменений схемы, и владельцы леса должны поддерживать испытательную
лабораторию для тестирования этих изменений. Политика управления изменениями леса должна
требовать полного испытания всех изменений уровня леса и гарантировать, что тестирование
закончится быстро. Если каждый запрос на изменение будет занимать много времени на
обработку, то уровень расстройства пользователей будет постоянно возрастать.
Политика управления изменениями леса должна быть сформирована прежде, чем вы начнете
развертывать Active Directory. В компаниях с разнообразными и обособленными деловыми
подразделениями пояснение этой политики может быть трудным делом и занять много времени,
но и после развертывания Active Directory делать это совсем не легче. Если деловые
подразделения не смогут договориться о политике управления изменениями леса перед
развертыванием, вы должны принять решение о развертывании нескольких лесов.

Проектирование доменной структуры

Как только вопрос о количестве развертываемых лесов улажен, необходимо определить доменную
структуру в пределах каждого из лесов. Ваша первая задача состоит в том, чтобы
задокументировать конфигурацию текущих служб каталога и определить, какая часть текущей
инфраструктуры может быть модернизирована, а какая должна быть реструктурирована или
заменена. Затем определяется потребное количество доменов и их иерархия.
Домены и проект Active Directory
Домены используются для разделения большого леса на более мелкие компоненты для целей
репликации или администрирования. Следующие характеристики домена крайне важны при
проектировании Active Directory.
• Граница репликации. Границы домена являются границами репликации для раздела
домена каталога и для информации домена, хранящейся в папке Sysvol на всех
контроллерах домена. В то время как другие разделы каталога (раздел схемы,
конфигурации и GC) реплицируются по всему лесу, раздел каталога домена реплицируется
только в пределах одного домена.
• Граница доступа к ресурсам. Границы домена являются также границами для доступа к
ресурсам. По умолчанию пользователи одного домена не могут обращаться к ресурсам,
расположенным в другом домене, если только им не будут явно даны соответствующие
разрешения.
• Границы политики безопасности. Некоторые политики безопасности могут быть
установлены только на уровне домена. Эти политики, такие как политика паролей,
политика блокировки учетных записей и политика билетов Kerberos, применяются ко всем
учетным записям домена.

Определение количества доменов

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

Выбор единственного домена

Для большинства компаний идеальный проект Active Directory Windows Server 2003 будет
включать множество более мелких доменов, чем имелись до этого в Windows NT. Для некоторых
компаний несколько доме-
нов Windows NT могут объединиться в единственный домен Active Directory. Многие из
ограничений, которые приводили к необходимости развертывания нескольких доменов в Windows
NT, были устранены в Windows Server 2003. Следующие факторы делают развертывание
единственного домена реальной возможностью для многих компаний, имеющих несколько
доменов в Windows NT.
Практический опыт. Конфигурация текущего каталога и проектирование
Active Directory
Важным требованием при проектировании Active Directory является баланс между
оптимальной структурой сети и тем, что уже развернуто к настоящему моменту.
Всякий раз, когда вы готовитесь к созданию проекта Active Directory, необходимо
рассмотреть уже имеющуюся инфраструктуру и последствия перехода к Active
Directory. Если ваша текущая служба каталога состоит из доменов Windows NT 4, вы
должны собрать информацию об имеющихся доменах и рассмотреть последствия
обновления их до Active Directory Windows Server 2003. Текущая доменная структура
может не быть идеальной для ее обновления до Active Directory. Однако
модернизировать ее значительно легче и дешевле, чем создать идеальную
структуру Active Directory, а затем переместить все объекты домена в новые
домены. Возможно, что вам придется работать не с идеальной структурой Active
Directory, потому что вы будете модернизировать текущие домены. Может
выясниться, что текущая структура настолько далека от идеальной, что
дополнительная работа и стоимость по реструктурированию всех доменов будет
оправдана. Вероятно также, что текущая структура окажется почти приемлемой, но
вы захотите сделать в ней некоторые изменения. В этом случае вы можете
модернизировать один или несколько доменов и затем присоединить другие
домены к модернизированным.
Готовясь к проектированию своей службы Active Directory, вы сначала создадите
идеальный проект Active Directory, а затем еще один, основанный на оптимальном
 сценарии обновления текущей среды. Очень вероятно, что ваша окончательная
модель окажется где-нибудь посередине.
Взаимодействие между идеальным и реальным проектом иллюстрирует другой
важный аспект проектирования Active Directory: проектирование почти всегда
представляет собой итерационный процесс. Вы можете начать проектирование,
имея в голове одну модель, и по мере сбора дополнительной информации, вам,
возможно, потребуется ее изменить. Когда вы начнете тестировать реализацию или
сценарии перехода, вероятно, проект Active Directory опять изменится.
Однако важно, чтобы некоторые части вашего проекта приняли окончательные
формы прежде, чем вы начнете развертывание. Реализацию
сильно затрагивает решение о количестве лесов и доменов, а также
проектирование доменного пространства имен. Эти решения трудно изменить после
того, как развертывание началось. Другие решения типа финального проекта OU и
проекта сайтов легко изменить после развертывания.
Ограничения на размер базы данных в значительной степени были сняты в Active Directory, теперь
она может содержать несколько сотен тысяч объектов. Для всех, кроме самых больших, компаний
общее количество объектов в Active Directory не будет превышать возможное количество объектов
в домене.
Одна из причин создания дополнительных доменов в Windows NT состояла в том, чтобы
ограничивать или делегировать административный доступ. В Active Directory структура OU
создает иерархию в пределах домена, которая облегчает делегирование администрирования
определенным частям каталога и ограничивает административный доступ.
Если ваша компания часто реорганизуется, и пользователи передвигаются между деловыми
подразделениями, то перемещать их между OU в домене достаточно легко. Труднее перемещать
пользователей между доменами.
Управлять одним доменом легче в том отношении, что надо заботиться только об одном наборе
администраторов доменного уровня и одном наборе политик доменного уровня. Кроме того, вы
должны управлять только одним набором контроллеров домена.
Самый легкий сценарий для управления групповыми политиками — это среда отдельного домена.
Некоторые компоненты групповой политики хранятся в папке Sysvol на каждом контроллере
домена. Если вы имеете только один домен, групповая политика автоматически копируется на все
контроллеры домена.
Единственный домен является самой легкой средой для планирования аутентификации и доступа
к ресурсам. Имея единственный домен, вам не нужно беспокоиться о доверительных отношениях
или о назначении доступа к ресурсам для пользователей из других доменов.

Выбор нескольких доменов

В то время как модель единственного домена может быть идеальной для многих компаний,
большинство крупных компаний развертывают несколько доменов. Существует много серьезных
оснований для такого решения.
• Трафик репликации должен быть ограничен. Раздел каталога домена, который является
самым большим и наиболее часто изменяемым разделом каталога, копируется на все
контроллеры домена в домене. В некоторых случаях это может вызывать слишком
большой трафик репликации между офисами компании (даже если сконфигурировано
несколько сайтов).
• Этот выбор делается, если между офисами компании существуют медленные сетевые
подключения или если в офисах имеется много пользователей. Единственный способ
ограничить в этом случае трафик репликации состоит в том, чтобы создать
дополнительные домены.
• Любые офисы компании, связь между которыми обеспечивается только простым
протоколом передачи почты (SMTP), должны конфигурироваться как отдельные домены.
Информация домена не может реплицироваться через связи сайта, использующие
протокол SMTP.
• Единственный способ иметь различную политику паролей, политику блокировки учетных
записей и политику билетов Kerberos состоит в развертывании отдельных доменов.
• Если вам необходимо ограничивать доступа к ресурсам и иметь административные
 разрешения, вы захотите развернуть дополнительные домены. Для некоторых компаний
могут существовать юридические причины для создания отдельных
административных подразделений.
• В некоторых случаях дополнительные домены создаются потому, что лучший путь
перехода для организации состоит в модернизации нескольких уже имеющихся доменов.
Существуют серьезные основания для создания дополнительных доменов. Однако каждый
дополнительный домен увеличивает административные и финансовые издержки. Каждый
дополнительный домен требует дополнительных аппаратных средств и дополнительных
администраторов. Пользователи будут обращаться к ресурсам через доверительные отношения,
что означает большую сложность и потенциально большее количество мест возможного отказа.
Пользователи, путешествующие между доменами, должны подтверждать свои права доступа на
контроллер домена в своем домашнем домене. Из-за этих дополнительных затрат общее
количество доменов должно оставаться настолько малым, насколько это возможно.

Проектирование корневого домена леса

Другое важное решение, которое вы должны принять при проектировании службы Active Directory
большой компании, — действительно ли вы должны развернуть назначенный корневой домен
(называемый также пустым корнем). Назначенный корневой домен (dedicated root domain) -это
домен, который выполняет функции корневого домена леса. В этом домене нет никаких учетных
записей пользователей или ресурсов, за исключением тех, которые нужны для управления лесом.
Лес с назначенным корневым доменом показан на рисунке 5-1.
Для большинства компаний, развертывающих несколько доменов, настоятельно рекомендуется
иметь назначенный корневой домен. Корневой домен - это критический домен в структуре Active
Directory. Он содержит административные группы уровня леса (группы Enterprise
Admins и Schema Admins) и хозяев операций уровня леса (хозяина именования доменов и хозяина
схемы). Кроме того, корневой домен должен быть всегда доступен, когда пользователи входят на
другие домены, не являющиеся их домашними доменами, или когда пользователи обращаются к
ресурсам, расположенным в других доменах. Корневой домен нельзя заменять, если он разрушен,
его нельзя восстановить, вы должны заново построить весь лес.

Рис. 5-1. Лес с назначенным корневым доменом

Назначенным корневым доменом управлять легче, чем корневым доменом, содержащим много
объектов. Поскольку база данных каталога будет мала, достаточно просто поддерживать и
восстанавливать контроллеры корневого домена. Между контроллерами корневого домена
практически нет трафика репликации, так что не сложно расположить контроллеры домена в
нескольких офисах компании для гарантии избыточности. Это облегчит также перемещение
корневого домена в другое место. Использование назначенного корневого домена облегчает
ограничение членства в административных группах уровня леса. Назначенный корневой домен
никогда не устаревает, особенно если домену дают групповое (generic) имя.
По этим причинам большинство компаний, выбирающие несколько доменов, должны
развертывать назначенный корневой домен. Даже компании, планирующие только один домен,
должны рассмотреть преимущества, связанные с развертыванием назначенного корневого домена.
Назначенный корневой домен требует конфигурирования, которое не применяется к другим
доменам леса. Поскольку корневой домен содержит хозяина операций леса, контроллеры домена
для корневого домена должны быть защищены в максимально возможной степени. Домен леса
также содержит группы, которые могут изменять лес и схему. Члены административных групп в
корневом домене должны иметь более высокий уровень доверия, чем в случае с любым другим
доменом. Вы, вероятно, захотите использовать опцию Restricted Group (Ограниченная группа) в
политике Domain Security Policy (Политика безопасности домена) для управления членством этих
групп. Конфигурация DNS корневого домена должна быть настолько безопасной, насколько это
возможно. Поскольку установка в корневом домене какого-либо дополнительного компьютера
маловероятна, вы должны включить безопасные динамические обновления для корневого домена
зоны DNS на время инсталляции контроллеров домена, а затем динамические обновления для этой
зоны следует отключить.

Проектирование иерархии доменов

Как только проект корневого домена выполнен, нужно определить количество дополнительных
доменов и то, и как они впишутся в пространство имен DNS леса. Используйте рекомендации,
полученные ранее. Если текущая служба каталога - это служба для сети Windows NT, то для
определения количества доменов Windows Server 2003 вы должны исследовать уже имеющуюся
структуру доменов.
Многие крупные компании развернули домены Windows NT, используя модели с одним или
несколькими хозяевами домена, в которой одни домены содержали учетные записи пользователей
и глобальных групп, а другие — ресурсы компании. В некоторых случаях компании имели
дюжины доменов с учетными записями и сотни доменов с ресурсами. Часто домены учетных
записей были организованы вокруг географических регионов или деловых подразделений, и
каждый из них обычно имел один или несколько доменов ресурсов в пределах одного
географического региона или делового подразделения. На рисунке 5-2 показан пример того, как
может выглядеть конфигурация доменов.
Переходя к Active Directory, эти компании могут значительно уменьшить количество доменов.
Обычный путь обновления для многих состоит в модернизации доменов учетных записей.
Поскольку домены Active Directory могут содержать значительно больше объектов, в некоторых
случаях компания могла бы соединить несколько главных доменов учетных записей в один домен
Active Directory. Как только произойдет модернизация доменов учетных записей, можно
реструктурировать домены ресурсов, чтобы они стали организационными единицами в домене
Active Directory. Иногда домены ресурсов можно удалить. Например, некоторые компании имели
домены ресурсов для инфраструктуры Exchange Server 5.5. При переходе организации к Exchange
Server 2000 серверы могут быть развернуты в домене Active Directory. Когда последний сервер, на
котором выполняется Exchange Server 5.5, удаляется, домен Exchange можно также удалить. На
рисунке 5-3 показан возможный переход для компании, имеющей несколько доменов Windows NT
4.
Рис. 5-2. Типичная модель с несколькими хозяевами для доменов учетных записей и
ресурсов в системе Windows NT

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

Рис. 5-3. Обновление доменов Windows NT 4 до Active Directory Windows Server 2003

Деревья доменов и доверительные отношения

По мере добавления доменов к лесу вы можете делать это в конфигурации с несколькими
деревьями или в единственном дереве. Если вы добавляете домены в единственное дерево, то они
будут иметь смежное пространство имен, т.е. подпадать под пространство имен корневого домена.
Часто это является наилучшим проектом для централизованной корпорации, где все деловые
подразделения известны под одним именем. Однако если корпорация имеет несколько деловых
подразделений со своеобразными отличительными чертами, то может возникнуть значительное
сопротивление к использованию пространства имен другого делового подразделения. В этих
случаях вы должны добавлять домены в отдельные деревья, создавая, таким образом, несколько
пространств имен.
С функциональной точки зрения между развертыванием единственного дерева или нескольких
деревьев нет почти никакого различия. В
любом случае все домены совместно используют транзитивные доверительные отношения с
другими доменами, GC и конфигурационный контейнер. Главная сложность в использовании
нескольких деревьев состоит в разработке пространства имен DNS и конфигурации серверов DNS.
Но с появлением условных ретрансляторов (conditional forwarders) и сокращенных зон (stub zones)
эта процедура в Windows Server 2003 упростилась.
Если вы развертываете несколько доменов, и пользователи часто обращаются к ресурсам,
расположенным в других доменах или входят на них, вы, возможно, захотите добавить прямые
доверительные отношения (shortcut trusts) к проекту своего домена. Прямые доверительные
отношения используются для улучшения производительности при доступе к ресурсам или при
входе в систему с разных доменов. По умолчанию дове- • рительные отношения между доменами
в Active Directory являются или родительско-дочерними, или доверительными отношениями корня
дерева. Каждая родительско-дочерняя пара совместно использует двухсторонние доверительные
отношения, так же как и корни каждого дерева. Поскольку доверительные отношения
транзитивны, это означает, что все домены в лесу доверяют друг другу. Однако когда
пользователь входит в домен, не являющийся его домашним доменом, возможно, что процессу
входа в систему придется пересекать весь путь доверительных отношений. Например, корпорация
имеет структуру домена, показанную на рисунке 5-4. Если пользователь с учетной записью в
домене Asia.Fab-rikam.com входит в домен Canada.NAmerica.Contoso.com Contoso.com, то
начальный запрос входа в систему пойдет на контроллер домена в канадском домене. Запрос на
вход в систему должен ссылаться на доверительные отношения с доменом NAmerica, затем с
доменом Contoso, далее с доменом Fabrikam и, наконец, с доменом Asia. Прямые доверительные
отношения могут сокращать путь доверительных отношений. Например, если прямые
доверительные отношения сконфигурированы между доменами Canada и Asia, запрос на вход в
систему может быть отправлен контроллеру домена в домене Asia напрямую.
Совет. Поскольку прямые доверительные отношения добавляют дополнительные
административные накладные расходы, их нужно реализовывать только при необходимости.
Они будут нужны только в том случае, если путь взаимных доверительных отношений включает
более четырех или пяти доменов, если пользователи часто входят в систему или пользуются
ресурсами в других доменах, не являющихся их собственными.
Рис. 5-4. Прямые доверительные отношения могут использоваться для оптимизации
доступа к ресурсам разных доменов

Изменение иерархии доменов

Планирование доменов следует закончить перед началом развертывания, потому что доменную
конфигурацию трудно изменять после. Windows Server 2003 имеет возможность переименования
доменов в лесу, работающем на функциональном уровне Windows Server 2003. Можно
перемещать домен из одного дерева в другое в пределах леса, но нет возможности замены
корневого домена леса. По существу, возможность переименования домена позволяет вам
изменять структуру именования в лесу, но не позволяет делать более фундаментальные
изменения. Например, если вы решите изменить деловые подразделения в каждом домене, вы
должны переместить большое количество объектов между доменами. Для этого вы должны
использовать инструмент для переме-
щения Active Directory (ADMT - Active Directory Migration Tool v.2) или сторонние
инструментальные средства. Инструмент ADMT можно найти в папке /I386/ADMT на компакт-
диске Windows Server 2003.

Назначение владельцев домена

Для каждого из доменов, включенных в проект Active Directory, вы должны назначить владельца
домена. В большинстве случаев владельцы домена являются администраторами деловых
подразделений или географического региона, в котором был определен домен.
Примечание. Если вы развертываете назначенный корневой домен, владельцами этого домена
являются владельцы леса. Реальные функции, выполняемые в назначенном корневом домене — это
функции леса, так что имеет смысл владельцев леса назначать также владельцами корневого
домена.
Роль владельца домена состоит в управлении индивидуальным доменом. Эти задачи включают
следующее.
• Создание политик безопасности уровня домена. Это включает политику паролей,
политику блокировки учетных записей и политику билетов Kerberos.
 • Проектирование конфигурации Group Policy (Групповая политика) уровня домена.
Владелец домена может проектировать групповую политику для всего домена и
делегировать право связывать групповую политику с администратором уровня OU.
• Создание в домене OU-структуры высокого уровня. После создания OU-структуры
высокого уровня задача создания подчиненных OU может быть передана администраторам
уровня OU.
• Делегирование административных прав в пределах домена. Владелец домена должен
установить административную политику уровня домена (включая политики схем
именования, проекта групп и т.д.), а затем делегировать права администраторам уровня
OU.
• Управление административными группами уровня домена. Как уже говорилось,
администраторы в каждом домене должны иметь высокую степень доверия, потому что их
действия могут вызывать последствия на уровне леса. Роль владельца домена состоит в
ограничении членства административной группы уровня домена и в делегировании
административных прав низшего уровня всегда, когда это возможно.

Проектирование инфраструктуры DNS

Как только вы определились с количеством доменов и их иерархией, следующий шаг должен
состоять в проектировании инфраструктуры DNS для вашей сети. Служба Active Directory
Windows Server 2003 требует DNS, поскольку каждое имя домена теперь является частью
пространство имен DNS. Ключевое решение проекта состоит в том, чтобы определить, где
расположить домены Active Directory в пределах этого пространства имен. В дополнение к этому
вы должны также спроектировать конфигурацию сервера DNS. Если компания уже имеет свою
инфраструктуру DNS, то вам придется спроектировать свое пространство имен, чтобы вписаться в
текущее пространство имен, а также сконфигурировать DNS-серверы Windows Server 2003 для
взаимодействия с существующими серверами DNS.

Исследование существующей инфраструктуры DNS

Первый шаг в проектировании инфраструктуры DNS должен состоять в исследовании уже
имеющейся инфраструктуры DNS. В большинстве случаев служба DNS в Active Directory должна
взаимодействовать с имеющейся инфраструктурой DNS. Это может означать просто
конфигурирование ретранслятора в существующем сервере DNS, использование имеющегося
DNS-сервера как основного для Active Directory или отсутствие развертывания DNS в Windows
Server 2003. Active Directory требует, чтобы работала служба DNS, однако, существует несколько
вариантов ее развертывания.
Исследуя существующую инфраструктуру DNS, сделайте следующее.
• Задокументируйте все DNS-имена доменов, используемые в настоящее время в пределах
компании. Сюда входят имена, использующиеся в интернете, а также внутренние имена.
• Задокументируйте все дополнительные имена, которые компания зарегистрировала в
структурах власти интернета. Часто компания использует в интернете только имя .com,
можно также зарегистрировать и другие имена домена высшего уровня типа .net или .org.
Вы могли бы использовать одно из этих имен домена для вашего внутреннего
пространства имен.
• Задокументируйте существующую конфигурацию серверов DNS. Эта документация
должна включать типы DNS-серверов, в настоящее время развернутых в сети (например
DNS-серверы на базе Windows, BIND - Berkeley Internet Name Domain или Lucent
VitalQIP). Кроме того, конфигурация DNS должна содержать информацию о
ретрансляторах, о делегировании зон и о конфигурации основных и дополнительных
серверов.

Проектирование пространства имен

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

Использование одного и того же пространства имен в качестве внутреннего

и внешнего пространства
Некоторые компании захотят использовать одно и то же имя DNS и внутри, и снаружи. В этом
случае компания должна зарегистрировать только одно DNS-имя в интернете. Например, на
рисунке 5-5 показано, что компания Contoso могла бы использовать Contoso.com и внутри, и вне
компании.

Рис. 5-5. Использование единственного пространства имен DNS

Предостережение. Независимо от того, используете ли вы одинаковые или различные внутреннее
и внешнее пространства имен, ваш внутренний сервер DNS никогда не должен быть доступен
внешним клиентам. Внутренний DNS-сервер будет содержать все записи контроллера домена, а
также, по возможности, записи всех компьютеров в вашей сети (если вы включите динамическую
службу DNS - DDNS). Доступными из интернета должны быть только те записи, которые
касаются ресурсов, предназначенных для этого доступа. Для большинства компаний список
ресурсов, доступных извне, состоит из адресов серверов SMTP, Web-серверов и нескольких
других серверов. Использование одного пространства имен не подразумевает, что вы должны
использовать один DNS-сервер или зонный файл для внутренних и внешних задач.
Главное преимущество использования единого внутреннего и внешнего пространства имен
состоит в том, что оно обеспечивает согласование для конечного пользователя. Пользователь
всегда использует одно имя домена для подключения к общей сети. Адрес SMTP пользователя и
основное пользовательское имя (UPN) будут использовать одно и то же имя домена в качестве
публичного веб-сайта. Когда пользователю нужно обратиться к доступным ресурсам, он может
использовать одно имя и внутри, и снаружи (хотя он может обращаться к разным серверам).
Другое преимущество использования единого пространства имен состоит в том, что надо
регистрировать только одно DNS-имя.
Основные недостатки использования единого пространства имен связаны с безопасностью и
усилиями администраторов. Многие компании обеспокоены выставлением внутреннего имени
DNS в интернете и видят в этом потенциальный риск в ослаблении безопасности. Использование
единого внутреннего и внешнего пространства имен может усложнять администрирование DNS,
потому что администраторы DNS должны будут управлять двумя различными зонами, имеющими
одно и то же имя домена. Использование одного имени может также усложнить
конфигурирование клиента. Например, большинство прокси-клиентов конфигурируются так,
чтобы они интерпретировали определенные имена домена как внутренние, и клиент будет
подключаться к ним напрямую, минуя прокси-сервер. Использование одного имени может
усложнить этот процесс.

Использование различного внутреннего и внешнего пространства имен

Большинство компаний использует различные внутренние и внешние пространства имен.
Например, компания могла бы использовать Contoso.com как внешнее пространство имен и имя
Contoso.net или ADContoso.com для внутреннего пространства имен (см. рис. 5-6).
Примечание. Любое различие в именах домена означает, что внутри вы используете
пространство имен, отличающееся от внешнего. Например, если вы используете Contoso.com как
внешнее пространство имен, то Contoso.net, ADContoso.com и AD.Contoso.com — это разные
пространства имен. AD.Contoso.com потребует конфигурации DNS, отличной от двух других, и
все три пространства имен являются уникальными.

Рис. 5-6. Использование отдельных, внутреннего и внешнего, пространств имен

Часто уникальное внутреннее пространство имен выбирается из соображений безопасности, чтобы

предотвратить выставление внутреннего пространства имен в интернете. Кроме того,
конфигурирование DNS и прокси упрощается в значительной степени. Главное неудобство в
использовании уникального пространства имен состоит в том, что компания должна
регистрировать дополнительные имена DNS у властей интернета. Хотя регистрация не является
обязательным требованием, однако она рекомендуется. Если вы не зарегистрируете имя, а другая
компания зарегистрирует, то ваши пользователи не смогут искать в интернете ресурсы, имеющие
такое же имя домена как внутреннее пространство имен.

Варианты проекта пространства имен

Фактические имена, которые вы выбираете для своего пространства имен DNS, будут в
значительной степени определяться текущей инфраструктурой DNS. Если у вас нет установленной
инфраструктуры DNS (такой сценарий встречается в сетях Windows NT), и если вы уже
зарегистрировали имя домена, которое хотите использовать для Active Directory, ваш проект будет
довольно простым. Однако если инфраструктура DNS уже имеется и вы должны
взаимодействовать с этой средой, то проектирование DNS усложняется.
Если инфраструктуры DNS не существует, имеются одно или несколько имен домена второго
уровня, уже зарегистрированных для вашей компании, то проектировать пространство имен DNS
несложно. Вы можете выбрать зарегистрированное имя домена второго уровня в качестве имени
корневого домена, а затем делегировать дочерние имена домена для дополнительных доменов в
том же самом дереве или дополнительные имена доменов второго уровня для дополнительных
деревьев в лесу (см. рис. 5-7).
Рис. 5-7. Проект пространства имен DNS в отсутствие инфраструктуры DNS

Практический опыт. Внутреннее и внешнее пространства имен

Вопрос использования внутреннего пространства имен, отличного от внешнего,
может вызвать дискуссии в компании. В некоторых случаях лучше использовать
различные пространства имен, но владельцы компании могут оказывать сильное
сопротивление использованию чего-либо, отличного от пространства имен
интернета. Часто причина для этого — торговая марка; некоторые компании
потратили годы и миллионы долларов, создавая торговую марку, которую клиенты
хорошо знают, вебсайты компании и адреса SMTP для всех пользователей
отражают это пространство имен. Некоторые компании имеют признанные
обществом идентификаторы при наличии несколько деловых подразделений в
пределах компании, каждое из которых обладает собственной торговой маркой. В
большинстве случаев деловые пользователи не хотят показывать внешнему миру
имя, отличное от их распознаваемого имени компании. Хорошая новость состоит в
том, что вы можете использовать различные внутреннее и внешнее пространства
имен, а внешне поддерживать только одно пространство имен. Например, Contoso
мог бы использовать Contoso.net как внутреннее пространство имен и Contoso.com
как публичное пространство имен. Внутреннее пространство имен может быть
полностью скрыто от всех, кроме сетевых администраторов. Адреса SMTP для
пользователей могут быть alias@contoso.com, а веб-серверы могут использовать
веб-индекс Contoso.com. Если нужно, то UPN для пользователей может быть
сконфигурирован как alias@contoso.com, несмотря на использование другого
внутреннего пространства имен.
На рисунке 5-7 показано, как серверы DNS сконфигурированы по этому сценарию. DNS-сервер
Contoso.com является официальным (authoritative) для своего домена и содержит записи
делегирования на NAmerica.Contoso.com и Europe.Contoso.com, а также условные ретрансляторы и
сокращенные зоны для домена Fabrikam.com. DNS-сервер Fabrikam.com является официальным
для своей зоны и содержит условные ретрансляторы и сокращенные зоны для Contoso.com. Чтобы
разрешать адреса интернета, серверы корня дерева должны быть сконфигурированы с
ретранслятором, указывающим на сервер в интернете, или с корневыми ссылками интернета.
Проектирование DNS усложнится, если у вас есть внутренняя инфраструктура DNS. В этом случае
существуют три варианта для объединения с текущей инфраструктурой. Первый вариант состоит в
использовании только текущей инфраструктуры DNS для Active Directory, включая имя домена.
Например, Contoso может использовать Contoso.net как свое внутреннее пространство имен, а
DNS-серверы BIND — для обеспечения службы DNS. Компания может взять Contoso.net как имя
домена Active Directory и продолжать использовать текущие серверы DNS (при условии, что они
поддерживают SRV-записи указателей служб). В качестве альтернативы компания может
использовать то же имя домена, но переместить службу DNS на DNS-сервера, на которых
выполняется Windows Server 2003. В любом случае требуется очень небольшая реконфигурация
DNS-серверов. Серверы DNS могут продолжать использовать те же самые ретрансляторы или
корневые ссылки для разрешения имен в интернете.
Совет. При конфигурировании DNS серверов для разрешения имен интернета вы можете
использовать ретрансляторы или корневые ссылки. Использование ретрансляторов более
безопасно, так как можно сконфигурировать внутренний DNS-сервер на ретрансляцию к одному
или двум внешним DNS-серверам. Это может упростить конфигурацию брандмауэра.
Использование корневых ссылок приводит к лучшей избыточности, потому что вы удаляете
единственную точку возможного отказа. Если сервер из корневых ссылок не отвечает, DNS-
сервер просто войдет в контакт с другим.
Второй вариант при наличии инфраструктуры DNS состоит в выборе различных DNS-имен для
доменов Active Directory. Например, Contoso может использовать Contoso.net как текущее
внутреннее пространство имен DNS и развернуть домены Active Directory, использующие
AD.Contoso.net как имя домена (см. рис. 5-8).
В этом случае DNS-сервер разворачивается как основной сервер имен для AD.Contoso.net с
записями делегирования для NAmerica.AD. Contoso.net и Europe.AD.Contoso.net. Этот DNS-сервер
может быть тем же самым DNS-сервером, который является официальным сервером для
Contoso.net, или можно развернуть дополнительный DNS-сервер. Если вы развертываете
дополнительный DNS-сервер для домена Active Directory, необходимо сконфигурировать
ретрансляторы и корневые ссылки для него.
В третьем варианте при наличии инфраструктуры DNS домен Active Directory является дочерним
доменом от внутреннего пространства имен. Например, Contoso мог бы создавать поддомен
AD.Contoso.net как домен Active Directory (см. рис. 5-9). В этом случае DNS-сервер для Contoso.net
может быть сконфигурирован с записью делегирования для домена AD.Contoso.net. DNS-сервер
AD.Contoso.net может быть сконфигурирован с записью ретранслятора, указывающего на DNS-
сервер Contoso.net.
Наиболее сложный проект DNS, с которым вы когда-либо столкнетесь, возникнет в случае, если
компания решит скомбинировать все способы объединения DNS с внутренним пространством
имен. Например, на рисунке 5-10 показано, что компания, возможно, уже использует Contoso.net и
Fabrikam.net как внутренние пространства имен. Решив развернуть Active Directory, компания
может добавить дочерние домены под существующие, а также создать новое дерево доменов
NWTraders.net. С помощью сконфигурированных ретрансляторов и корневых ссылок DNS-
серверы могут разрешать любые имена DNS в организации.
Рис. 5-8. Конфигурирование DNS для использования отличающегося внутреннего
пространства имен
Рис. 5-9. Конфигурирование DNS путем добавления поддомена к существующему
внутреннему пространству имен

Однако это пространство имен DNS не определяет иерархию Active Directory. В примере на
рисунке 5-10 домен AD.Contoso.net может быть корневым доменом Active Directory с дочерними
доменами NAmerica.AD.Contoso.net и Europe.AD.Contoso.net и доменами AD.Fabrikam.net и
NWTraders.net, использующимися в качестве корневых доменов для дополнительных деревьев в
лесу Active Directory.
Рис. 5-10. Конфигурирование DNS путем добавления дочерних доменов к существующим
доменам

Интеграция с существующей инфраструктурой DNS

Практически все большие компании уже имеют установленную инфраструктуру DNS. Во многих
случаях DNS используется для разрешения имен серверов UNIX или для обеспечения потребности
пользователей в услугах DNS для доступа в интернет. Иногда услуги DNS обеспечиваются DNS-
серверами BIND, выполняющимися на UNIX-серверах. Поскольку существует зависимость
Windows NT от имен NetBIOS и от
службы имен интернета для Windows (WINS), в противоположность именам хостов и DNS, многие
Windows-администраторы мало касаются службы DNS. Ситуация изменилась с выпуском Active
Directory систем Windows 2000 и Windows Server 2003. В главе 3 говорилось о том, что Windows
Server 2003 требуется служба DNS для того, чтобы клиенты могли находить контроллеры домена.
Поэтому критическим моментом при обсуждении проекта Active Directory становится вопрос о
размещении службы DNS.
Для большинства компаний с существующей инфраструктурой DNS маловероятно, чтобы они
просто удалили текущую инфраструктуру и переместили все в Windows Server 2003.
Необходимость в службе DNS для Active Directory заставит вас организовать взаимодействие с
текущей инфраструктурой DNS.
Есть два варианта интеграции для случая, когда должна поддерживаться текущая BIND
инфраструктура DNS. Первый вариант состоит в том, чтобы использовать DNS-сервера не от
Microsoft и располагать на этих серверах необходимую для Active Directory информацию зон DNS.
Такая возможность, конечно, существует. Единственное требование для DNS - сервер должен
поддерживать записи SRV. Вы, вероятно, захотите, чтобы серверы DNS также поддерживали
динамические обновления (особенно, если вы планируете регистрировать все IP адреса клиентов в
DNS) и дополнительные (incremental) зонные передачи. Если текущая инфраструктура использует
BIND серверы DNS, серверы BIND 8.1.2 поддерживают записи SRV и динамические обновления.
Сервер BIND 8.2.1 поддерживает дополнительные зонные передачи. Если вы используете одну из
этих версий BIND, то вы можете продолжать использование DNS-серверов BIND. (Если вы
используете DNS-серверы Lucent VitalQIP, то версии 5.2 и более поздние совместимы с BIND
8.2.2.)
Практический опыт. Выбор сервера DNS
Вопрос о том, использовать ли DNS-серверы системы Windows Server 2003 или
DNS-серверы не от компании Microsoft, может вызвать горячую дискуссию и не
привести к удовлетворительному результату. Большие компании в течение многих
лет пользовались DNS-серверами BIND, DNS-администраторы грамотны, опытны и
не хотят переходить к службе DNS на платформе Microsoft. Они выражают
беспокойство по поводу стабильности, надежности и безопасности службы DNS на
серверах Microsoft.
Один из подходов к решению этого вопроса состоит в следующем: на самом деле не
имеет значения, чем обеспечивается DNS-служба. Пока DNS-серверы
поддерживают записи SRV, Active Directory Windows Server 2003 может работать с
любым сервером DNS. Критичным является то, что служба DNS всегда должна быть
доступной. Если она перестанет работать в рабочее время, клиенты или серверы не
смогут найти контроллера домена Active Directory. Поэтому вопрос можно поставить
так: «Какой DNS-сервер обеспечит надежность, необходимую для работы Active
Directory?».
Длинные дискуссии относительно надежности различных серверов, похоже, не
отражают сути дела. Никакой сервер в единственном числе никогда не может быть
полностью надежен, поэтому вопрос надо переформулировать так: «Какой DNS-
сервер обеспечит наилучшие варианты для устранения выделенных точек отказа и
распределения доступных служб между несколькими серверами?». Серверы
Windows Server 2003 реализуют превосходные варианты для обеспечения
надежности за счет нескольких серверов, особенно если используются
интегрированные зоны Active Directory. С помощью этих зон каждый DNS-сервер
может иметь перезаписываемую копию информации DNS. Интегрированные зоны
Active Directory также реализуют безопасные обновления.
Многие компании решили оставаться с DNS-серверами BIND, и эти серверы
обеспечили требуемые функциональные возможности без каких-либо проблем.
Некоторые компании решили переместить основной DNS в DNS-серверы Microsoft и
сохранить DNS-серверы BIND как дополнительные серверы имен. Любая из этих
конфигураций будет работать до тех пор, пока DNS-серверы доступны, и не имеет
значения, какой вариант использует компания.
Второй вариант объединения DNS Windows Server 2003 с BIND состоит в развертывании обоих
типов DNS. Многие компании используют DNS-серверы BIND как основной сервер имен для
внутреннего пространства имен. Например, компания Contoso может использовать BIND при
разрешении имен для Contoso.com. Если она решит развертывать Active Directory и использовать
DNS-сервер на базе Windows Server 2003, существует множество вариантов. Если компания
Contoso захочет использовать Contoso.com как DNS-имя Active Directory, она может переместить
основную зону на DNS-сервер на базе Windows Server 2003 и поддерживать DNS сервер BIND в
качестве дополнительного сервера имен. Или DNS-сервер на базе Windows Server 2003 мог бы
стать дополнительным сервером имен к DNS-серверу BIND.
Примечание. Вы можете использовать DNS-серверы BIND и DNS-серверы на базе Windows
Server 2003 для одного и того же пространства имен. Оба DNS-сервера могут работать как
основной или дополнительный сервер имен, содержащие зонную информацию друг для друга.
Однако если вы планируете использовать интегрированные зоны Active Directory, то DNS-зона
BIND должна быть сконфигурирована как дополнительная зона. Интегрированная зона Active
Directory не может быть дополнительной зоной.
Компания Contoso может развертывать Active Directory, используя доменные имена, отличные от
тех, которые уже используются на DNS-серверах BIND. Например, имя Contoso.net может
использоваться как DNS-имя Active Directory. В этом случае DNS-серверы на базе Windows Server
2003 могут быть сконфигурированы как официальные серверы для Contoso.net, а серверы BIND -
как официальные серверы для Contoso.com. DNS-серверы на базе Windows Server 2003 могут быть
сконфигурированы с условным ретранслятором на DNS-сервер BIND для Contoso.com. Домен
Active Directory можно развернуть также с использованием AD.Contoso.com в качестве имени
домена. В этом случае DNS-серверы BIND Contoso.com будут сконфигурированы с записью
делегирования, направляющей любой поиск для домена AD.Contoso.com на DNS Windows Server
2003. Серверы DNS системы Windows Server 2003 могут быть сконфигурированы с
ретранслятором, указывающим на DNS-сервер BIND.
Совет. В разделе этой главы, посвященном планированию пространства имен DNS, было
показано множество сценариев для развертывания пространства имен DNS. DNS-серверы, по
существу, взаимозаменяемы: любой из них может быть сервером BIND или сервером Windows
Server 2003. Теоретически возможно использование службы DNS Windows Server 2003 как хозяина
внешнего имени DNS, а службы DNS BIND — для доменов Active Directory.

Проектирование структуры организационной

единицы
Как только проектирование на уровне доменов закончено, следующий шаг состоит в создании
модели организационной единицы OU для каждого домена. В главе 2 говорилось, что OU
используются для создания иерархической структуры в пределах домена. Эта иерархия может
затем использоваться для делегирования административных задач или применения групповых
политик к совокупности объектов.

Организационные единицы и проектирование Active Directory

Домены Windows NT используют неразветвленное пространство имен, т.е. все объекты в домене
находятся на одном уровне. Нет никакого способа назначить административное управление одним
объектом в домене без того, чтобы установить тот же самый уровень управления надо всеми
другими объектами в каталоге. OU в Active Directory позволяют со-
здавать иерархию объектов в пределах отдельного домена. Используя OU, вы можете давать
административный контроль только над одной частью домена или даже предоставлять
ограниченный административный доступ к этой части.
Когда вы проектируете структуру OU, вы группируете объекты вместе с целью единообразного
управления этой группой. Например, можно установить общий набор приложений для всех
пользователей в определенном отделе. Группируя всех пользователей в OU, вы можете назначить
групповую политику (Group Policy), которая автоматически установит требуемое программное
обеспечение. Возможно, вы захотите сгруппировать объекты для назначения одного
администратора этой группе. Например, если имеется отдаленный офис с местным
администратором, можно создать OU, поместить всех пользователей и компьютеры отдаленного
офиса в это подразделение, а затем делегировать администрирование этой OU местному
администратору.
Организационные единицы характеризуются следующим.
• Проектировани OU не оказывает влияния на проектирование пространства имен DNS. OU
получают имена каталога в пределах пространства имен DNS. Например, организационная
единица может иметь отличительное имя OU=ManagersOU,OU=AdministrationOU,
DC=Contoso, DC=Com. В этом случае Contoso.com является DNS-име-нем, а LDAP-имена
внутри пространства имен DNS являются именами OU.
• Организационные единицы могут быть созданы внутри других единиц. По умолчанию
административные права и параметры настройки Group Policy (Групповая политика),
установленные на верхнем уровне единиц OU, наследуются дочерними OU. Это поведение
может быть изменено.
• Организационные единицы 0U прозрачны для конечных пользователей. Когда
пользователь ищет объект в Active Directory, приложение пользователя делает запрос об
этой информации к GC-каталогу. Пользователю не требуется знать структуру OU, чтобы
сделать вход в систему или найти объекты в Active Directory.
• По сравнению с другими компонентами Active Directory, такими как домены и леса,
структуру OU легко изменить после развертывания. Перемещение объектов между OU
 сводится к щелчку правой кнопкой мыши на объекте и выбору Move (Переместить) из
контекстного меню.

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

Проект OU, основанный на делегировании администрирования

Одна из причин создания структуры OU заключается в возможности делегирования
административных задач. Многие компании, которые соединили домены ресурсов Windows NT в
единственный домен Active Directory, возможно, захотят делегировать административные задачи,
которые обычно выполняли администраторы домена в домене ресурсов. Некоторые компании
имеют несколько офисов с локальными сетевыми администраторами в каждом, и они, возможно,
захотят делегировать администрирование каждому из этих офисов. Другие компании захотят
делегировать определенную административную задачу. Например, дать одному или двум
человекам в каждом отделе право сбрасывать пароли пользователей, а также изменять
информацию для всех пользователей отдела.
Все это становится возможными путем создания структуры OU в Active Directory и последующим
делегированием административного доступа. Возможно представление любого уровня
административного доступа на уровне OU. Если вы создаете OU для отдаленного офиса, вы
можете представить его администратору полное управление объектами этого офиса.
Администратор может выполнять любую административную задачу в этой OU, включая создание
дочерних OU и делегирова-
ние разрешений другим администраторам. Если вы создаете OU для каждого отдела, вы можете
предоставить очень специфические права, типа права сбрасывания паролей, нескольким
пользователям в отделе. Можно предоставить административные права, основанные на типах
объектов в OU, например, администраторы отдела могут изменять учетные записи пользователя,
но не объекты групп или компьютеров. В главе 9 содержится подробная информация о
делегировании администрирования. Следует прочесть эту главу перед созданием проекта OU.
Для большинства компаний организационные единицы высшего уровня будут разрабатываться на
основе требований, связанных с делегированием администрирования. Скорее всего, эти единицы
OU будут основаны на географическом месте расположения офисов компании или на деловых
подразделениях. Эти границы OU будут также и административными границами.

Проект 0U, основанный на проекте групповых политик

Вторая причина для создания OU заключается в управлении назначением групповых политик.
Групповые политики используется для изменения и управления конфигурацией рабочих столов. С
помощью групповых политик можно обеспечить пользователям стандартную конфигурацию
рабочего стола, включая автоматическую инсталляцию набора приложений. Групповая политика
может управлять изменениями, которые пользователи выполняют на своих компьютерах, и
конфигурировать параметры настройки защиты. Почти все групповые политики в Active Directory
назначаются на уровне OU, так что развертывание групповых политик будет играть важную роль в
проекте OU. При планировании структуры OU вы группируете вместе объекты, которые требуют
одинаковых параметров настройки групповой политики. Например, если всем пользователям
одного отдела требуется одинаковый набор приложений, их можно установить, используя
групповую политику. Пользователи могут нуждаться в стандартном наборе отображаемых дисков
(mapped drives). Сценарии входа в систему для пользователей можно назначить, также используя
групповую политику. Возможно, что вы захотите применить шаблон защиты ко всем файловым
серверам вашей организации. Чтобы сделать это, сгруппируйте все файловые серверы в OU и
назначьте шаблон защиты, используя групповую политику.
В большинстве компаний низкие требования к уровню проекта OU будут определяться, прежде
всего, потребностью применения групповой политики. По умолчанию все групповые политики
наследуются от родительских OU. Это означает, что вы можете применить групповую политику на
высоком уровне в структуре OU, а затем применить специфичную групповую политику на более
низком уровне. Если нужно изменить заданное по умолчанию наследование групповой политики,
это можно сделать, создав OU и заблокировав любое наследование групповой политики
на уровне OU. Такая зависимость проекта OU от групповых политик означает, что вы должны
понять функциональные возможности групповых политик и требования вашей организации. В
главах 11, 12, 13 подробно обсуждается, что можно делать с помощью групповых политик.

Создание проекта OU
Начните разрабатывать проект OU с организационных единиц высшего уровня. Их труднее
модифицировать после развертывания из-за OU, расположенных ниже. OU высшего уровня
должны основываться на чем-то неизменном: на географических регионах или деловых
подразделениях.
Проект OU, основанный на географии компании, вероятно, будет наиболее устойчив к
изменениям. Некоторые компании часто реорганизуются, но редко изменяют географическую
конфигурацию. Структура OU, основанная на географии компании, хорошо работает, если
компания использует децентрализованную административную модель, основанную также на
географии. Если каждое географическое место (один офис или центральный офис с несколькими
филиалами) имеет свой собственный набор сетевых администраторов, то географические OU
могут использоваться для делегирования административных задач этим администраторам.
Основной недостаток структуры OU, основанной на географии, проявляется тогда, когда
возникает несколько деловых подразделений в каждом географическом месте. Например, если
каждый отдел представлен в каждом офисе компании, более эффективно на высшем уровне
использовать структуру OU, основанную на деловых подразделениях.
Вторая структура OU высшего уровня основывается на деловых подразделениях. В этой модели
OU высшего уровня создается для каждого делового подразделения в пределах корпорации. Этот
тип конфигурации является наиболее подходящим, если компания находится в одном месте или
если многие административные задачи делегируются на уровень делового подразделения.
Проблема, которая может возникнуть, заключается в том, что OU высшего уровня изменятся в
случае реорганизации компании.
Большинство крупных корпораций фактически будут использовать комбинацию единиц,
основанных на географии и на деловых подразделениях. Обычная конфигурация - это OU высшего
уровня, основанные на географических регионах, со следующим уровнем OU в пределах каждого
региона, основанных на деловых подразделениях. Некоторые компании могут выбрать OU
высшего уровня, основанные на деловых подразделениях, а затем создавать под высшим уровнем
структуру OU, основанную на географии.
На рисунке 5-11 показан проект OU для крупной компании. OU высшего уровня включает Domain
Controllers OU (OU контроллеров домена) (все контроллеры домена расположены в этой OU) и OU
администраторов уровня домена. OU высшего уровня могут включать OU службы
учетных записей для всех служебных учетных записей (Service Account), используемых в домене.
Создание на высшем уровне OU для специальных учетных записей пользователей, таких как
служебные учетные записи, упрощает их администрирование. OU высшего уровня могут включать
OU серверов, если все серверы управляются централизованно. В дополнение к этим
административным OU могут быть также OU высшего уровня, основанные на географии
корпорации. Организационные единицы высшего уровня, основанные на географии, могут
использоваться для делегирования административных задач.

Рис. 5-11. Типовая структура OU

OU второго уровня в каждом географическом регионе основаны на деловых подразделениях

региона. OU бизнес-подразделений могли бы использоваться для делегирования
администрирования, а также для назначения групповых политик. Под деловыми OU
располагаются OU,
основанные на отделах. На этом уровне OU будет использоваться для назначения групповых
политик или определенных административных задач, типа права сброса паролей. OU отделов
могут содержать другие OU.
• OU учетных записей - содержит учетные записи пользователей и групп отдела. В
некоторых случаях OU учетных записей разбиваются на OU, содержащие группы, учетные
записи пользователей или удаленных пользователей.
• OU компьютеров - содержит все пользовательские компьютеры и включает отдельные
OU компьютеров с системой Windows NT, Windows 2000, Microsoft Windows XP
Professional и OU портативных компьютеров.
• OU ресурсов - содержит ресурсы, связанные с данной OU. Включает домены локальных
групп, серверы, принтеры и совместно используемые папки.
• OU приложений или проектов. Если группа людей и ресурсов работают над
определенным проектом (приложением), который требует уникального управления, можно
создать структуру OU для этих пользователей, а затем сгруппировать пользователей,
ресурсы и компьютеры, необходимые для данного проекта, в OU.
Совет. Теоретически, не существует ограничения на количество уровней, которое может иметь
ваша структура OU. Обычно практический опыт подсказывает, что не нужно иметь более
десяти уровней. Для большинства компаний структура OU, состоящая из четырех или пяти
уровней, — это все, что может когда-либо потребоваться.
Работая над созданием проекта OU, нужно его тщательно задокументировать. Проект будет
включать диаграмму структуры OU, список всех организационных единиц OU и цели каждого OU.
Если вы используете OU для делегирования административных задач, задокументируйте права,
делегированные каждому уровню OU. Развертывая групповую политику, связанную с каждым OU,
задокументируйте конфигурацию групповых политик.

Проектирование топологии сайта

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

Сайты и проектирование Active Directory

В Active Directory сайты представляют собой определенные организационные объекты и
используются для управления сетевым трафиком. Это осуществляется тремя способами.
• Трафик репликации между сайтами сжат, поэтому репликация между сайтами использует
полосу пропускания сети в меньшей степени, чем репликация в пределах сайта.
Выполнение репликации происходит в соответствии с расписанием для гарантии того, что
в это время сеть занята меньшим количеством других запросов.
• Трафик, связанный с входами клиентов в систему, останется в пределах сайта, если
доступен локальный контроллер домена.
• Приложения, учитывающие наличие службы Active Directory, подобные распределенной
файловой системе (DFS - Distributed File System), можно добавить к сети для ограничения
трафика, связанного с доступом клиентов к местному сайту.

Инфраструктура организации сети и проектирование сайта

Поскольку проектирование сайта сильно зависит от организационной инфраструктуры сети,
первый шаг в создании проекта состоит в документировании этой инфраструктуры.
Документирование должно включать:
• схемы топологии глобальной (WAN) и локальной сети (LAN), детализирующие сеть
корпорации, в которых содержится информация о полной пропускной способности и
доступной пропускной способности между всеми офисами компании;
• список всех офисов компании, в которых компьютеры связаны через высокоскоростные
сетевые соединения. Определение высокоскоростного подключения меняется в
зависимости от таких факторов, как количество пользователей в офисах компании, общее
количество объектов в домене и доменов в лесу. Кроме того, нужно определить, какая
часть из полной полосы пропускания сети доступна для репликации. В большинстве
случаев сетевые подключения в пределах сайта должны иметь скорость доступной полосы
пропускания 512 Кб/с. В крупной компании в качестве минимальной скорости сетевого
подключения в пределах сайта устанавливается скорость в 10 Мб/с;
• для каждого офиса компании уточните количество пользователей, компьютеров, серверов
и локальных подсетей IP.

Создание модели сайта

Как только информация о сети компании собрана, можно приступать к проектированию сайта. Для
начала исследуйте каждый офис компании, в котором компьютеры связаны через
высокоскоростные сетевые подключения. Сколько пользователей находится в каждом месте?
Достаточно их для того, чтобы там требовался контроллер домена? Каковы сетевые соединения от
этого офиса до других офисов компании?
Каждый сайт должен иметь контроллер домена, а большинство из них -и GC-сервер. Если вы
решаете, создавать ли сайт для офиса компании с несколькими пользователями и медленным
сетевым соединением, то на самом деле решается вопрос о том, нужен ли здесь контроллер
домена. Для этого определите, какой вариант приведет к наименьшему количеству сетевого
трафика. Что создаст большее количество трафика: входы клиентов на контроллер домена из
других офисов компании или трафик репликации между контроллерами домена? Для тяжелого
трафика нужно рассмотреть другие факторы. Если вы не поместите контроллер домена в данное
место, то следует рассмотреть возможность прерывания работы пользователей в случае отказа
сетевого подключения, потому что пользователи не смогут войти в домен. Если вы все равно
развертываете Windows Server 2003 в данном месте, то не может ли он быть также и контроллером
домена сайта?
Совет. Общее правило при проектировании Active Directory для компании состоит в том, что во
всем, кроме планирования сайтов, надо придерживаться максимально возможной простоты.
При планировании леса, домена или структуры OU простота должна быть одной из ваших
основных целей. Однако создание дополнительных сайтов для офисов компании, связанных
медленными WAN-подключениями, обеспечивает значительную выгоду без существенного
увеличения объема администрирования. Возможно, это единственный момент в проектировании
Active Directory, когда самое простое решение не может быть самым лучшим.
После определения количества сайтов для Active Directory создается проект каждого сайта.
Каждый сайт в Active Directory связан с одной или более подсетями IP, поэтому нужно
определить, какие подсети будут включены в каждый сайт. Если вы решите не развертывать
контроллер домена в каком-нибудь офисе компании, нужно определить, к какому сайту будет
принадлежать этот офис, и добавить эту подсеть IP к соответствующему сайту. В этом случае
клиенты, находящиеся в удаленном офисе, соединятся с ближайшими контроллерами домена.
После создания сайтов нужно сформировать топологию репликации для сайтов. Для этого
сконфигурируйте связи сайта между офисами компании. Для каждой связи сайта спланируйте
график и интервал репликации, а также стоимость связи сайта. Если вы хотите назначить серверы-
плацдармы (bridgehead servers) для репликации каждого сайта, идентифицируйте все разделы
Active Directory, которые будет расположены в сайте, и назначьте сервер-плацдарм для каждого
раздела.
Определение стоимости каждой из связей сайта усложнится, если имеется несколько возможных
маршрутов между офисами компании. В этом случае нужно назначить затраты для связей сайта
так, чтобы для репликации Active Directory использовался оптимальный маршрут. Один из
способов определения стоимости каждой связи сайта состоит в создании таблицы,
сопоставляющей сетевую пропускную способность связи со стоимостью связи. Пример показан в
таблице 5-1.

Табл. 5-1. Сопоставление сетевой пропускной способности со стоимостью связи сайта

Доступная пропускная способность Стоимость связи сайта
Больше или равно 10 Мб/с 10
От 10 Мб/с до 1,544 Мб/с 100
От 1,544 Мб/с до 512 Кб/с 200
От 512 Кб/с до128 Кб/с 400
От 128 Кб/с до 56 Кб/с 800
Меньше 56 Кб/с 2000

Используя информацию, приведенную в таблице 5-1, вы можете назначить стоимость каждой

связи сайта. Затем нужно вычислить, по какому маршруту пойдет трафик репликации, если все
связи доступны, и эффекты сетевых отказов связей. Если есть избыточные пути в пределах сети,
убедитесь, что стоимость связей сайта сконфигурирована так, чтобы в случае отказа связи был
выбран оптимальный резервный путь.
Управлять репликациями Active Directory можно также при помощи отключения мостов (site link
bridging) между связями сайта. В большинстве случаев мосты связей сайта выключать не нужно,
потому что при наличии мостов все связи сайта становятся транзитивными, т.е. если сайт А имеет
связь с сайтом В, а сайт В имеет связь с сайтом С, то сайт А может реплицироваться напрямую с
сайтом С. В большинстве случаев такое поведение желательно. Однако существуют исключения,
когда необходимо отключить возможность наведения мостов между связями сайта. Например,
компания имеет несколько центральных сайтов (hub sites) во всем мире и несколько небольших
офисов, соединяющихся с центральными сайтами через медленные или средние сетевые
подключения (см. рис. 5-12). Если центральные сайты связаны высокоскоростными соединениями,
то автоматическое наведение мостов между связями сайта приемлемо. Однако, если сетевые
подключения между центральными сайтами недостаточно быстры или большая часть полосы
пропускания используется для других приложений, вы, возможно, не захотите иметь
транзитивные подключения.
На рисунке 5-12 сетевое подключение между центральными сайтами-концентраторами А и В
может иметь ограниченную доступную пропускную способность. Если заданная по умолчанию
функция наведения
мостов между связями сайта не изменена, то сервер-плацдарм центрального сайта А будет
реплицироваться с сервером-плацдармом сайта В и с серверами-плацдармами других сайтов,
связанных с центральным сайтом В. Это значит, что один и тот же трафик репликации может
пересылаться по сетевым подключениям пять раз. Чтобы изменить это, нужно отключить
возможность наведения мостов между связями сайта, а затем создать мосты связей сайта вручную.
Чтобы отключить наведение мостов между связями сайта, откройте инструмент
администрирования Active Directory Sites And Services (Сайты и службы Active Directory) и
найдите IP-свойства объекта в контейнере Inter-Site Transports (Передача между сайтами). На
вкладке General (Общее) окна IP-Properties (Свойства IP) очистите опцию Bridge All Site Links
(Мосты между всеми связями сайта). Затем вы можете создать мосты связей сайта для всех связей,
соединяющих центральные сайты с меньшими сайтами. Как только это будет выполнено, весь
трафик репликации от сайта А направится к центральному сайту В, а затем будет распределен ко
всем сайтам, связанным с сайтом В.

Рис. 5-12. Конфигурирование наведения мостов между связями сайта

Предостережение. Сбрасывая опцию Bridge All Site Links, вы выключаете транзитивность

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

Проектирование размещения серверов

В проектирование сайта входит определение мест размещения серверов, на которых выполняется
система Windows Server 2003, необходимых для обеспечения нужных служб каталога. В
большинстве случаев, как только вы завершите проектирование сайта, разместить серверы
несложно.

Размещение DNS-серверов
Как вы уже знаете, служба DNS - это критическая служба для Active Directory Windows Server
2003. Без DNS клиенты не смогут находить контроллеры домена Active Directory, а контроллеры
домена не смогут находить друг друга для репликации. DNS должна быть развернута в каждом
офисе вашей организации, исключая только очень маленькие офисы с несколькими
пользователями.
Служба DNS Windows Server 2003 обеспечивает несколько вариантов развертывания. Вы можете
помещать DNS-серверы в офисе там, где нет контроллера домена. Например, контроллер домена
нежелательно располагать в маленьком офисе с медленным сетевым подключением к
центральному офису из-за большого трафика репликации, направленного на контроллер домена.
Однако DNS-сервер в этот офис поместить можно, так как он может быть сконфигурирован так,
чтобы трафик репликации был очень мал или вообще отсутствовал. Если вы сконфигурируете
DNS-сервер как сервер, предназначенный только для кэширования, он будет оптимизировать
поиски клиента, но не создаст трафика зонной передачи. Можно сконфигурировать DNS-сервер с
сокращенными зонами для доменов Active Directory. Поскольку сокращенные зоны содержат
только несколько записей, к удаленному офису будет направляться очень небольшой трафик
репликации.
Практический опыт. Проектирование сайтов для филиалов
Специальным образом проектируется сайт для компании, которая имеет несколько
сотен маленьких офисов с контроллерами домена в каждом из них. Это усложняет
проектирование и развертывание Active
Directory во многих отношениях. Каждый дополнительный сайт увеличивает время,
которое требуется службе проверки целостности сведений (КСС) на вычисление
топологии репликации. Во время работы служба КСС может занимать 100
процентов времени процессора сервера. С большим количеством сайтов
контроллер домена, являющийся ISTG (генератор межсайтовой топологии) в
центральном офисе, может занять все время процессора и, тем не менее, никогда
не завершить вычисление. Если подключение сайта сконфигурировано с графиком,
разрешающим репликацию только в течение 6 часов каждую ночь, вы можете
обнаружить, что требуется развернуть несколько серверов-плацдармов для
еженощного выполнения репликации ко всем удаленным местам. Усложняется даже
установка контроллеров домена для каждого сайта. Если сетевое подключение
очень медленное, и вы просто устанавливаете контроллер домена в сайт, а затем
заполняете каталог путем репликации, начальная репликация для большого
каталога может занимать часы.
Windows Server 2003 имеет несколько нововведений, которые делают
развертывание Active Directory в этом сценарии более легким, чем в Windows 2000.
Усовершенствование алгоритма вычислений, который используется процессом
ISTG, значительно уменьшает время, необходимое для вычисления топологии
межсайтовой репликации. При создании контроллера домена и заполнении Active
Directory из резервных средств хранения информации в удаленном офисе не
возникнет большого трафика репликации.
Несмотря на это, планирование и развертывание сайтов Active Directory в компании
с сотнями сайтов все еще является сложным случаем. Если вы имеете дело с таким
типом среды, то лучшим ресурсом для вас является Active Directory Branch Office
Planning Guide (Руководство планирования Active Directory для филиалов),
имеющееся на сайте Microsoft по адресу http://www.microsoft.com/windows2000/
techinfо/planning/activedirectory/branchofficе/default.asp. Хотя это руководство
подготовлено для Windows 2000, многие из концепций применимы к Windows Server
2003.

Размещение контроллеров домена

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

Размещение серверов глобального каталога

GC-серверы нужны пользователям для входа на домены, которые работают на основном (native)
функциональном уровне Windows 2000, или когда пользователи делают поиск информации
каталога в Active Directory. Если домен работает на основном функциональном уровне Windows
2000, нужно поместить GC-сервер в каждый сайт. В идеале все это должно быть сбалансировано
трафиком репликации, который создается в результате помещения GC-сервера в каждом сайте.
Если у вас очень крупное предприятие с несколькими большими доменами, GC-тра-фик
репликации будет значительным. Общее правило состоит в том, что-
бы размещать GC-сервер в каждом сайте и несколько GC-серверов в больших сайтах.
Одно из улучшений Active Directory Windows Server 2003 состоит в том, что эта система
поддерживает входы в систему домена без доступа к GC-серверу за счет кэширования
универсального группового членства. Когда эта функция включена, контроллеры домена могут
кэшировать универсальное групповое членство пользователей в домене. Когда пользователь
входит на сайт в первый раз, универсальное членство группы пользователя должно быть найдено в
GC-сервере. После первого входа в систему контроллер домена будет кэшировать универсальное
групповое членство пользователя неопределенно долго. Кэш на контроллере домена
модифицируется каждые 8 часов в результате контакта с назначенным GC сервером. Чтобы
включить функцию универсального группового членства, откройте инструмент
администрирования Active Directory Sites And Services (Сайты и службы Active Directory) и
разверните объект того сайта, на котором вы хотите включить эту установку. Щелкните правой
кнопкой мыши на объекте NTDS Site Settings (NTDS параметры сайта) и выберите Properties
(Свойства) (см. рис. 5-13). На вкладке Site Settings (Параметры установки сайта) выберите опцию
Enable Universal Group Membership Caching (Разрешить кэширование универсального группового
членства) и в раскрывающемся списке Refresh Cache From (Обновить кэш из) выберите сайт, в
котором расположен самый близкий GC-сервер.
Рис. 5-13. Конфигурирование кэширования универсального группового членства

Совет. Развертывание Exchange Server 2000 создает большую нагрузку на GC-серверах. Exchange
Server 2000 не имеет своей собственной службы каталога, так что он зависит от GC. Когда клиент
просматривает GAL, он видит всех получателей почты, перечисленных в GC. Когда Exchange
Server 2000 надо найти адрес пользователя, чтобы доставить электронную почту, он делает запрос
каталогу GC. Если вы развертываете Exchange Server 2000, вы должны расположить GC в каждом
месте, где выполняется Exchange Server 2000, и увеличить общее количество GC серверов.

Размещение серверов хозяев операций

Наиболее важным хозяином операций для ежедневной работы является эмулятор основного
контроллера домена (PDC). Этот сервер особенно важен, если домен работает на смешанном
функциональном уровне Windows 2000 или на временном функциональном уровне Windows
Server 2003, потому что все резервные контроллеры домена (BDC) с системой Windows NT4
полагаются на эмулятор PDC для синхронизации каталога. Кроме того, если ваша организация
включает много клиентов низкого уровня без установленной службы Directory Services Client
(Клиента услуг каталога), эти клиенты должны подключаться к эмулятору PDC, чтобы изменить
свои пароли. Даже в основном режиме эмулятор PDC получает приоритетные обновления
изменений пароля пользователя. Поэтому очень важно, где он расположен. Эмулятор PDC должен
быть расположен в центральном офисе, где максимальное количество клиентов соединяется с
сервером.
Размещение другого хозяина операций не так критично. Принимая решение о том, где располагать
хозяина операций, используйте следующие рекомендации.
• По возможности хозяин схемы, хозяин именования домена и хозяин относительных
идентификаторов (RID) должны быть расположены в сайте, имеющем другой контроллер
домена в качестве прямого партнера по репликации. Причина связана с восстановлением
системы в случае отказа. Если один из этих серверов перестанет работать, вам, возможно,
придется захватить роль хозяина операций и передать ее другому контроллеру домена. Эту
роль желательно передать на такой контроллер домена, который полностью реплицируется
с первоначальным хозяином операций. С наибольшей степенью вероятности это
произойдет в том случае, если два контроллера домена будут находиться в одном и том же
сайте и будут сконфигурированы как прямые партнеры по репликации.
• Хозяин RID должен быть доступен для всех контроллеров домена через подключение по
удаленному запросу процедуры (RPC). Когда контроллеру домена потребуется больше
идентификаторов RID, он будет использовать RPC подключение, чтобы запросить их у
хозяина RID.
• Хозяин инфраструктуры не должен располагаться на GC-сервере, если у вас более одного
 домена. Роль хозяина инфраструктуры состоит в обновлении ссылок на отображаемые
имена пользователей между доменами. Например, если учетная запись пользователя
переименована, и пользователь является членом универсальной группы, хозяин
инфраструктуры обновляет имя пользователя. Если хозяин инфраструктуры расположен на
GC-сервере, он не будет функционировать, потому что GC постоянно обновляется самой
современной глобальной информацией. В результате хозяин инфраструктуры не
обнаружит никакой устаревшей информации и, таким образом, никогда не обновит
перекрестную междоменную информацию.
• Если организация имеет центральный офис, где располагается большинство
пользователей, всех хозяев операций следует помещать в этот сайт.

Резюме
Проектирование Active Directory - это тема отдельной книги. В этой главе говорилось, что
проектирование Active Directory начинается с компонентов высшего уровня, а затем
проектируются компоненты низших уровней. Это означает, что первый шаг состоит в создании
проекта леса, затем следует проект доменов, проект DNS и, наконец, проект OU. Для компаний,
расположенных в нескольких местах, проектирование сайтов — это еще один компонент проекта
Active Directory.
Глава 6. Установка Active Directory
Процесс установки службы каталога Active Directory на компьютере, выполняющем Microsoft
Windows Server 2003, несложен. Простота обеспечивается за счет прекрасного мастера
инсталляции Active Directory. Когда служба Active Directory устанавливается на сервер с Windows
Server 2003, компьютер фактически становится контроллером домена. Если это первый
контроллер домена в новом домене и лесу, то создается чистая база данных каталога, ожидающая
поступления объектов службы каталога. Если это дополнительный контроллер домена в уже
существующем домене, процесс репликации скоро размножит на этот новый контроллер домена
все объекты службы каталога данного домена. Если это контроллер домена, имеющий
модернизированную систему Microsoft Windows NT4, база данных учетных записей будет
автоматически обновлена до Active Directory после того, как на этом контроллере домена будет
установлен Windows Server 2003.
В этой главе приведена информация, необходимая для успешного выполнения Active Directory
Installation Wizard (Мастер инсталляции Active Directory), а также обсуждаются два других метода
установки Active Directory: инсталляция без помощи мастера и установка из восстановленных
резервных файлов. В конце главы обсуждается процесс удаления Active Directory с контроллера
домена.

Предварительные условия установки Active

Directory
Любой сервер, на котором выполняется Windows Server 2003 и который удовлетворяет условиям,
описанным в следующем разделе, может содержать Active Directory и стать контроллером домена.
Каждый новый контроллер домена фактически является автономным сервером, пока не
завершится процесс инсталляции Active Directory. В ходе этого процесса решаются две важные
задачи: создается или заполняется база данных каталога и запускается Active Directory, чтобы
сервер отвечал на попытки входа в систему домена и на запросы облегченного протокола службы
каталога LDAP.
В главе 2 говорилось, что база данных каталога хранится на жестком диске контроллера домена в
файле Ntds.dit. В процессе инсталляции Windows Server 2003 файл Ntds.dit сохраняется в папке
%systemroot
%\system32 на локальном диске. В процессе инсталляции Active Directory-файл Ntds.dit
копируется в место, идентифицированное во время инсталляции, или в заданную по умолчанию
папку %systemroot %\NTDS, если не определено другое место. При наличии файла Ntds.dit,
скопированного на жесткий диск в процессе инсталляции Windows Server 2003, Active Directory
может быть установлена в любое время без необходимости обращаться к инсталляционной среде.
Примечание. В то время как служба Active Directory может быть установлена без доступа к
инсталляционной среде, установка сервера доменной системы имен (DNS) и связанных с ним
инструментальных средств управления требует инсталляционных файлов. Не забудьте, что в
процессе инсталляции компакт-диск Windows Server 2003 должен находиться под руками.
Далее приводятся условия, необходимые для того, чтобы Active Directory могла работать в
Windows Server 2003.

Жесткий диск
Размер пространства на жестком диске, необходимого для хранения службы Active Directory,
будет зависеть от количества объектов в домене и от того, является ли данный контроллер домена
сервером глобального каталога (GC). Чтобы установить Active Directory на сервер, на котором
выполняется система Windows Server 2003, жесткий диск должен удовлетворять следующим
минимальным требованиям:
• 15 Мб свободного пространства - на раздел установки системы;
• 250 Мб свободного пространства - для базы данных Active Directory Ntds.dit;
• 50 Мб свободного пространства - для файлов регистрационного журнала транзакций
процессора наращивания памяти (ESENT). ESENT представляет собой систему
 взаимодействия базы данных, которая использует файлы регистрационных журналов для
поддержки семантики откатов (rollback), чтобы гарантировать передачу транзакций базе
данных.
В дополнение к перечисленным требованиям для поддержки установки папки Sysvol по крайней
мере один логический диск должен быть отформатирован под файловую систему NTFS v.5 (версия
NTFS, которая используется в системах Microsoft Windows 2000 и Windows Server 2003).
Дополнительная информация. Размер необходимого свободного пространства на жестком
диске для установки службы Active Directory будет зависеть от количества объектов в вашем
домене и лесу. Чтобы больше узнать о планировании дискового пространства для Active
Directory, смотрите статью «Planning Domain Controller Capacity (Планирование вместимости
контроллера домена)» на сайте www.microsoft.com/technet/
prodtechnol/windowsserver2003/evaluate/cpp/reskit/adsec/ parti /rkpdscap. asp.

Обеспечение сетевой связи

После установки Windows Server 2003 и до начала установки Active Directory убедитесь, что
сервер должным образом сконфигурирован для обеспечения сетевой связи. Попытайтесь
соединиться с другим компьютером по сети, указав путь UNC или IP-адрес целевого компьютера в
строке адреса программы Windows Explorer или используя утилиту Ping (например, в командной
строке напечатайте ping 192.168.1.1). Выполните все необходимые действия для оптимизации
сегмента сети, в котором будет находиться новый контроллер домена. Для этого используйте
инструмент сетевого управления Network Monitor (Сетевой монитор) для обеспечения
достаточной пропускной способности, необходимой для поддержки аутентификации и трафика
репликации, который будет генерировать контроллер домена.
Примечание. Инструмент Network Monitor по умолчанию не устанавливается в Windows Server
2003. Его нужно установить с помощью Windows Components Wizard (Мастер компонентов
Windows) в приложении Add/Remove Programs (Установка/ Удаление программ) окна Control
Panel (Панель управления). Для получения дополнительной информации об установке и
использовании сетевого монитора для анализа проблем сетевого трафика сделайте поиск
"Network Monitor" (включая двойные кавычки) в Windows Server 2003 Help and Support Center
(Центр справки и поддержки Windows Server 2003).
Перед установкой службы Active Directory вы должны сконфигурировать параметры настройки
протокола интернета в окне Local Area Connection Properties (Свойства локальных подключений).
Чтобы обратиться к этому диалоговому окну, щелкните правой кнопкой мыши на объекте Local
Area Connection (Локальные подключения) в папке Network Connections (Сетевые подключения) в
окне Control Panel и выберите Properties (Свойства). В окне Local Area Connection Properties
выберите Internet Protocol (TCP/IP) (Протокол интернета), затем щелкните на кнопке Properties. В
окне Internet Protocol (TCP/IP) Properties (Свойства протокола интернета), сделайте следующее.
• На вкладке General (Общее) сконфигурируйте статический IP-адрес компьютера.
• Если контроллер домена, который вы устанавливаете, не будет служить сервером DNS, то
на вкладке General вы должны сконфигурировать адрес сервера DNS, задав ему IP-адрес
сервера DNS, который является официальным (authoritative) для данного домена. Смотрите
следующий раздел для получения дополнительной информации о конфигурировании DNS
при инсталляции Active Directory.
• В окне Advanced TCP/IP Settings (Дополнительные параметры настройки TCP/IP)
щелкните на Advanced (Дополнительно) на вкладке General, щелкните на вкладке WINS и
сконфигурируйте сервер, задав IP-адрес сервера службы имен интернета для Windows
(WINS), который будет использовать данный контроллер домена.

DNS
Как говорилось в предыдущих главах, Active Directory требуется служба DNS в качестве указателя
ресурсов. Клиентские компьютеры полагаются на DNS при поиске контроллеров домена, чтобы
они могли аутен-тифицировать себя и пользователей, которые входят в сеть, а также делать
запросы к каталогу для поиска опубликованных ресурсов. Кроме того, служба DNS должна
поддерживать записи службы указателя ресурсов (SRV) и динамические модификации. Если
служба DNS не была установлена предварительно, то мастер инсталляции Active Directory
установит и сконфигурирует DNS одновременно с Active Directory.
Если DNS уже установлена в сети, проверьте ее конфигурацию, чтобы она могла поддерживать
Active Directory. Для этой проверки можно использовать команду Dcdiag (доступна как часть
набора инструментальных средств, созданного при установке файла \Support\Tools\ Support.msi с
компакт-диска Windows Server 2003). Наберите команду:
dcdiag/test:dcpromo/dnsdomain:domainname/newforest
Теперь вы сможете удостовериться, что DNS-сервер является официальным для домена
domainname и может принимать динамические обновления для новых контроллеров домена. Для
получения дополнительной информации об использовании инструмента dcdiag напечатайте
dcdiag/? в командной строке.
Если служба DNS в сети отсутствует, вас попросят установить службу сервера DNS в процессе
инсталляции Active Directory. Если контроллер домена, который вы устанавливаете, будет также
сервером DNS, то проведите тщательное планирование пространства имен DNS, которое вы
будете использовать (см. гл. 5 для получения дополнительной информации о проектировании
пространства имен DNS).
Если вы будете устанавливать службу сервера DNS одновременно с Active Directory,
сконфигурируйте установки сервера DNS на компьютере, чтобы указать себя перед установкой
Active Directory. Откройте окно Internet Protocol (TCP/IP) Properties (Свойства протокола интер-
нета) и установите адрес сервера Preferred DNS Server (Привилегированный сервер DNS) на IP-
адрес локального компьютера (см. рис. 6-1).

Рис. 6-1. Конфигурирование параметров настройки сервера DNS

Административные разрешения
Чтобы устанавливать или удалять Active Directory, ваша учетная запись должна иметь
соответствующие административные разрешения. Тип разрешений учетной записи зависит от типа
создаваемого домена. Мастер инсталляции Active Directory проверяет разрешения учетной записи
перед установкой службы каталога. Если вы войдете в систему с учетной записью, не имеющей
административных разрешений, мастер запросит вас о соответствующих сертификатах учетной
записи.
Чтобы создать новый корневой домен леса, вы должны войти в систему с правами локального
администратора, но сетевые сертификаты для этого не нужны. Если вы собираетесь создать новый
корневой домен дерева или новый дочерний домен в существующем дереве, необходим сетевой
сертификат для установки домена. Чтобы создать новый корневой домен дерева, вы должны
предъявить сертификат учетной записи члена группы Enterprise Admins (Администраторы
предприятия). Чтобы установить дополнительный контроллер домена в существующий домен, вы
должны предъявить сертификаты, которые имеют разрешения присоединять компьютер к домену
и создавать объект NTDS Setting (Параметры настройки NTDS) в разделе конфигурации каталога.
Глобальная группа Domain Admins (Администраторы домена) имеет такой уровень разрешений.
Варианты инсталляции Active Directory
Чтобы начать инсталляцию Active Directory, можете использовать один из графических
интерфейсов или запустить ее из командной строки. С помощью графических интерфейсов можно
установить и сконфигурировать службу каталога, а также создать и инициализировать хранилище
данных каталога. Так как Active Directory требует, чтобы реализация DNS была официальной для
запланированного домена, то в процессе инсталляции будет установлен и сконфигурирован сервер
службы DNS, если официальный DNS-сервер еще не установлен.
Существует несколько способов запуска процесса инсталляции Active Directory:
• Configure Your Server Wizard (Мастер конфигурирования сервера);
• Active Directory Installation Wizard (Мастер инсталляции Active Directory);
• инсталляция без сопровождения.
•
Мастер конфигурирования сервера
Окно Manage Your Server (Управление сервером) появляется автоматически после того, как
закончится инсталляция или обновление Windows Server 2003. Оно отображает список всех
сетевых услуг, которые установлены на сервере, и позволяет установить дополнительные услуги
(см. рис. 6-2).

Рис. 6-2. Окно Manage Your Server (Управление сервером)

Из окна Manage Your Server вы можете добавить серверу роль контроллера домена. Это можно
сделать, выбрав опцию Typical Settings for a First Server (Типичные параметры настройки первого
сервера) с предварительно разработанными настройками или роль контроллера домена. Если
выбраны типичные установки первого сервера, то автоматизированный процесс добавит службы
сервера DNS и DHCP. Программа инсталляции автоматически установит Active Directory с
заданными по умолчанию вариантами для многих опций, используя Active Directory Installation
Wizard (Мастер инсталляции Active Directory). Если вы планируете установить Active Directory со
всеми заданными по умолчанию опциями, то программа Configure Your Server Wizard (Мастер
конфигурирования сервера) обеспечит защищенную от ошибок установку этой службы.

Мастер инсталляции Active Directory

Active Directory Installation Wizard (Мастер инсталляции Active Directory) можно запустить,
напечатав dcpromo.exe в диалоговом окне Run или в командной строке. Команда Dcpromo.exe
имеет два параметра командной строки:
• параметр /answer[:answerfilе] используется для выполнения автоматической инсталляции
Active Directory. Включите в этот параметр имя файла автоматического ответа, который
 содержит всю информацию, необходимую для выполнения инсталляции;
• параметр /adv используется для запуска мастера инсталляции Active Directory в том случае,
когда контроллер домена будет создан из восстановленных резервных файлов. Когда вы
добавляете параметр /adv, то в процессе инсталляции нужно указать путь к
восстановленным резервным файлам.
Детальная информация о ключевых пунктах ответов дана в разделе этой главы «Использование
мастера инсталляции Active Directory».

Инсталляция без сопровождения

Для установки Active Directory вы можете запустить инсталляционный процесс в «тихом» режиме,
без сопровождения, напечатав dcpromo.exe/ answer:answerfilе, где answerfile — имя файла ответов,
который вы создали. В режиме «без сопровождения» файл сценария инсталляции передает
значения для всех полей пользовательского ввода, которые вы заполняли бы при использовании
мастера инсталляции Active Directory. Для любого ключа, который не определен в файле ответа,
будет использоваться заданное по умолчанию значение этого ключа, или появится окно, чтобы вы
могли ввести требуемое значение. Создание файла ответов для инсталляции без сопровождения
будет описано позже в этой главе.

Использование мастера конфигурирования

сервера
Чтобы установить Active Directory, используя мастера конфигурирования сервера (Configure Your
Server Wizard), можно выбрать добавление новой роли в утилите Manage Your Server (Управление
сервером) или Configure Your Server Wizard в папке Administrative Tools (Средства
администрирования).
Чтобы установить Active Directory, используя Configure Your Server Wizard, выполните следующие
действия.
1. В окне Manage Your Server щелкните на кнопке Add Or Remove A Role (Добавить или
удалить роль) или выберите Configure Your Server Wizard в папке Administrative Tools.
Запустится мастер конфигурирования сервера.
2. В окне Preliminary Steps (Предварительные шаги) щелкните на кнопке Next (Далее). Ждите
некоторое время, пока мастер ищет параметры настройки Local Area Connections
(Локальные подключения).
3. Чтобы установить Active Directory, службу сервера DNS и службу протокола
динамической конфигурации хоста (DHCP), в окне Configuration Options (Опции
конфигурации) выберите Typical Configuration For A First Server (Типичная конфигурация
для первого сервера). Чтобы установить только Active Directory, выберите Custom
Configuration (Выборочная конфигурация), а затем щелкните на кнопке Next (см. рис. 6-3).
Последующее описание предполагает, что вы выбрали опцию Custom configuration.

Рис. 6-3. Окно Configuration Options (Опции конфигурации)

 4. В окне Server Role (Роль сервера) выберите Domain Controller (Контроллер домена), затем
щелкните на кнопке Next (см. рис. 6-4).

Рис. 6-4. Окно Server Role (Роль сервера)

5. В окне Summary Of Selections (Резюме выбранных опций) подтвердите выбор роли сервера
и щелкните на кнопке Next. Для конфигурирования выбранных услуг появится окно
Applying Selections (Применение выбранных опций).
6. При создании роли контроллера домена появляется окно Welcome (Приветствие) мастера
инсталляции Active Directory (см. рис. 6-5). После этого будет выполняться тот же процесс,
как если бы вы запустили мастера инсталляции Active Directory из командной строки или
командой Run (Выполнить). Подробное описание ответов на вопросы мастера инсталляции
Active Directory дано в следующем разделе. Завершите мастера инсталляции Active
Directory, а затем щелкните на кнопке Finish (Готово). После того как служба Active
Directory установлена и сконфигурирована, появится напоминание о том, что нужно
перезапустить ваш сервер.

Рис. 6-5. Окно Welcome (Приветствие) мастера инсталляции Active Directory

Использование мастера инсталляции Active
Directory
Мастер инсталляции Active Directory работает просто. Все опции мастера хорошо объяснены и
представлены в логическом порядке. Вместо того чтобы проводить вас через этот достаточно
очевидный процесс, обсудим ключевые моменты ответов, с которыми вы столкнетесь при
установке Active Directory.
Чтобы запустить мастера инсталляции Active Directory, напечатайте dcpromo в диалоговом окне
Run (Выполнить) или в командной строке. Появится стартовое окно мастера инсталляции Active
Directory.

Совместимость операционных систем

Контроллеры домена, на которых выполняются Windows Server 2003, лучше защищены, чем те, на
которых выполняются предыдущие версии сетевых операционных систем Windows, и мастер
инсталляции Active Directory дает информацию о том, как эта защита затрагивает вход клиента в
систему. Заданная по умолчанию политика безопасности для контроллеров домена, на которых
выполняются Windows Server 2003, требует двух новых уровней защиты взаимодействия
контроллеров домена: подписи блока серверных сообщений (Server Message Block — SMB), а
также шифрования и подписи сетевого трафика безопасного канала.
Эти функции защиты вызывают проблемы при входе в систему клиентов низкого уровня.
Нижеприведенные клиентские операционные системы Windows в основном режиме не
поддерживают подписи SMB, шифрование и подписи безопасного канала:
• Microsoft Windows for Workgroups;
• Microsoft Windows 95 и Windows 98;
• Microsoft Windows NT 4 (Service Pack 3 и более ранние).
Если ваша сеть поддерживает эти системы, то вы должны выполнить определенные действия,
чтобы дать им возможность входить в систему контроллера домена, на котором выполняется
Windows Server 2003 (см. табл. 6-1).

Табл. 6-1. Предоставление клиентским операционным системам возможности входа в Active Directory
Клиент ОС Действие
Windows for Workgroups Модернизируйте операционную систему.
Windows 95/Windows 98 Модернизируйте операционную систему
(рекомендуется) или установите Directory
Services Client (Клиент служб каталога).
Windows NT 4 Модернизируйте операционную систему
(рекомендуется) или установите Service Pack
4 (или более поздний).

Directory Services Client (Клиент служб каталога) — это компонент клиентской стороны, который
дает возможность низкоуровневым клиентским операционным системам (Microsoft Windows 95,
Windows 98 и Windows NT 4) воспользоваться преимуществами Active Directory. (Это
использование распределенной файловой системы (DFS) и поиска). Посмотрите страницу
дополнений клиента Active Directory на сайте http:/
/www.microsoft.corn/windows2000/server/evaluation/news/bulletins/ adextension.asp для получения
информации относительно загрузки и использования службы Directory Services Client в системе
Windows NT 4 SP6a. Обратите внимание, что предыдущее название службы Directory Services
Client было Active Directory Client Extension, с этим именем вы будете сталкиваться во многих
статьях веб-сайта Microsoft.
На рисунке 6-6 показано окно Operating System Compatibility (Совместимость операционных
систем).
Типы доменов и контроллеров домена
Первое решение, которое вы должны принять в процессе инсталляции, -какой контроллер домена
должен быть создан. Это может быть первый контроллер домена в новом домене или
дополнительный контроллер домена для существующего домена (см. рис. 6-7). По умолчанию
создается новый домен и новый контроллер домена. Если вы выберете создание
дополнительного контроллера домена в существующем домене, то имейте в виду, что все
локальные учетные записи, которые существуют на сервере, будут удалены наряду со всеми
криптографическими ключами, которые хранились на компьютере. Вас попросят также
расшифровать все зашифрованные данные, потому что после установки Active Directory это будет
недоступно.

Рис. 6-6. Окно Operating System Compatibility (Совместимость операционных систем)

Рис. 6-7. Окно Domain Controller Type (Тип контроллера домена)

Если вы выберете создание нового домена, то далее нужно будет указать, создавать ли корневой
домен в новом лесу, дочерний домен в существующем домене или в новом дереве домена в
существующем лесу (см. рис. 6-8). Проконсультируйтесь с проектной документацией своей
службы Active Directory (см. гл. 5), чтобы определить природу создаваемого домена. Чтобы
создать дочерний домен в существующем домене или в новом дереве домена в существующем
лесу, вы должны представить соответствующие сетевые сертификаты для продолжения
инсталляционного процесса. Для создания корневого домена нового леса сетевые сертификаты не
требуются.
Рис. 6-8. Окно Create New Domain (Создание нового домена)

Именование домена
При создании нового контроллера домена для нового домена нужно задать полное имя DNS и имя
NetBIOS (см. рис. 6-9). При создании этих имен нужно соблюдать определенные правила.
Полное имя DNS должно содержать уникальное имя для нового домена, а при создании дочернего
домена должен существовать родительский домен, и его имя должно быть включено в имя DNS.
Например, если вы создаете новый домен NAmerica в дереве домена Contoso.com, то полное имя
DNS, которое вы должны ввести, будет NAmerica.Contoso.com. При именовании домена
доступные символы включают независимые от регистра буквы от А до Z, цифры от 0 до 9 и дефис
(-). Каждый компонент DNS имени домена (секции, отделенные точкой [.]) не может быть длиннее
63-х байтов.

Рис. 6-9. Окно New Domain Name (Имя нового домена)

После того как вы указали имя DNS для домена, необходимо задать имя NetBIOS (см. рис. 6-10).
Имя NetBIOS используется более ранними версиями системы Windows для идентификации имени
домена. Лучше всего принять автоматическое имя NetBIOS, полученное из ранее введенного
имени DNS. Единственное ограничение на имя NetBIOS состоит в том, что оно не должно
превышать четырнадцать символов. Кроме того, имя NetBIOS должно быть уникальным.
Рис. 6-10. Окно NetBIOS Domain Name (Имя NetBIOS домена)

Место расположения файла

Мастер инсталляции Active Directory попросит вас выбрать место для хранения файла базы
данных Active Directory (Ntds.dit), файлов регистрационных журналов Active Directory и общей
папки Sysvol. Вы можете выбрать заданные по умолчанию места или задать другие (см. рис. 6-11).

Рис. 6-11. Окно Database And Log Folders (Папки базы данных и регистрационных журналов)

Заданное по умолчанию место для базы данных каталога и журналов — папка %systemroot
%\system32. Однако для обеспечения лучшей производительности нужно сконфигурировать Active
Directory так, чтобы хранить файл базы данных и журналы на отдельных жестких дисках.
Заданное по умолчанию место общей папки Sysvol - %systemdrive %\Windows. Единственное
ограничение на выбор места для общей папки Sysvol состоит в том, что она должна храниться в
разделе с файловой системой NTFS v5. В папке Sysvol хранятся все файлы, которые должны быть
доступны клиентам домена Active Directory, например, сценарии входа в систему (см. рис. 6-12).

Проверка или установка DNS-сервера

Active Directory требует, чтобы в сети была установлена служба DNS, тогда компьютеры-клиенты
смогут находить контроллеры домена для аутентификации. Для этого реализация DNS должна
поддерживать записи SRV. Microsoft рекомендует также поддержку динамических обновлений.
Реализация службы DNS в сети может быть выполнена не на платформе Microsoft, это может быть
DNS-сервер, работающий под Windows NT 4 (SP4), Windows 2000 Server или Windows Server 2003.
Рис. 6-12. Окно Shared System Volume (Общедоступный системный том)

Если компьютер, на котором вы устанавливаете Active Directory, не является DNS-сервером, или

если мастер инсталляции Active Directory не проверяет, что DNS-сервер должным образом
сконфигурирован для нового домена, то служба DNS сервера может быть установлена в процессе
инсталляции Active Directory. (Если вы устанавливаете дополнительный контроллер домена в уже
существующем домене, то считается, что служба DNS уже установлена, и этот шаг проверки
пропускается.) Если служба DNS реализована в сети, но не сконфигурирована должным образом,
то окно DNS Registration Diagnostics (Диагностика регистрации DNS) мастера инсталляции Active
Directory сообщает об ошибках конфигурации. В этом месте нужно сделать все необходимые
изменения в конфигурации DNS и повторить программу диагностики DNS. В качестве
дополнительного варианта можно продолжить инсталляцию Active Directory и позже
сконфигурировать DNS вручную. На рисунке 6-13 показаны результаты диагностики DNS,
выполненной во время работы мастера инсталляции Active Directory и три варианта возможных
продолжения. Обратите внимание, что вторая опция, связанная с установкой и
конфигурированием DNS-сервера на этом компьютере, является заданной по умолчанию в
ситуации, когда DNS сервер не найден.
Если вы выберете заданную по умолчанию опцию, связанную с установкой и конфигурированием
DNS сервера, то сервер DNS и служба DNS сервера будут установлены в процессе инсталляции
Active Directory. Основная зона DNS будет соответствовать имени нового домена Active Directory,
она будет сконфигурирована так, чтобы принимать динамические обновления. Предпочтительные
параметры установки DNS-cep-
вера (в окне свойств TCP/IP) будут модифицированы для указания на локальный DNS-сервер.
(Выше рекомендовалось сконфигурировать локальный IP-адрес компьютера перед инсталляцией
Active Directory.)

Рис, 6-13. Окно DNS Registration Diagnostics (Диагностика регистрации DNS) мастера
инсталляции Active Directory
Дополнительная информация. Когда служба DNS сервера устанавливается мастером инсталляции
Active Directory, то зона DNS создается как интегрированная зона Active Directory. Для получения
дополнительной информации о конфигурировании интегрированной зоны Active Directory см. гл.
3.

Выбор заданных по умолчанию разрешений для

пользовательских и групповых объектов
Обе системы, Windows Server 2003 и Windows 2000, реализуют более строгую защиту для
атрибутов пользовательских и групповых объектов, чем та, которая была в Windows NT 4. Доступ
к пользовательским объектам и групповое членство по умолчанию недоступны для анонимных
пользовательских входов в систему. Чтобы сохранить обратную совместимость с приложениями и
службами, созданными до Windows 2000 (Microsoft SQL-сервер и служба удаленного доступа
Remote Access Service, RAS), Active Directory конфигурируется так, чтобы ослабить заданную по
умолчанию защиту и позволить анонимный доступ к этим объектам службы каталога. Это
выполняется путем добавления специальных групп Everyone (Все) и Anonymous Logon
(Анонимный вход в систему) к локальной группе Pre-Windows 2000 Compatible Access (Доступ,
совместимый с системами, разработанными до Windows 2000).
В процессе инсталляции Active Directory вы должны установить заданные по умолчанию
разрешения для групповых и пользовательских объектов. В окне Permissions (Разрешения)
выберите одну из двух опций (см. рис. 6-14):
• Permissions Compatible With Pre-Windows 2000 Server Operating Systems (Разрешения,
совместимые с операционными системами, созданными до Windows 2000);
• Permissions Compatible Only With Windows 2000 Or Windows Server 2003 Operating Systems
(Разрешения, совместимые только с операционными системами Windows 2000 или
Windows Server 2003).

Рис. 6-14. Окно Permissions (Разрешения)

Какую опцию выбрать? Если ваша сетевая среда будет включать серверы Windows NT, а также
службы или приложения, которые требуют защиты Windows NT для пользователей и групп, вы
должны принять заданную по умолчанию: Permissions Compatible With Pre-Windows 2000 Server
Operating Systems. Если ваша сетевая среда включает только Windows 2000 или Windows Server
2003, если в ней не будут выполняться программы, разработанные для более ранних, чем Windows
2000, систем, выберите Permissions Compatible Only With Windows 2000 Or Windows Server 2003
Operating Systems. Имейте в виду, что с заданной по умолчанию опцией анонимные пользователи
будут способны обращаться к данным Active Directory, нарушая защиту.
После того как вы модернизируете все серверы в домене до Windows 2000 или Windows Server
2003, нужно заново установить разрешения Windows Server 2003 для групповых и
пользовательских объектов. Для этого просто удалите всех членов локальной группы Pre-Windows
2000 Compatible Access (Доступ, совместимый с системами, разработанными до Windows 2000). В
домене Windows Server 2003 членами будут идентификаторы SID групп Everyone (Все) и
Anonymous Logon (Анонимный вход в систему).
Чтобы удалить членов этой группы с помощью инструмента администрирования Active Directory
Users And Computers (Пользователи и компьютеры Active Directory), откройте контейнер Builtin
(Встроенные объекты), а затем дважды щелкните на группе Pre-Windows 2000 Compatible Access
(раскройте столбец Name (Имя) в случае необходимости). На вкладке Members (Члены) окна
групповых свойств выберите оба идентификатора SID и щелкните на кнопке Remove (Удалить).
Для удаления членов этой группы из командной строки напечатайте следующую команду:
net localgroup "Pre-Windows 2000 Compatible Access" Everyone "Anonymous Logon"
/delete

В любом случае, чтобы вступило в силу изменение группового членства, необходимо

перезагрузить все контроллеры домена в домене.
перед началом первичного процесса репликации появится кнопка Finish Replication Later
(Выполнить репликацию позже). Выберите эту опцию, чтобы позволить нормальному процессу
репликации синхронизировать разделы каталога на этом контроллере домена позже.

Рис. 6-15. Окно Directory Services Restore Mode Administrator Password (Пароль
администратора режима восстановления службы каталога)

Первичная репликация данных раздела каталога может занимать много времени, особенно по
медленным сетевым подключениям, поэтому в Active Directory Windows Server 2003 предлагается
новая функция установки дополнительного контроллера домена из восстановленных резервных
файлов, которая обсуждается далее в этой главе.
Наилучшая практика. После установки службы Active Directory вы должны открыть инструмент
администрирования Active Directory Users And Computers и проверить, что созданы все
встроенные участники безопасности, такие как учетная запись пользователя Administrator и
группы безопасности Domain Admins, Enterprise Admins. Вы должны также проверить создание
«специализированных тождеств» Authenticated Users (Удостоверенные пользователи) и Interactive
(Интерактивный). «Специализированные тождества» обычно известны как группы, но вы не
можете видеть их членство. Пользователи автоматически включаются в эти группы, когда они
обращаются к специфическим ресурсам. «Специализированные тождества» по умолчанию не
отображаются в инструменте администрирования Active Directory Users And Computers. Чтобы
рассмотреть эти объек-
ты, выберите View (Вид), а затем выберите Advanced Features (Дополнительные функции).
В результате отобразятся дополнительные компоненты инструмента. Откройте контейнер Foreign
Security Principals (Внешние участники безопасности). Там вы найдете объекты S-1-5-11 и S-1-5-4,
которые являются идентификаторами Authenticated Users SID и Interactive SID, соответственно.
Дважды щелкните на этих объектах, чт�