Active Directory для Windows Server 2003. Справочник

С. Реймер, М. Малкер
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 Server 2003
(промежуточный)
Windows Server 2003
Windows 2000, Windows Server 2003.
interim Windows NT 4, Windows Server 2003.
Windows Server 2003.
В таблице 2-2 показаны функциональные уровни леса и операционные системы, поддерживаемые
на контроллерах домена в лесу.
Табл. 2-2. Функциональные уровни леса
Функциональные уровни леса
Windows 2000
умолчанию)
(значение
Windows Server 2003
(промежуточный)
Windows Server 2003
Операционные
системы,
поддерживаемые на контроллерах
данного домена в лесу
по Windows NT 4, Windows
Windows Server 2003.
2000,
interim Windows NT 4, 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-сервер провайдера службы
2.
3.
4.
5.
6.
7.
8.
интернета). Рекурсивный запрос может иметь только два возможных ответа: IP-адрес,
запрашиваемый клиентом, или сообщение об ошибках, указывающее, что информация не
может быть найдена.
Если DNS-сервер провайдера имеет необходимую информацию в своем кэше, то он
возвращает IP-адрес пользователю. Если нужной информации нет, то он пробует найти
информацию, посылая итерационный запрос на другой сервер. Ответом на итерационный
запрос может быть или разрешенное имя, запрашиваемое клиентом, или переадресация на
другой DNS-сервер, который сможет выполнить запрос. В нашем примере DNS-сервер
провайдера посылает итерационный запрос корневому серверу об IP-адресе, который
соответствует www.NAmerica.Contoso.com.
Корневой сервер не может ответить на запрос, но в ответ он присылает список серверов,
ответственных за домен высшего уровня сот. Этот процесс предоставления списка
альтернативных DNS-серверов для дальнейшего контакта называется направлением
(referral). DNS-сервер интернет-провайдера посылает итерационный запрос одному из этих
серверов с просьбой об IP-адресе.
Сервер сот дает в ответ список серверов, которые являются ответственными за домен
Contoso.com. Далее DNS-сервер провайдера посылает запрос DNS-серверу Contoso.com,
который дает в ответ имена DNS-серверов, управляющих доменом NAmerica.Contoso.com.
DNS-сервер NAmerica.Contoso.com содержит всю информацию об этом домене, и он
посылает DNS-серверу провайдера IP-адрес нужного хоста.
DNS-сервер провайдера отвечает на рекурсивный запрос, который он получил от клиентапреобразователя, и посылает IP-адрес запрошенного Web-сервера.
Компьютер клиента соединяется с www.NAmerica.Contoso.com.
Этот процесс происходит очень быстро и может не включать некоторые шаги. Когда 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
Имя
contoso.com
Протокол, используемый для этой службы.
Может быть протоколом TCP или
протоколом пользовательских датаграмм
(UDP).
Имя домена, на который ссылается запись.
Время
жизни (TTL
- Time to
Live)
Класс
Запись
ресурса
Приоритет
600
Заданное по умолчанию «время жизни»
записи (в секундах).
IN
SRV
Стандартный DNS-класс интернета.
Идентифицирует запись как запись SRV.
0
Вес
100
Идентифицирует приоритет записи для
клиента. Если существует несколько SRVзаписей для одной и той же службы,
клиенты
будут
сначала
пытаться
соединиться с сервером, имеющим самый
низкий приоритет.
Механизм балансировки нагрузки. Если
существует несколько 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
_ldap._tcp.pdc._msdcs.domainname
_ldap._tcp.sitename._sites.gc.
_msdcs.Forestrootdomainname
DS_KDC_REQUIRED
_kdc._tcp.sitename._sites.dc
._msdcs.domainname
DS_ONLY_LDAP_NEEDED
_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-SiteName (в дальнейшем сайт можно переименовать). Если не создается дополнительных сайтов, то
все последующие контроллеры домена будут добавляться к этому сайту по мере их установки.
Однако если ваша компания расположена в нескольких местах с ограниченной пропускной
способностью между ними, то вы наверняка захотите создать дополнительные сайты.
Дополнительные сайты создаются с помощью инструмента администрирования 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 Мб/с до 1,544 Мб/с
От 1,544 Мб/с до 512 Кб/с
10
100
200
От 512 Кб/с до128 Кб/с
От 128 Кб/с до 56 Кб/с
Меньше 56 Кб/с
400
800
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
/delete
"Pre-Windows
2000
Compatible
Access"
Everyone
"Anonymous
Logon"
В любом случае, чтобы вступило в силу изменение группового членства, необходимо
перезагрузить все контроллеры домена в домене.
перед началом первичного процесса репликации появится кнопка 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, соответственно.
Дважды щелкните на этих объектах, чтобы просмотреть их свойства и заданные по умолчанию
разрешения.
Выполнение инсталляции «без сопровождения»
Чтобы установить Active Directory без пользовательского участия, можно использовать параметр
/answer [:filename] с командой Dcpromo. В этот параметр нужно включить имя файла ответов.
Файл ответов содержит все данные, который обычно требуются в процессе инсталляции. Можно
также устанавливать Active Directory при установке Windows Server 2003 в автоматическом
режиме. В этом случае используется команда E:\I386\winnt32/unattend[:unattend.txt], где
unattend.txt - имя файла ответов, используемого для полной инсталляции Windows Server 2003.
(Предполагается, что дисководом CD-ROM является диск Е, и вы вставили в дисковод диск.) Файл
Unattend.txt должен содержать раздел [Deinstall], чтобы можно было установить Active Directory.
Чтобы выполнить автоматическую установку Active Directory после установки операционной
системы Windows Server 2003, создайте файл ответов, который содержит раздел [Deinstall]. Для
этого напечатайте в командной строке или в диалоговом окне Run dcpromo/ answer:answerfile (где
answerfile - имя файла ответов). Файл ответов представляет собой текстовый ASCII-файл, который
содержит всю информацию, необходимую для заполнения страниц мастера инсталляции Active
Directory. Для создания нового домена в новом дереве нового леса так, чтобы служба DNS сервера
была сконфигурирована автоматически, содержание файла ответов выглядит следующим образом:
[Deinstall]
UserName=admin_ username
Password=admin_password
UserDomain=acmin_domain
DatabasePath=
LogPath=
SYSVOLPath=
SafeModeAdminPassword=password
ReplicaOrNewDomain=Domain
NewDomain=Forest
NewDomainDNSName=DNSdomainname
DNSOnNetwork
DomainNetbiosName=NetBIOSdomainname
AutoConfigDNS=yes
AllowAnonymousAccess=yes
CriticalReplicationOnly=yes
SiteName=
RebootOnSuccess=yes
Для ключей, не имеющих значений, или для отсутствующих ключей будут использоваться
значения, заданные по умолчанию. Ключи, необходимые для файла ответов, изменяются в
зависимости от типа домена, который будет создан (новый или уже существующий лес, новое или
уже существующее дерево). Для получения дополнительной информации относительно ключей и
соответствующих
значений
смотрите<
документ
http://support.microsoft.com/default.aspx?scid=kb%3ben-us%3b223757.
Ключ ReplicationSourcePath — это дополнительный ключ, который можно использовать для
создания контроллера домена с помощью информации, восстановленной из резервных средств.
Чтобы использовать его, укажите местоположение восстановленных резервных файлов, которые
будут использоваться для заполнения базы данных каталога в первый раз. (Это тот же самый путь,
который выбирается при использовании мастера инсталляции Active Directory.) Смотрите
следующий раздел «Установка Active Directory из восстановленных резервных файлов» для
получения дополнительной информации.
Примечание. Чтобы получить информацию по созданию файла ответов для установки Active
Directory, щелкните правой кнопкой мыши на файле Deploy.cab в папке Support\Tools компактдиска Windows Server 2003, выберите Explore (Найти) из всплывающего меню. Затем щелкните
правой кнопкой мыши на файле Ref.chm, выберите Extract (Извлечь), а затем дважды щелкните
на Ref.chm в месте извлечения файла. Файл Deploy.cab также включает Setupmgr.exe, утилиту
Setup Manager (Менеджер установки), то есть GUI, который используется для создания файла
Unattend.txt, предназначенного для установки Windows Server 2003 (создает раздел [Deinstall]). Он
также включает «Microsoft Windows Corporate Deployment Tools User's Guide» (Руководство
пользователя по развертыванию инструментальных средств Microsoft Windows), в котором
описываются заголовки разделов файла ответов, ключи и значения каждого ключа в разделах
[Unattended] и [Deinstall] файла Unattend.txt.
Установка Active Directory из восстановленных
резервных файлов
В Windows Server 2003 имеется возможность установить дополнительный контроллер домена,
используя мастер инсталляции Active Directory, 'причем начальное заполнение трех разделов
каталога выполняется путем восстановления предварительно созданного резервного набора
данных вместо использования нормального процесса репликации по сети. Выгода состоит в том,
что новые контроллеры домена будут синхронизированы значительно быстрее. В противном
случае создание разделов домена с помощью нормального процесса репликации может занимать
часы или дни. Этот метод, скорее всего, будет использоваться в среде с низкой пропускной
способностью сети или с большими разделами каталога.
Процесс установки из резервной копии не предназначен для восстановления существующих
контроллеров домена в случае их отказов. Для выполнения этой задачи используется метод
восстановления состояния системы. После того как контроллер домена будет синхронизирован с
помощью восстановленных резервных данных, произойдет репликация, обновляющая новый
контроллер домена всеми изменениями, которые произошли с момента создания резервного
набора данных. Чтобы уменьшить время репликации, всегда используйте недавнюю копию
резервных данных Active Directory. Резервный набор не может быть старше, чем время жизни
объектов-памятников домена, который имеет заданное по умолчанию значение 60 дней. Резервная
копия состояния системы должна быть взята с контроллера домена Windows Server 2003 в
пределах того же самого домена, в котором создается новый контроллер домена; резервные копии
с контроллера домена Windows 2000 несовместимы. Последнее ограничение состоит в том, что
резервный файл должен быть восстановлен на локальный диск, и обращаться к нему нужно как к
диску, обозначенному буквой логического имени (пути UNC и отображаемые диски (mapped
drives) недопустимы в качестве части параметра /adv). Для получения дополнительной
информации о создании резервной копии разделов Active Directory см. гл. 15.
Чтобы создать дополнительный контроллер домена из восстановленных резервных файлов,
выполните следующие действия.
1. Создайте и проверьте резервную копию System State (Состояние системы) на контроллере
домена в домене. Восстановите эту резервную копию на локальный диск или в другое
место в сети, где к ней можно обращаться (через букву — имя диска) с сервера, на котором
выполняется Windows Server 2003 и который должен быть назначен контроллером домена.
2. На сервере запустите мастер инсталляции Active Directory из командной строки или
диалогового окна Run, используя параметр /adv — напечатайте dcpromo / adv.
3. В окне Domain Controller Type (Тип контроллера домена) выберите Additional Domain
Controller For An Existing Domain (Дополнительный контроллер домена для
существующего домена).
4. В окне Copying Domain Files (Копирование файлов домена) выберите место расположения
восстановленных резервных файлов.
5. В окне Copy Domain Information (Копирование информации домена) выберите место
расположения восстановленных резервных файлов для этого домена.
6. Заполните остальные пункты мастера инсталляции Active Directory так, как описано в
предыдущих разделах.
Создание дополнительного контроллера домена из восстановленных резервных файлов требует
наличия сетевой связи и доступного контроллера домена в том же самом домене. Содержание
общедоступного ресурса Sysvol, например, копируется на новый контроллер домена вне этого
процесса. Репликация будет выполняться между контроллером, содержащим свежие данные, и
недавно созданным контроллером домена для всех объектов, созданных после того, как был
создан резервный набор данных.
Дополнительная информация. Для организаций со множеством маленьких отдаленных
сайтов, связанных медленными связями с центральным сайтом или центром данных,
развертывающих Active Directory, смотрите документ «Active Directory Branch Office Guide»
(Руководство
по
созданию
Active
Directory
для
филиалов)
по
адресу
http://www.microsoft.com/windows2000/
techinfо/planning/activedirectory/branchoffice/default.asp.
Этот
документ
включает
руководства по планированию и развертыванию, предназначенные помочь вам в
проектировании стратегии развертывания Active Directory в сценарии с несколькими
филиалами. В руководствах содержатся также пошаговые инструкции реализации этой
стратегии.
Удаление Active Directory
Служба Active Directory удаляется из контроллера домена с помощью той же самой команды,
которая используется для ее установки -Dcpromo.exe. Когда вы выполняете эту команду на
компьютере, являющемся контроллером домена, мастер инсталляции Active Directory уведомит
вас, что если вы выберете продолжение этой процедуры, то Active Directory будет
деинсталлирована. Последовательность действий зависит от того, является ли контроллер домена,
с которого вы удаляете Active Directory, последним контроллером домена в домене или нет. В
этом разделе обсуждаются последствия удаления Active Directory.
Что происходит с контроллером домена, когда вы удаляете Active Directory? Удаляется база
данных каталога, все услуги, необходимые для Active Directory, останавливаются и удаляются,
создается локальная база данных SAM, и компьютер понижается до роли автономного сервера или
сервера члена группы. Результат будет зависеть от того, является ли контроллер домена
дополнительным контроллером домена или последним контроллером домена в домене или лесу.
Чтобы удалить Active Directory из контроллера домена, напечатайте dcpromo в командной строке
или в диалоговом окне Run. Вначале нужно определить, является ли контроллер домена
дополнительным контроллером домена или последним контроллером домена в домене. На
рисунке 6-16 показано окно соответствующего мастера.
Рис. 6-16. Опция удаления последнего контроллера домена
Затем мастер инсталляции Active Directory отобразит список всех разделов приложений каталога,
найденных на контроллере домена. Если этот контроллер домена - последний в домене, то он
является последним источником этих данных приложений. Возможно, что вы захотите защитить
эти данные, прежде чем продолжать использование мастера, который удалит эти разделы. Если
контроллер домена, из которого вы удаляете Active Directory, является также сервером DNS, то
там будут находиться, по крайней мере, два раздела приложений каталога, в которых хранятся
зонные данные. На рисунке 6-17 смотрите пример разделов приложений DNS каталога, найденных
при деинсталляции Active Directory.
После того как вы подтвердите удаление прикладного раздела каталога, вас попросят ввести
новый пароль для локальной учетной записи администратора. Затем появится окно Summary
(Резюме), и удаление
Active Directory завершится. Для окончания этого процесса вы должны перезапустить компьютер.
После перезапуска компьютера он будет играть роль сервера-члена домена или автономного
сервера.
Рис. 6-17. Удаление разделов приложений DNS в каталоге
Удаление дополнительных контроллеров домена
Удаление Active Directory из дополнительных контроллеров домена -не такое запутанное дело, как
удаление Active Directory с последнего контроллера домена в домене или лесу. В случае удаления
дополнительных контроллеров домена остаются реплики разделов каталога, хранящиеся на других
контроллерах домена, так что фактически данные не будут потеряны. Множество интересных
изменений происходит на контроллере домена при деинсталляции Active Directory.
• Все роли хозяина операций передаются другим контроллерам домена в домене.
• Папка Sysvol и все ее содержимое удаляется из контроллера домена.
• Объект NTDS Settings (Параметры настройки NTDS) и перекрестные ссылки удаляются.
• Служба DNS обновляется для удаления SRV записей контроллеров домена.
• Создается локальная база данных SAM для обработки локальной политики безопасности.
• Все службы, которые были запущены при установке Active Directory (например, Net Logon
- Сетевой вход в систему), останавливаются.
Тип учетных записей компьютера изменяется с контроллера домена на сервер-член домена, и
учетная запись компьютера перемещается из контейнера Domain Controllers (Контроллеры
домена) в контейнер Computers (Компьютеры). Чтобы удалить Active Directory из
дополнительного контроллера домена, вы должны войти в систему как член группы Domain
Admins или Enterprise Admins.
Примечание. При удалении Active Directory с дополнительного контроллера домена
удостоверьтесь, что в домене имеется другой доступный каталог GC. Каталоги GC требуются
для пользовательского входа в систему, и эта роль не передается автоматически, как
передаются роли хозяина операций.
Удаление последнего контроллера домена
При удалении последнего контроллера домена в домене происходят некоторые специфические
события. При удалении последнего контроллера домена удаляется сам домен. Аналогично, если
контроллер домена является последним в лесу, то лес также удаляется. События, связанные с
удалением последнего контроллера домена в домене, включают следующее.
• Мастер инсталляции Active Directory проверяет, что не существует никаких дочерних
доменов. Удаление Active Directory блокируется, если обнаружены дочерние домены.
• Если домен, который будет удален, является дочерним доменом, то организуется контакт с
контроллером домена в родительском домене, и на него копируются изменения.
• Все объекты, связанные с этим доменом, удаляются из леса.
• Все объекты доверительных отношений на родительском контроллере домена удаляются.
• После того как Active Directory удалена, тип учетной записи компьютера изменяется с
контроллера домена на автономный сервер. Сервер помещается в рабочую группу по
имени Workgroup (Рабочая группа).
Административные разрешения, необходимые для удаления последнего контроллера домена в
дочернем домене или в корневом домене дерева предполагают, что вы должны войти в систему
как член группы Enterprise Admins (Администраторы предприятия) или предъявить сертификаты
администратора предприятия в процессе выполнения мастера инсталляции Active Directory. Если
вы удаляете Active Directory из последнего контроллера домена в лесу, вы должны войти в
систему или как Administrator (Администратор), или как член группы Domain Admins
(Администраторы домена).
Автоматическое удаление Active Directory
Удаление Active Directory может происходить в автоматическом режиме, подобно автоматической
инсталляции. Для этого используется командная строка. Единственное различие — содержание
файла ответов.
Чтобы выполнить автоматическое удаление Active Directory, в командной строке или в
диалоговом окне Run, напечатайте dcpromo/ answer:answer file (где answerfile — имя файла
ответов, который вы создадите). Файл ответов содержит значения ключей, которые
рассматривались выше. Важнейший ключ — IsLastDCInDomain —.может иметь значение Yes (Да)
или No (Нет). Если вы устанавливаете значение этого ключа на Yes, то тем самым указываете, что
удаляете Active Directory из последнего контроллера домена в домене и сам домен тоже будет
удален. Типовой файл ответов, предназначенный для удаления дополнительного контроллера
домена, показан ниже:
[Deinstall]
RebootOnSuccess=Yes
lsLastDCInDomain=No
AdministratorPassword=passivord
Passwo rd =password
UserName=Administrator
Резюме
В этой главе обсуждались решения, которые вы должны принять в процессе инсталляции Active
Directory Windows Server 2003. В то время как механизм установки Active Directory достаточно
прост, решения должны быть тщательно спланированы и согласованы с проектом Active Directory.
Удаление Active Directory — тоже простая процедура, но необходимо рассмотреть воздействие
удаления данного контроллера домена на остальную часть вашей инфраструктуры службы
каталога. В главе был также рассмотрен новый способ инсталляции Active Directory — установка
дополнительного или содержащего реплику контроллера домена из восстановленных резервных
файлов. Этот способ значительно уменьшает время, необходимое для установки дополнительного
контроллера домена, за счет уменьшения времени на синхронизацию разделов каталога.
Глава 7. Переход к Active Directory
В Главе 6 рассказывалось, какие ключевые решения вы должны были принять при установке
службы каталога Active Directory на компьютере серверного класса. Для простоты понимания
предполагалось, что ваша среда представляла «чистое поле», т.е. в ней ранее не существовало
инфраструктуры службы каталога. В главе б подчеркивалась важность пространства имен Active
Directory и пространства имен DNS. На самом деле «чистая» среда будет встречаться не очень
часто. Скорее всего, организация, которая переходит к Active Directory Microsoft Windows Server
2003, уже имеет некоторые службы каталога. В этой главе показан переход к Active Directory
Windows Server 2003 от существующей службы каталога Microsoft, точнее, переход от управления
безопасными учетными записями (SAM) системы Microsoft Windows NT 4 или от Active Directory
Microsoft Windows 2000. Сценарии перехода с технологий службы каталога, не принадлежащих
Microsoft, типа Novell Directory Services (NDS) или NetWare 3 Bindery, или реализаций службы
каталога на платформе UNIX, в данную главу не вошли.
Дополнительная информация. Веб-сайт компании Microsoft содержит много информации,
касающейся перехода на Windows Server с других платформ. Для получения дополнительной
информации о переходе из сред UNIX или Linux смотрите раздел веб-сайта Windows «Migrating to
Windows from UNIX and Linux (Переход к Windows от UNIX и Linux)» по адресу http://
www.microsoft.com/windows2000/migrate/unix/default.asp.
Для
получения
дополнительной
информации о переходе от Novell системы Netware смотрите раздел «NetWare to Windows 2000
Server Migration Planning Guide (Руководство по планированию перехода с NetWare на Windows
2000
Server)»
по
адресу
http://
www.microsoft.com/windows2000/techinfo/planning/
incremental/netmigrate.asp. Для получения полной информации о переходе к Windows Server 2000, а
также по технологии серверов Windows, смотрите документ «Переход к Windows» по адресу
http://www.microsoft.com/windows2000/migrate/.
В начале главы обсуждаются различные варианты путей перехода к Active Directory Windows
Server 2003. Затем уточняются ключевые моменты каждого способа и процедуры, необходимые
для этого.
Примечание. Основное внимание в главе уделено процессу перехода от Windows NT 4. Этот
сценарий предполагает большие изменения в технологии и, как следствие, является более
сложным. Поскольку Active Directory Windows Server 2003 несущественно отличается от Active
Directory Windows 2000, то в этом случае переход не очень сложен. Ключевые моменты сценариев
перехода с Windows 2000 описаны в соответствующих разделах далее в этой главе. Поэтому, если
не указано другого, процессы, описанные в главе, касаются перехода от службы каталога Windows
NT 4 к Windows Server 2003.
Обратите внимание, что если нет специального ограничения, то ссылки на Windows 2000 Server
включают Windows 2000 Server, Windows 2000 Advanced Server и Windows 2000 Datacenter Server.
Пути перехода
Если обновление службы каталога представить как переход из пункта А в пункт Б, то пунктом А
является инфраструктура вашей текущей службы каталога, а пунктом Б - желаемая структура
Active Directory Windows Server 2003. Первое решение, которое вы должны сделать при
планировании перехода, - это то, как добраться в пункт Б. Для этого существует несколько
способов, которые называются путями перехода. Ваш путь перехода будет главным звеном в
общей стратегии обновления. Эта стратегия будет включать описание того, какие объекты службы
каталога и в каком порядке вы будете перемещать. Наилучший способ любого проекта
перемещения службы каталога состоит в документировании каждой детали в рабочий документ,
называемый планом перехода.
Существует три пути перехода:
• обновление домена;
• реструктуризация домена;
• обновление с последующей реструктуризацией.
Обновление домена достигается модернизацией операционной системы до Windows Server 2003 на
контроллере домена низкого уровня. В случае Windows NT 4 служба каталога обновляется от базы
данных SAM к Active Directory Windows Server 2003. Другими словами, пункт А обновляется от
Windows NT 4 или Windows 2000 к Windows Server 2003 и становится пунктом Б. После
завершения обновления пункт А прекращает существование. Обновление домена является
наименее сложным методом перехода, который может считаться заданным по умолчанию.
Второй вариант — это реструктуризация домена. В процессе реструктуризации объекты службы
каталога копируются из существующей платформы службы каталога (пункт А) в Active Directory
Windows Server 2003 (пункт Б). Этот процесс называется также клонированием. При
реструктуризации домена пункт А и пункт Б сосуществуют. Когда все объекты службы каталога
перенесены из А в Б, а все клиенты и компьютеры сконфигурированы так, чтобы использовать
новую службу каталога, пункт А можно просто выключить. Если специфика вашей компании
такова, что реструктуризация домена является подходящим путем перехода, то примите во
внимание несколько дополнительных соображений для сравнения этого пути с обновлением
домена. Они обсуждаются в последующих разделах.
Третий путь перехода — обновление с последующей реструктуризацией - известен как переход с
двумя стадиями, или гибридный переход. Этот метод выполняется обновлением доменов,
имеющих систему Windows NT 4, и последующим перемещением учетных записей в новый или
уже существующий домен Windows Server 2003. Он объединяет преимущества первого и второго
пути, которые будут рассмотрены далее. В последующих разделах объясняются достоинства и
недостатки каждого из трех путей.
Переход через обновление домена
Обновление домена, или «обновление на месте» (in-place), является самым простым путем
перехода. Но определить это для вашей организации может оказаться весьма затруднительно. При
обновлении домена существующая платформа службы каталога преобразуется в Active Directory
одновременно с модернизацией контроллера домена до Windows Server 2003. Простота состоит в
том, что вы не имеете возможности изменить структуру домена в процессе обновления. Если вы администратор домена NAmerica в Contoso.com, представляющего среду Windows NT 4, то после
обновления вы будете администратором домена NAmerica Windows Server 2003. При обновлении
домена вы не сможете изменить структуру домена или доменное имя.
Примечание. В терминах процесса обновления исходным доменом (source domain) называется
домен, который вы модернизируете, т.е. «пункт А». Доменная структура, к которой вы
переходите, называется целевым доменом (target domain) - это «пункт Б». В сценарии обновления
домена первоначальный домен считается исходным до момента окончания инсталляция Active
Directory, с этого момента он становится целевым доменом.
Обновление Windows NT 4
Наиболее часто встречающийся сценарий — это переход от службы каталога Windows NT 4 к
Active Directory Windows Server 2003. Несмотря на свой возраст, система Windows NT 4 Server
является оплотом рынка сетевых операционных систем (NOS) для предприятий. На момент
выхода книги компания Microsoft объявила о планах «отставки» системы Windows NT 4 Server и
постепенного «свертывания» поддержки этого продукта в течение следующих нескольких
месяцев. С выпуском Windows Server 2003 многие организации, которые не хотели переходить к
Windows 2000, будут обновляться до Active Directory Windows Server 2003.
Обновление Windows Server 2000
Более простой путь доступен для владельцев Windows Server 2000, которые планируют провести
модернизацию до Windows Server 2003. Многие архитектурные изменения службы каталога
осуществлялись тогда, когда клиенты создавали свою среду сети Windows 2000, или когда они
модернизировали систему Windows NT Server 4. Клиенты, переходящие к Active Directory
Windows Server 2003 с системы Windows 2000, наиболее вероятно планируют извлечь выгоду из
новых функций, доступных в версии Active Directory Windows Server 2003.
Дополнительная информация. Для получения дополнительной информации о новых
функциях, доступных в Active Directory Windows Server 2003, см. гл. 1.
Для Windows NT 4 переход к Active Directory выполняется путем модернизации операционных систем на
контроллерах домена. Как только обновление закончено, можно пользоваться преимуществами новых
функций Active Directory Windows Server 2003. Может клиент Windows 2000 Server выбрать
реструктуризацию домена вместо обновления домена? Да, по тем же самым причинам, по которым клиенты
Windows NT 4 Server выбирают реструктуризацию домена, - инфраструктура службы каталога больше
соответствует потребностям бизнеса в организации. Клиент Windows 2000 Server, вероятнее всего,
модернизирует NOS, a затем реструктуризирует ее, чем выполнит чистую реструктуризацию домена.
Перед модернизацией Windows 2000 Server до Windows Server 2003 нужно выполнить два действия:
подготовить лес и домен Active Directory для Windows Server 2003. В папке \I386 на компакт-диске Windows
Server 2003 находятся два инструмента для решения этих задач: ForestPrep и DomainPrep. Процедуры
подготовки леса и домена описываются далее в этой главе.
Практический опыт. Переименование домена
При обновлении Windows NT 4 или Windows 2000 до Windows Server 2003 Active
Directory не изменяет имя домена. Новой функцией в Active Directory является
инструмент Domain Rename (Переименование домена). После того как домены
модернизированы, и уровень леса поднят до Windows Server 2003, можно изменить
имя модернизированного домена в соответствии с текущими потребностями вашей
организации. Инструменты переименования домена обеспечивают следующее:
• переименование домена без необходимости изменять положение какогонибудь домена леса;
• создание структуры нового дерева доменов путем изменения положения
доменов в пределах дерева;
• создание новых деревьев доменов.
Инструменты переименования доменов могут использоваться для изменения имени
корневого домена леса, но с их помощью нельзя назначить корневым доменом леса
другой домен, добавлять или удалять домены из леса. Для переименования
доменов Windows Server 2003 нужно установить инструмент Domain Rename
(Переименование доменов). Файлы Rendom.exe и Gpfixup.exe находятся на компактдиске Windows Server 2003 в папке \VALUEADD\MSFT\MGMT\DOMREN. Инструмент
Domain Rename доступен также на веб-сайте Microsoft по адресу http://
www.microsoft.com/windowsserver2003/downloads/
domainrename.mspx.
Domain
Rename работает только в Windows Server 2003 и не поддерживает Windows 2000.
Для получения дополнительной информации об использовании Domain Rename
смотрите статью «Understanding How Domain Rename Works (Как работают
инструменты
переименования
доменов)»
по
адресу
http:
/
/www.
microsoft.com/windowsserver2003 /docs /Domain-Rename- Intro.doc. Подробно
процедура развертывания Domain Rename описана в статье «Step-by-Step Guide to
Implementing Domain Rename (Пошаговое руководство по применению средства
Domain
Rename)»
no
адресу
http://www.microsoft.com/windowsserver2003/docs/Domain-Rename- Procedure, doc.
Переход путем реструктуризации домена
При реструктуризации домена создается новая инфраструктура службы каталога Windows Server
2003, а затем объекты перемещаются в эту среду. Преимущество этого пути перехода состоит в
том, что оригинал среды Windows NT 4 остается нетронутым во время создания целевой среды,
известной также как «чистый» лес (pristine forest). Образ «чистого» леса, безусловно,
привлекателен, его можно быстро заполнить объектами службы каталога: пользователями, группами и компьютерами. Реструктуризация домена процесс выборочный, здесь имеется возможность выбора тех объектов, которые вы хотите
перенести на новую платформу. (Обновление домена — это бескомпромиссная сделка, т.е.
каждый объект домена Windows NT 4 обновляется до Windows Server 2003 и Active Directory.)
Проектирование реструктуризации домена - прекрасный момент, чтобы убрать все дубликаты,
пассивные, тестовые и другие более не функционирующие учетные записи пользователей и групп.
Они исчезнут, когда вы перейдете к новой модели домена и дадите новое назначение старым
контроллерам домена.
Перемещение против клонирования
Учетные записи пользователей, групп, служб и компьютеров, называемые также участниками
безопасности (security principals), обновляются от службы каталога SAM Windows NT 4 Server к
Active Directory. Это обновление выполняется двумя способами: учетные записи могут быть или
перемещены, или клонированы. При перемещении объекта первоначальный участник
безопасности в исходном домене удаляется. Перемещение объекта - это деструктивный процесс,
исходные объекты домена, необходимые для восстановления в случае сбоя, не сохраняются.
Клонирование — это процесс создания нового, идентичного участника безопасности в целевом
домене, основанном на объекте исходного домена. Предпочтительным методом передачи
участников безопасности в чистый лес Windows Server 2003 является клонирование. Перемещение
участников безопасности, как правило, производится при переходе между двумя лесами Windows
Server 2003 или между лесом Windows 2000 и лесом Windows Server 2003.
Сценарий перехода, связанный с обновлением и последующей реструктуризацией, приведен в
разделе «Обновление и реструктуризация» в этой главе.
Практический опыт. Понимание атрибута SID-History
Как учетные записи пользователей поддерживают доступ к принтерам и общим
папкам, когда вы переносите учетные записи пользователя из одного домена в
другой?
Рассмотрим пример. Во время реструктуризации домена вы переносите пакет
учетных записей пользователей из домена Windows NT 4 в домен Windows Server
2003. После завершения переноса вы инструктируете пользователей, как входить в
новый домен и сбрасывать свои пароли. Допустим, пользователь X успешно входит
на целевой домен, а затем пытается обратиться к существующей ранее общей
папке файлового сервера, на котором выполняется система Windows NT 4 Server, с
которой он работал в течение нескольких месяцев. Сможет ли пользователь X
обратиться к этой папке?
Да, и это возможно благодаря атрибуту SID-History.
SID-History является атрибутом участников безопасности Active Directory, который
используется для хранения старых идентификаторов защиты (SID) объекта. Если
пользователь X имел в домене Windows NT 4 идентификатор SID, равный S-1-5-212127521184-1604012920-18879275 27-324294, то такое же значение появится в поле
атрибута SID-History для созданного объекта учетной записи Windows Server 2003.
При перемещении группы из домена Windows NT 4 в домен Active Directory SID
домена Windows NT 4 сохраняется в атрибуте SID-History данной группы. При
перемещении пользователей и групп учетные записи пользователя автоматически
назначаются членами групп, перенесенных в домен Windows Server 2003. Это
значит, что права доступа, назначенные для группы в домене Windows NT 4,
сохраняются в процессе перехода. Новый SID, сгенерированный целевым
контроллером домена, помещается в атрибут SID перемещенной учетной записи.
Каким образом сохраняется доступ к ресурсам? Когда пользователь X пытается
обратиться к общей папке, расположенной на файловом сервере Windows NT 4,
подсистема защиты проверяет его лексему доступа, чтобы удостовериться в
наличии необходимых разрешений на доступ к папке. Лексема доступа содержит не
только SID пользователя X и SID всех групп, к которым он принадлежит, но и все
входы SID-History самого пользователя и учетных записей его групп. Если найдено
соответствие между дискреционным списком управления доступом (DACL discretionary access control list) на дескрипторе защиты папки и предыдущим SID
(теперь включенным в лексему доступа с помощью атрибута SID-History), то
выдается разрешение на доступ к папке.
Как много из всего этого должен знать конечный пользователь? Ничего. Как много
должны знать вы, как системный администратор? Вам следует знать все. Доступ к
ресурсам — это наиболее проблемная область переноса учетных записей
пользователя. Понимая то, как поддерживаются разрешения после перехода, вы как
администратор можете эффективно решать проблемы, возникающие при доступе к
ресурсам. В процессе перехода вам, возможно, придется дополнительно
поработать для гарантии того, что поле SID-History заполнено. Вы узнаете больше
при исследовании утилиты Active Directory Migration Tool (Инструмент перехода к
Active Directory, ADMT).
Как работает атрибут SID-History в сценарии обновления домена? Ответ: он не
работает. При обновлении домена поддерживаются SID учетных записей групп и
пользователей. Пользователь X сможет нормально обращаться к ресурсам. Как SIDHistory работает в сценарии обновления с последующей реструктуризацией? Ответ:
так же, как в сценарии с простым обновлением домена, т.е. доступ к ресурсам
сохраняется за счет поддержки первоначального SID объекта в атрибуте SIDHistory. Единственное различие состоит в том, что Active Directory требует, чтобы
идентификаторы SID появлялись в лесу только один раз, включая оба поля: SID и
SID-History. В результате в сценарии обновления с последующей реструктуризацией
участники безопасности должны быть перенесены, а не клонированы.
Переход через обновление с последующей
реструктуризацией
Переход через обновление с последующей реструктуризацией представляет собой комбинацию
двух главных путей перехода. Сначала домен Windows NT 4 обновляется до Windows Server 2003
и службы Active Directory. Затем учетные записи реструктуризируются в новые или
существующие домены Windows Server 2003. Этот метод сочетает сиюминутные выгоды от
обновления домена (скорость, малый риск, высокий уровень автоматизации) с долгосрочными
преимуществами от реструктуризации домена (создает новую модель домена, реализован в виде
стадий, убирает старые и ненужные объекты учетных записей).
Обновление доменов от Windows NT 4 до Windows Server 2003 является наиболее целесообразным
способом перехода. Процесс реструктуризации объектов учетных записей может быть выполнен
через какое-то время, согласно вашему расписанию, ресурсам и бюджету. Он дает возможность
сетевым администраторам познакомиться с новой службой каталога, прежде чем погрузиться в
процесс перепроектирования домена или начать какой-либо опасный проект перехода. Этот путь
выгоден конечным пользователям, поскольку их мир сетевых услуг не изменится внезапно:
сначала они перейдут к новой NOS, а затем, через какое-то время, будет реструктуризирована
модель домена.
Определение подходящего пути перехода
При выборе пути перехода имейте в виду, что это решение касается только одного домена,
совершенно справедливо использовать различные пути перехода для различных доменов в
пределах одной организации. Популярная стратегия перехода состоит в том, чтобы обновить
домен Windows NT 4 с главными учетными записями, а затем реструктуризировать домен
ресурсов Windows NT 4 в новый домен Windows Server 2003. Если модель вашего домена с
Windows NT 4 ориентирована на географию, можно модернизировать один или несколько
больших доменов, а затем реструктуризировать более мелкие домены, сохраняя их
административную автономию через организационные единицы (OU). Оба эти сценария дают
примеры консолидации доменов.
Давайте рассмотрим критерии, которые используются при выборе наиболее подходящего пути.
Критерии выбора пути перехода
Следующие вопросы уместно задать при определении наиболее подходящего пути перехода для
вашей организации.
1. Удовлетворены ли вы моделью вашего домена? Отвечает ли существующая модель домена
Windows NT 4 вашим организационным и деловым потребностям?
2. Какую степень риска вы можете допустить при переходе к новой модели домена?
3. Сколько времени вы готовы потратить на выполнение перехода?
4. Какое количество рабочего времени системы потребуется на проект перехода?
5. Какие ресурсы доступны для выполнения перехода?
6. Каков бюджет проекта перехода?
7. Какое количество серверных приложений, которые не смогут выполняться на Windows
Server 2003, должны быть поддержаны после перехода?
Представьте себе возможные ответы в виде спектра от низкого к высокому уровню, причем, путь
обновления домена находится на самом низком уровне, а путь реструктуризации домена - на
самом высоком. Для пути перехода, связанного с обновлением и последующей реструктуризацией
вы, вероятно, увидите комбинацию деловых требований на каждой стороне спектра или
посередине (см. рис. 7-1).
Рис. 7-1. Спектр критериев выбора пути перехода для домена
Выбор обновления домена в качестве пути перехода
Учитывая все вышесказанное, давайте рассмотрим условия, при которых обновление домена
является наилучшим путем перехода для вашей организации.
Удовлетворение текущей моделью домена
Если нет никаких существенных изменений, которые хотелось бы сделать в доменной модели
одновременно с переходом к Windows Server 2003, тогда обновление домена обеспечит самый
легкий путь. Имя домена останется тем же самым, так же как и существование всех учетных
записей пользователей и групп. Обновление домена - это безальтернативная сделка, просто будет
реализована ваша текущая службы каталога в версии Windows Server 2003.
Низкий уровень риска
Являясь самым легким способом перехода, обновление домена представляет собой и метод с
минимальным риском. Когда вы модернизируете контроллер домена с операционной системой
Windows NT 4 Server, процесс выполняется автоматически. Без взаимодействия с пользователем
возможностей для ошибок возникает немного. Методология восстановления после сбоя при
обновлении домена также относительно проста. Если обновление прошло неудачно, выключите
основной контроллер домена (PDC), назначьте любой резервный контроллер домена (BDC),
имеющий свежие данные, на роль PDC, и начните процедуру снова.
Ограничение времени выполнения перехода
График времени перехода не является решающим фактором при выборе пути перехода, тем не
менее, он может быть определяющим для небольших организаций с ограниченными ресурсами.
Меньше действий требуется для обновления домена, чем для реструктуризации, и,
соответственно, меньше времени требуется для выполнения всего перехода. Например,
реструктуризация занимает много времени на создание и проверку инфраструктуры целевого
домена, на перемещение всех учетных записей с исходного домена на целевой домен. Крупные
организации, возможно, не смогут переместить все объекты за один раз, так что достаточно часто
реструктуризация домена производится в несколько этапов. Напротив, обновление домена - это
линейный процесс, если он был начат, то должен быть закончен.
Требование малых затрат рабочего времени
Другое соображение, касающееся временного графика, — это количество рабочего времени
службы каталога, которое необходимо затратить на процесс перехода. В процессе обновления
домена объекты учетных записей самостоятельно модернизируются в объекты Windows Server
2003. В результате эти ресурсы становятся недоступными непосредственно в процессе.
Обновление домена вызывает простой в сетевом доступе к ресурсам в течение времени,
необходимого для полного обновления NOS. В зависимости от размера вашего домена Windows
NT 4 и количества заложенных шагов проверки процедура может занять лучшую часть дня (если
все идет согласно плану). Таким образом, организация, которая
выберет путь перехода, связанный с обновлением домена, должна быть готова к простою службы
каталога.
Наличие ограниченных ресурсов
Поскольку обновление домена является менее сложной, автоматизированной операцией, то на
реализацию этого пути перехода потребуется меньшее количества ресурсов. Организации,
которые не в состоянии набрать кадры на выполнение более сложной задачи реструктуризации
домена, могут выбирать этот путь.
Малый бюджет проекта перехода
Обновление домена стоит дешевле, чем реструктуризация, потому что вы можете использовать
существующие серверные аппаратные средства. Это вовсе не означает, что вы должны к этому
стремиться; в действительности, обновление NOS — весьма подходящее время для модернизации
аппаратных средств контроллеров домена и других серверов, выполняющих критические миссии
(электронная почта, веб-серверы и т.д.). Однако если ваши имеющиеся серверные аппаратные
средства функционально пригодны для работы с Windows Server 2003, вы можете потратить
меньшее количество денег на обновление домена. Вы можете избежать необходимости покупать
дополнительные серверы для создания среды «чистого» леса, которая требуется для
реструктуризации домена. Среди других факторов, способствующих уменьшению необходимых
бюджетных средств, будет более низкая стоимость ресурсов (включая минимальные контрактные
расходы и стоимость «нереализованных возможностей» для постоянных служащих), а также
уменьшение расходов на тестирование (поскольку нужно будет тестировать меньшее количество
задач модернизации).
Серверные приложения, которые не будут выполняться на Windows Server
2003
Обновление домена - это хороший выбор, если на контроллерах домена, которые вы хотите
модернизировать, не выполняется сетевая служба или коммерческие приложения, которым
требуется Windows NT Server 4 как операционная система. Эти приложения могут включать
обслуживание факса, бухгалтерии или любое серверное приложение, которое не модернизируется
достаточно часто. Если такие службы и приложения существуют в вашей организации, то имеет
смысл потратить время на их проверку на компьютере с Windows Server 2003 и определить,
функционируют ли они должным образом. Если обнаружатся приложения, которые не смогут
выполняться на Windows Server 2003, то возможны следующие варианты: вы можете отложить
обновление до тех пор, пока не будет найдена совместимая версия приложения или подходящая
замена; переместить приложение с контроллера домена на сервер-член домена (если возможно); не
обновлять сервер, на котором выполняется
система Windows NT Server 4, пока не появится новая версия вашего приложения. Имейте в виду,
что сервер, на котором выполняется Windows NT 4, может существовать неопределенно долго в
качестве сервера-члена домена в сети, основанной на Windows Server 2003.
Примечание. Для поддержки BDC Windows NT 4 в вашей сети Windows Server 2003 помните, что
не следует поднимать функциональный уровень домена выше заданного по умолчанию значения
Windows 2000 mixed (смешанный) или, если в домене нет ни одного Windows Server 2000, выше
функционального уровня Windows Server 2003 interim (временный).
Выбор реструктуризации домена в качестве пути перехода
Ниже приводятся характеристики организации, которой хорошо подходит реструктуризация
домена в качестве пути перехода.
Неудовлетворенность текущей моделью домена
Если имеющаяся доменная модель Windows NT 4 больше не удовлетворяет организационным
потребностям вашей организации: устарела из-за слияния компаний, приобретения, отделения
дочерних компаний и пр., по другим причинам больше не является наиболее оптимальной сетевой
платформой для служб вашей организации, то наилучшим выбором будет реструктуризация
домена. Это даст вам возможность начать с нового проекта Active Directory, который будет
удовлетворять вашим деловым и организационным потребностям. Учитывая время и усилия,
которые потребуются для развертывания Active Directory в пределах вашего предприятия,
начинать с проекта имеет смысл только в том случае, если он упростит вашу жизнь настолько,
насколько это возможно.
Высокий уровень риска
Реструктуризация домена представляет собой путь с более высоким риском, чем обновление
домена. Надо выполнить большее количество задач, и поэтому многие вещи могут идти не так, как
надо. В результате растет недовольство пользователей, которые не могут войти в систему,
обратиться к необходимым ресурсам или получить доступ к своим почтовым ящикам. Если вы
достаточно оснащены, чтобы управлять этим риском, то не избегайте реструктуризации домена.
Как можно управлять этим риском? Нужно тщательно планировать, тестировать, обучаться и
пользоваться поддержкой.
Наличие времени, достаточного для выполнения перехода
Реструктуризация домена всегда занимает больше времени. Однако если график вашего проекта
перехода разрешает включить необходимое планирование, тестирование и выполнение задач, то не избегайте реструктуризации домена.
Высокие требования к сохранению работоспособности системы
Если вы работаете в организации, где рабочее время системы является критической величиной,
например в бизнесе, связанным с электронной коммерцией, где каждая минута простоя
пересчитывается бухгалтерами в размер потерянного дохода, то реструктуризация домена —
хороший выбор. Так как она включает создание незаполненного, «чистого» леса и оставляет
исходную среду, по существу, без изменений, то работоспособность службы каталога сохраняется,
поскольку пользователи продолжают функционировать в существующей среде. Вы можете
переносить большие или маленькие партии пользователей в течение непиковых часов работы и
оставлять эти новые учетные записи бездействующими до того времени, как будете готовы
покинуть старую систему.
Наличие адекватных ресурсов
Реструктуризация домена влечет за собой большее количество задач, чем обновление домена, и
поэтому требуется большее количество ресурсов. Выбирая этот путь перехода, убедитесь, что ваш
штат сотрудников адекватно укомплектован для выполнения дополнительной рабочей нагрузки,
связанной с реструктуризацией домена. Не забудьте учесть, что ваш штат не будет выполнять
обычные ежедневные обязанности из-за времени, потраченного на реструктуризацию. Велика
вероятность того, что вы не сможете приостановить процедуры сетевого резервирования на
несколько недель из-за того, что ваши техники будут налаживать испытательную лабораторию,
поэтому не забудьте предусмотреть заполнение этих ролей, если вы осуществляете переход с
внутренним штатом. В качестве альтернативы можно переложить часть задач или весь проект на
внешних сотрудников, поскольку существует множество консультативных групп, которые
специализируются на таких проектах. Это сэкономит время и деньги, необходимые для обучения
ваших внутренних сотрудников.
Увеличение бюджета проекта модернизации
По многим причинам реструктуризация домена потребует большего бюджета, чем обновление
домена. Аппаратные требования, необходимые для построения незаполненной среды леса, в
которую вы будете переносить ваши объекты службы каталога, следует рассмотреть с точки
зрения бюджетных затрат. Если вы находитесь на стадии обновления Windows NT 4, то эти
аппаратные расходы, вероятно, произойдут в любом из трех сценариев перехода.
Серверные приложения, требующие Windows NT 4 Server
Если вы поддерживаете сетевые службы или коммерческие приложения, которые выполняются
только на контроллерах домена с системой Windows NT 4 Server, вы, очевидно, не захотите
выполнять обновление домена, который содержит эти компьютеры. Этот факт может повлиять на
ваше решение переместить участников безопасности путем реструктуризации домена, а затем
модернизировать контроллер домена, после того как приложение или служба будут перемещены
на сервер-член домена, или после того как вы будете иметь версию приложения, совместимую с
Windows Server 2003.
Путь обновления домена с последующей реструктуризацией
Если вы решите, что ваша компания не удовлетворяет условиям, позволяющим уверенно выбрать
обновление или реструктуризацию домена в качестве пути обновления, или если для нее подходят
оба пути, то, возможно, вы выберете третий путь — обновление с последующей
реструктуризацией. Рассмотрите возможность обновления с последующей реструктуризацией,
если хотите получить немедленную выгоду от перехода к Active Directory (включая делегирование
администрирования, групповые политики, публикацию приложений и многое другое), а также
долговременную выгоду от реструктуризации домена (меньшее количество доменов с
увеличенным объемом домена, проект домена в соответствии с вашими деловыми и
организационными целями).
Критический вопрос, на который нужно ответить при рассмотрении этого пути, следующий:
«Будет ли текущая модель вашего домена адекватно функционировать в среде Windows Server
2003? » (понятие «адекватно» является очень субъективным, и каждый сетевой администратор
должен решить для себя, может ли компания продолжать поддерживать конгломерат предыдущих
операционных систем, если да, то как долго.) Если ответ - да, возможно, вы наилучшим образом
достигните своих целей через путь обновления с последующей реструктуризацией.
Практический опыт. Консолидация доменов через реструктуризацию
Ваша цель может состоять в объединении несколько доменов в вашей организации.
Большие организации могут иметь сотни доменов, отвечающих потребностям
службы каталога их пользователей. Почему количество доменов растет, выходя изпод контроля? Одна из причин - довольно низкий размер базы данных SAM (предел
в 80 Мб, выше которого происходит ухудшение производительности, для
существующих аппаратных стандартов, 40 Мб - на более старых системах). По мере
роста организации должны добавлять большее число доменов Windows NT 4, чтобы
удовлетворить возрастающие требования к объему. Другая причина «раздувания
домена» - это модель с одним хозяином домена. Она использует
домены учетных записей для учетных записей пользователей и групп, домены
ресурсов для общедоступных ресурсов (компьютеров, принтеров и т.д.) и локальные
группы, которые управляют доступом к ресурсам. По мере увеличения количества
общедоступных ресурсов в сети растет и число доменов ресурсов. В результате
возникает слишком много доменов, и административные заботы увеличиваются.
Такая организация является хорошим кандидатом на реструктуризацию домена,
причем сокращение количества доменов должно быть целью при проектировании
Active Directory. Домены Active Directory Windows Server 2003 могут поддерживать
миллионы объектов, возможно объединение такое количество доменов учетных
записей, которое необходимо для удовлетворения потребностей вашего бизнеса.
Через введение OU вы можете достичь того же уровня административной власти,
какой вы имели в доменной модели системы Windows NT 4, без необходимости
делать всех администраторов ресурсов членами группы Domain Admins
(Администраторы домена). Организация с сотнями доменов Windows NT 4 может
перейти к Active Directory с единственным доменом.
Как только вы определили лучший путь перехода для ваших доменов, пришло время работать.
Следующие разделы уточняют действия, необходимые для модернизации инфраструктуры вашей
службы каталога с Windows NT 4 к Windows Server 2003.
Подготовка перехода к Active Directory
Подготовка перехода от Windows NT 4 к Windows Server 2003 и к Active Directory происходит в
три этапа.
1. Планирование перехода.
2. Испытание плана перехода.
3. Проведение экспериментального перехода.
Кроме того, вы должны запланировать время на обслуживание и поддержку, которые следуют за
развертыванием. Однако этот этап не является обязательным для проекта перехода службы
каталога и в этом разделе не обсуждается.
Дополнительная информация. Для получения дополнительной информации об обновлении
службы каталога Windows NT 4 до Windows Server 2003 смотрите статью «Upgrading
Windows NT 4.0 Domains to Windows Server 2003 (Обновление доменов Windows NT 4.0 до
Windows
Server
2003)
по
адресу
http://
www.microsoft.com/technet/prodtechnol/windowsserver2003/ evaluate/cpp/reskit/ad. Имеется
также статья «Domain Migration Cookbook (Кухня обновления доменов)» по адресу
http://www.microsoft.co7n/technet/prodtechnol/windows2000serv/deploy/cookbook/cookintr. Хотя
эти статьи написаны для Windows Server 2000, они дают критический анализ техники
перехода от Windows NT 4 и включают процедуры и наилучшие методы реализации
обновления и реструктуризации. Эти процедуры и методы уместны и в среде Windows
Server 2003.
Планирование модернизации
Чтобы гарантировать успешный переход к Windows Server 2003 и Active Directory, затратьте
достаточно усилий на его планирование, будь то оперативное обновление контроллеров домена
или полная реструктуризация доменной модели. Конечным результатом будет полное описание
всех задач, которые нужно выполнить в процессе модернизации. После проверки этот план будет
служить сценарием, по которому вы выполните многочисленные и разнообразные задачи
модернизации своего домена.
Документирование текущей среды
Первый шаг в планировании модернизациии Active Directory состоит в документировании
существующего каталога и платформы сетевых служб. Вы будете удивлены, обнаружив, как
многого вы не знали о серверах, службах и приложениях, выполняющихся на ваших контроллерах
домена. Используйте эту ревизию как возможность почистить «паутину» и, возможно, удалить
избыточные или неиспользуемые элементы. Вы сделаете вашу сеть более эффективной и легкой в
сопровождении и уменьшите объем работы, который предстоит проделать в процессе
модернизации службы каталога.
Как только текущая среда будет задокументирована, примите решение о том, как и когда
модернизировать Active Directory.
Ниже приводятся те элементы, описание которых вы включите в свой план.
• Текущая доменная структура Windows NT 4. Перед началом модернизации вы должны
иметь ясную картину текущего состояния. Эта информация будет жизненно необходимой,
когда вы будете планировать откат перехода. Наилучшая практика состоит в
документировании следующей информации о вашем текущем каталоге, сетевых службах и
среде, в которой они выполняются:
o все домены вашей организации (домены ресурсов и учетных записей);
o все доверительные отношения между доменами (включая тип и направление
доверительных отношений);
o все учетные записи пользователей, глобальных и локальных групп, а также
учетные записи компьютеров;
o все учетные записи служб и другие учетные записи, которые необходимы для
запуска сетевых служб или приложений;
o все системные политики и политики безопасности, которые внедрены в вашей
организации.
• Текущие сетевые службы Windows NT 4. Задокументируйте все сетевые службы,
использующиеся на вашем предприятии, включая сервер, на котором они выполняются.
Убедитесь, что ваш план перехода отвечает за выполнение этих служб. Вы должны
задокументировать следующие службы:
o серверы DNS;
o серверы протокола динамической конфигурации хоста (DHCP), a также параметры
настройки области действия (scope);
o серверы службы имен интернета для Windows (WINS);
o серверы службы удаленного доступа (RAS) (см. примечание ниже);
o файловые серверы и сервера печати.
Предостережение. RAS-серверы системы Windows NT 4 используют NULL-сеансы для
определения разрешений модема и других параметров его настройки, типа номеров
телефона повторного вызова (call-back) для удаленных пользователей. По умолчанию Active
Directory не принимает запросы к атрибутам объектов при использовании NULL-сеансов.
Без надлежащего планирования взаимодействие служб удаленного доступа в смешанной
среде может вызвать отказ в сетевом удаленном доступе для законных пользователей,
связывающихся с системой через модем. Чтобы избегать RAS-конфликтов в процессе
модернизации, нужно как можно раньше обновить RAS-серверы Windows NT 4. Если в
процессе модернизации вы будете поддерживать смешанную среду, нужно понизить
заданную по умолчанию защиту Active Directory, выбирая опцию Permissions Compatible
With Pre-Windows 2000 Server Operating Systems (Разрешения, совместимые с
операционными системами, предшествующими Windows 2000 Server) при выполнении
мастера инсталляции Active Directory.
• Аппаратные средства сервера с Windows NT 4 Server и конфигурации программного
обеспечения. Это особенно важно для обновления, при котором вы планируете
продолжать использование имеющихся аппаратных средств сервера в модернизированной
среде домена. Должна быть уверенность в том, что любой сервер, который снова будет
использоваться в том же качестве, удовлетворяет требованиям, предъявляемым к
аппаратным средствам Windows Server 2003. Важно также задокументировать
программную конфигурацию каждого сервера для гарантии того, что все приложения и
службы будут учтены в новой среде. Для контроллеров домена и серверов-членов домена,
этот список должен включать следующее:
o количество процессоров и их скорость;
o оперативная память;
o системы хранения информации;
o NOS, выполняющаяся на каждом сервере. (Вы можете обнаружить, что у вас
имеется совокупность разных NOS, которые имеют различные пути
обновления.);
o операционная система, выполняющаяся на рабочих станциях. (Это определит то,
как вы реализуете системные политики и сценарии входа в систему.);
o все приложения, связанные с бизнесом, выполняющиеся на контроллере домена
с системой Windows NT 4. (Вы должны задокументировать, совместимы ли они с
Windows Server 2003 и следует ли их проверять на новой платформе.)
Данный список - это только основа. Вы должны тщательно исследовать вашу сеть для выявления
проблем, которые могут помешать осуществлению ваших планов. Теперь, когда вы имеете ясное
представление о той точке, где вы находитесь, т.е. о пункте А, пришло время планировать ваше
путешествие в пункт Б.
Создание сценария развертывания
Сценарий развертывания модернизации - это пошаговый список задач и порядок их выполнения.
Этот документ будет вашей инструкцией до тех пор, пока не придет время «повернуть
выключатель». К началу модернизации этот список должен быть проверен, пересмотрен и
переделан несколько раз.
Если выполняется обновление домена, то сценарий развертывания будет относительно прост: в
нем будут перечислены все модернизируемые PDC и BDC, порядок модернизации, действия,
которые вы предпримите для того, чтобы гарантировать продолжение работы сетевых служб в
процессе обновления, действия по проверке правильности выполнения. В плане развертывания
также будут перечислены пользователи, группы, компьютеры и учетные записи служб, которые
вы будете переносить, исходные и целевые домены. Будет выбрано время для выполнения
процесса модернизации, указаны действия, необходимые для переключения пользователей на
новую среду, уточнены шаги по проверке правильности перехода.
Практический опыт. Пример обновления домена
Приведем краткий пример модернизации через обновление домена. Курсивом
выделены все специфические для сайта имена и данные, которые в вашей среде
будут другими. В списке процедур обратите внимание на шаги проверки
правильности.
Чтобы выполнить модернизацию системы путем обновления домена, необходимы
следующие шаги.
1. Установите самый последний пакет обновлений к системе Windows NT 4 Server
на всех контроллерах домена Contoso.
2. Синхронизируйте все контроллеры домена в домене Contoso.
3. Сделайте резервную копию контроллера BDC по имени DC7 на магнитной ленте.
Выполните контрольное восстановление образа, чтобы проверить набор данных.
Спрячьте ленту в надежное место и пометьте ее как образ DC7, сделанный
перед обновлением.
4. Переведите DC7 в автономный режим и обеспечьте его безопасность. Теперь он
будет резервным сервером для отката.
5. С помощью Server Manager (Менеджер сервера) пошлите сетевое сообщение
пользователям, связанным с PDC по имени DC1 за один час до начала
обновления NOS.
6. Запустите обновление NOS контроллера DC1, после того как все пользователи
отключатся. (Этот процесс включает установку Active Directory и может занимать
несколько часов.)
7. После окончания процесса обновления и последующей перезагрузки
контроллера DC1 выполните следующие действия по проверке правильности
перехода.
• Проверьте журнал регистрации событий, чтобы убедиться в отсутствии
ошибок, которые могут возникнуть при запуске служб (контроллер домена,
DNS, WINS, RAS).
• Откройте оснастку Active Directory Users And Computers (Пользователи и
компьютеры Active Directory). Проверьте, что учетные записи
пользователя были модернизированы должным образом.
• Войдите в систему как тестирующий обновление пользователь с именем
Upgradel, пароль = P@sswOrd. Задокументируйте результаты входа в
систему в тестовом документе в папке проекта. Доложите менеджеру
проекта, если вход не был успешным.
• Обратитесь к общей папке \\ ITStaff\Policies\ и откройте файл
PersonalSoftware.doc. Сделайте изменения и сохраните этот файл.
Открылась ли эта папка? Открылся ли этот файл? Возникли какие-либо
ошибки?
И так далее. Ваша процедура должна быть достаточно детализирована, чтобы ее можно было
легко выполнять, не полагаясь на память. Полагаться на свою память, когда под угрозой
находится сетевой доступ всех пользователей домена — это плохая идея.
Наилучшая практика. В процедуре, описанной в разделе «Практический опыт»,
дана инструкция входить в систему с учетной записью тестера Upgradel. Хорошей
практикой является создание такого количества учетных записей тестера, сколько
вам потребуется для проверки доступа к сети после обновления или
реструктуризации. Учетная запись тестера может быть сконфигурирована без
необходимости полагаться на правильную установку разрешений для реальной
учетной записи или на вашу собственную административную учетную запись, у
которой не будет проблем со входом в систему, с которыми может столкнуться
учетная запись, не имеющая административных разрешений. Возможно, что вы
захотите иметь одну учетную запись для тестирования входа в локальную сеть
(LAN), другую - для входа в систему с удаленного сайта, и еще одну - для
тестирования удаленного доступа.
Теперь, когда вы уточнили все, что будете делать при успешном ходе событий, пришло время
задокументировать, какие действия вы будете выполнять, если процесс пойдет неправильно, т.е.
план восстановления системы при сбое
Проектирование плана восстановления
Ваш план восстановления системы в случае сбоя, или, более оптимистично, просто план
восстановления, эквивалентен плану модернизации, но он используется тогда, когда действия по
проверке правильности модернизации окончились неудачей. Определите в вашем плане
модернизации не только то, что вы будете делать для проверки правильности шагов, выполняемых
в процессе перехода, но и то, что вы сможете сделать для восстановления домена до последнего
работоспособного состояния. Так вы сможете поддерживать доступ к ресурсам для ваших
пользователей, найти ошибки в плане модернизации и попробовать все снова. В следующем
разделе рассмотрено планирование восстановления системы после сбоя в процессе перехода к
Active Directory.
Восстановление системы после неудавшегося обновления домена
Чтобы приготовиться к восстановлению системы в случае неудавшегося обновления домена,
выполните следующее.
1. Добавьте BDC ко всем доменам Windows NT 4 с одним контроллером домена. Это будет
гарантировать путь восстановления в случае сбоя при обновлении единственного
контроллера домена в домене.
2. Синхронизируйте все контроллеры BDC с PDC. Это будет гарантией того, что база данных
SAM содержит самые свежие данные.
3. Сделайте резервную копию контроллера PDC. Выполните контрольное восстановление
резервного набора данных, чтобы проверить, что резервирование прошло успешно.
4. Переведите полностью синхронизированный BDC в автономный режим и обеспечьте его
безопасность. Тем самым вы сохраните копию базы данных SAM, которую в случае
необходимости можно использовать для восстановления домена без необходимости
повторно устанавливать сервер и восстанавливать резервную копию.
5. Периодически подключайте этот защищенный BDC контроллер назад к сети и
перезагружайте его. Это сохранит актуальность базы данных SAM. Делайте это
обязательно, когда домен все еще находится на смешанном уровне Windows 2000 или на
временном (interim) уровне Windows Server 2003 (если нет контроллеров домена с
системой Windows 2000 Server). После того как функциональный уровень домена будет
поднят, вы не сможете реплицировать между контроллерами домена Windows Server 2003
и BDC более низкого уровня.
Чтобы восстановить систему PDC контроллера после неудавшегося обновления домена,
выполните следующие действия.
1. Выключите обновленный контроллер домена. Он считается PDC контроллером в домене
Windows NT 4 и будет мешать успешному выполнению следующего шага.
2. Подключите автономный BDC назад в сеть и назначьте его на роль PDC контроллера. Это
действие запустит репликацию сохраненной базы данных SAM на все оставшиеся в сети
BDC контроллеры с системой Windows NT 4.
Выполняя эту процедуру, вы восстановите свою сеть, основанную на Windows NT 4, до рабочего
состояния. Оставшиеся задачи восстановления состоят в том, чтобы расследовать причины
неудавшегося обновления, соответствующим образом откорректировать свой план развертывания
и начать сначала.
Восстановление системы после неудавшейся реструктуризации домена
Так как вы переносите учетные записи из домена Windows NT 4 в Active Directory Windows Server
2003, то ваш план восстановления в случае сбоя будет относительно прост. Процесс
реструктуризации домена - это не-разрушающий процесс, среда Windows NT 4 будет полностью
функционировать в процессе перехода. Если перемещение учетных записей окончится неудачей,
это вызовет определенные неудобства, но не затронет возможностей функционирования
пользователей в сети Windows NT 4.
Чтобы гарантировать возможность восстановления системы после неудавшейся реструктуризации
домена, выполните следующие действия.
1. Добавьте BDC ко всем доменам Windows NT 4, которые имеют только один контроллер
домена. Это будет гарантировать путь восстановления в том случае, если произойдет сбой
при обновлении единственного контроллера домена в домене.
2. Синхронизируйте все контроллеры BDC с PDC. Это будет гарантировать актуальность
базы данных SAM.
3. Сделайте резервную копию контроллера PDC. Выполните контрольное восстановление
резервного набора данных, чтобы проверить, что резервирование прошло успешно.
Если реструктуризация домена окончится неудачей, план восстановления состоит в том, чтобы
продолжить работу в среде Windows NT 4, расследовать причины неудачи, проверить план
развертывания и пробовать снова. Если база данных SAM системы Windows NT 4 разрушена в
процессе перемещения учетных записей, используйте резервную копию для восстановления базы
данных учетных записей. Разрушение данных проявит себя тем, что не все объекты появятся в
User Manager (Менеджер пользователей), или пользователи не смогут войти в систему.
Тестирование плана модернизации
Есть несколько серьезных оснований для тестирования вашего плана модернизации.
• Тестирование подтвердит, что действия по обновлению приведут к желаемым результатам.
• Тестирование даст возможность определить время, необходимое для полного завершения
модернизации.
• Тестирование даст возможность ознакомиться с инструментальными средствами и
процедурами, которые вы будете использовать при переходе к Active Directory.
Не забудьте проверить все элементы перехода. Рассмотрите ваш план и создайте набор тестов для
всех процедур, которые вам надо будет выполнить. Не забудьте также протестировать план
восстановления, так как момент отката к домену Windows NT 4 — не самое подходящее время для
обнаружения ошибки в вашем плане. Если тестирование показывает ошибки, модифицируйте план
и повторно проверяйте его до тех пор, пока он не будет работать так, как нужно.
Наилучшая практика. При тестировании вашего плана перехода создайте испытательную среду,
похожую на вашу производственную среду. Удостоверьтесь, что испытательная среда полностью
изолирована от производственной.
Проведение экспериментальной модернизации
Прежде чем развертывать модернизацию по всей организации, нужно провести
экспериментальный откат перехода с ограниченной и управляемой группой пользователей. Это
даст вам возможность тщательно проанализировать результаты перехода в управляемой среде
перед выполнением полного плана модернизации. Экспериментальный откат имеет несколько
преимуществ.
• Тестирует ваш план перехода в производственной среде.
• Позволяет обнаружить непредвиденные ошибки в плане модернизации.
• Дает возможность ознакомиться с инструментальными средствами модернизации.
Экспериментальная модернизация даст вам возможность оценить результаты вашего плана и
внести изменения. Не забудьте повторно проверить любые модификации и развернуть их в
экспериментальной группе перед развертыванием модернизации во всей организации.
Примечание. Вы не сможете сделать экспериментальное обновление домена. Это событие
происходит по принципу «все или ничего». Однако если у вас будет такая возможность, вы
должны сначала модернизировать меньший домен, а затем заняться большим.
Реструктуризация доменов может проводиться в несколько стадий. Воспользуйтесь этим
преимуществом, развертывая реструктуризацию в контрольной группе пользователей.
Как только экспериментальное развертывание закончено, и все ошибки в плане модернизации
выявлены и исправлены, вы можете переходить к Active Directory Windows Server 2003.
Обновление домена
Обновление домена - это вторая стадия процесса перехода к Windows Server 2003. (Первая стадия
- обновление NOS.) При обновлении контроллера домена, на котором выполняются системы
Windows NT 4 Server или Windows 2000 Server, после модернизации NOS и перезапуска
компьютера мастер инсталляции Active Directory запускается автоматически. По окончании
работы мастера служба каталога будет модифицирована до Active Directory Windows Server 2003.
Дополнительная информация. Для получения дополнительной информации о
проектировании структуры Active Directory см. гл. 5. Для получения дополнительной
информации об использовании мастера инсталляции Active Directory см. гл. 6.
В зависимости от версии Windows в процессе обновления выполняются различные действия.
Первая часть этого раздела описывает процессы обновления домена с системой Windows NT 4
Server, вторая — домена с системой Windows 2000 Server.
Примечание. Если у вас установлена более ранняя версия системы, чем Windows NT 4, вы не
можете обновить ее сразу до Windows Server 2003. Сначала модернизируйте ее до Windows NT 4
и примените комплект обновлений Service Pack 5 (или более поздний) перед обновлением
операционной системы.
Обновление Windows NT 4 Server
При обновлении Windows NT 4 Server до Active Directory Windows Server 2003 вначале
модернизируется операционная система, а после перезагрузки компьютера завершается
обновление домена. В этом разделе описано, как проводить подготовку и выполнение обновления
от Windows NT 4 Server к Active Directory.
Дополнительная информация. В этом разделе обсуждаются только вопросы обновления
до Active Directory Windows Server 2003. Поскольку вначале выполняется обновление
операционной системы Windows NT 4 Server до Windows Server 2003, необходимо
предварительно ознакомиться с техническими требованиями для модернизации NOS. Для
получения дополнительной информации для небольших инсталляций (от одного до пяти
серверов) смотрите страницу «Installing and Upgrading the Operating System (Установка и
обновление операционной системы)» на веб-сайте Microsoft по адресу http://
www.microsoft.com/technet/prodtechnol/windowsserver2003/
proddocs/entserver/ins.
Информацию для больших инсталляций смотрите в статье Microsoft Windows Server 2003
Deployment Kit (Комплект развертывания Windows Server 2003) по адресу http://
www.microsoft.co7n/windowsserver2003/techinfo/reskit/ deploykit.mspx.
Прежде чем начать
Перед началом обновления выполните несколько действий на PDC контроллере с системой
Windows NT 4, который должен быть модернизирован.
• Очистите базу данных SAM. Помните, что при обновлении домена все в ней будет
обновлено до Active Directory. Велика вероятность того, что очистка уменьшит количество
учетных записей, которые будут перемещаться в Active Directory, уменьшив тем самым
потребное дисковое пространство на контроллерах домена Windows Server 2003. Имейте в
виду, что существующая база данных учетных записей пользователей при обновлении до
Active Directory может увеличиться в 10 раз. При очищении SAM с помощью инструмента
администрирования Windows NT 4 User Manager For Domains (Менеджер пользователей
для доменов) или с помощью команды Net User (Пользователь сети) происходит
следующее:
o удаление дублированных учетных записей пользователей;
o объединение дублированных групп учетных записей;
o удаление неиспользуемых учетных записей пользователей, групп и компьютеров;
o удаление учетных записей локальных групп для ресурсов, которые больше не
существуют;
o установка комплекта Service Pack 5 для Windows NT 4 или более позднего. Вы
можете загрузить все поддерживаемые комплекты обновлений для Windows NT 4 с
веб-сайта
Microsoft
по
адресу
http://www.microsoft.com/ntserver/nts/downloads/default.asp.
Сначала обновляем PDC
Первый контроллер домена, который нужно модернизировать в вашем домене Windows NT 4 - это
PDC. Если вы попытаетесь модернизировать BDC раньше, чем PDC, произойдет ошибка, потому
что домены, основанные на системе Windows NT 4, могут иметь только один PDC. Все
контроллеры домена Windows Server 2003 в действительности являются контроллерами PDC по
отношению к домену Windows NT 4, поэтому модернизируйте сначала PDC, чтобы не нарушить
это правило.
Наилучшая практика. Вместо обновления существующего PDC вашего домена
наилучшая практика состоит в том, чтобы построить чистый BDC с Windows NT 4,
назначить его на роль PDC, a затем обновить тот контроллер домена до Windows
Server 2003. Этот дополнительный шаг гарантирует, что вы начнете обновление с
контроллера домена, который по аппаратным средствам совместим с Windows
Server 2003, и что сервер не будет иметь истории модификаций, которые могут
предотвратить чистое обновление.
После окончания этого процесса и проверки на повреждения сети и службы каталога вы можете
добавлять другие контроллеры домена, инсталлируя новые или модернизируя существующие
BDC. Пока вы находитесь на смешанном функциональном уровне Windows 2000 или пока вы не
поднимете его до временного (interim) уровня Windows Server 2003, вы сможете поддерживать
контроллеры домена Windows Server 2003 и резервные контроллеры домена с системой Windows
NT 4. Когда и как быстро вы будете модернизировать контроллеры BDC, зависит от вас.
Когда все контроллеры домена модернизированы до Windows Server 2003, можно поднять
функциональные уровни домена и леса. Для получения дополнительной информации о
функциональных уровнях смотрите раздел «Представление о функциональных уровнях» далее в
этой главе.
Чтобы модернизировать контроллеры PDC, выполните следующие действия.
Вставьте компакт-диск с Windows Server 2003 в CD-ROM. Если ваш CD-ROM разрешает
Autorun (Автоматическое выполнение), автоматически запустится программа Setup
(Установка). Вы можете также запустить файл Setup.exe из корневой папки компакт-диска
вручную.
При запуске программы Setup выберите опцию Install Windows Server 2003 (Установка
Windows Server 2003).
После того как программа Setup соберет информацию о вашей текущей операционной системе,
выберите опцию Upgrading To Windows Server 2003 (Обновление до Windows Server 2003).
Введите информацию, необходимую для завершения программы Setup.
Когда обновление системы до Windows Server 2003 закончится, компьютер будет
перезагружен, после чего автоматически начнет работать мастер инсталляции Active
Directory.
Выполните мастера инсталляции Active Directory в соответствии с вашим проектом Active
Directory. После того как инсталляция закончится, ваш компьютер будет перезагружен, и
обновление до Active Directory завершится.
Проверка обновления до Active Directory
Для проверки установки службы Active Directory на модернизированном» контроллере домена
нужно выполнить несколько действий. Некоторые из этих действий имеют характер
диагностических тестов, другие -функциональных. Давайте сначала рассмотрим функциональное
тестирование.
• Проверьте, что все учетные записи пользователей, групп и компьютеров перемещены в
Active Directory. Для этого откройте инструмент Active Directory Users And Computers
(Пользователи и компьютеры Active Directory) и просмотрите список объектов учетных
записей. Возможно, вы не сможете проверить каждую, но обязательно следует выбрать
несколько учетных записей Windows NT 4 и проверить, что они существуют на
модернизированном контроллере домена.
• Проверьте доверительные отношения с помощью инструмента Active Directory Domains
And Trusts (Домены и доверительные отношения Active Directory).
• Проверьте системный журнал Event Viewer (Средство просмотра событий) в поисках
каких-либо ошибок, которые могли произойти при запуске службы Active Directory.
• Проверьте, можете ли вы создавать новых пользователей на контроллере домена Windows
Server 2003. На модернизированном контроллере домена откройте инструмент Active
Directory Users And Computers и создайте новую контрольную учетную запись
пользователя.
• Проверьте, могут ли пользователи входить в домен. С компьютера, находящегося в
домене, попытайтесь войти в систему с модернизированной учетной записью
пользователя. Для этой цели вы можете использовать «живую» учетную запись
пользователя или перед обновлением создать контрольную учетную запись.
• Проверьте репликацию на BDC контроллеры. После создания нового контрольного
пользователя откройте User Manager For Domains на BDC с системой Windows NT 4 Server
и проверьте, что пользователь реплицируется. Вы можете отсоединить контроллер домена
Windows Server 2003 от сети и войти в сеть как контрольный пользователь, чтобы BDC с
системой Windows NT 4 обработал запрос входа в систему.
Средства диагностики Active Directory расположены в комплекте Support Tools (Средства
поддержки) на компакт-диске Windows Server 2003. Вы можете установить эти средства на
обновленном контроллере домена с Windows Server 2003, выполняя файл Suptools.msi из папки
\SUPPORT\TOOLS, расположенной на компакт-диске Windows Server 2003. Нужно выполнить
следующие действия по диагностической проверке.
Чтобы проверить способность к взаимодействию и функциональность Active Directory,
запустите инструмент Domain Controller Diagnostic (Диагностика контроллера домена) (в
командной строке напечатайте dcdiag). В результате успешного испытания возвращается
ряд сообщений «passed» (пройдено).
Дополнительная информация. Компонент Dcdiag инструмента Support Tool Windows
Server 2003 анализирует состояние контроллеров домена в лесу и дает детальную
информацию о том, как идентифицировать неправильное поведение в системе. Контроллеры
домена идентифицируются и проверяются согласно директивам, которые пользователь
вводит в командную строку. Для получения дополнительной информации об инструменте
Dcdiag напечатайте dcdiag/? в командной строке.
Если это не первый домен Active Directory в лесу, напечатайте repadmin/showreps в командной
строке, чтобы проверить успешность репликации между контроллерами домена Active
Directory. В результате успешного испытания возвращается соответствующее сообщение о
каждом событии репликации с входящими и исходящими партнерами по репликации.
Чтобы проверить успешность репликации на контроллеры BDC, напечатайте
nltest/bdc_query:domainname, где domainname — имя реп-лицируемого домена. В
результате успешного испытания возвращается сообщение «status = success (статус =
успех)» для каждого BDC контроллера в домене.
После проверки обновления PDC вы можете модернизировать контроллеры BDC.
Обновление BDC контроллеров
Возможно, что в модернизации BDC-контроллеров с системой Windows NT 4 нет никакой
необходимости. С обновлением PDC вся информация домена обновится до Active Directory
Windows Server 2003. После этого
можно ввести дополнительные контроллеры домена с Windows Server 2003 для поддержки
потребностей службы каталога домена, установив новые контроллеры домена с Windows Server
2003 или модернизируя существующие контроллеры BDC. Предпочтительно установить новые
контроллеры домена с Windows Server 2003, потому что таким образом устраняется риск,
связанный с обновлением BDC с неизвестной (или, что еще хуже, проблемной) историей. Новая
инсталляция Windows Server 2003 на этих дополнительных контроллерах домена гарантирует, что
компьютер будет находиться в чистом состоянии.
Когда выбирается модернизация BDC? Возможно, только в том случае, если имеются приложения,
выполняющиеся на BDC, которые неудобно или невозможно повторно установить на новом
контроллере домена.
Если вы решите, что необходимо провести обновление BDC, то этот процесс будет таким же, как
обновление PDC. Сначала модернизируете NOS, а после перезапуска компьютера воспользуетесь
мастером инсталляции Active Directory для установки Active Directory и назначения сервера на
роль контроллера домена. Мастер инсталляции Active Directory можно и fie выполнять. В этом
случае компьютер останется сервером-членом домена Windows Server 2003, а информация базы
данных SAM на этом сервере будет потеряна. Ваш проект Active Directory предписывает
потребное количество контроллеров домена, а в плане модернизации указано, какие из оставшихся
контроллеров BDC должны быть назначены контроллерами домена после обновления, а какие —
остаться серверами-членами домена.
Предотвращение перезагрузки контроллера домена
Перегрузка контроллера домена по сценарию обновления домена происходит, когда у вас есть
клиентские компьютеры с системами Windows 2000 Professional и/или Windows XP Professional в
домене, основанном на системе Windows NT 4, и вы модернизируете PDC до Windows Server 2003.
Такая ситуация может привести к перегрузке единственного контроллера домена, имеющего
Windows Server 2003. Это происходит потому, что компьютеры с системами Windows 2000
Professional и Windows XP Professional, присоединяющиеся к домену Active Directory, для
выполнения любых действий, требующих контакта с контроллером домена, будут
взаимодействовать только с контроллерами домена, на которых установлена система Windows
2000 Server или Windows Server 2003. Если у вас есть обновленные клиентские компьютеры или
новые, на которых выполняются вышеупомянутые операционные системы, вы должны
предпринять некоторые шаги для устранения риска, связанного с появлением единственной точки
возможного отказа (модернизированный PDC).
Предотвратить перезагрузку контроллера домена можно, если быстро добавить в сеть
контроллеры домена с Windows Server 2003. Если не предполагается немедленного обновления
всех BDC с системой Windows NT 4 Server или добавления новых контроллеров домена с Windows
Server 2003, можно изменить системный реестр на модернизированном PDC таким образом, чтобы
контроллер домена Windows Server 2003 эмулировал поведение контроллера домена с системой
Windows NT 4 для всех клиентов, на которых выполняются Windows 2000 Professional и Windows
ХР Professional. Чтобы включить режим эмуляции Windows NT 4, выполните следующие действия
на PDC с модернизированной системой Windows NT 4.
1. После того как компьютер был модернизирован от Windows NT 4 до Windows Server 2003,
до начала установки Active Directory откройте редактор системного реестра (напечатайте
regedit в диалоговом окне Run).
2. Создайте
значение
NT4EMULATOR
в
ключе
системного
реестра
HKEY_LOCAL_MACHINE\SYSTEM\CurrentContro lSet\Services\ Netlogon\Parameters.
3. Выберите Edit (Правка), затем New (Новый), а затем DWORD Value (Значение DWORD).
Замените имя New Value #1 именем NT 4Emulator и нажмите Enter.
4. В меню Edit щелкните на Modify(Изменить). В диалоговом окне Edit DWORD Value
(Правка значения DWORD) напечатайте 1 в текстовом поле Value Data (Данные), а затем
щелкните на ОК.
5. Сохраните изменения и закройте редактор системного реестра.
6. Запустите мастер инсталляции Active Directory, напечатав dcpromo в диалоговом окне Run.
Повторите этот процесс на каждом из недавно установленных контроллеров домена с Windows
Server 2003 или на каждом контроллере домена с модернизированной системой Windows NT 4,
пока не будет введено достаточное количество контроллеров домена с Windows Server 2003, чтобы
возможность перегрузки была устранена.
Имейте в виду, что это временное решение временной проблемы. После того как все
запланированные контроллеры домена с Windows NT 4 будут модернизированы до Windows
Server 2003, вы должны или установить значение NT 4Emulator на 0x0, или удалить ключ
системного реестра для каждого из модифицированных компьютеров.
Практический опыт. Нейтрализация эмуляции NT 4
Для некоторых компьютеров нужно будет изменить системный реестр так, чтобы
они игнорировали установку NT 4EMULATOR. Это компьютеры с Windows Server
2003 или Windows 2000, которые будут назначены контроллерами домена, и
компьютеры с Windows 2000 Professional или Windows XP Professional, которые
будут использоваться для управления доменом Active Directory. Имеется способ
дать им возможность входить в контакт с контроллерами домена Windows Server
2003 как обычно.
Чтобы нейтрализовать установку NT 4EMULATOR, выполните следующие действия.
Запустите редактор системного реестра (напечатайте regedit в диалоговом окне
Run).
Создайте
значение
NeutralizeNT4Emulator
в
ключе
HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\
Netlogon\Parameters.
Выберите Edit (Правка), затем New (Новый), а затем DWORD Value (Значение
DWORD). Замените имя New Value #1 именем NeutralizeNT4Emulator и
нажмите Enter.
В меню Edit (Правка) щелкните на Modify (Изменить). В диалоговом окне Edit
DWORD Value (Правка значения DWORD) напечатайте 1 в текстовом поле Value
Data (Данные), а затем щелкните на ОК.
После того как все BDC с Windows NT 4 будут установлены или модернизированы до Windows
Server 2003, обновление можно считать почти законченным. Заключительный шаг состоит в
поднятии функционального уровня домена и леса с уровня mixed Windows 2000 (значение по
умолчанию) к уровню Windows Server 2003.
Подъем функционального уровня
После того как вы модернизировали все контроллеры домена до Windows Server 2003, нужно
поднять функциональные уровни домена и леса, чтобы ощутить преимущества от обновления
сетевой операционной системы. Информацию о функциональных уровнях смотрите в разделе
«Представление о функциональных уровнях» далее в этой главе.
Чтобы поднять функциональный уровень домена, выполните следующие шаги на контроллере
домена в модернизированном домене.
1. Откройте инструмент Active Directory Domains And Trusts (Домены и доверительные
отношения Active Directory).
2. В дереве консоли щелкните правой кнопкой мыши на домене, функциональность которого
вы хотите поднять, а затем щелкните на Raise Domain Functional Level (Поднять
функциональный уровень домена).
3. В пункте Select An Available Domain Functional Level (Выберите доступный
функциональный уровень домена) выберите один из вариантов:
• чтобы поднять функциональный уровень домена до уровня Windows 2000 native
(естественный), щелкните на Windows 2000 Native, а затем щелкните на Raise
(Поднять);
• чтобы поднять функциональный уровень домена до уровня Windows Server 2003,
выберите Windows Server 2003, а затем щелкните на Raise.
После того как вы подняли функциональный уровень домена (по крайней мере, до естественного
(native) уровня Windows 2000), вы можете поднять функциональный уровень леса до Windows
Server 2003. Это обеспечит функционирование службы Active Directory по всему лесу. Чтобы
поднять функциональный уровень леса, выполните следующие действия.
Откройте инструмент Active Directory Domains And Trusts.
В дереве консоли щелкните правой кнопкой мыши на узле Active Directory Domains And
Trusts, а затем щелкните на Raise Forest Functional Level (Поднять функциональный
уровень домена).
В пункте Select An Available Domain Functional Level (Выберите доступный функциональный
уровень домена) выберите 2003 Windows Server, затем щелкните на Raise (Поднять).
Предостережение. Процедура поднятия функционального уровня домена или леса является
необратимой. Для восстановления более низкого уровня вы должны будете
деинсталлировать Active Directory (при этом после деинсталляции службы на последнем
контроллере домена домен будет удален), а затем повторно установить службу каталога.
Представление о функциональных уровнях
Функциональные уровни используются в Windows Server 2003, чтобы задействовать
соответствующий набор функций Active Directory для тех контроллеров домена, которые могут их
поддерживать. Уровень функциональности, который вы выберете для вашего предприятия,
диктуется версией операционной системы Windows, выполняющейся на контроллерах домена.
Функциональные уровни могут быть установлены и для домена, и для леса. Когда уровень леса
установлен на функциональный уровень Windows Server 2003, все функции Active Directory
доступны.
Концепция функциональных уровней подобна параметрам настройки смешанного и естественного
режима, которые были представлены в Windows Server 2000. Эти понятия были расширены в
Windows Server 2003, чтобы вместить дополнительные функции Active Directory. Функциональные
уровни используются для того, чтобы обеспечить обратную совместимость с контроллерами
доменов низкого уровня.
Имеются четыре функциональных уровня домена: Windows 2000 mixed (смешанный) (значение по
умолчанию), Windows 2000 native (естественный), Windows Server 2003 interim (временный) и
Windows Server 2003. Когда вы модернизируете все контроллеры домена низкого уровня,
имеющиеся в домене, до Windows Server 2003, вы должны поднять функциональный уровень
этого домена до уровня Windows Server 2003. Подъем функционального уровня домена от
смешанного Windows 2000 к естественному Windows 2000 или к Windows Server 2003 задействует
такие функции, как SID-History, Universal Groups (Универсальные группы) и вложенные группы.
Имеются три функциональных уровня леса: Windows 2000, Windows Server 2003 interim и
Windows Server 2003. Чтобы задействовать все функции Active Directory после того, как все
домены леса будут работать на функциональном уровне native Windows 2000 или выше, нужно
поднять функциональный уровень леса до уровня Windows Server 2003.
Предостережение. Не поднимайте функциональный уровень леса до уровня Windows Server 2003,
если у вас есть контроллеры домена, на которых выполняется система Windows NT 4 Server или
Windows 2000 Server. Как только функциональный уровень леса будет поднят до уровня Windows
Server 2003, его нельзя вернуть назад на уровень mixed или native Windows 2000, и вы не сможете
поддерживать контроллеры домена низкого уровня вашего леса.
Обновление Windows 2000 Server
Процесс обновления домена с Active Directory Windows 2000 Server до Active Directory Windows
Server 2003 более прост по сравнению с обновлением домена Windows NT 4. Сети, основанные на
системе Windows 2000, уже используют Active Directory в качестве службы каталога, поэтому этот
переход больше похож на сценарий чистого обновления, чем на модернизацию. В модернизации
системы Windows 2000 имеется несколько специфических шагов, о которых вы должны знать
перед началом обновления.
Вы должны «подготовить» домен с Active Directory Windows 2000 и лес для обновления до Active
Directory Windows Server 2003. Эти процессы обновят структуры существующих доменов и леса,
чтобы они были совместимы с новыми функциями Active Directory.
Наилучшая практика Перед подготовкой домена (и леса, в котором он расположен) вы должны
применить комплект обновления Windows 2000 Server Service Pack 2 (SP2), или более поздний, ко
всем контроллерам домена, на которых выполняется Windows 2000 Server. Вы можете загрузить
комплекты обновлений для Windows 2000 Server с веб-сайта Microsoft по адресу
http://www.microsoft.com/ windows2000/downloads /servicepacks/default, asp.
Подготовка леса
Чтобы подготовить лес Active Directory для обновления, используйте инструмент
администрирования Adprep.exe, чтобы сделать необходимые изменения к схеме Active Directory.
Помните, что этот процесс нужно выполнить прежде, чем будет начато обновление до Windows
Server 2003.
Чтобы подготовить лес к обновлению первого контроллера домена с Windows 2000 Server до
Windows Server 2003, выполните следующие действия.
Найдите сервер, который является хозяином схемы. Для этого откройте оснастку Active
Directory Schema Microsoft Management Console (Консоль управления схемой), щелкните
правой кнопкой мыши на узле Active Directory Schema (Схема Active Directory), а затем
щелкните на Operations Master (Хозяин операций). В диалоговом окне Change Schema
Master (Изменение хозяина схемы) найдите имя текущего хозяина схемы.
Сделайте резервную копию хозяина схемы. Возможно, вам потребуется восстановить этот
образ, если подготовка леса не будет успешной.
Отсоедините хозяина схемы от сети. Не восстанавливайте подключение до шага 8 в этой
процедуре.
Вставьте компакт-диск Windows Server 2003 в дисковод CD-ROM.
Откройте командную строку, перейдите на дисковод CD-ROM и откройте папку \I386.
Напечатайте adprep/forestprep. Вы должны быть членом групп Enterprise Admins
(Администраторы предприятия) и Schema Admins (Администраторы схемы) в Active
Directory, или вам должны быть делегированы соответствующие полномочия.
Чтобы проверить выполнение команды, откройте Event Viewer (Средство просмотра событий)
и проверьте системный журнал на предмет ошибок или неожиданных событий. Если вы
найдете сообщения об ошибках, связанные с процессом подготовки леса, займитесь этими
ошибками, прежде чем выполнять следующий шаг. Если вы не можете расследовать
ошибки, используйте инструмент диагностики Active Directory (напечатав dcdiag в
диалоговом окне Run), чтобы проверить функциональность контроллера домена. Если вы
не можете разобраться с этими ошибками, восстановите хозяина схемы из резервной
копии, исследуйте скорректированные действия и добейтесь, чтобы подготовка леса была
закончена успешно.
Если инструмент adprep/forestprep выполнился без ошибок, повторно подключите хозяина
схемы к сети.
На этом завершится подготовка леса к обновлению домена с Windows 2000 Server до Windows
Server 2003. Следующий шаг состоит в подготовке домена.
Совет. Перед началом подготовки домена подождите, пока изменения, сделанные в хозяине
схемы, будут реплицированы хозяину инфраструктуры. Помните, что если серверы находятся в
различных сайтах, вы должны ждать дольше, чтобы завершить репликацию. Если вы попробуете
выполнить процесс подготовки домена, прежде чем изменения будет реплицированы, сообщение об ошибках уведомит вам,
что необходимо еще подождать.
Подготовка домена
Подготовка домена очень похожа на подготовку леса. Для этого нужно найти и подготовить
держателя роли хозяина инфраструктуры вместо хозяина схемы.
Чтобы подготовить каждый домен для обновления первого контроллера домена с Windows 2000
Server до Windows Server 2003, выполните следующие действия.
Найдите сервер, который является хозяином инфраструктуры. Для этого откройте инструмент
администрирования Active Directory Users And Computers, щелкните правой кнопкой мыши
на узле домена, а затем щелкните на Operations Masters (Хозяева операций). На вкладке
Infrastructure (Инфраструктура) окна Operations Masters узнайте имя текущего хозяина
инфраструктуры.
На сервере, функционирующем как хозяин инфраструктуры, вставьте компакт-диск Windows
Server 2003 в дисковод CD-ROM.
Откройте командную строку, перейдите на дисковод CD-ROM и откройте папку \I386.
Напечатайте adprep/domainprep. Вы должны быть членом групп Domain Admins
(Администраторы домена) или Enterprise Admins (Администраторы предприятия) в Active
Directory, или вам должны быть делегированы соответствующие полномочия.
Для проверки выполнения команды откройте Event Viewer (Средство просмотра событий) и
поищите ошибки или неожиданные события в системном журнале. Если инструмент
adprep/domainprep выполнился без ошибок, значит, вы успешно подготовили домен к
обновлению с Windows 2000 Server до Windows Server 2003.
Повторим еще раз, что вы должны подождать до тех пор, пока изменения, сделанные на хозяине
инфраструктуры, не будут реплицированы на другие контроллеры домена леса перед обновлением
любого из контроллеров домена. Если вы начнете модернизировать один из контроллеров домена
прежде, чем изменения будут реплицированы, сообщение об ошибках уведомит вас, что
необходимо подождать.
Теперь, когда домен и лес подготовлены для обновления до Active Directory Windows Server 2003,
вы можете начинать.
Обновление контроллеров домена
В отличие от контроллеров домена с системой Windows NT 4 все контроллеры домена в сети, на
которых выполняется Windows 2000, являются в некотором смысле PDC контроллерами. Они
одинаково способны писать в базу данных Active Directory, подтверждать подлинность
пользователей и отвечать на запросы. За исключением держателей ролей хозяев операций все контроллеры домена равны. Это означает, что не имеет значения, какой
контроллер домена вы будете модернизировать первым.
Процесс обновления Windows 2000 такой же, как для обновления Windows NT 4 до Windows
Server 2003. Он состоит из двух шагов: модернизация NOS до Windows Server 2003 и выполнение
мастера инсталляции Active Directory.
Реструктурирование домена
Путь реструктуризации домена наиболее часто выбирается организациями, которые нуждаются в
изменении структуры своей службы Active Directory. Чтобы выполнить реструктуризацию домена,
вы сначала должны создать нужную структуру леса и домена, а затем переместить существующие
объекты Active Directory в эту новую структуру. Эта новая структура называется также «чистым»
лесом.
Примечание. Путь реструктуризации домена известен также как модернизация между лесами
(перемещение от одного леса Active Directory к другому). В этом случае главным является
перемещение с домена Windows NT 4 к Windows Server 2003, которое рассматривается как
процесс перехода между лесами. Реструктуризация Active Directory Windows 2000 до Active
Directory Windows Server 2003 в этой главе рассматривается как перемещение в пределах леса и
обсуждается в разделе «Обновление с последующей реструктуризацией».
Работа по перемещению объектов Active Directory (которые включают учетные записи
пользователей, групп и компьютеров, учетные записи доверительных отношений и служб)
облегчена за счет использования инструментов модернизации домена. Имеется множество средств
для выполнения этой задачи — и от компании Microsoft, и от сторонних производителей. Ниже
приводится список средств, имеющихся в настоящее время (или в ближайшей перспективе) у их
изготовителей. Убедитесь, что вы выбрали версию инструмента, которая поддерживает переход к
доменам Active Directory в Windows Server 2003. Включите в ваше планирование модернизации
домена задачу повторного исследования доступных инструментов перехода и определения
наиболее подходящего.
Active Directory Migration Tool (Инструмент модернизации Active Directory) (ADMT). Он
находится на компакт-диске Windows Server 2003 папке в \I386\ADMT. Дважды
щелкните на файле Admigration.msi для его установки.
Оценочная версия инструмента bv-Admin для модернизации Windows 2000 и Windows Server
2003 от корпорации BindView (http://www.bindview.com/products/Admin/winmig.cfm) можно
взять на веб-сайте продуктов компании.
Испытательная версия программы Domain Migration Administrator (Администратор
модернизации домена) (DMA) от компании NetlQ (http://www.netiq.com/products/dma/)
доступна для загрузки на веб-сайте продуктов компании.
Испытательная версия программы Domain Migration Wizard (Мастер модернизации домена)
(DMW) от компании Aelita Software (http:// www.aelita.com/products/DMW.htm) доступна
для загрузки на вебсайте продуктов компании.
Оставшаяся часть этого раздела будет посвящена концептуальным аспектам процесса
модернизации, а не деталям специфических инструментов. В случае необходимости процесс будет
описан в контексте инструмента модернизации Active Directory ADMT от Microsoft.
Прежде чем вдаваться в детали модернизации объектов, скажем несколько слов об организации
этого раздела. Следующие далее задачи разбиты на категории: реструктуризация доменов учетных
записей и доменов ресурсов. Эта несколько искусственная организация отражает существующую
доменную структуру сети, основанную на Windows NT 4, в которой предметная область состоит
из доменов учетных записей (они содержат учетные записи пользователей и глобальных групп) и
доменов ресурсов (они содержат учетные записи компьютеров, ресурсов и локальные группы,
которые используются для управления доступом к этим ресурсам). На рисунке 7-2 показана
организационная модель домена учетных записей и домена ресурсов.
Что делать, если вы не имеете доменов учетных записей и ресурсов в предметной области вашей
среды Windows NT 4? Тогда рассмотрите только содержимое, имеющее отношение к объектам
каталога, которые вы должны перенести. Это полезно только для обсуждения порядка
перемещения объектов и выполнения процесса модернизации.
Создание чистого леса
Чистый лес включает целевой домен Windows Server 2003, в который вы будете перемещать
учетные записи системы Windows NT 4, т.е. ваш пункт Б. При реструктуризации домена вы имеете
возможность создать оптимальную среду домена для вашей организации. Будем надеяться, что это
произойдет в конце длинного и вдумчивого процесса проектирования Active Directory, и все
компоненты вашей структуры Active Directory будут ясно определены в документе, описывающем
ваш проект. Для получения дополнительной информации о процессе проектирования см. гл. 5.
Рис. 7-2. Организационная модель домена учетных записей и домена ресурсов в системе
Windows NT 4
Совет. При установке Active Directory в чистый лес в окне Permissions (Разрешения) мастера
инсталляции Active Directory выберите опцию Permissions Compatible With Pre-Windows 2000
Server Operating Systems (Разрешения, совместимые с операционными системами,
предшествующими Windows 2000). Эта установка позволяет анонимным учетным записям
пользователя обращаться к информации домена и требуется для клонирования участников
безопасности. Чтобы получить доступ к этой опции, вы должны выбрать опцию Custom
configuration (Выборочная конфигурация) в окне Custom Options (Выборочные опции) мастера
конфигурирования сервера.
После того как вы реализуете структуру своего целевого домена, нужно выполнить несколько
действий для подготовки к перемещению учетных записей.
Подъем функционального уровня
Чтобы выполнить реструктуризацию домена, целевой домен с Windows Server 2003 должен
работать на функциональном уровне native Windows 2000 или Windows Server 2003. Заданный по
умолчанию функциональный уровень домен для новой реализации Windows Server 2003 — mixed
Windows 2000. Если ваш целевой домен будет включать контроллеры домена с Windows 2000
Server и Windows Server 2003, то вы должны поднять функциональный уровень до уровня native
Windows 2000. Если ваш новый домен будет включать только контроллеры домена Windows
Server 2003, вы должны выбрать функциональный уровень Windows Server 2003. Имейте в виду,
что подъем функционального уровня домена является необратимым процессом, вы не можете
понизить его до предыдущего состояния.
Создание учетной записи модернизации
Первая учетная запись пользователя, которую вы захотите создать в вашем чистом лесу, будет
запись, необходимая для выполнения перемещения. Создавая специальную учетную запись
пользователя, вы можете гарантировать, что она будет удовлетворять всем требованиям защиты,
необходимой для выполнения задач, связанных с реструктуризацией домена. Кроме того, вы
поупражняетесь в наилучшей защитной практике — не входить в систему с использованием
учетной записи Administrator (Администратор). Например, вы можете создать новую учетную
запись пользователя (типа Migrator) или несколько учетных записей (Migrator 1, Migrator2 и т.д.),
если вы планируете иметь несколько доверенных администраторов, выполняющих перемещение.
Таким образом, вы сможете проследить события, выполненные каждым владельцем учетной
записи, и избежать наличия общедоступной учетной записи с административными привилегиями.
Учетные записи, использующиеся для модернизации учетных записей пользователей, групп и
служб, должна быть членами группы Domain Admins (Администраторы домена) в целевом домене,
если вы используете SID-History для сохранения доступа к ресурсам. Учетная запись должна быть
также членом группы Administrators (Администраторы) в исходных доменах Windows NT 4.
Создание доверительных отношений
Поскольку процесс перехода требует предоставления административных разрешений для учетных
записей из различных доменов, необходимо создать несколько доверительных отношений, чтобы
иметь возможность перенести учетные записи исходного домена в целевой домен. В целевом
домене Windows Server 2003 и в исходном домене Windows NT 4 создайте односторонние
доверительные отношения от каждого из исходных доменов (тот, кто доверяет) к целевому домену
(тот, кому доверяют).
После этого проверьте их, используя инструмент администрирования Active Directory Domains
And Trusts (Домены и доверительные отношения Active Directory) в Windows Server 2003 и
инструмент администрирования Server Manager (Менеджер серверов) в системе Windows NT 4
Server.
Изменение системного реестра
При создании безопасного канала связи между исходными и целевыми контроллерами домена на
исходном контроллере домена Windows NT 4 должен быть модифицирован системный реестр.
Если этого не сделать перед установкой ADMT, то инструмент выполнит изменения при первом
использовании. После того как ADMT сделает изменения системного реестра, необходимо будет
перезагрузить PDC.
Установка этого значения разрешает удаленные вызовы процедуры (RPC) по протоколу TCP,
нисколько не уменьшая защиту системы Windows NT 4. На исходном PDC откройте системный
реестр и создайте следующий ключ:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentContolSet\Control\Lsa.
Создайте значение TcpijpClientSupport, установив DWORD, равный 1.
Наилучшая практика. Если вы планируете переместить пароли учетных записей пользователя
одновременно с самими учетными записями (в противоположность тому, чтобы прекратить срок
действия пользовательских паролей в Windows NT 4 и заставить пользователей создавать новые
пароли при первом входе в систему домена с сервером Windows Server 2003), то вам сТпять
потребуется редактировать системный реестр. Чтобы поддержать перемещение паролей, на
исходном PDC отредактируйте (или создайте, если он еще не существует) следующий ключ
системного реестра:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Control\Lsa.
Для значения AllowPasswordExport установите DWORD, равный 1. Для получения
дополнительной информации о переносе паролей смотрите справку инструмента ADMT.
Установка Active Directory Migration Tool
Инструмент администрирования Active Directory Migration Tool (Инструмент перемещения Active
Directory) создан компанией Microsoft с целью модернизации объектов службы каталога. ADMT
может выполнять модернизацию между лесами и внутри леса. Перемещение с системы Windows
NT 4 на Windows Server 2003 — это пример модернизации между лесами. Инструмент ADMT
обеспечивает графический интерфейс пользователя (GUI) и интерфейс создания сценария, он
может выполняться на целевых контроллерах домена в системе Windows 2000 и Windows Server
2003.
Инструмент ADMT версии 2.0, имеющийся на компакт-диске Windows Server 2003, поддерживает
следующие задачи, необходимые для модернизации домена:
• перемещение учетных записей пользователей;
• перемещение учетных записей групп;
• перемещение учетных записей компьютеров;
• перемещение учетных записей служб;
• перемещение доверительных отношений;
•
•
•
•
перемещение каталога Exchange;
перевод защиты на мигрированные учетные записи компьютеров;
сообщения о просмотре результатов модернизации;
функциональные возможности отмены последнего перемещение и повтор последнего
перемещения.
Одно из» преимуществ ADMT по сравнению с другими инструментами состоит в том, что это
средство включено в продукт Windows Server 2003. Инсталляционная папка расположена на
компакт-диске Windows Server 2003 в папке \I386\ADMT.
Дополнительная информация. Вместе с инсталляционными файлами ADMT папка ADMT
на компакт-диске Windows Server 2003 содержит документ Readme.doc, в котором хранится
важная информация, касающаяся ADMT. Обязательно прочтите этот документ перед
установкой инструмента ADMT или его использованием. Наиболее свежую версию этого
документа смотрите на веб-сайте Windows 2000 Active Directory Migration Tool по адресу:
http://www.microsoft.com/windows2000/downloads/ tools/admt/default.asp. С этого сайта можно
также загрузить сам инструмент ADMT. Убедитесь, что он совпадает или является более
новым, чем версия, имеющаяся на компакт-диске Windows Server 2003.
Чтобы установить инструмент ADMT на целевом контроллере домена, выполните следующие
действия.
1. Откройте папку \I386\ADMT на компакт-диске Windows Server 2003.
2. Дважды щелкните на файле Admigration.msi, чтобы установить ADMT на вашем
компьютере.
3. Примите лицензионное соглашение и заданные по умолчанию параметры на страницах
мастера.
После того как инструмент ADMT будет установлен, его можно запустить из папки Administrative
Tools (Средства администрирования) в
меню Start (Пуск). Инструмент ADMT запускается как оснастка ММС вместе со всеми мастерами,
доступными из меню Action (Действие) (см. рис. 7-3).
Рис. 7-3. Мастера, доступные в инструменте ADMT Разрешение аудита в исходных и
целевых доменах
Процесс реструктуризации домена требует, чтобы был включен аудит отказов и успехов операций
управления учетными записями и в исходном, и в целевом доменах.
Чтобы разрешить аудит в целевом домене Windows Server 2003, выполните следующие действия.
1. Откройте инструмент администрирования Active Directory Users And Computers
(Пользователи и компьютеры Active Directory), щелкните правой кнопкой мыши на
контейнере Domain Controllers (Контроллеры домена) и выберите Properties (Свойства).
2. В окне Domain Controllers Properties (Свойства контроллера домена) выберите вкладку
Group Policy (Групповая политика).
3. Выберите Default Domain Controllers Policy (Заданная по умолчанию политика
контроллеров домена) и щелкните на кнопке Edit (Правка).
4. Раскройте пункт Default DomainControllers Policy\Computer Conf iguration\ Windows
Settings\Security Settings\Local Policies\ Audit Policy (Заданная по умолчанию политика
контроллеров домена\Кон-фигурация компьютера\Параметры настройки Windows\
Параметры настройки защиты\Локальные политики\Политика аудита), дважды щелкните
на Audit Account Management (Управление аудитом учетных записей), а затем выберите
обе опции: Success (Успех) и Failure (Отказ).
5. Вызовите принудительную репликацию этого изменения на все контроллеры домена в
домене или подождите, пока изменения будут реп-лицированы автоматически.
Чтобы разрешить аудит в исходном домене Windows NT 4, выполните следующие действия.
Откройте инструмент администрирования User Manager For Domains (Менеджер
пользователей для доменов), выберите Policies (Политики), а затем выберите Audit
(Аудит).
Проверьте, что опция Audit These Events (Проводить аудит этих событий) выбрана и что для
User And Group Management (Управление пользователями и группами) выбраны опции
Success (Успех) и Failure (Отказ). Кроме того, нужно создать новую локальную группу на
исходном контроллере домена для целей внутреннего аудита ADMT. Имя этой новой
группы — sourcedomainname$$$ (например, Contoso$$$). ADMT создаст группу
автоматически при первом запуске, если вы не создадите ее заранее.
Изменение анонимного доступа к целевому домену
Если вы не выберете опцию Permissions Compatible With Pre-Windows 2000 Server Operating
Systems (Разрешения, совместимые с операционными системами, предшествующими Windows
2000 Server ), при установке Active Directory можно добавить группу Everyone (Все) к группе PreWindows 2000 Compatible Access (Доступ, совместимый с операционными системами,
предшествующими Windows 2000), напечатав net localgrowp "Pre-Windows 2000 Compatible
Access" everyone /add в командной строке и нажав Enter.
После того как сделано изменение группового членства, нужна гарантия, что разрешения группы
Everyone (Все) применяются к анонимным пользователям. Откройте инструмент Active Directory
Users And Computers (Пользователи и компьютеры Active Directory), щелкните правой кнопкой
мыши на контейнере Domain Controllers (Контроллеры домена) и выберите Properties (Свойства).
На вкладке Group Policy (Групповая политика) отредактируйте объект Default Domain Controllers
Policy (Заданная по умолчанию групповая политика). В поле Group Policy Object Editor (Редактор
объектов групповой политики) раскройте опцию Default Domain Controllers Policy\Computer
Configuration\Windows Settings\Security Settings\Local Policies\Security Options (Заданная по
умолчанию политика контроллеров домена\Конфигурация компьюте-ра\Параметры настройки
Windows\Параметры настройки защиты\Ло-кальные политики\Опции защиты) и дважды щелкните
на Network Access: Let Everyone Permissions Apply To Anonymous Users (Сетевой доступ:
Разрешения группы Все применять к анонимным пользователям). Отметьте опцию Define This
Policy Setting (Определить настройки этой политики), выберите Enabled (Разрешено), а затем
щелкните на ОК.
Перемещение доменов учетных записей
Домен учетных записей Windows NT 4 содержит учетные записи пользователей и групп, которые
обращаются к сетевым ресурсам. Согласно сценарию перехода путем реструктуризацией домена
вы будете перемещать объекты службы каталога в доменах учетных записей перед перемещением
доменов ресурсов. Этот порядок операций предпочтителен, потому что при этом сохраняется
доступ к ресурсам в процессе перехода.
Чтобы переместить домен учетных записей, выполните следующие действия.
Установите доверительные отношения между целевым доменом Windows Server 2003 и
доменом ресурсов Windows NT 4.
Переместите учетные записи глобальной группы.
Переместите учетные записи пользователей (с паролями или без).
Это лучшая практика для перемещения домена учетных записей.
Установление доверительных отношений
Чтобы сохранить доступ к ресурсам для пользователей, нужно создать односторонние
доверительные отношения от каждого домена Windows NT 4, содержащего ресурсы, к которым
должны обращаться перемещенные пользователи, к целевому домену Windows Server 2003.
Создание доверительных отношений состоит из двух шагов.
Первый шаг выполняется на контроллере целевого домена с Windows Server 2003. Добавьте
каждый домен ресурсов с системой Windows NT 4 к списку Domains That Trust This Domain
(Домены, которые доверяют этому домену) в окне Properties (Свойства) целевого домена,
используя инструмент Active Directory Domains And Trusts. Чтобы защитить эти доверительные
отношения, создайте пароль, который потребуется при формировании второй половины
доверительных отношений.
Второй шаг выполняется на PDC домена ресурсов с системой Windows NT 4. С помощью User
Manager For Domains (Менеджер пользователей для доменов) добавьте целевой домен Windows
Server 2003 к разделу Trusted Domains (Доверенные домены). Чтобы выполнить эту задачу, вам
потребуется пароль, созданный на первом шаге. Будет получено сообщение о статусе, если
доверительные отношения успешно создадутся.
Перемещение учетных записей глобальных групп
Порядок операций при перемещении учетных записей следующий: сначала глобальные группы, а
затем пользователи. Такой порядок позволяет сохранить групповое членство, когда учетные
записи пользователя перемещаются в целевой домен позже, и доступ к ресурсам. Когда вы
перемещаете глобальные группы с Windows NT 4 на Windows Server 2003, создаются новые
идентификаторы SID для новой глобальной группы. SID исходного домена добавляется к атрибуту
SID-History для каждого объекта новой группы. Сохраняя SID исходного домена в поле SID-History, пользователи могут
продолжать обращаться к ресурсам, расположенным в домене ресурсов с Windows NT, которые
еще не перемещены.
Клонируя учетные записи глобальных групп (используя ADMT), вы создадите структуру
скелетной группы в целевом домене согласно вашему проекту Active Directory. Поскольку
учетные записи пользователя переместятся позже, они будут автоматически присоединены к
группе, членами которой они были в исходном домене.
Процесс перемещения глобальных групп с Windows NT 4 на Windows Server 2003 при помощи
Group Account Migration Wizard (Мастер модернизации учетных записей групп) инструмента
ADMT несложен.
Чтобы перенести глобальные группы с Windows NT 4 на Windows Server 2003 с помощью Group
Account Migration Wizard, выполните следующие действия.
1. Идентифицируйте исходные и целевые домены. Если имена доменов не появляются в
раскрывающемся списке, их можно напечатать.
2. Выберите глобальные группы Windows NT 4, которые вы хотите переместить на Windows
Server 2003.
3. Выберите OU, к которой вы хотите добавить глобальные группы в целевом домене.
Примечание. Инструмент ADMT дает возможность выбрать только одну OU в качестве
контейнера адресата для перенесения учетных записей глобальных групп. Имейте это в виду,
планируя модернизацию ваших глобальных групп. Вместо выбора всех исходных глобальных групп
можно выбрать все группы, которые будут перемещаться в определенную OU. Затем повторно
выполняется мастер перемещения учетных записей групп для перемещения групп, которые
должны быть сохранены в другой OU.
4. Выберите желательные опции для группы. Сюда входят опция, позво-ляющаю копировать членов
группы одновременно с копированием группы. По умолчанию члены группы не должны
копироваться вместе с группой. Копирование членов группы одновременно с модернизацией
группы является хорошим выбором для маленьких организаций, в этом случае перемещение
группами - приемлемый многоступенчатый подход. В больших организациях глобальные группы
высшего уровня (типа служащих) имеют слишком большое количество пользователей, чтобы их
можно было переместить одновременно.
Как только глобальные группы перемещаются в Windows Server 2003, приходит время перемещения
учетных записей пользователя.
Перемещение учетных записей пользователя
Перемещение учетных записей пользователей не делается за один раз. Было бы неплохо тщательно
спланировать порядок этого перемещения и согласование во времени. Поскольку в процессе перехода будет
сохраняться доступ к ресурсам, связанным с Windows NT 4, этот процесс можно растянуть на дни, недели
или месяцы. При перемещении учетных записей пользователя следует иметь в виду следующее.
Сколько новых пользователей сможет поддерживать одновременно ваша ГГ-группа?
Какой набор пользователей должен перемещаться вместе?
Какой набор пользователей не сможет за определенное время приспособиться к неудобствам
реструктуризации домена?
Этими соображениями нужно руководствоваться при определении порядка и согласования во времени
процесса модернизации учетных записей пользователей. На первом шаге выбираются пользователи,
которые будут перемещаться одновременно, и время выполнения модернизации.
Фактическое перемещение учетных записей пользователя процедурно очень похоже на перемещение
учетных записей глобальных групп.
Чтобы переместить учетные записи пользователя с Windows NT 4 на Windows Server 2003 и в Active
Directory с помощью User Account Migration Wizard инструмента ADMT, выполните следующие действия.
1. Выберите исходные и целевые домены.
2. Выберите учетные записи пользователей в Windows NT 4, которые вы хотите переместить.
3. Выберите OU-адресата в целевом домене.
4. Подтвердите, что вы на самом деле хотите переместить пароли учетных записей пользователей.
Используя ADMT, вы можете выбрать одно из следующих действий.
• Создание новых, сложных паролей. Создается текстовый документ (формат значений,
отделенных запятой, [.csv]), который устанавливает соответствие между пользователями и новыми
паролями, затем решается задача связывания паролей с мигрированными пользователями.
• Установление пароля, совпадающего с именем пользователя. Пароль устанавливается на
значение username (имя пользователя). Поскольку эта опция и описанная выше создают риск для
безопасности, то для перемещенного пользователя в целевом домене устанавливается атрибут User
Must Change Password At Next Logon (Пользователь должен изменить пароль при следующем входе
в систему).
• Перемещение паролей. Эта опция позволяет переместить пользовательские пароли с исходного
домена в целевой домен, для чего требуется идентификация исходного контроллера домена
перемещаемых паролей.
Дополнительная информация. Исходным контроллером домена перемещаемых паролей
является контроллер домена в исходном домене, который сконфигурирован как Password
Export Server (Сервер экспорта паролей) (PES) путем установки DLL для модернизации
паролей. Модернизация паролей - это отдельный компонент ADMT, его можно установить
на любом контроллере домена (рекомендуется на BDC) в исходном домене с компакт-диска
Windows Server 2003. Чтобы установить DLL для модернизации паролей на контроллере
домена с Windows NT 4, откройте папку \I386\ADMT\PWDMIG и дважды щелкните на
файле Pwdmig.msi. Сервер PES обслуживает базу данных паролей пользователей исходного
домена и создает безопасный канал связи с целевым доменом для перемещения этих
паролей. Для получения дополнительной информации об установке и использовании
функции перемещения паролей смотрите документ Readme.doc в папке \I386\ADMT на
компакт-диске Windows Server 2003 или по адресу: http://www.7nicrosoft.co7n/
windows2000/downloads/tools/admt/default.asp.
5. Управляйте состоянием учетных записей с помощью опции перемещения учетных
записей. С помощью инструмента ADMT можно управлять переходом от исходной
учетной записи к целевой учетной записи в окне Account Transition Options (Опции
перехода учетных записей). Существует возможность управления состоянием учетной
записи целевого домена (разрешать, блокировать или уравнять ее с исходной учетной
записью) и учетной записи исходного домена (блокировать или разрешить на
установленное количество дней).
Наилучшая практика. Обычный сценарий состоит в том, чтобы перемещать партии
учетных записей пользователей, но не активизировать их, пока модернизация не
завершится. После завершения модернизации можно программно активизировать
все учетные записи пользователя и перейти к целевому домену. Из соображений
безопасности лучше не иметь учетных записей, которые активны в исходном и
целевом доменах одновременно. Если ваш план состоит в том, чтобы заставить
пользователей входить на домен Windows Server 2003 сразу после перехода,
используйте инструмент ADMT, чтобы отключить учетную запись исходного домена
в процессе перехода. Если вы хотите позволить пользователям иметь доступ к
домену Windows NT 4 в процессе перехода, используйте ADMT, чтобы отключить
исходный домен через несколько дней после запуска ADMT.
Прекращение эксплуатации домена учетных записей
Заключительный шаг в модернизации домена учетных записей к Windows Server 2003 состоит в
прекращении эксплуатации исходного домена, которое производится после проверки того, что
учетные записи нужных пользователей и групп перемещены к Windows Server 2003, а сетевые
службы работают в чистом лесу. Чтобы прекратить эксплуатацию домена учетных записей,
контроллеры домена просто выключают. Спустя некоторое время (в течение которого монитор
отслеживает любые перерывы в доступе к сети или ресурсам) контроллеры домена или
модернизируются до Windows Server 2003, или на них заново устанавливается операционная
система Windows Server 2003, а они назначаются контроллерами домена или остаются в роли
серверов-членов домена.
Наилучшая практика. Рекомендуется не прекращать эксплуатацию домена учетных
записей с системой Windows NT 4 до перемещения домена ресурсов, поскольку
совместно используемые локальные группы и локальные группы в доменах
ресурсов не смогут разрешать имена своих членов из домена учетных записей.
Вместо этого групповое членство для локальной группы будет отображаться как
«account unknown (учетная запись неизвестна)». Хотя это не влияет на доступ
пользователей к ресурсам, важно не удалять входы «account unknown», потому что
это нарушит доступ к ресурсам, сохраненным с помощью идентификатора SIDHistory. После того как все домены ресурсов будут реструктуризированы, можно
прекратить эксплуатацию исходных доменов с Windows NT 4.
Теперь, когда учетные записи глобальных групп и пользователей перемещены, процесс
модернизации домена учетных записей завершен. Ваши пользователи входят в домен Windows
Server 2003 и легко обращаются к их общедоступным сетевым ресурсам с домена ресурсов
Windows NT 4. Благодаря идентификатору SID-History и вашему опыту конечные пользователи не
почувствуют, что среда, в которой они работают, является смешанной, и будут работать как
обычно. Чтобы завершить проект реструктуризации домена в соответствии с вашим графиком
работ, теперь можно перемещать домены ресурсов в Windows Server 2003.
Перемещение доменов ресурсов
Чтобы переместить домены ресурсов, необходимо выполнить следующее.
Удовлетворить дополнительные требования защиты.
Идентифицировать учетные записи служб, выполняющихся на серверах-членах домена.
Переместить учетные записи компьютеров (серверы-члены домена и рабочие станции).
Переместить совместно используемые локальные группы.
Переместить учетные записи служб.
Прекратить эксплуатацию всех исходных доменов.
Дополнительные требования защиты
Чтобы разрешить перемещение ресурсов Windows NT 4 в Windows Server 2003, выполните
действия, связанных с защитой.
1. Удостоверьтесь, что группа Domain Admins (Администраторы домена) целевого домена
является членом локальной группы администраторов на домене ресурсов с системой
Windows NT 4. Это обеспечит необходимые административные права на каждом серверечлене домена и на каждой рабочей станции в домене ресурсов, чтобы вы могли
перемещать ресурсы домена.
2. Создайте второе доверительное отношение от целевого домена к домену ресурсов. В
разделе «Создание чистого леса» этой главы рассказывалось, как это сделать.
Устанавливая второе доверительное отношение, вы создаете два односторонних
доверительных отношения между доменом ресурсов и целевым доменом. Используйте
оснастку Active Directory Domains And Trusts (Домены и доверительные отношения Active
Directory) для проверки того, что это доверительное отношение было установлено.
Идентификация учетных записей служб
Учетные записи служб - это специальные учетные записи пользователей, которые используются
для оперирования службами, выполняющимися на компьютерах с системами Windows NT 4 и
Windows Server 2003. Большинство служб работают под учетной записью Local System Authority
(LSA) (Власти локальной системы). При модернизации домена ресурсов сначала нужно
идентифицировать службы, сконфигурированные так, чтобы не выполняться под учетной записью
LSA.
Модернизация учетных записей служб состоит из двух этапов. Сначала нужно идентифицировать
учетные записи служб. После перемещения компьютеров, на которых выполняется система
Windows NT 4, в целевой домен с Windows Server 2003 можно переносить учетные записи
идентифицированных служб.
Чтобы идентифицировать учетные записи служб, работающих на исходных доменах с Windows
NT 4, используя инструмент ADMT, выполните следующие действия:
1. Откройте Service Account Migration Wizard (Мастер модернизации учетных записей).
2. Выберите исходный и целевой домены.
3. В исходном домене выберите все компьютеры, на которых нужно найти учетные записи
служб. Чтобы выполнить эту задачу, вы должны посмотреть документацию, касающуюся
среды домена, которая существовала до модернизации. 4. Завершите выполнение Service
Account Migration Wizard.
Вся информация будет сохранена в базе данных ADMT, пока она не потребуется для фактического
перемещения учетных записей. Перемещение учетных записей служб происходит после
перемещения учетных записей самих компьютеров.
Перемещение учетных записей компьютеров
Учетные записи компьютеров, которые постоянно находятся в домене ресурсов Windows NT 4,
включают серверы-члены домена с Windows NT 4 Server, а также компьютеры с Windows NT
Workstation 4, Windows 2000 Professional и Windows XP Professional. При модернизации учетных
записей будут клонированы все учетные записи компьютеров из исходного домена в OU целевого
домена.
Примечание. Вы не сможете переместить учетную запись контроллера домена, потому что
нельзя изменить домен, к которому принадлежит контроллер домена с Windows NT 4 без
повторной установки операционной системы. Контроллеры домена должны быть «переведены»
в домен Windows Server 2003. Это «перевод» выполняется путем обновления операционной
системы до Windows Server 2003 и последующим назначением компьютера на роль контроллера
домена в целевом домене. После обновления операционной системы можно не устанавливать
Active Directory, а оставить модернизированный сервер членом домена в целевом домене. ,
Чтобы переместить учетные записи компьютеров с помощью инструмента ADMT, выполните
следующие действия.
Откройте Computer Migration Wizard (Мастер модернизации компьютеров).
Выберите исходный и целевой домены.
В исходном домене выберите учетные записи компьютеров, которые нужно перенести.
Выберите в целевом домене организационные единицы OU, в которые нужно перенести
учетные записи компьютеров.
Выберите любые компьютерные объекты, для которых нужно переместить защиту учетных
записей. При этом обновятся списки разграничительного контроля доступа (DACL) для
ресурсов, расположенных на перенесенных компьютерах, новыми идентификаторами SID
целевых доменов для учетных записей перемещенных групп и пользователей. Доступны
следующие объекты:
• файлы и папки;
• локальные группы;
• принтеры;
• системный реестр;
• совместно используемые ресурсы;
• пользовательские профили;
• пользовательские права.
Совет. Если вы решите не переводить защиту для перечисленных выше объектов в процессе
выполнения Computer Migration Wizard, это можно сделать позже, используя Security Translation
Wizard (Мастер перевода защиты) в инструменте ADMT. В состав мастера перевода защиты
входит такое же окно Translate Objects (Перевести объекты), как и в мастере модернизации
компьютеров. Вначале мастер перевода защиты спрашивает о том, хотите ли вы перевести
защиту для перемещенных объектов. Если мастер перевода защиты выполняется после
модернизации учетных записей компьютеров, выберите опцию Previously Migrated Objects (Ранее
перемещенные объекты).
Установите перезапуск перемещенного компьютера. Чтобы переместить компьютерную
учетную запись с одного домена на другой, инструмент ADMT посылает агента, чтобы
сделать изменение на самом компьютере. Процесс модернизации компьютерной учетной
записи завершается после перезапуска перемещенного компьютера. Инструмент ADMT
позволяет задать интервал времени между окончанием работы мастера и перезапуском
компьютера.
Выполните Computer Migration Wizard (Мастер модернизации компьютеров). После окончания
его работы щелкните на View Dispatch Log (Просмотр журнала отправки), чтобы
проверить урпешность работы агента отправки (dispatch agent). Этот компонент
обновляет членство компьютера в домене, а затем перезапускает компьютер. Журнал
регистрации отправки агента полезен для поиска неисправностей при неудавшейся
модернизации учетной записи компьютера.
Перемещение общих локальных групп
Общие локальные группы (shared local groups) — это просто локальные группы на контроллере
домена с Windows NT 4. Они используются для организации прав доступа. Если на вашем
предприятии существуют такие группы, то вы должны перенести их на целевой домен для
сохранения доступа к ресурсам для перемещенных пользователей. Процесс модернизации общих
локальных групп не сильно отличается от процесса модернизации глобальных групп, который был
описан выше.
Примечание. Модернизация локальных групп, расположенных на серверах-членах домена или
рабочих станциях, не является необходимой. Эти локальные группы используются для
предоставления доступа к ресурсам, находящимся на компьютере, и находятся в базе данных
SAM на сервере-члене домена или на рабочей станции. Поскольку база данных SAM всегда
перемещается с компьютером, то нет необходимости перемещать эти учетные записи. Вы
должны перевести защиту для этих локальных групп, чтобы обновить ссылки SID для новых
учетных записей домена. Посмотрите описание Computer Migration Wizard, приведенное выше в
этой главе, для получения дополнительной информации о переводе защиты в процессе
модернизации компьютера.
Чтобы переместить общие локальные группы, используя ADMT, выполните следующие действия.
1. Откройте Group Account Migration Wizard (Мастер модернизации учетных записей групп).
2. Выберите исходные и целевые домены.
3. Выберите общую локальную группу, которую нужно переместить.
4. Выберите организационную единицу OU, в которую нужно переместить учетную запись
группы.
5. Обязательно выберите опцию Migrate Group SIDs To Target Domain (Переместить SID
группы в целевой домен).
6. Позвольте мастеру перемещения учетной записи группы выполняться до завершения
модернизации общих локальных групп в целевой домен.
Перемещение учетных записей служб
После перемещения учетных записей компьютера на целевой домен можно завершать вторую
стадию процесса перемещения учетных записей служб. В начале процесса модернизации домена
ресурсов вы идентифицировали учетные записи служб, которые использовались для оперирования
службами серверов-членов домена. Теперь вы будете переносить учетные записи служб домена
ресурсов с Windows NT 4 на целевой домен Windows Server 2003. Эта процедура гарантирует, что
все службы, не выполняющиеся под LSA, будут запускать требуемые службы после того, как
сервер-член домена переместится в целевой домен.
Чтобы переместить учетные записи служб, используя ADMT, выполните следующие действия.
1. Откройте User Account Migration Wizard (Мастер модернизации учетных записей
пользователя).
2. Выберите исходные и целевые домены.
3. Выберите учетные записи служб, которые нужно переместить.
1. Совет. Если вы не помните имена учетных записей ранее идентифицированных учетных
записей служб, можно просмотреть журнал агентов отправки (Dctlog.txt), который
расположен в папке %userprofile %\Temp. Если вы вошли в систему Windows
2. Server 2003 как Migratorl, вы найдете этот файл в папке C:\Documents and
Settings\Migratorl\Temp.
3. Выберите организационную единицу OU в целевом домене, в которую нужно перенести
учетные записи служб.
4. Генерация сложного пароля будет использоваться для модернизации учетных записей
служб. Независимо от того, какую опцию модернизации пароля вы выберете в окне
Password Options (Опции пароля), инструмент ADMT будет всегда использовать опцию
сложного пароля. ADMT распознает, что учетная запись пользователя, которую вы
перемещаете, является учетной записью службы, и предоставит ей право входить в
систему в качестве службы.
Примечание. Если учетные записи служб, которые вы переносите, имеют локальные права,
унаследованные от членства в локальной группе, например, право «log on as a service» (входить в
качестве службы), имеющееся у членов локальной группы администраторов. Вы должны
установить эти права с помощью Security Translation Wizard (Мастер перевода защиты). В окне
Translate Objects (Перевод объектов) мастера перевода защиты выберите объекты Local Groups
(Локальные группы) и User Rights (Права пользователя) для перемещаемого сервера-члена домена,
содержащего локальную группу, через которую эти права были унаследованы. Это тот
компьютер, на котором будет происходить перевод защиты.
Прекращение эксплуатации исходных доменов
Теперь, когда все домены учетных записей и домены ресурсов были перемещены в Windows
Server 2003 и в Active Directory, можно прекратить эксплуатацию исходных доменов Windows NT
4. Ведь единственные компьютеры, оставшиеся в исходных доменах - это контроллеры домена.
Если ваш план перехода требует перемещения этих контроллеров домена в целевой домен
Windows Server 2003, можно переместить их. Существует довольно сложный процесс перевода
контроллеров домена в автономный режим, их обновления, назначения на роль контролера,
отмена этой роли, повторного назначения, чтобы сделать их контроллерами домена в новом
домене. Будет лучше, если вы убедитесь, что все необходимые данные перемещены с этих
серверов, а затем выполните новую инсталляцию операционной системы Windows Server 2003.
Заключительная задача состоит в том, чтобы удалить все доверительные отношения, которые
были созданы для выполнения модернизации. Используя инструмент Active Directory Domains
And Trusts, выберите каждое доверительное отношение с более не существующим доменом
системы Windows NT 4 и щелкните на кнопке Remove (Удалить).
Обновление с последующей реструктуризацией
Третий путь, который мы рассмотрим, — обновление с последующей реструктуризацией, или
перемещение в пределах леса. Выше говорилось, что в процессе обновления с последующей
реструктуризацией контроллеры домена низкого уровня сначала обновляются до Windows Server
2003 (при этом сохраняется первоначальная иерархия домена), а затем происходит
реструктуризация домена, при которой объекты службы каталога переносятся с
модернизированных исходных доменов в целевой домен (или домены). Вы уже знакомы с
задачами, которые необходимо выполнить при модернизации до Active Directory путем
обновления с последующей реструктуризацией. Однако, в связи с требованиями защиты Windows
Server 2003, вы увидите, что перемещение учетных записей в пределах леса работает иначе, чем в
сценарии модернизации между лесами.
Процесс реструктуризации домена после обновления к Windows Server 2003 не обязательно
происходит сразу же. Реструктурирование домена может быть проведено, когда вы получите
навык управления службой Active Directory, поскольку структура Active Directory может
изменяться при изменении вашего бизнеса.
Этот раздел показывает отличия обновления с последующей реструктуризацией от
реструктуризации домена, которую вы уже знаете. В этом разделе не обсуждаются инструменты,
поскольку технические различия относятся к любому инструменту модернизации домена, который
вы выберите.
Модернизация в пределах леса и модернизация между лесами имеют следующие отличия.
• При модернизации в пределах леса для сохранения доступа к ресурсам, использующим
SID-History, учетные записи должны быть перемещены, а не клонированы. Перемещение
объектов учетных записей в пределах леса является деструктивным процессом, так как
учетные записи пользователей, групп и компьютеров исходного домена удаляются по мере
создания новых учетных записей в целевом домене. В результате вы не сможете
поддерживать «параллельную среду», которая предлагает удобные варианты отступления,
которая имеется в сценарии реструктуризации между лесами.
• При модернизации в пределах леса для поддержки правил группового членства нужно
переместить учетные записи пользователей и групп, которым они принадлежат,
одновременно. Это называется замкнутым набором (closed set). Этот процесс отличается
от модернизации исходного домена Windows NT 4 до целевого домена Windows, в котором
учетные записи пользователя и учетные записи группы можно переносить или вместе, или
по отдельности. Однако инструмент ADMT не вычисляет полный замкнутый набор, так
что нужно очень осторожно перемещать пользователей, которые являются членами
глобальных групп. Если вы переносите группу, которая включает учетную запись
пользователя, являющуюся членом другой глобальной группы, и если та глобальная
группа не является рекурсивно членом какой-либо группы, перемещаемой в это же время,
то будет нарушено членство данной учетной записи пользователя в глобальной группе,
которая не включена в модернизацию. Другие типы групп (типа универсальных групп)
допускают наличие членов, не принадлежащих их собственным доменам.
Конфигурирование доверительных отношений
между лесами
В качестве альтернативы модернизации между лесами, описанной в предшествующем разделе,
можно использовать доверительное отношение между лесами, направленное от одного леса
Windows Server 2003 к другому, обособленному, лесу Windows Server 2003, в котором
расположены ресурсы, предназначенные для доступа.
Одним из существенных улучшений в Active Directory Windows Server 2003 по сравнению с
Windows 2000 является опция создания доверительных отношений между лесами Active Directory.
В Active Directory Windows 2000 можно создавать доверительные отношения только между
отдельным доменом в одном лесу и отдельным доменом в другом лесу. В Active Directory
Windows Server 2003 можно установить доверительные отношения между корневыми доменами
леса. Они могут быть односторонними или двухсторонними доверительными отношениями. После
того как доверительные отношения созданы, можно использовать глобальные группы или
универсальные группы одного леса для предоставления доступа к ресурсам другого леса.
Примечание. Создание доверительных отношений между двумя лесами допускает только
совместное использование ресурсов между лесами. Все другие различия, существующие на уровне
леса, сохранятся после создания доверительных отношений. Например, создание доверительных
отношений не подразумевает, что леса будут совместно использовать глобальный каталог (GC)
или общую схему.
Когда вы создаете доверительные отношения леса в Active Directory, они автоматически
допускают маршрутизацию суффикса имени (name suffix routing) между этими лесами. Используя
маршрутизацию суффикса имени, пользователи могут использовать свои основные
пользовательские имена (UPN) при входе на любой домен любого леса. Например, если вы
создаете доверительные отношения леса между лесом NWTraders.com и лесом Contoso.com,
пользователи леса Contoso.com могут входить на рабочие станции в лесе NWTraders.com,
используя свои UPN alias@contoso.com. Маршрутизация суффикса имени применяется по
умолчанию ко всем именам доменов первого уровня, имеющимся в лесу. Это включает заданный
по умолчанию UPN-суффикс и любые альтернативные суффиксы, сконфигурированные в лесу.
Маршрутизация суффикса имени не работает между лесами, если один и тот же UPN-суффикс
сконфигурирован в обоих лесах. Если UPN-суффикс Contoso.com сконфигурирован в лесе
NWTraders.com, пользователи леса Contoso.com не смогут входить в лес NWTraders.com,
используя свои UPN.
Когда вы впервые разрешаете доверительные отношения леса, все суффиксы домена первого
уровня автоматически направляются на UPN доверительного отношения. Все дочерние суффиксы
домена направляются неявно через суффикс родительского домена. Если вы добавляете другой
UPN-суффикс к лесу, после того как создано доверительное отношение, вы должны разрешить
маршрутизацию суффикса имени для нового суффикса. Вы можете сделать это, проверяя
доверительное отношение между доменами или вручную добавляя новый суффикс на вкладку
Name Suffix Routing (Маршрутизация суффикса имени) в окне свойств доверительного отношения.
Чтобы создать доверительное отношение леса, лес должен работать на функциональном уровне
Windows Server 2003. Только члены группы Enterprise Admins (Администраторы предприятия)
имеют разрешение создавать доверительные отношения леса.
Чтобы создать доверительные отношения леса, выполните следующее.
1. Запустите инструмент Active Directory Domains And Trusts. Щелкните правой кнопкой
мыши на имени корневого домена леса и выберите Properties (Свойства). Выберите
вкладку Trusts (Доверительные отношения).
2. Щелкните на кнопке New Trust (Новое доверительное отношение). Запустится New Trust
Wizard (Мастер новых доверительных отношений). Напечатайте имя корневого домена
леса в другом лесу.
3. Затем нужно будет выбрать тип доверительных отношений, которые вы хотите установить
(см. рис. 7-4). Можно создать внешние доверительные отношения или доверительные
отношения леса. Внешние доверительные отношения не являются транзитивными
доверительными отношениями, в то время как доверительные отношения леса всегда
являются транзитивными. Выберите Forest Trust (Доверительные отношения леса).
4. Выберите направления доверительных отношений (см. рис. 7-5).
Рис. 7-4. Конфигурирование типа доверительных отношений леса
Рис. 7-5. Конфигурирование направления доверительных отношений леса
5. Выберите вариант, создавать ли доверительные отношения только для этого домена или
также для другого домена. (Эти два домена -корневые домены леса для каждого леса.)
Доверительные отношения леса могут быть установлены только между корневыми
доменами леса (см. рис. 7-6). Если нужно установить обе стороны доверительных
отношений одновременно, впечатайте имя и пароль для учетной записи Enterprise Admins
(Администраторы предприятия), которая существует в другом лесу. Если нужно
установить доверительные отношения только для этого домена, напечатайте пароль,
который будет использоваться для установки начального доверительного отношения.
Затем это пароль должен использоваться для конфигурирования доверительных
отношений в корневом домене леса другого леса.
Рис. 7-6. Выбор конфигурирования одной или обеих сторон доверительных отношений
6. Выберите уровень аутентификации, который будет предоставлен для исходящих и
входящих доверительных отношений (см. рис. 7-7). Это позволит тщательно
контролировать доступ к ресурсам между лесами. Если нужно применить аутентификацию
по всему лесу, то пользователи одного леса будут иметь доступ ко всем серверам и
ресурсам другого леса. Это такая же конфигурация, как доверительные отношения между
доменами в пределах леса. Пользователи из одного домена леса могут обращаться к
ресурсам в любом другом домене любого леса при условии, что им дано разрешение на
доступ к ресурсу. Можно применять выборочную аутентификацию для доверительных
отношений леса. В этом случае вы должны явно дать пользователям или группам из
одного леса разрешения на доступ к серверам другого леса. Это можно сделать,
предоставляя им права Allowed To Authenticate (Разрешено аутентифицировать) в Active
Directory.
7. После конфигурирования доверительных отношений будет выполнена автоматическая
проверка доверительных отношений.
Рис. 7-7. Конфигурирование уровня аутентификации для доверительных отношений леса
Резюме
В этой главе были рассмотрены различные пути перехода от службы каталога Windows NT 4 или
Active Directory системы Windows 2000 к Active Directory Windows Server 2003. Были описаны три
главных пути перехода: обновление, реструктуризация и обновление с последующей
реструктуризацией. Существует несколько критериев, которые можно использовать для
определения подходящего пути перехода для вашей организации. Для организаций, которые
удовлетворены своей текущей доменной структурой, обновление домена является наименее
сложным и опасным средством модернизации службы каталога. Если ваша доменная структура не
соответствует организационной модели, вы должны реструктуризировать ваш домен. Независимо
от выбранного пути, осторожное планирование, тестирование и пробная реализация вашего плана
перехода являются важными условиями для успеха вашего проекта модернизации.
В главе описаны также основные этапы, необходимые при реализации обновления систем
Windows NT Server 4 и Windows 2000 Server. Затем показан процесс реструктуризации домена
учетных записей и домена ресурсов с системой Windows NT 4 с помощью инструмента ADMT.
Обсуждены отличия пути обновления с последующей реструктуризацией, известного как
перемещение в пределах леса, от реструктуризации домена. Заканчивает эту главу обсуждение
функции доверительных отношений между лесами, имеющейся в Windows Server 2003.
Часть III. Администрирование
службы каталога Active Directory
Windows Server 2003
В частях I и II этой книги были объяснены концепции и компоненты Active Directory — службы
каталога Microsoft Windows Server 2003, а также дана информация о том, как проектировать,
реализовывать, и развертывать Active Directory. После развертывания Active Directory вы должны
управлять ею для обеспечения максимальной выгоды вашей компании. В части III показаны
административные процессы, которые вы будете использовать для выполнения этой задачи. Одна
иэ основных причин развертывания службы каталога состоит в том, чтобы обеспечить защиту,
поэтому глава 8 рассказывает про концепции, лежащие в основе безопасности Active Directory
Windows Server 2003. В главе 9 дается описание способов, которыми вы можете делегировать
административные разрешения в пределах вашего домена. Глава 10 знакомит вас с управлением
объектами службы каталога Active Directory. Одна из наиболее мощных функций в Active
Directory - это Group Policy (Групповая политика), которая может применяться для управления
тысячами компьютеров, использующих Active Directory. Главы 11, 12 и 13 посвящены групповым
политикам, в них объясняется, как использовать эти инструментальные средства, чтобы
осуществить распределение программ и управление клиентскими компьютерами.
Глава 8. Защита Active Directory
Одна из основных причин развертывания службы каталога Active Directory состоит в обеспечении
безопасности корпоративной сети. Каждая компания хранит важнейшую для своего бизнеса
информацию на файловых серверах в сети. Управление безопасным доступом к информации
должно гарантировать, что доступ к данным получат только должным обраЗЬм уполномоченные
пользователи. Почти все компании развертывают почтовые серверы типа Microsoft Exchange 2000
Server, и они должны гарантировать пользователям безопасный доступ к почтовым ящикам.
Служба Active Directory Microsoft Windows Server 2003 обеспечивает такой уровень защиты.
Эта глава начинается с введения в основы безопасности Active Directory. Служба каталога Active
Directory использует несколько основных концепций для обеспечения безопасности сети Windows
Server 2003. После введения в основы защиты будет показан основной компонент этой защиты,
состоящий из аутентификации и функций разрешения, который используется в Active Directory
для обеспечения гарантии того, что пользователи действительно являются теми, кем они себя
представляют (аутентификация), и для обеспечения доступа к тем ресурсам, к которым
пользователь должен иметь доступ (разрешение). Система Windows Server 2003, подобно Microsoft
Windows 2000, использует Kerberos в качестве основного протокола защиты, поэтому большая
часть этой главы посвящена роли Kerberos в аутентификации и разрешениях.
Основы защиты Active Directory
Существуют некоторые основные концепции, необходимые для понимания принципов защиты
Active Directory в сети Windows Server 2003. Защита Active Directory строится на двух типах
объектов и на взаимодействии между ними. Первый объект - участник безопасности, который
представляет пользователя, группу, службу или компьютер, который нуждается в доступе к
некоторому ресурсу в сети. Второй объект -это сам ресурс, являющийся объектом, к которому
нужно получить доступ участнику безопасности. Чтобы обеспечить надлежащий уровень защиты,
служба Active Directory должна идентифицировать участников безопасности, а затем
предоставлять правильный уровень доступа к ресурсам.
Участники безопасности
Только участники безопасности службы Active Directory могут входить в Active Directory и
получать разрешения на доступ к ресурсам сети. Участник безопасности - это объект Active
Directory, который представляет пользователя, группу, службу или компьютер. Каждому
участнику безопасности при создании объекта назначается идентификатор защиты (SID).
Идентификатор SID составлен из двух частей. Первая часть -идентификатор домена, все
участники безопасности в домене имеют один и тот же идентификатор домена. Вторая часть
идентификатора SID -относительный идентификатор (RID), который является уникальным для
каждого участника безопасности в домене Active Directory.
Идентификатор SID является основным компонентом конфигурирования защиты для ресурсов,
расположенных в сети Windows Server 2003. При выдаче разрешения на доступ к ресурсу вы
используете отображаемое имя участника безопасности, но Windows Server 2003 фактически
использует SID для управления доступом к ресурсу. Когда пользователь пытается обратиться к
ресурсу, расположенному на сервере в домене, операционная система предоставляет разрешение
идентификатору SID пользователя, а не имени человека. Это означает, что если отображаемое имя
пользователя изменено, разрешения, представленные пользователю, не изменяются. Однако если
пользовательский объект удален, а затем создан заново с тем же самым именем, пользователь не
сможет обращаться к ресурсам, так как SID изменится.
Списки управления доступом
Еще один компонент, включенный в защиту Active Directory, - это объект, к которому участник
безопасности должен обращаться. Этот может быть другой объект Active Directory, например,
организационная единица (OU), принтер или участник безопасности. Объект может быть файлом
на сервере с системой Windows Server 2003 или почтовым ящиком на сервере с Microsoft Exchange
2000 Server.
Разрешения, которые предоставляются этим объектам, расположены в списке управления
доступом (ACL - Access Control List), также называемом дескриптором защиты (security
descriptor). Каждый объект в Active Directory или в разделе файловой системы NTFS имеет
дескриптор защиты. Дескриптор защиты включает идентификатор SID участника безопасности,
который владеет объектом, а также SID для основной группы объекта. Кроме того, каждый объект
имеет два отдельных списка ACL: список управления разграничительным доступом (DACL —
Discretionary Access Control List) и список управления системным доступом (SACL - System Access
Control List). Список DACL перечисляет участников безопасности, которым были назначены
разрешения на доступ к объекту, а также уровень разрешений, которые были назначены
каждому участнику безопасности. Список DACL состоит из записей управления доступом (АСЕ
— Access Control Entries). Каждая запись АСЕ содержит идентификатор SID и определяет уровень
доступа к объекту, который разрешен данному SID. Список АСЕ включает записи для всех типов
участников безопасности. Например, учетная запись пользователя может иметь разрешение Read
(Чтение) для файла, а группа защиты -разрешение Full Control (Полное управление). Список
DACL для файла имеет, по крайней мере, две записи АСЕ, одну - на предоставление пользователю
разрешения Read, другую - на предоставление группе разрешения Full Control.
Список SACL перечисляет участников безопасности, чей доступ к ресурсу должен подвергаться
аудиту. Список записей АСЕ в SACL указывает, чей доступ должен подвергаться аудиту, а также
необходимый уровень аудита.
Примечание. Список DACL может содержать записи АСЕ, которые предоставляют доступ к
ресурсу, а также АСЕ, которые запрещают доступ. Записи АСЕ, которые запрещают доступ,
всегда перечисляются первыми в ACL, так что подсистема защиты сначала оценивает их. Если
АСЕ запрещает доступ к ресурсу, то подсистема защиты не оценивает другие записи АСЕ, т.е.
запись АСЕ, запрещающая доступ к ресурсу, всегда отменяет любую запись АСЕ, которая
предоставляет доступ определенному идентификатору SID.
Лексемы доступа
Связующей точкой между SID участника безопасности и ACL является лексема доступа. Когда
пользователь аутентифицируется через Active Directory, в процессе входа в систему ему
назначается лексема доступа. Эта лексема включает основной SID пользователя, идентификаторы
SID всех групп, которым принадлежит пользователь, а также права и привилегии пользователя.
Лексема доступа используется подсистемой защиты всякий раз, когда пользователь пытается
обратиться к ресурсу. В этом случае лексема предъявляется компьютером клиента любому
процессу или приложению, которые запрашивают информацию, касающуюся безопасности, перед
получением доступа к ресурсу. Например, когда пользователь пытается обратиться к почтовому
ящику сервера, на котором выполняется Exchange 2000 Server, лексема доступа предъявляется
серверу. Подсистема защиты Exchange 2000 Server сравнивает идентификаторы SID в лексеме
доступа с разрешениями, которые были предоставлены в списке ACL. Пользователь сможет
открыть почтовый ящик, если это позволяют разрешения, предоставленные данному
идентификатору SID.
Аутентификация
Чтобы процессы защиты, включающие использование идентификаторов SID и записей ACL,
работали должным образом, должен существовать какой-то способ, которым пользователь
получает доступ к сети. По существу, пользователи должны иметь возможность доказать, что они
являются теми, кем они себя представляют, чтобы извлечь свою лексему доступа с контроллера
домена. Этот процесс называется аутентификацией.
Аутентификация происходит перед входом клиента в систему. Когда пользователь садится за
компьютер с системами Windows 2000 или Microsoft Windows XP Professional и вводит
Ctrl+Alt+Del, служба Winlogon локального компьютера переключается на экран входа в систему и
загружает файл Graphic Identification and Authentication (GINA) (Графическая идентификация и
аутентификация) из библиотеки динамической компоновки (DLL). По умолчанию этот файл —
Msgina.dll. Однако сторонние производители могут создавать альтернативные файлы GINA
(например, клиент системы Netware использует файл Nwgina.dll). После того как пользователь
впечатал имя пользователя, пароль и выбрал домен, GINA передает введенные «верительные
грамоты» службе Winlogon. Winlogon передает информацию локальной службе безопасности LSA
(Local Security Authority). Служба LSA немедленно применяет к паролю пользователя операцию
одностороннего кэширования и удаляет понятный текстовый пароль, который пользователь
напечатал. Затем вызывается соответствующий провайдер защиты (SSP — Security Support
Provider) через интерфейс провайдеров защиты (SSPI - Security Support Provider Interface).
Windows Server 2003 обеспечивает двух основных SSP-провайдеров для сетевой аутентификации
— KerbeVos SSP и NT LAN Manager (NTLM) SSP. Если клиенты с системой Windows 2000, или
более поздней, входят в сеть системы Windows 2000 или Windows Server 2003, выбирается SSP
Kerberos, и информация передается SSP. Затем SSP связывается с контроллером домена для
подтверждения подлинности пользователя. Опознавательный процесс с использованием
протокола Kerberos будет описан далее в этой главе.
Если процедура входа в систему прошла успешно, значит, пользователь аутентифицирован, и ему
предоставлен доступ к сети. Если пользователь вошел в домен и все ресурсы, к которым
пользователю нужно обратиться, находятся в том же самом лесу, то это единственный момент
аутентификации пользователя. Пока пользователь не выйдет из системы, все разрешения, которые
он получит в сети, будут основаны на начальной аутентификации.
Разрешение
Разрешение (authorization) — это второй шаг в процессе получения доступа к сетевым ресурсам,
он происходит после аутентификации. В процессе аутентификации вы доказываете свою идентичность, впечатывая правильное имя
пользователя и пароль. В процессе разрешения вам дается доступ к сетевым ресурсам. В процессе
аутентификации для вас создается лексема доступа. В процессе разрешения вы предъявляете
лексему доступа серверу или службе и запрашиваете доступ к ресурсу. Если идентификатор SID в
вашей лексеме доступа соответствует идентификатору SID в записи ACL, которая предоставляет
доступ, вам предоставляется доступ к ресурсу.
Защита с использованием протокола Kerberos
До сих пор в этой главе описывались основы защиты Active Directory без обсуждения
фактического механизма, который осуществляет защиту. Основной механизм аутентификации в
Active Directory — это протокол Kerberos. Протокол Kerberos был впервые разработан инженерами
Массачусетского Технологического института (MIT) в конце 80-х годов. Текущая версия Kerberos
- это версия 5 (Kerberos v5), которая описана в документе RFC 1510. Реализация Kerberos в
Windows Server 2003 полностью совместима с документом RFC-1510 с некоторыми расширениями
для аутентификации открытых (public) ключей.
Протокол Kerberos является заданным по умолчанию опознавательным протоколом для Active
Directory систем Windows 2000 Windows Server 2003. Всякий раз, когда клиент с системой
Windows 2000, или более поздней, подтверждает свою подлинность в Active Directory, он
использует протокол Kerberos. Другой протокол, использующийся для подтверждения
подлинности в Active Directory, - это NTLM, который поддерживается для обратной
совместимости с клиентами, пользующимися более старыми версиями операционных систем.
Протокол Kerberos имеет множество преимуществ по сравнению с NTLM.
• Взаимная аутентификация. При использовании протокола NTLM аутентификация
происходит только в одном направлении, т.е. сервер подтверждает подлинность клиента.
При использовании протокола Kerberos клиент может также подтверждать подлинность
сервера, гарантируя, что сервер, который отвечает на запрос клиента, является правильным
сервером.
• Более эффективный доступ к ресурсам. Когда пользователь обращается к сетевому
ресурсу в сети, использующему протокол NTLM (например, Microsoft Windows NT 4), то
сервер, на котором расположен ресурс, должен контактировать с контроллером домена для
проверки разрешения на доступ данного пользователя. В сети, использующей Kerberos,
клиент соединяется с контроллером домена и получает билет на сетевое соединение, чтобы
получить доступ к серверу ресурса. Это означает, что сервер ресурса не должен
соединяться с контроллером домена.
• Улучшенное управление доверительными отношениями. Доверительные отношения
NTLM всегда односторонние, не транзитивные, они конфигурируются вручную.
Доверительные отношения Kerberos конфигурируются автоматически, поддерживаются
между всеми доменами леса и являются транзитивными и двусторонними. Кроме того,
доверительные отношения Kerberos могут быть сконфигурированы между лесами и
доменами Kerberos Windows Server 2003 и другими реализациями протокола Kerberos.
• Делегированная аутентификация. Когда клиент подключается к серверу, используя
аутентификацию NTLM, сервер может использовать сертификаты клиента для доступа к
ресурсам, расположенным только на локальном сервере. С аутентификацией Kerberos
сервер может использовать сертификаты клиента для доступа к ресурсам, расположенным
на другом сервере.
Примечание. Windows Server 2003 поддерживает аутентификацию через протокол SSL/TLS
(Secure Sockets Layer/Transport Layer Security — Защищенные сокеты/Защита транспортного
уровня), аутентификацию Digest и аутентификацию Passport. Так как эти службы используются
в среде интернета для аутентификации служб информационного интернет-сервера от Microsoft
(IIS - Internet Information Services) версии 6.0, то эти опознавательные опции обсуждаться не
будут.
Введение в протокол Kerberos
В системе, основанной на протоколе Kerberos, имеется три компонента. Во-первых, клиент,
который должен получить доступ к сетевом ресурсам. Во-вторых, сервер, который управляет
сетевыми ресурсами и гарантирует, что только должным образом заверенные и уполномоченные
пользователи могут получать доступ к ресурсу. Третий компонент — центр распределения ключей
(KDC - Key Distribution Center), который служит центральным местом хранения пользовательской
информации и главной службой, подтверждающей подлинность пользователей.
Протокол Kerberos определяет то, как эти три компонента взаимодействуют между собой. Это
взаимодействие основано на двух ключевых принципах. Прежде всего, Kerberos работает,
основываясь на предположении, что опознавательный трафик между рабочей станцией и сервером
пересекает незащищенную сеть. Это означает, что никакой конфиденциальный опознавательный
трафик никогда не посылается по сети открытым, незашифрованным текстом, а пользовательский
пароль никогда не посылается по сети, даже в зашифрованной форме. Второй
принцип состоит в том, что протокол Kerberos имеет в своей основе опознавательную модель с
общим секретом. В этой модели клиент и опознающий сервер владеют общим секретом, который
неизвестен кому-либо еще. В большинстве случаев общий секрет — это пароль пользователя.
Когда пользователь входит в сеть, защищенную протоколом Kerberos, пароль пользователя
используется для шифрования пакета информации. Когда сервер Kerberos получает пакет, он
расшифровывает информацию, используя копию пароля, хранящегося на сервере. Если
расшифровка прошла успешно, то опознающий сервер знает, что пользователю известен общий
секрет, и ему предоставляется доступ.
Примечание. Когда пользователь входит в систему, он обычно впечатывает свой пароль.
Контроллер домена проверяет точность пароля. Однако поскольку Kerberos работает в
предположении, что сеть не защищена, то эта проверка делается без пересылки пароля по сети.
Одной из проблем общего секрета является то, что пользователь и сервер, управляющий сетевым
ресурсом, должны иметь какой-либо способ владения общим секретом. Если пользователь пробует
получить доступ к ресурсу на определенном сервере, то учетная запись пользователя может быть
создана на сервере с паролем, который знает только пользователь. Когда пользователь попытается
обратиться к ресурсам на этом сервере, он может представить общий секрет (пароль) и получить
доступ к ресурсу. Однако в корпоративной среде могут быть тысячи пользователей и сотни
серверов. Управление различными общими секретами всех этих пользователей было бы
непрактичным. Протокол Kerberos справляется с этой проблемой, используя центр распределения
ключей (KDC - Key Distribution Center). Служба KDC выполняется как служба сервера в сети и
управляет общими секретами всех пользователей в сети. KDC имеет одну центральную базу
данных для всех учетных записей пользователей сети и хранит общий секрет каждого
пользователя (в форме одностороннего кэша пароля пользователя). Когда пользователю требуется
получить доступ к сети и сетевым ресурсам, служба KDC подтверждает, что пользователь знает
общий секрет, а затем подтверждает подлинность пользователя.
Примечание. В терминологии Kerberos центральным сервером, управляющим учетными записями
пользователя, является служба KDC. В реализации Kerberos сервера Windows Server 2003 этот
сервер называется контроллером домена. Каждый контроллер домена Active Directory является
KDC. В Kerberos граница, определенная пользовательской базой данных, расположенной на одном
KDC, называется областью (realm). В терминологии Windows Server 2003 эта граница
называется доменом.
Каждая служба KDC состоит из двух отдельных служб: службы аутентификации (AS Authentication Service) и службы предоставления билетов (TGS — Ticket-Granting Service). Служба
AS отвечает за начальный вход клиента в систему и выдает билет TGT (TGT - Ticket-Granting
Ticket) клиенту. Служба TGS отвечает за все билеты сеанса, которые используются для доступа к
ресурсам в сети Windows Server 2003.
Служба KDC хранит базу данных учетных записей, которая используется для аутентификации
протоколом Kerberos. В реализации Kerberos Windows Server 2003 база данных управляется
агентом системы каталога (DSA - Directory System Agent), который выполняется в пределах
процесса LSA на каждом контроллере домена. Клиенты и приложения никогда не получают
прямой доступ к базе данных учетных записей - все запросы идут через агента DSA, используя
один из интерфейсов Active Directory. Каждый объект в пределах базы данных учетных записей
(фактически, каждый атрибут каждого объекта) защищен с помощью списка ACL. Агент DSA
гарантирует, что любые попытки обращения к базе данных учетных записей должным образом
санкционированы.
Совет. Когда Active Directory устанавливается на первом контроллере домена в домене, создается
специальная учетная запись, которая называется krbtgt. Эта учетная запись не может быть удалена
или переименована, ее никогда нельзя разрешать (enable). При создании этой записи назначается
пароль, который регулярным образом автоматически изменяется. Этот пароль используется для
создания секретного ключа, предназначенного для шифрования и расшифровки билетов TGT,
выдаваемых всеми контроллерами домена в домене.
Аутентификация на базе протокола Kerberos
На компьютерах с системой Microsoft Windows 2000 Professional или Windows XP Professional, на
серверах с Windows 2000 Server или Windows Server 2003 аутентификация по протоколу Kerberos
начинается с того, что служба LSA вызывает провайдера защиты Kerberos. Когда пользователь
входит в систему, впечатывая имя пользователя и пароль, компьютер клиента применяет
одностороннее хэширование к паролю пользователя для создания секретного ключа, который
кэшируется в надежной памяти на компьютере. Одностороннее хэширование означает, что пароль
не может быть восстановлен исходя из хэш-значения (hash).
Для осуществления процесса входа клиента в систему клиент и сервер выполняют следующие
действия.
1. Провайдер Kerberos SSP на рабочей станции посылает опознавательное сообщение службе
KDC (см. рис. 8-1). Это сообщение включает: • имя пользователя;
• область (realm) пользователя (имя домена);
• запрос на TGT-билет;
• предварительные опознавательные данные, которые включают метку времени.
Предварительные опознавательные данные зашифрованы с помощью секретного ключа,
полученного из пользовательского пароля.
Рис. 8-1. Получение билета Kerberos TGT
2. Когда сообщение достигдет сервера, сервер исследует имя пользователя, а затем проверяет
базу данных каталога в поисках своей копии секретного ключа, связанного с данной
учетной записью пользователя. Сервер расшифровывает зашифрованные в сообщении
данные с помощью секретного ключа и проверяет временную метку. Если расшифровка
прошла успешно, и временная метка отличается от текущего времени на сервере в
пределах 5 минут, сервер готов подтвердить подлинность пользователя. Если расшифровка
окажется неудачной, это означает, что пользователь ввел неправильный пароль, и
аутентификация потерпит неудачу. Если временная метка отличается более чем на 5 минут
от текущего времени на сервере, то аутентификация также потерпит неудачу. Причина
такой маленькой разницы во времени состоит в том, что она должна предотвратить
возможную попытку перехвата опознавательного пакета с последующим повторением его
в более позднее время. Заданная по умолчанию максимальная допустимая разница во
времени, составляющая 5 минут, может быть сконфигурирована в политике защиты
домена.
3. После аутентификации пользователя сервер посылает клиенту сообщение, которое
включает ключ сеанса и TGT (см. рис. 8-1). Ключ сеанса - это ключ шифрования, который
клиент будет использовать для взаимодействия с KDC вместо секретного ключа клиента.
TGT — это билет сеанса, который предоставляет пользователю доступ к контроллеру
домена. В течение срока службы TGT клиент предъявляет TGT контроллеру домена всякий
раз, когда ему требуется обратиться к сетевым ресурсам. Полное сообщение от сервера
зашифровано с помощью секретного ключа пользователя. Кроме того, билет TGT
зашифрован с помощью долгосрочного секретного ключа сервера.
4. Когда пакет прибывает на компьютер клиента, секретный ключ пользователя используется
для расшифровки пакета. Если расшифровка прошла успешно и временная метка
допустима, то компьютер пользователя предполагает, что центр KDC надежно
идентифицировал пользователя, потому что ему знаком его секретный ключ. Ключ сеанса
затем кэшируется на локальном компьютере, пока не кончится срок его действия или пока
пользователь не сделает выход из системы рабочей станции. Этот ключ сеанса будет
использоваться для шифрования всех будущих подключений к центру KDC, т.е. клиент
больше не должен помнить секретный ключ, и он удаляется из кэша рабочей станции.
Билет TGT сохраняется в зашифрованной форме в кэше рабочей станции.
Примечание. Протокол Kerberos включает в себя Authentication Service (AS) Exchange
(Коммутатор
аутентификационной
службы),
который
является
подпротоколом,
предназначенным для выполнения начальной аутентификации пользователя. Только что
описанный процесс использует подпротокол AS Exchange. Начальное сообщение, посланное
клиентом к центру KDC, называется сообщением KRB_AS_REQ. Ответ сервера клиенту
называется сообщением KRB_AS_REP.
*•
5. Пользователь был опознан, но он все еще не имеет никакого доступа к сетевым ресурсам.
TGT - это билет сеанса, который предоставляет доступ к центру KDC, но чтобы получить
доступ к каким-либо другим сетевым ресурсам, пользователь должен получить другой
билет сеанса от KDC центра (см. рис. 8-2.) Рабочая станция клиента посылает запрос на
билет сеанса к центру KDC. Запрос включает имя пользователя, билет TGT,
предоставленный в процессе аутентификации, имя сетевой службы, к которой
пользователь хочет получить доступ, и временную метку, которая зашифрована с
использованием ключа сеанса, полученного в процессе AS Exchange.
Рис. 8-2. Получение билета сеанса Kerberos для сетевого ресурса
6. Служба KDC расшифровывает билет TGT, используя свой долгосрочный ключ. Затем она
извлекает ключ сеанса из билета TGT и расшифровывает временную метку, чтобы
убедиться, что клиент использует правильный ключ сеанса, и гарантировать, что
временная метка допустима. Если ключ сеанса и временная метка приемлемы, то KDC
готовит билет сеанса для доступа к сетевой службе.
7. Билет сеанса включает две копии ключа сеанса, который клиент будет использовать для
соединения с требуемым ресурсом. Первая копия ключа сеанса зашифрована, используя
ключ сеанса клиента, полученный в процессе начального входа в систему. Вторая копия
ключа сеанса предназначена для сетевой службы и включает информацию о доступе
пользователя. Эта часть билета сеанса зашифрована, используя секретный ключ сетевой
службы, который неизвестен рабочей станции клиента, но известен и службе KDC и
сетевой службе, потому что сервер, на котором расположен ресурс, является членом сферы
KDC.
8. Рабочая станция клиента кэширует обе части билета сеанса в памяти.
Примечание. Процесс, описанный в шагах с 5-го по 8-ой, использует подпротокол Ticket-Granting
Service Exchange (Коммутатор службы предоставления билетов ). Запрос на билет сеанса,
посланный клиентом, называется сообщением KRB_TGS_REQ; ответ сервера - сообщением
KRB_TGS_REP.
9. Теперь клиент предъявляет билет сеанса сетевой службе для получения доступа (см. рис.
8-3.)
Рис. 8-3. Доступ к сетевой службе
10. Сетевая служба расшифровывает ключ сеанса, зашифрованный в билете сеанса, используя
долгосрочный ключ, которым она владеет совместно с центром KDC. Если эта
расшифровка прошла успешно, то сетевая служба знает, что билет выдан доверенной
службой KDC. Затем сетевая служба расшифровывает лексему доступа пользователя,
используя ключ сеанса, и проверяет пользовательский уровень доступа. Запрос клиента
включает также временную метку, которая зашифрована с помощью ключа сеанса и
проверена сервером.
Примечание. Процесс, описанный в шагах 9 и 10, использует под-протокол Client/Server (CS)
Exchange. Запрос клиента называется сообщением KRB_AP_REQ.
В предположении, что аутентификация и проверка разрешения прошли успешно, клиенту
предоставляется доступ к ресурсам сервера. Если клиент нуждается в дальнейшем использовании
ресурса или службы, то билет сеанса перемещается из кэша, предназначенного для билета
клиента, и передается на целевой сервер ресурса. Если срок действия билета сеанса истек, клиент
должен обратиться к KDC для получения нового билета.
Дополнительная информация. Вы можете посмотреть содержимое кэша клиента,
используя инструменты, доступные для загрузки на веб-сайте Microsoft. Инструмент
KList.exe предоставляет интерфейс командной строки для просмотра и удаления билетов
Kerberos. Инструмент Kerberos Tray (Kerbtray.exe) обеспечивает для просмотра билетов
графический интерфейс пользователя (GUI). На рисунке 8-4 показан пример информации,
предоставленной инструментом Kerberos Tray. Инструмент Kerberos Tray доступен по
адресу http://www.microsoft.com/ windows2000/techinjo/reskit/tools/existing/kerbtray-o.asp , а
инструмент
KList
доступен
по
адресу
http://www.microsoft.co7n/windows2000/techinfo/reskit/tools/ existing /klist-o. asp.
Рис. 8-4. Просмотр билетов Kerberos с помощью инструмента Kerberos Tray
Процесс получения доступа к сетевому ресурсу показывает, что центр KDC вовлечен только в
процесс начального входа в систему клиента, когда клиент первый раз пробует обращаться к
ресурсу, расположенному на определенном сервере. Когда пользователь впервые входит в
систему, ему выдается билет TGT, который предоставляет клиенту доступ к центру KDC в течение
срока службы билета. Когда клиент пробует соединиться с сетевым ресурсом, он снова входит в
контакт с KDC и получает билет сеанса для доступа к этому ресурсу. Билет сеанса включает
лексему доступа пользователя. Когда эта лексема предъявляется серверу, на котором расположен
ресурс, сервер определяет уровень доступа к ресурсу, который должен иметь данный
пользователь.
Аутентификация, пересекающая границы домена
Тот же самый опознавательный процесс применяется и в том случае, когда при подтверждении
подлинности пользователя пересекаются границы домена. Например, компания может иметь лес с
тремя доменами, как показано на рисунке 8-5.
Рис. 8-5. Аутентификация, пересекающая границы домена
Если пользователь, имеющий учетную записью в домене Fabrikam.com, перейдет в домен
NAmerica.Contoso.com и попытается войти в сеть, рабочая станция клиента сможет соединиться с
контроллером домена в домене Fabrikam.com. В этом случае компьютер клиента посылает
начальный запрос входа в систему на контроллер домена NAmerica.Contoso.com. Контроллер
домена определяет, что учетная запись пользователя расположена в домене Fabrikam.com, так что
нужно переправить запросы рабочей станции клиента к этому домену. Если все домены были
сконфигурированы с прямыми доверительными отношениями (shortcut trusts), то контроллер
домена может напрямую направить компьютер клиента к контроллеру домена в домене
Fabrikam.com. Однако если прямых доверительных отношений не было создано, то нет и прямого
доверительного отношения между доменами NAmerica.Contoso.com и Fabrikam.com. В этом случае
контроллер домена NAmerica направит компьютер клиента к контроллеру домена в домене
Contoso.com. Направление включает ключ сеанса, предоставляющий доступ к контроллеру домена
в домене Contoso.com. Ключ сеанса создается, когда домен NAmerica добавляется к лесу
Contoso.com и создаются начальные доверительные отношения между этими двумя доменами.
Ключ сеанса гарантирует, что запрос на вход в систему исходит от доверенного домена. Затем
компьютер клиента посылает опознавательный запрос к домену Contoso.com. Теперь клиент
направляется к контроллеру домена в домене Fabrikam.com. Снова это направление включает
ключ сеанса, необходимый для доступа к контроллеру домена. Далее компьютер клиента посылает
запрос TGT на свой домашний контроллер домена в Fabrikam.com.
Аналогичный процесс происходит тогда, когда клиент пробует получить доступ к ресурсу,
расположенному за пределами домашнего домена пользователя. В этом случае клиент должен
получить билет сеанса от контроллера домена, расположенного в том домене, где находится
ресурс, пока он не сможет соединиться с правильным контроллером домена.
Опознавательный процесс влияет на проект леса, особенно если пользователи часто входят на
домены, к которым они сами не принадлежат, или обращаются к ресурсам других доменов. Если
вы разрабатываете лес с несколькими доменами, клиенту, вероятно, придется пересекать весь путь
доверительных отношений между доменами. Если это случается часто, нужно поместить
контроллеры домена корневых доменов ближе к пользователям. Можно также использовать
прямые доверительные отношения, чтобы направления контроллера домена посылались нужным
доменам напрямую.
Делегирование аутентификации
Одна из причин сложности доступа к сетевым службам состоит в том, что сетевая служба может
быть распределена между несколькими серверами. Например, клиент для получения информации
соединяется с крайним сервером внешнего интерфейса цепочки серверов, который должен
подключиться к серверу базы данных, являющимся другим концом этой цепочки. Чтобы
пользователь получил доступ только к санкционированной информации, для обращения к
крайнему серверу базы данных должны использоваться «верительные грамоты» пользователя
(вместо «верительных грамот» сервера внешнего интерфейса). В системе Windows 2000 протокол
Kerberos обеспечивает это двумя способами: путем использования прокси-билетов (proxy tickets) и
ретранслированных билетов (forwarded tickets). Если прокси-билеты разрешены, то клиент пошлет
запрос на билет сеанса к центру KDC, требуя доступ к крайнему серверу. Служба KDC
предоставит билет сеанса и установит на билете флажок PROXIABLE. Затем клиент представит
билет сеанса серверу внешнего интерфейса, который использует его для доступа к информации,
расположенной на крайнем сервере. Главная проблема с про-кси-билетами состоит в том, что
клиент должен знать отличительные характеристики крайнего сервера. Другой вариант состоит в
использовании ретранслированных билетов. Если эти билеты разрешены, то клиент посылает запрос AS Exchange к центру KDC, требуя билет TGT, позволяющий серверу
внешнего интерфейса обратиться к крайним серверам. Служба KDC создает билет TGT и
посылает его клиенту для пересылки серверу внешнего интерфейса, который использует билет
TGT для получения билета сеанса, позволяющего обратиться к крайнему серверу от имени
клиента.
Имеется два существенных недостатка, связанных с реализацией делегирования аутентификации в
системе Windows 2000. Первый недостаток состоит в том, что делегирование аутентификации
может использоваться только в том случае, если клиент аутентифицирован через протокол
Kerberos. Клиенты с системами Windows NT, Microsoft Windows 95 и Windows 98 не могут
использовать делегирование аутентификации. В Windows Server 2003 клиент может использовать
любой опознавательный протокол. Второй недостаток системы Windows 2000 касается защиты
делегирования. В Windows 2000 после получения сервером внешнего интерфейса
ретранслированного билета от центра KDC он может использовать его для доступа к любой
сетевой службе от имени клиента. Windows Server 2003 имеет опцию, ограничивающую
делегирование, т.е. учетную запись можно сконфигурировать так, что это делегирование будет
применяться только для определенных сетевых служб (основываясь на основных именах служб).
Ограниченное делегирование доступно в случае, если функциональный уровень домена
установлен на функциональный уровень Windows Server 2003.
Для успешного делегирования аутентификации нужна гарантия, что и учетная запись
пользователя, и учетная запись компьютера (или службы) сконфигурированы так, чтобы
поддерживать делегирование аутентификации. Для этого обратитесь к окну Properties (Свойства)
пользователя через инструмент Active Directory Users And Computers (Пользователи и компьютеры
Active Directory), выберите вкладку Account (Учетная запись), а затем просмотрите список Account
Options (Опции учетной записи). Удостоверьтесь, что oпция Account Is Sensitive And Cannot Be
Delegated (Учетная запись точна и не может быть делегирована) не выбрана. (По умолчанию
опция не выбрана.) Чтобы сконфигурировать учетную запись службы для делегирования, нужно
определить, является ли учетная запись, используемая службой для входа в систему, нормальной
учетной записью пользователя, или она является учетной записью LocalSystem. Если служба
выполняется под нормальной учетной записью пользователя, обратитесь к вкладке Account
пользователя и удостоверьтесь, что опция Account Is Sensitive And Cannot Be Delegated не
выбрана. (По умолчанию она не выбрана.) Если служба выполняется под учетной записью
LocalSystem, то делегирование было сконфигурировано в окне Properties компьютерной учетной
записи (см. рис. 8-6). Чтобы реализовать уровень аутентификации Windows 2000, выберите опцию
Trust This Computer For Delegation To Any Service (Kerberos Only) (Доверять этому компьютеру
при делегировании к любой службе (Только протокол Kerberos)). Чтобы реализовать усовершенствованный
уровень аутентификации Windows Server 2003, выберите опцию Trust This Computer For Delegation
To Specified Services Only (Доверять этому компьютеру только при делегировании к указанной
службе). Затем укажите, должен ли клиент подтверждать подлинность только с использованием
протокола Kerberos, или он может использовать любой другой протокол, а затем выбрать службы
(основываясь на основных именах служб, зарегистрированных в Active Directory), которым
компьютер может представлять делегированные «верительные грамоты».
Рис. 8-6. Конфигурирование ограниченного делегирования для учетной записи компьютера
Конфигурирование Kerberos в Windows Server
2003
Как говорилось выше, протокол Kerberos по умолчанию задан в качестве опознавательного
протокола для клиентов с системами Windows 2000, или более поздними, которые входят в Active
Directory. Вы можете сконфигурировать несколько свойств Kerberos через политику безопасности
домена. Чтобы обратиться к параметрам настройки политики Kerberos, откройте пункт Domain
Security Policy (Политика безопасности домена) из инструментов администрирования и разверните
папку Account Policies (Политики учетных записей) (см. рис. 8-7). Вам станут доступны
следующие политики.
Рис. 8-7. Конфигурирование параметров настройки протокола Kerberos через Domain
Security Policy (Политика безопасности домена)
•
•
•
•
•
Enforce User Logon Restrictions (Усиление ограничений пользовательского входа в
систему). Эта политика устанавливает опцию службы KDC, по которой при каждом
запросе на билет сеанса проверяются установки прав пользователя на целевом
компьютере. Если эта политика включена, то пользователь, запрашивающий билет сеанса,
должен иметь права Allow Log On Locally (Разрешить локальный вход), если он вошел в
систему в интерактивном режиме, или права Access This Computer From The Network
(Доступ к этому компьютеру из сети) на целевом компьютере. Эти права назначаются в
меню Local Policies\User Rights Assignment (Локальные политики\ Назначение прав
пользователей) в пункте Domain Security Policy (Политика безопасности домена). По
умолчанию эта политика включена.
Maximum Lifetime For Service Ticket (Максимальный срок годности служебного билета).
Эта политика устанавливает максимальное время (в минутах), в течение которого билет
сеанса может использоваться для доступа к определенной службе. Если установлен нуль
минут, то срок годности билета никогда не окончится. Если установлено ненулевое
количество минут, то оно должно быть больше, чем 10 минут, и меньше или равно
значению, установленному для параметра Maximum Lifetime For User Ticket
(Максимальный срок годности для пользовательского билета). По умолчанию эта
установка составляет 600 минут (10 часов).
Maximum Lifetime For User Ticket (Максимальный срок годности для пользовательского
билета). Эта политика устанавливает максимальное время (в часах), в течение которого
может использоваться TGT-билет пользователя. После того как истечет срок годности
TGT-биле-та, существующий билет должен быть возобновлен, иначе нужно затребовать
новый билет в центре KDC. По умолчанию эта установка составляет 10 часов.
Maximum Lifetime For User Ticket Renewal (Максимальный срок, в течение которого
возможно обновление пользовательского билета). Эта политика устанавливает время (в
днях), в течение которого TGT-билет может быть возобновлен (вместо получения нового
TGT-биле-та). По умолчанию эта установка составляет 7 дней.
Maximum Tolerance For Computer Clock Synchronization (Максимально допустимое
расхождение в показаниях компьютерных часов). Эта политика устанавливает
максимальную разницу во времени (в минутах) между временем на компьютере клиента и
временем на контроллере домена, обеспечивающем аутентификацию по протоколу
Kerberos, которую протокол Kerberos считает допустимой. Если разница во времени между
показаниями этих двух компьютеров больше, чем допустимый уровень, все билеты
Kerberos будут отвергнуты. По умолчанию эта установка составляет 5 минут. Имейте в
виду, что в случае изменения этой установки при перезапуске компьютера она возвратится
к заданному по умолчанию значению.
В большинстве случаев параметры настройки протокола Kerberos, заданные по умолчанию,
являются приемлемыми. В средах с высоким уровнем безопасности можно уменьшить сроки
службы билетов. Однако в этом случае клиенты должны будут более часто подключаться к центру
KDC, создавая дополнительный сетевой трафик и лишнюю нагрузку на контроллерах домена.
Интеграция с инфраструктурой открытых ключей
В основе протокола Kerberos лежит опознавательная модель с общим секретом. Это обеспечивает
превосходную защиту, но налагает одно важное ограничение на обеспечение доступа к сети
Windows Server 2003. Это ограничение состоит в том, что каждый пользователь, который
обращается к сети, должен иметь учетную запись в базе данных учетных записей службы KDC.
Если пользователь не существует в базе данных, ему нельзя предоставить доступ к сети.
Эта модель хорошо работает в тех компаниях, в которых все пользователи, входящие в сеть,
известны, и учетная запись может быть создана для каждого пользователя. Однако многие
компании расширяют список пользователей, имеющих доступ к сетевым ресурсам, включая в него
пользователей, которые не являются служащими. Компания может вступить в краткосрочное
партнерство с другой компанией, и ей потребуется обеспечить доступ к сетевым ресурсам для
служащих другой компании. Или компания захочет предоставить доступ к ресурсам, имеющимся
в сети компании, определенным клиентам. В этих сценариях список людей, которым требуется
доступ к сети, может быть очень длинным, так что создание учетной записи для каждого из
пользователей будет непрактичным.
Инфраструктура открытых ключей (PKI - Public Key Infrastructure) стала основным средством для
решения проблемы предоставления доступа к сети пользователям, не имеющим учетной записи
пользователя. Система PKI отходит от модели аутентификации с общим секретом и заменяет ее
опознавательной моделью, основанной на сертификате. В системе PKI пользователи
аутентифицируются на основании того факта, что они имеют правильный сертификат. Система
PKI основана на трех основных концепциях: открытые (public) и личные (private) ключи,
цифровые сертификаты и сертификационные власти (СА - certificate authorities). PKI начинается с
концепции, согласно которой каждый пользователь или компьютер, вовлеченный в
информационный обмен, имеют два ключа: личный ключ и открытый ключ. Личный ключ
известен только одному пользователю. Его можно сохранить на жестком диске компьютера, как
часть роумингового (roaming) профиля, или на устройстве типа смарт-карты. Открытый ключ
доступен любому, кто его попросит. Личные и открытые ключи связаны, но нет никакого способа
извлечь личный ключ из открытого ключа. Эти ключи используются различными способами.
Один из способов состоит в шифровке информации при пересылке ее по сети. Открытый ключ
пользователя используется для шифровки сообщения. Поскольку открытый ключ доступен
любому, кто его запросит, то все могут посылать сообщение, зашифрованное с помощью
открытого ключа пользователя. Однако, единственный ключ, с помощью которого можно
расшифровать сообщение, — это личный ключ пользователя. Он является единственным
человеком, способным расшифровывать сообщение. Кто-то другой, перехвативший этот пакет в
сети, не имеет правильного личного ключа и не сможет прочитать сообщение.
Другой способ применения состоит в использовании цифровой подписи и печати для сообщений,
посылаемых между двумя пользователями. Цифровая подпись используется для гарантии
подлинности отправителя сообщения и целостности сообщения. Чтобы создать цифровую
подпись, все сообщение подвергается математическому хэшированию. Хэш является «сверткой
сообщения», или цифровым дайджестом (digest), который зашифрован с помощью личного ключа
отправителя сообщения. Зашифрованный хэш посылается вместе с сообщением как цифровая
подпись. Когда адресат получает сообщение, к нему применяется тот же самый хэш, создавая
второй дайджест сообщения. Затем используется открытый ключ отправителя для расшифровки
цифровой подписи. Если дайджест сообщения получателя идентичен расшифрованной подписи,
то целостность и подлинность сообщения подтверждены.
Второй компонент PKI — цифровой сертификат. Цель применения сертификата состоит в том,
чтобы идентифицировать владельца сертификата. Когда человек или компания обращаются к
сертификационным властям (СА) для получения сертификата, СА-власти подтверждают
подлинность человека или компании, запрашивающей сертификат. Когда
пользователю предоставляется сертификат, он получает соответствующий открытый ключ, а
также личный ключ для сертификата. Сертификат подписан сертификационными властями с
помощью цифровой подписи, добавляя к сертификату штамп подлинности СА-властей. Текущий
стандарт для сертификатов -Х.509 v3. Сертификат включает информацию о человеке, компьютере
или службе, для которых он был выпущен, информацию о самом сертификате (дата истечения
срока годности) и информацию об СА-властях, выпустивших данный сертификат.
Сертификаты, необходимые для инфраструктуры PKI, выпускаются властями СА, которые
являются сетевыми серверами, управляющими предоставлением и отменой удостоверений. Из-за
важности PKI для интернета в настоящее время доступно множество СА-властей, включая
популярные коммерческие СА типа Verisign и Thawte. Большинство интернет-клиентов, таких как
Microsoft Internet Explorer, автоматически сконфигурированы доверять удостоверениям,
выпущенным коммерческими властями С А. Вы можете установить свои собственные СА-вла-сти,
используя Windows Server 2003. Сертификационная служба, поставляемая с Windows Server 2003,
является СА-властью с полной функциональностью, которая может использоваться для выдачи
удостоверений людям, работающим в пределах вашей компании, представляющим организации
партнера.
Дополнительная информация. Планирование и развертывание инфраструктуры PKI
требует значительных усилий. Windows Server 2003 обеспечивает опцию для создания PKI с
использованием СА-властей предприятия, интегрированных в Active Directory. Развертывая
СА-власти предприятия, можно сконфигурировать политики для автоматизации
большинства административных усилий, связанных с выдачей и возобновлением
удостоверений. Веб-сайт компании Microsoft и Help And Support Center (Центр справки и
поддержки) в Windows Server 2003 содержат детальную информацию, необходимую для
установки инфраструктуры PKI.
Одна из главных причин использования сертификатов состоит в том, чтобы позволить
пользователям, не имеющим учетной записи в Active Directory, получать доступ к ресурсам в сети
Windows Server 2003. Например, вы захотите установить безопасный веб-сайт, чтобы партнерские
организации или клиенты могли получить доступ к некоторой конфиденциальной информации,
касающейся вашей сети. Однако в Windows Server 2003 разрешение на доступ к сетевым ресурсам
можно предоставлять только участникам безопасности. Нет никакой опции, позволяющей
назначить разрешения, основываясь исключительно на сертификатах. Вы можете предоставить
доступ к ресурсам для пользователей, имеющих удостоверения и не имеющих учетных записей
пользователя Active
Directory, путем отображения сертификата на учетную запись пользователя и использованием
учетной записи для назначения разрешений.
Windows Server 2003 обеспечивает два различных способа отображения сертификата на учетную
запись пользователя.
• Однозначное отображение. В этом случае один сертификат отображается на одну
учетную запись пользователя Windows Server 2003. При однозначном отображении вы
должны назначить сертификат и создать учетную запись для каждого пользователя. Это
может быть хорошим решением, если вы хотите дать доступ удаленным служащим
компании к безопасным ресурсам через безопасный веб-сайт. Это не упрощает ваше
администрирование, тем не менее, с помощью однозначного отображения имен можно
управлять уровнем доступа каждого пользователя.
• Многозначное отображение. В этом случае несколько сертификатов отображаются на
одно имя учетной записи Active Directory. Например, если вы создаете партнерские
отношения с другой компанией, и служащим компании нужен доступ к безопасному вебсайту, вы можете создать одну учетную запись пользователя. Затем вы можете с этой
учетной записью связать такое количество сертификатов, какое захотите. Например, если
та компания имеет свою собственную власть СА, вы можете создать правило, по которому
все выданные ею удостоверения будут отображаться на одну учетную запись пользователя
в вашем домене. Затем, используя эту запись, вы сможете назначать разрешения на
сетевые ресурсы.
Совет. Можно отображать сертификаты на учетные запкси пользователя через инструмент
Active Directory Users And Computers или Менеджер информационного сервера интернета (IIS) от
Microsoft. В Active Directory Users And Computers используйте опцию Name Mappings
(Отображение имен^, которая становится доступной при щелчке правой кнопкой мыши на
учетной записи пользователя.
Интеграция со смарт-картами
Смарт-карты обеспечивают другой способ объединения инфраструктуры PKI с аутентификацией
по протоколу Kerberos. Когда Kerberos используется без PKI, общий секрет между клиентом и
службой KDC используется для шифрования обмена информацией с опознавательной службой
при начальном входе в систему. Этот ключ получен из пароля пользователя, тот же самый ключ
используется при шифровании и расшифровки информации. Смарт-карты используют модель
инфраструктуры PKI, в которой и открытый, и личный ключи используются для шифрования и
расшифровки информации, касающейся входа в систему.
Смарт-карта содержит открытый и личный ключи пользователя плюс сертификат Х.509 v3. Все
это применяется при использовании пользователем смарт-карты для аутентификации в Active
Directory. Процесс входа в систему начинается в тот момент, когда пользователь вставляет смарткарту в устройство чтения смарт-карт и вводит свой личный идентификационный номер (PIN —
personal identification number). Это интерпретируется властями LSA на компьютере как
последовательность Ctrl+Alt+Del, и процесс входа в систему начинается.
Номер PIN используется для чтения сертификата пользователя и открытого и личного ключей со
смарт-карты. Затем клиент посылает обычный TGT-запрос к службе KDC. Вместо посылки
данных предварительной аутентификации (временная метка), зашифрованных с помощью
секретного ключа пользователя, полученного из пароля, клиент посылает службе KDC открытый
ключ и сертификат. Запрос TGT все еще включает в себя данные предварительной
аутентификации, но он подписан с помощью личного ключа пользователя.
Когда сообщение достигает службы KDC, она проверяет сертификат клиента, чтобы убедиться в
его правильности и в том, что СА-власти, выдавшие сертификат, являются доверенными властями.
Служба KDC проверяет также цифровую подпись данных предварительной аутентификации,
чтобы гарантировать подлинность отправителя сообщения и целостность сообщения. Если обе эти
проверки дают положительный результат, служба KDC использует основное пользовательское
имя (UPN), включенное в сертификат клиента, чтобы искать имя учетной записи в Active
Directory. Если учетная запись пользователя правильна, то служба KDC подтверждает
подлинность пользователя и посылает в ответ клиенту билет TGT, включающий ключ сеанса.
Ключ сеанса зашифрован с помощью открытого ключа клиента, и клиент использует свой личный
ключ для расшифровки информации. Затем этот ключ сеанса используется для всех подключений
к службе KDC.
Совет. Установка входа в систему вашей сети с использованием смарт-карты требует
значительного объема работы. Прежде всего, нужно развернуть СА-власти для выпуска
сертификатов. Затем установить станции регистрации смарт-карт, где пользователи смогут
получать свои смарт-карты, и где смарт-картам могут быть назначены правильные
сертификаты и ключи. После начального развертывания нужно решить административные
задачи, связанные с потерянными или забытыми картами. Смарт-карты обеспечивают
превосходную дополнительную защиту вашей сети, но эта дополнительная защита связана со
значительными административными усилиями.
Способность к взаимодействию с другими системами
Kerberos
Поскольку в основе протокола Kerberos лежит открытый стандарт, он обеспечивает превосходные
возможности для взаимодействия с другими системами, основанными на протоколе Kerberos.
Любой из компонентов, который являются частью реализации протокола Kerberos Windows Server
2003, может быть заменен эквивалентным элементом, не принадлежащим системе Windows. Эти
три компонента следующие:
• клиент Kerberos;
• центр распределения ключей Kerberos;
• сетевой ресурс, использующий протокол Kerberos для разрешений.
Имеются четыре возможных сценария взаимодействия.
• Клиенты Windows 2000 или Windows XP Professional могут входить на контроллер домена
Windows Server 2003 и иметь доступ к ресурсам, расположенным на Windows Server 2003
или на других службах, в основе которых находится протокол Kerberos.
• Клиенты Windows 2000 или Windows XP Professional могут входить на KDC-центры, не
принадлежащие Windows-платформе, и иметь доступ к ресурсам, расположенным на
Windows Server 2003 или на других службах, в основе которых находится протокол
Kerberos.
• Клиенты Kerberos, не принадлежащие Windows-платформе, могут входить на KDC-центры
Windows Server 2003 и иметь доступ к ресурсам, расположенным на Windows Server 2003
или на других службах, в основе которых находится протокол Kerberos.
• Клиенты Kerberos, не принадлежащие Windows-платформе, могут взаимодействовать с
реализациями Kerberos, не принадлежащими Windows-платформе, и иметь доступ к
ресурсам, расположенных на Windows Server 2003 или на других службах, в основе
которых находится протокол Kerberos.
Windows Server 2003 можно сконфигурировать для участия в любом из этих сценариев. Самый
легкий вариант — это однородное решение, в котором вся среда основана или на Kerberos
Windows Server 2003, или на реализации Kerberos, не принадлежащей Windows-платформе.
Однако реализация Kerberos Windows Server 2003 позволяет легко взаимодействовать с другими
реализациями Kerberos. Для этого нужно создать доверительные отношения между областями
домена Windows Server 2003 и областью Kerberos, не принадлежащей Windows-платформе.
Доверительные отношения сферы могут быть сконфигурированы как транзитивные или
нетранзитивные, а так же как односторонние или двухсторонние. Чтобы сконфигурировать
доверительные отношения с другой областью, откройте инструмент Active Directory Domains And
Trusts (Домены и доверительные отношения Active Directory) и перейдите в окно Properties (Свойства) того домена, в котором вы хотите создать доверительные
отношения. На вкладке Trusts (Доверительные отношения) щелкните на кнопке New Trust,
запустив New Trust Wizard. С помощью мастера вы можете создать доверительные отношения со
стороны Windows Server 2003 с другой областью Kerberos. На рисунке 8-8 показано окно Properties
доверительного отношения области после его создания.
Рис. 8-8. Конфигурирование доверительного отношения между областями
Дополнительная информация. Microsoft обеспечивает пошаговое руководство для
конфигурирования доверительных отношений Kerberos между областями. Это руководство,
озаглавленное как «Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability» доступно на
веб-сайте Microsoft по адресу http:// www.microsoft.com/technet/prodtechnol/windows2000serv/
howto/kerbstep.asp.
Безопасность протокола NTLM
Второй вариант аутентификации на контроллере домена Windows Server 2003 должен
использовать NTLM-аутентификацию. Она поддерживается для совместимости с клиентскими
компьютерами, на которых выполняются системы Windows NT 4, Windows 95 и Windows 98. Этот
протокол используется в следующих ситуациях.
•
Когда компьютер, на котором выполняются системы Windows 95, Windows 98 или Windows NT,
подтверждает свою подлинность на контроллере домена Windows Server 2003. На компьютерах с
системами Windows 95 и Windows 98 должна быть установлена служба Directory Services Client, или
эти операционные системы смогут подтверждать подлинность только с использованием протокола
LAN Manager.
• Когда компьютер, на котором выполняются системы Windows XP Professional или Windows Server
2003, подтверждает подлинность на Windows NT 4 Server.
• Когда любой клиент обращается к автономному серверу с системой Windows Server 2003.
• Когда клиент, на котором выполняются системы Windows XP Professional или Windows 2000,
пробует войти на контроллер домена с Windows Server 2003, но не способен подтвердить
подлинность, используя протокол Kerberos. В этом случае NTLM аутентификация может
использоваться как альтернативный протокол.
Протокол NTLM значительно менее безопасен, чем Kerberos. С пакетом Windows NT 4 Service Pack 4
компания Microsoft представила новую версию протокола NTLM с именем NTLMv2. Эта новая версия
включает дополнительную защиту, такую как создание уникального ключа сеанса каждый раз при
установлении нового подключения, а также расширенный процесс обмена ключами для защиты ключей
сеанса.
Резюме
В этой главе сделан краткий обзор основных концепций безопасности службы Active Directory Windows
Server 2003, включая участников безопасности, списки управления доступом, аутентификацию и
разрешения. Большая часть этой главы посвящена основным средствам обеспечения аутентификации и
разрешений службы Active Directory через протокол Kerberos. Протокол Kerberos предлагает безопасный
механизм подтверждения подлинности пользователей в Active Directory и получения доступа к сетевым
ресурсам. Обсуждена также интеграция протокола Kerberos с инфраструктурой открытых ключей PKI,
смарт-картами и другими реализациями Kerberos.
Глава 9. Делегирование администрирования
службы Active Directory
Как говорилось в предыдущих главах, служба Active Directory операционной системы Microsoft Windows
Server 2003 больше не поддерживает единое неструктурированное пространство имен, которое
использовалось в доменах Microsoft Windows NT. Вместо этого она обеспечивает иерархическое
представление каталога, сначала через иерархию доменной системы имен (DNS) множества доменов, а
затем через структуру организационных подразделений (OU) в пределах доменов. Эта иерархия создает
важную административную возможность: делегирование административных разрешений. В доменах
Windows NT такой возможности не было. Разрешения, полученные в одной части домена, действовали
повсюду в домене. Теперь это полностью изменилось. Служба Active Directory Windows Server 2003 имеет
мощные опции для управления разрешениями и делегирования административных задач в пределах домена.
Данная глава построена на обсуждении безопасности Active Directory, начатой в главе 8. Глава начинается с
повторного рассмотрения защиты Active Directory с целью уточнения списков управления доступом (ACL)
на объектах Active Directory. После этого в главе обсуждается делегирование прав. Для делегирования
разрешений вы можете напрямую обращаться к спискам ACL индивидуальных объектов. Для назначения
разрешений служба Active Directory Windows Server 2003 имеет.также Delegation Of Control Wizard (Мастер
делегирования управления).
Разрешения объектов службы Active Directory
Как описано в главе 8, когда пользователь входит в сеть Windows Server 2003, ему предоставляется лексема
доступа. Лексема доступа включает идентификаторы защиты (SID) для учетной записи пользователя, а
также SID для всех групп, к которым принадлежит пользователь. Как только пользователь вошел, он
пытается обратиться к сетевому ресурсу, ко-
торый включает объект Active Directory. Каждый сетевой ресурс или объект Active Directory имеет
список ACL, хранящийся в его атрибуте NT Security Descriptor, который состоит из одной или
более записей управления доступом (АСЕ), определяющей, какие права на данный объект имеет
каждый идентификатор SID. Дескриптор защиты содержит владельца объекта, а также список
управления разграничительным доступом (DACL) и список управления системным доступом
(SACL). Список DACL определяет разрешения на объект, которые имеют все участники
безопасности. Список SACL определяет параметры настройки аудита объекта.
Примечание. Каждый объект в Active Directory имеет список ACL, т.е. разрешения на этом
объекте можно изменять. Это справедливо для объектов, отражаемых как через инструменты
Active Directory Users And Computers (Пользователи и компьютеры Active Directory), Active
Directory Sites And Services (Сайты и службы Active Directory), ADSI Edit или Ldp.exe. Основное
внимание в этой главе будет уделено объектам, отображаемым через Active Directory Users And
Computers, потому что почти все администрирование защиты выполняется с помощью этого
инструмента. Однако многие из концепций и процедур, обсуждаемых здесь, могут применяться и
к другим инструментальным средствам администрирования Active Directory. Например, вы
можете использовать тот факт, что каждый объект имеет список ACL, чтобы изменить
разрешения для объектов сайтов в инструменте Active Directory Sites And Services. Можно
использовать также Delegation Of Control Wizard, который будет обсуждаться позже в этой
главе.
Есть множество различных инструментов, которые могут использоваться для просмотра
дескриптора защиты любого объектов Active Directory. Обычно используется инструмент Active
Directory Users And Computers. Он может давать несколько различных представлений списков
ACL. Это связано с тем, что разрешения на доступ к объектам Active Directory разбиты на две
категории: стандартные (standard) и специальные (special). Просмотр информации о защите через
Active Directory Users And Computers осложняется, если вы можете предоставлять разрешения
объектам внутри контейнерного объекта или атрибутам объекта.
Стандартные разрешения
Чтобы просмотреть стандартные разрешения для любого объекта Active Directory в разделе
домена каталога, обратитесь к вкладке Security (Безопасность) в окне Properties (Свойства)
нужного объекта в инструменте Active Directory Users And Computers. (Если вкладка Security не
видна, выберите Advanced Features (Дополнительные функции) в меню View (Вид), повторно
выберите объект и откройте окно Properties). Вкладка Security(Безопасность) показывает
стандартные разрешения, которые доступны для каждого объекта (см. рис. 9-1).
Рис. 9-1. Просмотр стандартных разрешений на объекте «пользователь»
Каждый класс объектов в Active Directory имеет свой набор стандартных разрешений. Например,
организационная единица (OU) - это контейнерный объект, который может содержать дочерние
объекты, поэтому он имеет набор разрешений, применяемых к дочерним объектам, которые не
подходят для объектов «пользователь». Однако, некоторые стандартные разрешения, например,
Full Control (Полный контроль), Read (Чтение), Write (Запись), Create All Child Objects (Создание
всех дочерних объектов) и Delete All Child Objects (Удаление всех дочерних объектов),
применимы ко всем объектам.
Некоторые объекты Active Directory имеют стандартные разрешения, которые применяются к
сгруппированным наборам свойств. Например, каждый объект «пользователь» имеет несколько
наборов свойств типа Public Information (Открытая информация), Personal Information (Личная
информация) или Web Information (Веб-информация). Каждый из этих наборов свойств относится
к набору атрибутов, так что предоставление доступа к нему обеспечивает доступ к набору
атрибутов. Например, набор свойств Personal Information включает атрибуты
homePhone, homePostalAddress, streetAddress и так далее. Использование наборов свойств для
назначения доступа к группам атрибутов упрощает процесс назначения разрешений.
Дополнительная информация. Чтобы найти полный список атрибутов, включенных в каждый
набор свойства, сделайте поиск выражения "property sets" (включая открывающие и закрывающие
кавычки) в Help And Support Center (Центр справки и поддержки). Схема Active Directory
определяет то, какие атрибуты являются частью каждого свойства, установленного с помощью
значения rightsGuid для категории свойства (в разделе конфигурации каталога) и значения
attributesSecurityGUID для объекта схемы. Например, значение rightsGuid для cn=PersonalInformation, cn=Extended-Rights, cn=conf iguration, dc=forestname равно значению attributes
ecurityGUID для cn=Telephone-Number, cn=Schema, cn=Configuration, dc=forestname. Это означает,
что номер телефона включен в набор свойств Personal Information.
В дополнение к стандартным разрешениям вкладка Security показывает некоторые
дополнительные права, такие как Receive As, Send As, Send To (все права, связанные с Microsoft
Exchange 2000 Server), Change Password и Reset Password. Список разрешений может также
включать разрешение Validated Write (Запись с проверкой ее достоверности). Например, объектам
Group требуется разрешение Validated Write на то, чтобы добавить/удалить себя как члена.
Различие между разрешением Validated Write и обычным Write состоит в том, что Validated Write
гарантирует, что записанное значение допустимо. В этом случае пользователь, имеющий
разрешение добавлять/удалять себя как члена группы, сможет добавлять к группе только себя
самого.
Специальные разрешения
Одна из записей в стандартном списке разрешений на вкладке Security (Безопасность) - Special
Permissions (Специальные разрешения). Вы можете предоставлять объектам Active Directory не
только стандартные разрешения, но и специальные. Они более детализированы и специфичны, чем
стандартные разрешения. Чтобы получить доступ к ним, щелкните на Advanced (Дополнительно)
на вкладке Security (рис. 9-2). В таблице 9-1 объясняется назначение столбцов в окне.
Примечание. Кнопка Default (По умолчанию) на вкладке Advanced сбрасывает разрешения,
установленные на объекте к разрешениям, заданным по умолчанию.
Рис. 9-2. Просмотр дополнительных параметров настройки защиты Advanced Security
Settings для пользовательского объекта
Табл. 9-1. Столбцы конфигурации специальных разрешений
Столбец
Туре (Тип)
Объяснение
Значение устанавливается для разрешений
Allow (Разрешить) или Deny (Запретить).
Обычно разрешения отсортированы так, что
сначала перечисляются все разрешения Deny
(Запретить). Порядок сортировки может быть
изменен щелчком на любом заголовке столбца.
Независимо от порядка появления в этом
столбце
сначала
всегда
оцениваются
разрешения Deny (Запретить).
Name (Имя)
Имя участника безопасности, к которому
применяется запись АСЕ.
Permission (Разрешение)
Столбец перечисляет уровень разрешения,
предоставленного участнику безопасности.
Уровни
разрешений
могут
быть
стандартными,
например
Full
Control,
специальными, например, Create/Delete User
Objects (Создавать/Удалять пользовательские
объекты), или только Special (Специальный).
Доступные типы разрешений зависят от типа
объекта.
Inherited
From Столбец указывает место, в котором
(Унаследованный от)
установлено это разрешение.
Apply To (Применяется к)
Столбец определяет глубину применения
разрешение. Она имеет разнообразные
параметры настройки, включая This Object
Only (Только этот объект), This Object And All
Child (Этот объект и все дочерние объекты)
или Only Child Objects (Только дочерние
объекты).
Это окно перечисляет все АСЕ-записи для объекта. Во многих случаях одни и те же участники
безопасности могут быть перечислены в нескольких записях АСЕ. Например, группе Authenticated
Users (Удостоверенные пользователи) дано разрешение Read Permissions (Читать разрешения),
Read General Information (Читать информацию общего характера), Read Personal Information
(Читать личную информацию), Read Web Information (Читать веб-информацию) и Read Public
Information (Читать открытую информацию) в отдельных записях АСЕ.
Вы можете добавлять и удалять участников безопасности или редактировать текущие разрешения,
предоставленные участнику безопасности, используя окно Advanced Security Settings
(Дополнительные параметры настройки защиты). Если вы добавляете или редактируете
разрешения, предоставленные участнику безопасности, вам дается два способа для назначения
разрешений. На рисунке 9-3 показан первый способ назначения разрешений на объект.
Рис. 9-3. Назначение специальных разрешений на доступ к объектам Active Directory
Вкладка Object (Объект) используется для назначения разрешений, которые применяются только к
объекту, ко всем дочерним объектам или к определенным дочерним объектам. Например, на
уровне OU можно предоставлять разрешения, которые применяются к объекту (OU), к объекту и
всем его дочерним объектам, ко всем дочерним объектам или к определенным дочерним объектам
(таким как учетные записи пользователя, группы и компьютера). Список разрешений изменяется в
зависимости от типа объекта, с которым вы работаете.
Второй способ назначения разрешений предназначен для управления параметрами настройки
свойств объекта (см. рис. 9-4).
Рис. 9-4. Конфигурирование разрешений, применяемых к свойствам объектов
Вкладка Properties (Свойства) используется для назначения разрешений на индивидуальные
свойства объекта, выбранного в поле Name (Имя) окна Advanced Security Settings
(Дополнительные параметры настройки защиты). Например, если вы применяете разрешения к
пользовательским объектам, вам предоставляется опция назначения разрешений Read и Write для
каждого атрибута, доступного для данного класса объектов.
Примечание. Когда вы увидите эти опции в первый раз, вы, вероятно, отреагируете двумя
способами. Первая реакция будет реакцией удовлетворения от того, что, наконец-то, вы
сможете назначать разрешения так, как вам всегда хотелось. Другая реакция - недовольство,
потому что у вас никогда не было потребности назначать разрешения на таком уровне. Обе
реакции отражают существо дела. Так происходит потому, что чаще всего вам не требуется
назначать разрешения на таком уровне, но этот уровень является определенно полезным, когда
вы сталкиваетесь с очень специфическими требованиями.
Просмотр записей АСЕ с помощью инструмента Ldp.exe
Графический интерфейс пользователя (GUI) является инструментом, который очень удобен для
управления огромной совокупностью АСЕ-записей. Чтобы получить возможность по-настоящему
оценить значение GUI, потратьте некоторое время на знакомство с инструментом Ldp.exe. Чтобы
просмотреть список ACL с помощью Ldp.exe, откройте диалоговое окно Run (Выполнить) и
напечатайте ldp. (Если Ldp.exe не был установлен на компьютере, откройте папку
\SUPPORT\TOOLS на компакт-диске Windows Server 2003 и дважды щелкнете на файле
Suptools.msi, чтобы установить средства поддержки Active Directory.) Выберите раскрывающееся
меню Connection (Подключения), затем выберите Connect (Подключиться). Если вы оставите
пустым поле сервера, то сервер соединится с локальным компьютером. Вы можете напечатать имя
сервера. Как только вы свяжетесь с сервером, выберите раскрывающееся меню Connection
(Подключения) и выберите Bind (Связаться). Если вы входите не с учетной записью пользователя,
имеющей административные права, введите дополнительные мандаты. Другим способом, оставьте
пробелы в полях, предназначенных для информации входа в систему. После подключения к
домену щелкните на раскрывающемся меню View (Вид), а затем выберите Tree (Дерево). Чтобы
просмотреть весь домен, щелкните на ОК. Структура OU домена будет представлена в левой
области окна (см. рис. 9-5).
Чтобы просмотреть список ACL для любого объекТа, найдите объект в дереве в левой области
окна. Затем щелкните правой кнопкой мыши на объекте и выберите Advanced (Дополнительно),
затем - Security Descriptor (Дескриптор защиты). Список ACL хранится в значении NT Security
Descriptor каждого объекта Active Directory. Затем инструмент Ldp.exe запишет каждый АСЕ в
правую область окна в зашифрованном формате:
(A;; CCDCLCSWRPWPDTLOCRSDRCWDWO;;; DA)
Каждая пара букв в первом списке АСЕ-записей соответствует определенному разрешению.
Например, СС означает, что пользователь имеет право создать все дочерние объекты. Последние
две буквы в АСЕ записи относятся к группе или пользователю, который имеет разрешения DA, т.е.
относится к группе Domain Admins. Если разрешения назначены пользователю или группе,
которая не имеет известного идентификатора SID, то последняя часть каждой записи АСЕ содержит SID пользователя или группы.
(Чтобы увидеть полный список всех возможных разрешений, которые могут быть назначены в
записях АСЕ, просмотрите справочную информацию для команды DsAcls, сопровождающую
инструменты Active Directory. Инструмент командной строки DsAcls может использоваться для
назначения или удаления разрешений к любому объекту в Active Directory).
Рис. 9-5. Использование инструмента Ldp.exe для просмотра свойств домена
После строк такого типа информации инструмент Ldp.exe даст более понятное объяснение каждой
записи АСЕ. Например, для строки, приведенной выше, это будет выглядеть так:
Асе[О]
Асе Туре: 0x0 - ACCESS_ALLOWED_ACE_TYPE
Асе Size: 36 bytes
Асе Flags: 0x0
Асе Mask: OxOOOfOiff
DELETE
READ CONTROL
WRITE DAC
WRITE_OWNER
ACTRL DS CREATE_CHILD
ACTRL DS DELETE CHILD
ACTRL DS LIST
ACTRL DS SELF
ACTRL DS READ_PROP ACTRL DS WRITE_PROP ACTRL_DS_DELETE_TREE ACTRL_DS_UST_OBJECT
ACTRL_DS_CONTROL_ACCESS
Ace Sid: Contoso\Domain Admins S-1 -5-21 -602162358-688789844-1957994488-512
Наследование разрешений
Служба Active Directory Windows Server 2003 использует статическую модель наследования
разрешений. Когда изменяется разрешение на контейнерном объекте в структуре Active Directory,
то оно рассчитывается и применяется к дескриптору защиты всех объектов, находящихся в этом
контейнере. Если изменяются разрешения на высшем уровне и применяются ко всем дочерним
объектам, то вычисление нового списка ACL для каждого объекта может быть значительной
нагрузкой на процессор. Однако это не означает, что разрешения не должны рассчитываться
повторно, когда пользователь или процесс обращаются к объекту.
По умолчанию все разрешения в Active Directory наследуются. Большинство разрешений,
установленных на контейнерном уровне, наследуется всеми объектами в пределах этого
контейнера, включая другие контейнерные объекты. Например, если пользователь имеет
разрешение создавать учетные записи пользователей в OU, он также может создавать учетные
записи в любой дочерней OU в пределах этой OU. В большинстве случаев вы, вероятно, примете
заданное по умолчанию наследование разрешений. Если вы разработали свою структуру OU с
целью делегирования администрирования, то нужно создать OU-структу-ру, в которой на высшем
иерархическом уровне предоставляются разрешения администраторам высшего уровня,
нуждающимся в разрешениях ко всем объектам Active Directory. По мере продвижения вниз по
иерархии вы можете назначать разрешения для других администраторов, которые должны иметь
контроль над меньшей частью домена.
В некоторых случаях можно блокировать любые административные разрешения администраторов
высокого уровня для определенной дочерней OU. Например, вы создали дочернюю OU для
филиала вашей компании и дали локальной административной группе полное управление над этой
OU. Возможно, вы не хотите, чтобы эти локальные администраторы имели доступ к учетным
записям пользователей, представляющих исполнительную власть в этой OU. Вы можете создать
OU Executives (Руководство) в пределах OU-филиала, а затем блокировать наследование
разрешений на уровне Executives OU.
Чтобы блокировать наследование разрешений на объекте Active Directory, обратитесь к окну
Advanced Security Settings для данного
объекта (см. рис. 9-2). Затем очистите опцию Allow Inheritable Permissions From The Parent To
Propagate To This Object And All Child Objects (Разрешить наследованным разрешениям
распространяться от родителя к этому объекту и всем дочерним объектам). После очистки этой
опции вам будет представлена опция, позволяющая копировать существующие разрешения или
удалять разрешения перед явным назначением новых разрешений (см. рис. 9-6).
Рис. 9-6. Выбор опции, позволяющей
блокировании наследования разрешений
копировать
или
удалять
разрешения
при
После блокировки наследования вы можете сконфигурировать разрешения на объектах.
Блокировка наследования имеет несколько следствий.
• Разрешения блокируются для объекта и любых дочерних объектов. Вы не можете
блокировать наследование разрешений на контейнерном уровне, а затем повторно
применять наследование от более высокого контейнера на более низкий уровень.
• Если вы решите копировать разрешения перед модификацией, наследование разрешений
начинается там, где вы блокируете разрешения. Если вы измените разрешения на более
высоком уровне, разрешения не будут унаследованы в обход блокированных разрешений.
• У вас нет большого выбора того, какие разрешения будут блокированы. Когда вы
блокируете разрешения, то все наследованные разрешения также блокируются.
Разрешения, которые были назначены на объект или дочерние объекты явно, не
блокируются.
Примечание. Одна из возможных проблем с блокированием унаследованных разрешений состоит
в том, что можно создать «осиротевший» объект, к которому никто не имеет разрешений.
Например, в организационной единице OU можно блокировать все наследование разрешений к ней
и назначить разрешения только для административной группы. Вы можете даже удалить
группу Domain Admins из списка ACL этой OU, чтобы группа Domain Admins не имела никаких
разрешений при нормальных обстоятельствах, и в OU не будет групп с административным управлением. В этом случае группа Domain
Admins всегда может взять объект в собственность и повторно назначить разрешения.
Фактические разрешения
Как описано в этой главе к настоящему моменту, пользователь может получить разрешения к
объекту в Active Directory несколькими способами.
• Учетной записи пользователя можно предоставить явные разрешения на доступ к объекту.
• Одной или более группам, к которым принадлежит пользователь, можно предоставить
явные разрешения на доступ к объекту.
• Учетной записи пользователя или группам, к которым принадлежит пользователь, могут
быть даны разрешения на уровне контейнерного объекта и разрешения, унаследованные
объектами низшего уровня.
Все разрешения суммируются, т.е. пользователю предоставляется самый высокий уровень
разрешений от любой из этих конфигураций. Например, если пользователю явно дано разрешение
Read (Чтения) к определенному объекту, при этом он принадлежит к группе с разрешением Modify
(Изменять) и группе с разрешением Full Control (Полное управление) на контейнерном уровне, то
этот пользователь будет иметь разрешение Full Control. Когда пользователь обращается к объекту,
подсистема защиты исследует все записи АСЕ, которые прикреплены к объекту. Они
оцениваются, и устанавливается самый высокий уровень разрешения. В дополнение к записям
АСЕ, которые предоставляют разрешения, Active Directory поддерживает также блокирование
разрешений. Блокирование разрешений может применяться на двух уровнях.
• Пользовательскому объекту или группе, к которой принадлежит пользователь, может быть
блокировано разрешение на доступ к определенному объекту явно.
• Пользовательскому объекту или группе, к которой принадлежит пользователь, может быть
блокировано разрешение на контейнерном уровне, и оно может быть унаследовано
объектами низшего уровня.
Блокирование разрешения (Deny) всегда отменяет разрешение (Allow). Например, если
пользователь является членом группы, которая имеет разрешение Modify для объекта Active
Directory, и если разрешение Modify к этому объекту явно блокировано для данного пользователя,
то он не сможет изменять объект. Это происходит потому, что записи АСЕ, которые блокируют
разрешения, оцениваются перед оценкой записей АСЕ, которые позволяют разрешения. Если одна
из записей АСЕ блокирует разрешение участнику безопасности, то другие записи АСЕ для
данного объекта не оцениваются.
Ситуация, в которой разрешения отменяют блокирование разрешения, возникает тогда, когда
разрешения Deny унаследованы, а разрешения Allow назначены явно. Например, вы можете
блокировать пользователю разрешение изменять любые учетные записи пользователя в
контейнере. Но если вы явно позволите разрешение Modify для объекту в пределах контейнера, то
данная учетная запись пользователя будет иметь разрешение Modify для этого объекта.
Блокирование разрешения: используйте осторожно
Использование блокирования разрешения может привести к тому, что работать с моделью защиты
вашей службы Active Directory будет очень трудно. Есть множество различных сценариев, в
которых вы можете предусмотреть блокировку разрешения. Один из них состоит в том, что вы
можете использовать Deny (Запретить) для удаления некоторых унаследованных разрешений.
Например, вы можете предоставить разрешения Modify на контейнерном уровне, но заменить его
на Read-Only (Только для чтения) далее вниз по иерархии. В этом же сценарии вы можете
блокировать разрешение Write на любых объектах или свойствах далее вниз по иерархии.
Еще одним сценарием, в котором можно было бы использовать Deny, является создание
контейнера, требующего более высокой защиты. Например, имеется контейнер для всех
должностных лиц, и нужно сделать так, чтобы обычный пользователь не смог читать свойства
учетных записей должностных лиц. Вы можете блокировать разрешение Read для контейнера,
используя группу Domain Users (Пользователи домена). В результате пользователям будет
запрещено читать объекты каталога, включая администраторов. Из-за осложнений, которые может
вызвать использование Deny, вы должны применять эту опцию с осторожностью.
В большинстве случаев вместо блокировки разрешений можно удостовериться, что пользователю
или группе не были даны эти разрешения. Если пользователь при этом не является членом группы,
которой были предоставлены разрешения, он не будет иметь доступа к объектам. Вам не
обязательно блокировать разрешение для предотвращения доступа пользователей к объектам
Active Directory.
Один из немногих сценариев, в которых выгодно использовать Deny, состоит в том, что группа
должна иметь определенные разрешения, а один или более пользователей этой же группы должны
иметь разрешения более низкого уровня. Например, вы можете создать группу по имени Account
Admins, которая отвечает за управление всеми учетными записями пользователей в домене.
Некоторые члены этой группы могут быть временными служащими, которые должны управлять
всеми учетными записями пользователей в домене, но не имеют права изменять свойства учетных
записей должностных лиц. В этом случае вы можете назначить группе Account Admins
разрешение управлять учетными записями
пользователей в домене, затем создать OU для учетных записей должностных лиц и группу для
временных членов группы Account Admins. Затем можно заблокировать право временных
пользователей изменять какие-либо учетные записи пользователей в OU должностных лиц.
Таким образом, конфигурирование защиты объектов Active Directory может затрагивать большое
количество взаимосвязанных переменных. Многие компании могут начинать с довольно простого
проекта защиты, в котором маленькой группе администраторов предоставляются все разрешения в
Active Directory. В большинстве случаев начальная конфигурация защиты Active Directory ясно
задокументирована. Однако со временем она становится более запутанной. Иногда другой группе
администраторов предоставляется набор разрешений для выполнения определенной задачи в
течение определенного периода времени. Предоставить разрешение просто, но часто случается
так, что впоследствии разрешения забывают удалить. Часто модификации защиты, сделанные
после начального развертывания Active Directory, не документируются.
Для любой структуры Active Directory существует возможность того, что текущая конфигурация
защиты окажется более сложной, чем первоначально разработанная конфигурация. Иногда это
кончается тем, что пользователи имеют больше разрешений, чем следует. К счастью, в Windows
Server 2003 есть инструмент, который может использоваться для определения фактических
разрешений, представленных участнику безопасности для доступа к объектам Active Directory.
Обратитесь к свойствам объекта через соответствующий инструмент администрирования Active
Directory. Выберите вкладку Security (Безопасность), щелкните на Advanced (Дополнительно), а
затем выберите вкладку Effective Permissions (Фактические разрешения). На рисунке 9-7 показано
окно инструмента Active Directory Users And Computers. Чтобы определить фактические
разрешения для определенной учетной записи пользователя или группы, щелкните Select (ВыборХ
а затем найдите имя группы или пользователя. Выбрав имя, щелкните на ОК. Окно Effective
Permissions (Фактические разрешения) отображает все разрешения, которые предоставлены
выбранному участнику безопасности для доступа к данному объекту Active Directory.
Примечание. Данный инструмент имеет некоторые ограничения, которые могут влиять на
отображаемые фактические разрешения. Инструмент определяет фактические разрешения,
основанные на наследовании и явно определенных разрешениях для учетной записи пользователя
и его группы. Однако пользователь может также получить некоторые разрешения на основании
того, как он входит в систему и соединяется с объектом. Например, в Windows Server 2003 вы
можете назначать разрешения для группы Interactive (членом этой группы становится каждый, кто
cделал вход на компьютер) или группы Network Login (каждый, кто обращается к информации по
сети). Описанный выше инструмент Active Directory не может определять разрешения,
предоставленные пользователю на основании принадлежности к этим типам групп. Кроме того, он
может определять разрешения, используя только разрешения человека, выполняющего
инструмент. Например, если пользователь, который выполняет инструмент, не имеет разрешения
читать состав некоторых групп, к которым принадлежит интересующий его пользователь, то
инструмент не способен точно определить разрешения.
Рис. 9-7. Отображение фактических разрешений для объекта Active Directory
Право собственности на объекты Active Directory
Каждый объект в Active Directory должен иметь владельца. По умолчанию
пользователь, создавший объект, является его владельцем. Владелец объекта
имеет право изменить разрешения на доступ к объекту, что означает, что даже
если владелец не имеет полного управления объектом, он всегда может изменить
разрешения на доступ к объекту. В большинстве случаев владельцем объекта
является определенная учетная запись пользователя, а не учетная запись
группы. Единственное исключение - это когда объект создан членом группы Domain Admins. В
этом случае владельцем объекта назначается группа Domain Admins. Если владелец объекта
является членом локальной группы Administrators, a не членом группы Domain Admins, то
владельцем объекта назначается группа Administrators.
Чтобы определить владельца объекта Active Directory, обратитесь к свойствам объекта, используя
соответствующий инструмент Active Directory. Выберите вкладку Security (Безопасность),
щелкните на Advanced (Дополнительно), а затем выберите вкладку Owner (Владелец). На рисунке
9-8 показано окно инструмента Active Directory Users And Computers.
Рис. 9-8. Просмотр владельца объекта Active Directory
Если вы имеете разрешение Modify Owner (Модификация владельца) для объекта, вы можете
использовать это окно для изменения владельца объекта. Вы можете назначить владельцем свою
собственную учетную запись, учетную запись другого пользователя или группу. Эта последняя
возможность уникальна для Active Directory Windows Server 2003. В Active Directory системы
Microsoft Windows 2000 вы сами можете стать владельцем или назначать владельцем другого
участника безопасности.
Административные привилегии
Административные разрешения являются специфическими для объектов Active Directory и
определяют, какие действия администратор может выполнять с этими объектами. Разрешения,
которые обсуждались до сих пор, основаны на списках ACL, приложенных к каждому объекту
Active Directory. Пользовательские привилегии отличаются тем, что они применяются к учетным
записям пользователя. Пользовательские привилегии пользователь получает за то, кем он
является, а не за то, что он имеет разрешения изменять специфический объект Active Directory.
Например, есть два способа дать пользователю (или группе) право добавлять рабочие станции к
домену. Один способ состоит в том, чтобы дать пользователю (или группе) разрешение Create
Computer Objects (Создание компьютерных объектов) на уровне OU или контейнера Computers
(Компьютеры). Это позволит пользователю добавить необходимое количество рабочих станций к
домену в указанном контейнере.
Другой способ состоит в том, чтобы дать пользователю привилегию добавления компьютеров к
домену. Она является частью политики Default Domain Controllers Policy (Заданная по умолчанию
политика контроллеров домена). Любой пользователь, имеющий эту привилегию, может добавить
к домену до десяти рабочих станций. По умолчанию это разрешение предоставляется группе
Domain Users (Пользователи домена).
Аудит использования административных
разрешений
Важным аспектом обеспечения безопасности службы Active Directory является создание
тщательно спланированной конфигурации защиты всего домена. Этот план должен ясно и точно
определить, какие разрешения должна иметь каждая административная группа. Другим
существенным компонентом защиты домена является аудит использования этих разрешений.
Аудит служит достижению двух целей. Во-первых, он обеспечивает свидетельство изменений,
которые были сделаны к каталогу. Если в каталоге были сделаны изменения, вы должны
проследить, кто их сделал. Это особенно важно, если в информации домена произведены
неправильные или злонамеренные изменения. Второй целью аудита является обеспечение
дополнительной проверки административных прав, применяемых по всему домену. Периодически
исследуя регистрационные журналы аудита, вы сможете определить, применяет ли
административные права тот, кто не должен их иметь.
Включение аудита изменений, сделанных для объектов Active Directory, состоит из двух шагов.
Первый шаг состоит во включении аудита на уровне OU Domain Controllers (Контроллеры
домена). Это делается с помощью инструмента администрирования Domain Controller Security
Policy (Политика безопасности контроллера домена). На консоли Microsoft Management Console
(ММС) выберите оснастку File>Add/ Remove (Файл>Добавление/Удаление), щелкните на кнопке
Add (Добавить), а затем добавьте Group Policy Object Editor (Редактор объектов групповой
политики). В Group Policy Wizard (Мастер групповой политики), щелкните на кнопке Browse
(Просмотр), затем трижды щелкните на Domain Controllers.domainname.com (где domainname —
имя домена, в котором вы включаете аудит). На рисунке 9-9 показана заданная по умолчанию
конфигурация аудита в Active Directory Windows Server 2003.
Рис. 9-9. Конфигурирование аудита в организационных единицах Default Domain Controllers
Если нужно производить аудит изменений для объектов Active Directory, вы должны
гарантировать, что включена функция Audit Account Management (Аудит управления учетными
записями). В этом случае все модификации, сделанные для объектов Active Directory, могут быть
проверены. Вы можете делать аудит успешных изменений к Active Directory, а также неудавшихся
попыток изменения Active Directory.
По умолчанию служба Active Directory Windows Server 2003 сконфигурирована для проведения
аудита всех успешных действий по управлению учетными записями.
Разрешение аудита на уровне OU контроллера домена является первым шагом в предоставлении
аудита. Это дает возможность сконфигурировать аудит для реальных объектов, расположенных в
пределах данного домена. Чтобы разрешить аудит объекта Active Directory, обратитесь к окну
Properties (Свойства) этого объекта через соответствующий инструмент Active Directory. Затем
выберите вкладку Security (Безопасность), щелкните на Advanced (Дополнительно) и выберите
вкладку Auditing (Аудит). На рисунке 9-10 показано окно инструмента Active Directory Users And
Computers и заданная по умолчанию установка для аудита OU в Active Directory.
Рис. 9-10. Конфигурирование аудита объектов Active Directory
Чтобы добавить больше записей для аудита, щелкните на кнопке Add (Добавить) и выберите
пользователей или группы, действия которых вы хотите контролировать. В большинстве случаев
вы должны выбрать группу Everyone, чтобы модификации, сделанные любым пользователем,
подвергались аудиту. Затем вы можете выбрать, какие действия вы хотите подвергать аудиту. Вы
можете делать аудит всех модификаций, сделанных для любого объекта в контейнере, для
определенного типа объектов или для определенных свойств объектов. Вы можете допустить
аудит всех успешных модификаций, всех неудавшихся попыток модификации или оба варианта.
Если вы включите аудит всех успешных модификаций, вы будете отслеживать все изменения,
сделанные к каталогу. Если вы включите аудит неудавшихся попыток модификаций, вы сможете
контролировать любые незаконные попытки изменить информацию каталога. Как только аудит
включен, все контрольные события записываются в файле регистрации Security, доступном через
инструмент Event Viewer (Средство просмотра событий).
Разрешение аудита делается просто. Управлять аудитом гораздо сложнее. Если вы разрешаете
аудит всех модификаций каталога на уровне OU контроллера домена, то файл регистрации
Security будет расти очень быстро. Почти все события будут законными изменениями, и не будут
представлять для вас никакого интереса, кроме как отслеживание событий. Однако среди
законных изменений может быть разбросано несколько изменений, о которых вы должны знать.
Проблема состоит в том, чтобы среди большого количества обычных событий найти несколько
интересных контрольных событий. В некоторых компаниях одному администратору каждый день
поручают просмотр зарегистрированных событий. Наилучший способ справиться с этой
проблемой состоит в том, чтобы создать некоторый автоматизированный способ анализа файлов
регистрации событий. Другой путь состоит в использовании инструмента Microsoft Operations
Manager (Менеджер операций) (отдельно продаваемый продукт) для фильтрации событий и
вынесения предупреждений только в случае интересных событий.
Дополнительная информация. Если вы хотите больше узнать о продукте Microsoft
Operations Manager (MOM), посетите веб-сайт http://www.microsoft.com/mom. MOM
обеспечивает большое количество функциональных возможностей, которые выходят далеко
за пределы проблемы контроля журналов безопасности.
Делегирование административных задач
В этой главе мы имеем дело с гарантией безопасности объектов Active Directory. Все сказанное до
сих пор являлось подготовкой к данному разделу, который посвящен использованию опций
защиты для делегирования административных задач. Поскольку все объекты в Active Directory
имеют ACL-список, вы можете управлять административным доступом к любому свойству
любого объекта. Это означает, что вы можете предоставлять другим администраторам Active
Directory очень точные разрешения, чтобы они могли выполнять только делегированные им
задачи.
Хотя при делегировании административных прав можно очень сильно их детализировать,
необходимо поддерживать равновесие между сохранением максимально возможной простоты
вещей и удовлетворением требований безопасности. В большинстве случаев делегирование
административных разрешений в Active Directory подпадает под один из следующих сценариев.
• Назначение полного управления одной OU. Довольно типична ситуация, когда
компания имеет несколько офисов с локальным администратором в каждом офисе,
который должен управлять всеми объектами локального офиса. Этот вариант может также
использоваться компаниями, которые слили домены ресурсов Windows NT в OU одного
домена Active Directory. Прежним администраторам доменов ресурсов можно дать полное
управление всеми объектами, расположенными в определенной OU. Использование этой
опции означает, что можно практически полностью децентрализовать администрирование
вашей организации, имея единственный домен.
• Назначение полного управления определенными объектами в OU. Это разновидность
первого сценария. В некоторых случаях компания может иметь несколько офисов, но
локальные администраторы должны управлять только определенными объектами в OU
данного офиса. Например, можно позволить локальному администратору управлять всеми
объектами пользователей и групп, но не компьютерными объектами. В ситуации, когда
домены ресурсов стали организацион-ньши единицами (OU), вы, возможно, захотите,
чтобы администраторы OU управляли всеми компьютерными учетными записями и
локальными группами в OU, но не пользовательскими объектами.
• Назначение полного управления определенными объектами всего домена. Некоторые
компании имеют высоко централизованное администрирование пользователями и
группами, когда только одна группа имеет разрешение добавлять и удалять учетные
записи групп и пользователей. В этом сценарии данной группе можно давать полное
управление объектами пользователей и групп независимо от того, где в пределах домена
расположены объекты. Этот сценарий довольно типичен для компании с
централизованной
группой
администрирования
компьютерами
и
берверами.
Компьютерной группе можно дать полное управление всеми компьютерными объектами в
домене.
• Назначение прав на модификацию только некоторых свойств объектов. В некоторых
случаях можно предоставить группе административное разрешение управлять поднабором
свойств объекта. Например, устанавливать пароли для всех учетных записей пользователя,
но не иметь других разрешений. Отделу кадров можно дать разрешение на модификацию
личной и открытой информации, касающейся всех учетных записей пользователя в
домене, но не давать разрешение на создание или удаление учетных записей пользователя.
Можно использовать эти опции и любую их комбинацию в Active Directory Windows Server 2003.
Один из способов конфигурирования делегированных разрешений состоит в прямом обращении к
списку ACL для объекта и конфигурировании разрешений. Это может быть достаточно сложным
из-за большого числа доступных опций и реальной возможности сделать ошибку.
Чтобы сделать эту задачу более легкой, Active Directory Windows Server 2003 включает Delegation
Of Control Wizard (Мастер делегирования управления).
Чтобы использовать Delegation Of Control Wizard, выполните следующие действия.
1. Откройте инструмент Active Directory Users And Computers и найдите родительский
объект, которому нужно делегировать управление. В большинстве случаев делегировать
управление можно на уровне OU, домена или контейнера, например, на уровне
контейнеров Computers (Компьютеры) или Users (Пользователи). Щелкните правой
кнопкой мыши на родительском объекте и выберите Delegate Control (Делегировать
управление). Щелкните на кнопке Next (Далее).
2. На странице Users Or Groups (Пользователи или группы) выберите пользователей или
группы, которым вы хотите делегировать управление. Щелкните на кнопке Add
(Добавить), чтобы просмотреть Active Directory для поиска соответствующих
пользователей или групп.
3. Затем выберите задачи, которые вы хотите делегировать. Окно (рис. 9-11) дает вам
возможность выбрать задачи из списка обычных или создать собственную задачу для
делегирования.
Рис. 9-11. Использование Delegation Of Control Wizard (Мастер делегирования управления)
для выбора обычной задачи или создания собственной задачи для делегирования
4. Если вы выберите создание собственной задачи, можете задать тип объектов, которым вы
хотите делегировать административные разрешения (рис. 9-12).
Рис. 9-12. Выбор типа объектов, которым будут делегированы разрешения
5. Можно выбрать уровни разрешений, которые вы хотите применить к объекту: полный
контроль над объектом или доступ к определенным свойствам (рис. 9-13).
Рис. 9-13. Выбор специфических разрешений для делегирования
Delegation Of Control Wizard значительно облегчает делегирование управления по сравнению с
конфигурированием разрешений через ACL-списки. Однако эффект от применения обоих методов
одинаков, т.е. ACL-списки объектов изменяются для обеспечения соответствующего уровня
доступа.
Настройка инструментов для делегирования
администрирования
Служба Active Directory Windows Server 2003 обеспечивает мощные способы делегирования
административных задач и назначения очень точных разрешений, которые пользователи должны
иметь при необходимости выполнить специфические задачи. В дополнение к этим способам
Active Directory облегчает развитие административных средств, которые соответствуют
конкретной задаче пользователя. Например, если вы делегируете право устанавливать пароли для
отдельной OU, вы можете воспользоваться простым инструментом администрирования, который
может использоваться только для этой задачи. Windows Server 2003 имеет два способа создания
специально настроенных инструментов. Вы можете настроить внешний вид средств обычных
консолей ММС или создать панель задач (taskpad), которая является полностью настроенным
инструментом администрирования.
Настройка консоли управления Microsoft
Первый вариант разработки инструмента администрирования состоит в настройке консоли
управления Microsoft (ММС - Microsoft Management Console) с помощью одной из заданных по
умолчанию оснасток.
Предостережение. Простое создание настроенной ММС-консо-ли не предоставляет и не
ограничивает права пользователя на выполнение административных задач. Перед созданием
настроенного административного интерфейса нужно делегировать правильный уровень
разрешений. Например, если вы даете пользователю право создания учетных записей
пользователя на уровне домена, а затем создаете ММС-консоль, которая дает возможность
пользователю рассматривать только одну OU, то он сможет создавать учетные записи
пользователя в любой OU. Если пользователь загружает обычный инструмент
администрирования Active Directory Users And Computers или садится за другой рабочий
стол с другой ММС-консолью, он сможет создать учетную запись где угодно.
Для создания настроенной ММС-консоли откройте диалоговое окно Run (Выполнить) и
напечатайте ттс. Будет открыта пустая ММС-консоль. Из меню File (Файл) добавьте нужную
оснастку инструмента Active Directory. Если вы создаете собственную консоль ММС, используя
оснастку Active Directory Users And Computers, разверните домен и найдете
контейнерный объект, которому вы делегировали разрешения. В левой области окна щелкните
правой кнопкой мыши на контейнерном объекте и выберите New Window From Here (Отсюда
новое окно).
Откроется новое окно, в котором будут видны только контейнерный объект и все дочерние
объекты. Затем вы можете переключиться назад к окну, которое отображает весь домен, и закрыть
окно. Далее сохраните инструмент администрирования и предоставьте его пользователям, которые
будут управлять только частью домена, видимого в ММС-консо-ли. Консоль ММС может быть
предоставлена пользователю несколькими способами. Например, вы можете установить консоль
ММС на рабочий стол пользователя или создать ярлык к инструменту администрирования на
сетевом ресурсе.
Чтобы быть уверенным, что администраторы контейнера не изменят ММС-консвль, можно
изменить опции ММС-консоли, выбирая Options в меню File. Вы можете сконфигурировать ММСконсоль так, чтобы она сохранялась в режиме User Mode (Режим пользователя), и изменить
разрешения на ММС, чтобы конечный пользователь не мог сохранять изменения ММС-консоли.
На рисунке 9-14 показан соответствующий интерфейс. Для уточнения деталей настройки ММСконсолей смотрите Help And Support Center (Центр справки и поддержки).
Рис. 9-14. Конфигурирование собственной ММС-консоли для предотвращения возможных
ее изменений
Создание панели задач для администрирования
Собственная ММС-консоль полезна в том случае, когда пользователю требуется полное
административное управление специфической OU.
Однако если разрешения пользователя ограничены выполнением определенных задач в
контейнере, то панель задач обеспечивает более простой инструмент управления.
Создание панели задач состоит из двух шагов. Сначала создается вид панели задач, а затем
назначаются задачи, которые пользователь может выполнять на объектах. Чтобы создать панель
задач, создайте настроенную ММС-консоль, содержащую административную оснастку, которую
вы хотите использовать. Найдите контейнер, в который вы делегировали административные
разрешения, затем щелкните правой кнопкой мыши и выберите New Taskpad View (Новый вид
панели задач). Запустится мастер New Taskpad View Wizard. Мастер предоставит вам опции для
выбора типа объектов, отображаемых на панели задач, и информации, отображаемой на экране.
После создания вида панели вы можете добавлять задачи с помощью мастера новых задач. Мастер
определит, какие типы задач могут быть выполнены пользователями панели задач. Список
доступных задач зависит от типов объектов, которые видны на панели задач. Например, если вы
выберите просмотр OU, которая содержит учетные записи пользователей, вы получите опцию
назначения задач, которые могут быть выполнены с учетными записями пользователя. Закончив
создание панели задач, можно также сконфигурировать ее параметры настройки, чтобы она
содержала очень простой интерфейс.
На рисунке 9-15 показана панель задач, которая может использоваться администратором для
установки паролей в определенной OU. Чтобы использовать этот инструмент, администратор
просто выбирает учетную запись пользователя, а затем щелкает Reset Password (Заново установить
пароль).
Рис. 9-15. Панель задач для сброса пользовательских паролей
Планирование делегирования
администрирования
Active Directory Windows Server 2003 предоставляет средства, предназначенные для делегирования
административных разрешений в вашем домене. Однако вместе с положительными сторонами
делегирования разрешений вы получаете риск назначения неправильных разрешений.
Пользователям можно предоставить слишком большое количество разрешений, позволяющее им
делать в Active Directory то, что им делать не положено. Пользователям можно предоставить
слишком малое количество разрешений, не позволяющее делать то, что они должны делать.
Создание структуры делегирования, которая обеспечит пользователей точными разрешениями, в
которых они нуждаются, требует серьезного планирования. Ниже приведены некоторые советы,
помогающие это сделать.
• Тщательно документируйте административные требования для всех потенциальных
администраторов. В большинстве компаний вы обнаружите, что имеются различные
группы, которые нуждаются в некоторых административных разрешениях в домене. Если
компания использовала Windows NT, многие из этих пользователей могли быть членами
группы Domain Admins. Документируя административные задачи, которые эти
пользователи должны выполнять, вы обнаружите, что на самом деле они нуждаются в
•
•
•
гораздо более низком уровне доступа. Часто единственный способ документирования
уровня административных разрешений, в которых нуждается каждая группа, состоит в
документировании всей административной работы, которую они делают каждый день.
Документируя действия, которые администраторы должны выполнять, вы смбжете
разработать точные разрешения, которые для этого следует иметь.
Перед тем как сделать какие-либо изменения в производственной среде, проверьте все
модификации защиты в испытательной среде. Создание неправильной конфигурации
защиты может иметь серьезные последствия для вашей сети. Используйте испытательную
лабораторию для гарантии того, что модификации разрешений отвечают необходимым
требованиям, но не дают разрешений, которые не являются необходимыми.
Используйте Effective Permissions (Фактические разрешения) в окне Advanced Security
Settings (Дополнительные параметры настройки защиты) для мониторинга и проверки
разрешений, которые имеют пользователи. Окно Effective Permissions является отличным
новым инструментом службы Active Directory Windows Server 2003, который может
использоваться для определения точных разрешений пользователя или группы.
Используйте этот инструмент в испытательной среде для гарантии того, что ваша
конфигурация точна, а затем используйте его в производственной среде, чтобы
удостовериться, что ваша реализация соответствует плану.
Документируйте все разрешения, которые вы назначаете. Из всех задач, возложенных на
сетевых администраторов, документирование изменений, сделанных в сети, относится к
самым неприятным, потому что это очень утомительно и кажется не особо важным. В
результате документация часто оказывается неполной или устаревшей. Единственный путь
эффективного управления конфигурацией защиты вашей сети состоит в том, чтобы
документировать начальную конфигурацию, а затем взять обязательство обновлять
документацию всякий раз, когда один из первоначальных параметров настройки изменен.
Резюме
Возможность делегирования административных разрешений в Active Directory Windows Server
2003 дает большую гибкость в управлении вашим доменом. Оно основано на модели безопасности
Active Directory, в которой все объекты и все атрибуты объектов имеют список ACL,
контролирующий разрешения на доступ к объекту для различных участников безопасности.
Согласно этой модели по умолчанию все разрешения наследуются от контейнерных объектов к
объектам, находящимся в пределах контейнера. Эти особенности модели защиты подразумевают,
что вы можете назначить любой уровень разрешений на доступ к любому объекту Active Directory.
Такая гибкость может привести к увеличению сложности, если защита Active Directory не
поддерживается настолько простой, насколько это возможно. В этой главе был дан краткий обзор
разрешений защиты, делегирования административных прав в Active Directory и некоторых из
инструментальных средств, которые могут использоваться для этой работы.
Глава 10. Управление объектами Active
Directory
Обычные задачи, которые вы будете выполнять с помощью службы каталога Microsoft Active
Directory системы Windows Server 2003, вовлекут вас в управление такими объектами Active
Directory как пользователи и группы. Большинство компаний создает и реализует проект Active
Directory один раз. После развертывания с большинством объектов Active Directory произойдут
небольшие изменения. Однако работа с объектами user (пользователь) и объектами group (группа)
является исключением из этого правила. По мере того как служащие присоединяются к компании
или оставляют ее, администратор тратит время на управление пользователями и группами. Служба
Active Directory содержит другие объекты, такие как printer (принтер), computer (компьютер) и
shared folder (общие папки), которые также требуют частого администрирования.
В этой главе обсуждаются концепции и процедуры, которые используются для управления
объектами Active Directory. В ней обсуждаются типы объектов, которые можно хранить в Active
Directory и объясняется, как управлять этими объектами. Показан основной интерфейс, который
вы будете использовать для работы с объектами, инструмент Active Directory Users And Computers
(Пользователи и компьютеры Active Directory) и некоторые усовершенствования, которые
сделаны для этого инструмента в Windows Server 2003.
Управление пользователями
В службе Active Directory Windows Server 2003 существуют три объекта, которые используются
для представления индивидуальных пользователей в каталоге. Два из них, объект user
(пользователь) и объект inetOrgPerson, являются участниками безопасности, которые могут
использоваться для назначения доступа к ресурсам вашей сети. Третий объект contact (контакт) не
является участником безопасности и используется для электронной почты.
Объекты User
Один из наиболее типичных объектов в любой базе данных Active Directory — объект user. Объект
user, подобно любому другому объекту
класса Active Directory, представляет собой совокупность атрибутов. Фактически, он может иметь
более 250-ти атрибутов. Этим служба Active Directory Windows Server 2003 сильно отличается от
службы каталога Microsoft Windows NT, в которой объекты user имеют очень мало атрибутов.
Поскольку Active Directory может обеспечить эти дополнительные атрибуты, она полезна именно
как служба каталога, а не просто как база данных для хранения опознавательной информации.
Active Directory может стать основным местом хранения большей части пользовательской
информации в вашей компании. Каталог будет содержать пользовательскую информацию: номера
телефона, адреса и организационную информацию. Как только пользователи научаться делать
поиск в Active Directory, они смогут найти практически любую информацию о других
пользователях.
Когда вы создаете объект user , нужно заполнить некоторые из его атрибутов. Как показано на
рисунке 10-1, при создании учетной записи пользователя требуется только шесть атрибутов,
причем атрибуты сп и sAMAccountName конфигурируются на основе данных, которые вы вводите
при создании учетной записи. Остальные атрибуты, включая идентификатор безопасности (SID),
автоматически заполняются системой безопасности.
Рис. 10-1. Обязательные
инструментом Adsiedit.msc
атрибуты
учетной
записи
пользователя,
отображаемые
При создании учетной записи пользователя вы можете назначить значения многим атрибутам
объекта user. Некоторые из атрибутов нельзя увидеть через интерфейс пользователя (UI),
например, атрибут Assistant (Помощник). Его можно заполнять, используя скрипт или инструмент
Adsiedit.msc, который обращается к атрибуту напрямую. Можно заполнять скрытые атрибуты в
процессе общего импорта информации каталога с использованием утилит командной строки Csvde
или Ldifde. Детальную информацию по использованию этих утилит смотрите в Help And Support
Center (Центр справки и поддержки). Заполнять невидимые в UI атрибуты необходимо, так как
они используются для поиска и изменения объектов. В некоторых случаях скрытый атрибут
доступен через диалоговое окно Find (Поиск). Например, в инструменте Active Directory Users And
Computers (Пользователи и компьютеры Active Directory) для поиска всех пользователей, которые
имеют один и тот же атрибут Assistant, используйте вкладку Advanced (Дополнительно) в
диалоговом окне Find, чтобы создать запрос, основанный на атрибуте Assistant (см. рис. 10-2). В
этом окне щелкните на кнопке Field (Поле), выберите User (Пользователь), а затем выберите
атрибут, по которому вы хотите сделать поиск. Так можно найти многие скрытые атрибуты.
Рис. 10-2. Поиск учетных записей пользователя по атрибутам, которые не видны в
пользовательском интерфейсе
Дополнительная информация. Вы можете просматривать и изменять любой атрибут
объекта user, используя инструменты Adsiedit.msc или Ldp.exe. Более эффективный способ
состоит в использовании скриптов. От этого можно получить значительную выгоду,
поскольку Active Directory написана так, чтобы разрешать и поощрять использование
скриптов. Информацию об использовании скриптов для автоматизации задач управления
службой Active Directory смотрите в центре TechNet Script Center
по
адресу
http://www.microsoft.com/technet/scriptcenter/default.asp. TechNet Script Center содержит
ресурсы для создания скриптов и типовые сценарии, используемые для расширения
административных задач, которые иначе выполняются через консоли управления службой
Active Directory. Смотрите также веб-сайт Microsoft Press Online по адресу http://
www.microsoft.com/mspress/, где находится бонус-глава по созданию сценариев «Introduction
to ADSI Scripting Using VBScript» (Введение в ADSI сценарии на языке VBScript),
написанная Майком Малкером (Mike Mulcare).
Большинство административных задач, связанных с обычными пользователями, выполняются при
помощи инструмента Active Directory Users And Computers. Чтобы создать с его помощью объект
user, найдите контейнер, в котором вы хотите создать объект, щелкните правой кнопкой мыши и
выберите New>User (Новый>Пользователь). При создании пользователя вы должны ввести Full
Name (Полное имя) и User Logon Name (Пользовательское имя для входа в систему). Данные Full
Name используются для заполнения атрибута сп пользователя, данные User Logon Name
становятся значением sAMAccountName. После создания пользователя можно обращаться к
свойствам объекта для заполнения дополнительных атрибутов пользователя, назначение которых
вполне понятно. Наиболее важная вкладка, предназначенная для управления учетной записью
пользователя — это вкладка Account (Учетная запись) (см. рис. 10-3). Пользовательские
параметры настройки, доступные на вкладке Account, описаны в таблице 10-1.
Рис. 10-3. Вкладка Account для объекта user
Табл. 10-1. Свойства учетной записи объекта User Параметры учетной записи
UserLogonName
Идентифицирует
основное
имя
(Пользовательское имя для пользователя (UPN) для данного
входа в систему)
пользователя.
User
Logon
Name Идентифицирует имя, применяющееся
(Пользовательское имя для для входа в более ранние, чем Microsoft
входа
в
систему) Windows 2000, системы, используя
(использовалось до Windows формат domain\username.
2000)
Logon Hours (Часы входа в Устанавливает
часы,
в
которые
систему)
пользователь может входить в домен.
Log On To (Вход на)
Перечисляет компьютеры (используя
имена NetBIOS компьютеров), на
которые пользователю разрешается вход.
Пояснение
Account Is Locked Out Указывает на то, что учетная запись
(Учетная запись блокирована) была блокирована из-за слишком
большого числа неудавшихся попыток
входа в систему.
Account
Options
(Опции Обеспечивает
настройку
таких
учетной записи)
параметров, как политики пароля и
опознавательные требования.
Account Expires (Учетная Определяет время окончания срока
запись недействительна)
действия учетной записи.
Именование объектов user в Active Directory
Каждый объект в Active Directory должен иметь уникальное имя, но для объекта user это простое
утверждение может стать довольно сложным, потому что объект user фактически имеет несколько
возможных имен. В таблице 10-2 перечислены все имена, которые могут быть связаны с именем
пользователя username, и область действия, в пределах которой это имя должно быть уникальным.
Табл. 10-2. Требования уникальности имени пользователя
Username (Имя пользователя)
Требование уникальности
First name, initials, last name (Имя, Уникальность не требуется.
инициалы, фамилия)
Display name (Отображаемое имя)
Уникальность не требуется.
Full name (Полное имя) - используется
для заполнения атрибута сп учетной
записи пользователя. По умолчанию
полное имя создается из полей First
Name, Initials и Last Name диалогового
окна New Object-User (Новый объектпользователь). Его можно изменить,
используя Adsiedit.msc
Username (Имя пользователя)
Должно быть уникальным в
пределах организационной
единицы (OU).
User principal name (Основное имя
пользователя). UPN составлено из имени
входа в систему и DNS-имени домена
или альтернативного UPN, если для леса
были
сконфигурированы
дополнительные UPN-суффиксы.
User Logon Name (Pre-Windows 2000)
(Пользовательское имя входа в систему,
используемое до Windows 2000)
Должно быть уникальным в
пределах леса.
Требование уникальности
Должно быть уникальным в
пределах домена.
UPN является очень полезным именем для пользователя. Пользователь может перейти в любой
домен леса и войти в систему, используя свое UPN-имя, вместо того чтобы при входе выбирать
свой домашний цомен. По умолчанию UPN-суффикс является также DNS-именем для цомена. Вы
можете изменять UPN-суффикс, например, использовать различные DNS-имена внутри и вне
системы для отображения в интернете. В большинстве случаев SMTP-адрес электронной почты
для всех пользователей соответствует внешнему имени DNS. Ваши пользователи, возможно,
захотят входить в домен, используя свои адреса SMTP. Вы можете включить эту опцию, добавляя
альтернативный UPN-суффикс к лесу и назначая его всем учетным записям пользователя. Чтобы
создать дополнительный UPN-суффикс, откройте инструмент Active Directory Domains And Trusts
(Домены и доверительные отношения Active Directory), щелкните правой кнопкой мыши на записи
Active Directory Domains And Trusts, расположенной в верхней левой области окна, и выберите
Properties (Свойства) (см. рис. 10-4). Напечатайте любой альтернативный UPN-суффикс, который
вы желаете использовать.
Рис. 10-4. Добавление альтернативного UPN-суффикса к вашему лесу
Объекты inetOrgPerson
Одним из новых объектов Active Directory Windows Server 2003 является объект inetOrgPerson. Он
является основной учетной записью пользователя, которая используется другими каталогами с
применением облегченного протокола службы каталогов (Lightweight Directory Access Protocol —
LDAP) и Х.500, совместимыми с требованиями документа Request for Comments (RFC) 2798.
Вводя объект inetOrgPerson, Microsoft облегчил интеграцию службы Active Directory с другими
каталогами и упростил перемещение из каталогов в Active Directory.
Примечание. При обновлении леса Windows 2000 до Windows Server 2003 в схеме создается объект
inetOrgPerson, когда вы выполняете команду Adprep.exe с ключом /forestprep. Утилиту Adprep.exe
можно найти в папке \I386 на компакт-диске Windows Server 2003.
Объект inetOrgPerson может быть создан с помощью инструмента Active Directory Users And
Computers. Для этого найдите контейнер, в котором вы хотите создать объект, щелкните на нем
правой кнопкой мыши и выберите New>InetOrgPerson. При создании объекта inetOrgPerson вы
должны ввести пользовательское имя входа в систему и полное имя. Объект inetOrgPerson
является подклассом объекта user, т.е. он имеет все характеристики пользовательского класса,
включая и то, что он действует как участник безопасности. Объекты inetOrgPerson управляются и
используются теми же способами, как и объект user.
Учетные записи Contact
Третий тип объектов, который может использоваться для представления пользователей в Active
Directory, — это объект contact (контакт). Объекты contact отличаются от объектов user и
inetOrgPerson тем, что они не является участниками безопасности (security principal). Обычно
объекты contact используются только для информационных целей. Чтобы создать объект contact в
инструменте Active Directory Users And Computers, найдите контейнер, в котором вы хотите
создать объект, щелкните на нем правой кнопкой мыши и выберите New>Contact. При создании
объекта contact вы должны ввести полное имя, можно также заполнить множество атрибутов
объекта, включая номера телефона и адрес.
Контакты полезны в нескольких сценариях. Например, имеется пользователь, который не является
участником безопасности в вашем домене, но чья контактная информация должна быть
доступной. Это могут быть консультанты, работающие в вашем офисе и не имеющие прав на вход
в сеть, но их контактная информация должна храниться в компании, чтобы ее могли легко найти
все сотрудники. Контактами можно пользоваться для хранения общей информации лесов.
Предположим, что ваша компания слилась с другой компанией, которая уже развернула Active
Directory. Можно создать доверительные отношения между двумя лесами так, чтобы совместно
использовать сетевые ресурсы, но глобальный каталог (GC) каждого леса будет содержать только
учетные записи этого леса. Однако ваша работа может требовать, чтобы все или некоторые
учетные записи обоих лесов были видны пользователям. Для разрешения этого используется
инструмент Microsoft Metadirectory Services (MMS), чтобы создать объекты contact для каждой
учетной записи пользователя из другого леса и заполнить эти объекты соответствующей
контактной информацией.
Дополнительная информация. Инструмент MMS доступен через Microsoft Consulting
Services (Консультационная служба) или через существующего партнера MMS. Для
получения
дополнительной
информации
смотрите
веб-страницу
http://
www.microsoft.com/windows2000 /technologies/directory / mms/'default, asp.
Другой вариант использования объекта contact возникает при реализации Microsoft Exchange 2000
Server, который, в отличие от более ранних версий, не имеет своей собственной службы каталога.
Вместо этого Exchange 2000 Server требует наличия Active Directory, и вся информация сервера
хранится в каталоге Active Directory. В Exchange Server 5.5 и более ранних версиях вы можете
создавать собственного получателя. Собственный получатель имеет адрес электронной почты, вы
можете посылать ему почту, но у него нет почтового ящика на вашем Exchange-сервере. Если вы
используете Exchange 2000 Server, то объект contact с поддержкой электронной почты заменит
объект собственного получателя. Когда вы включаете почту для объекта contact, вы назначаете
учетной записи адрес электронной почты, и он становится видимым для почтового клиента. Когда
вы посылаете почту объекту contact, она доставляется по правильному адресу электронной почты.
Управление группами
Основная функция Active Directory состоит в санкционировании доступа к сетевым ресурсам. В
конечном счете, доступ к сетевым ресурсам основан на индивидуальных учетных записях
пользователя. В большинстве случаев вы не захотите управлять доступом к. ресурсам с их
помощью. В крупной компании это может привести к слишком большой загрузке администратора,
кроме того, списки управления доступом (ACL) на сетевых ресурсах быстро стали бы
неуправляемыми. Поскольку управление доступом к сетевым ресурсам с помощью
индивидуальных учетных записей трудно поддается обработке, вы будете создавать
объекты group для одновременного управления большими совокупностями пользователей.
Типы групп
В системе Windows Server 2003 имеется два типа групп, называемых группами распространения
(distribution group) и группами безопасности (security group). Когда вы создаете новый объект
group, вам необходимо выбрать тип создаваемой группы (см. рис. 10-5).
Рис. 10-5. Создание новой группы в инструменте Active Directory Users And Computers
Стандартным типом группы в Active Directory является группа безопасности. Группа безопасности
является участником безопасности и может использоваться для назначения разрешений на сетевые
ресурсы. Группа распространения не может быть участником безопасности, поэтому она не очень
полезна. Вы используете данную группу, если установили Exchange 2000 Server и должны
объединить пользователей вместе, чтобы можно было посылать электронную почту всей группе.
Таким образом, группа распространения имеет возможность получать почту, а вы можете
добавлять пользователей, поддерживающих электронную почту, и контакты к этой группе, а также
посылать электронные сообщения одновременно всем пользователям группы.
Примечание. Группа распределения похожа на список рассылки в Exchange Server 5.5, но не
является точным эквивалентом списка рассылки Exchange 2000 Server. В Exchange Server 5.5 вы
можете использовать список рассылки, чтобы собрать группу пользователей в почтовых целях,
а также для назначения разрешений на общие папки Exchange-сервера. В Exchange 2000 Server вы
должны использовать группу безопасности с поддержкой электронной почты, если нужно
назначить разрешения на общую папку.
Вы можете преобразовывать группы распространения в группы безопасности и обратно, пока ваш
домен работает на функциональном уровне Windows 2000 native (естественный). (Для получения
дополнительной информации о функциональных уровнях см. табл. 2-1, 2-2 в гл. 2.) Если группа
содержит учетные записи пользователей или контакты, то объекты user или contact не изменяются,
когда изменяется тип группы.
Примечание. Поскольку группы распространения имеют ограниченное использование в Active
Directory, остальная часть этой главы будет посвящена группам безопасности.
Область действия группы
В Active Directory Windows Server 2003 вы можете создавать группы с тремя различными
областями действия: доменной локальной, глобальной и универсальной. В таблице 10-3
перечислены характеристики каждой области действия группы.
Примечание. Универсальные группы доступны только в том случае, если домен работает на
функциональном уровне Windows 2000 native. Вложенные группы (nested groups} — это группы,
которые являются членами других групп. Опции, предназначенные для вложения групп, зависят
от функционального уровня домена. Например, вы можете вложить глобальную группу в
доменную локальную группу на любом функн|иональном уровне, но вкладывать глобальную группу
внутрь другой глобальной группы можно только в том случае, если домен работает на
функциональном уровне Windows 2000 native, или более высоком.
Локальные группы домена являются полнофункциональными только в том случае, когда домен
поднят на уровень Windows 2000 native. Если домен выполняется на смешанном (mixed) уровне
Windows 2000, локальные группы домена работают точно так же, как локальные группы на
контроллерах домена в Windows NT 4. Группа может использоваться для назначения разрешений
на ресурсы только контроллеров домена, но не других компьютеров, расположенных в домене.
Если домен был переключен на естественный функциональный уровень Windows 2000, то
локальные группы домена могут использоваться для предоставления разрешений ресурсам,
расположенным на любом сервере с Windows 2000 или с Windows Server 2003.
Табл. 10-3. Область действия групп Active Directory
Область
действия группы
Domain
Local
(Локальная
Доменная)
Членство
группы Область
действия
включает
группы включает
Учетные
записи Используется
для
пользователя из любого назначения доступа к
домена леса
ресурсам
только
в
локальном домене.
Глобальные группы или Используется на всех
универсальные группы из серверах Windows 2000
любого домена леса
или Windows Server 2003.
Учетные
записи
пользователя
или
глобальные
и
универсальные группы из
любого
домена
доверенного леса
Вложенные
локальные
группы
домена
из
локального домена
Global
(Глобальная)
Учетные
записи
пользователя из домена, в
котором данная группа
создана
Вложенные
глобальные
группы из того же домена
Universal
(Универсальная)
Учетные
записи
пользователей из любого
домена в лесе
Глобальные группы из
любого домена леса или из
доверенного леса
Вложенные
универсальные группы из
любого домена в лесе или
из доверенного леса
Используется
для
назначения доступа к
ресурсам,
расположенным во всех
доменах леса, или между
доверенными лесами.
Используется на любом
сервере-члене домена, на
котором
выполняется
Windows.
Используется
для
назначения доступа к
ресурсам,
расположенным во всех
доменах леса, или между
доверенными лесами.
Используется только на
серверах Windows 2000
или Windows Server 2003.
Планирование. Вы используете группы по-разному, в зависимости от того, какие серверы
развернуты в вашей среде. Если ваш домен содержит только серверы с Windows 2000 и Windows
Server 2003, используйте локальные группы домена для назначения разрешений на все ресурсы,
расположенные на этих серверах. Однако вы также можете использовать локальные группы на
серверах-членах домена. Обратите внимание, что необходимо использовать локальные группы на
серверах Windows NT. В любом случае локальные группы могут содержать глобальные группы из
любого домена в лесе. Если вы создаете локальные группы на серверах с Windows 2000 или с
Windows Server 2003, группы могут содержать универсальные группы из любого домена леса или
из доверенного леса.
Функциональные возможности глобальных групп в Active Directory Windows Server 2003 и Active
Directory Windows 2000 остаются согласующимися между собой. Если домен был переключен на
функциональный уровень Windows 2000 native, вы можете вкладывать глобальные группы из того
же самого домена внутрь других глобальных групп. Если ваш домен работает на функциональном
уровне Windows 2000 mixed или native, вы можете использовать эту опцию, чтобы преодолеть
ограничение числа пользователей в пять тысяч на группу. Если группа очень большая, можно
создать несколько подгрупп и вложить их в одну группу. Вложение групп может быть полезным и
в других обстоятельствах. Например, ваша компания содержит несколько уникальных деловых
подразделений, в каждом из которых есть менеджеры и исполнители. Вы можете создать
глобальную группу Managers для каждого подразделения, а затем вложить эти глобальные группы
в единую для компании группу менеджеров.
Универсальные группы являются наиболее гибкими группами в Active Directory, но эта гибкость
дается «не бесплатно». Они могут содержать любого члена домена леса и использоваться для
назначения разрешений на ресурсы, расположенные в любом домене леса. Для этого список
членства для всех универсальных групп должен храниться в глобальном каталоге (GC) как
отдельный атрибут. Если ваш домен работает на функциональном уровне Windows 2000 native, то
каждый раз после добавления к универсальной группе нового члена весь список членов должен
копироваться на другие контроллеры домена. Для универсальной группы с тысячами
пользователей это может привести к значительной репликации. Однако если домен был поднят на
функциональный уровень Windows Server 2003, то контроллеры домена, на которых выполняется
Windows Server 2003, будут реплицировать только изменения в списке членства.
Использование универсальных групп создает и другие осложнения. Поскольку они используются
в любом месте леса, а члены группы могут
находится также в любой части леса, то GC-сервер должен быть доступен всякий раз, когда
пользователь входит в домен, иначе вход не будет выполнен. Эта проблема решена в Active
Directory Windows Server 2003. Если домен переключен на функциональный уровень Windows
Server 2003, вы можете сконфигурировать все контроллеры домена сайта так, чтобы они
кэшировали универсальное групповое членство, когда пользователь входит в домен. Если GCсервер недоступен, локальный контроллер домена может использовать кэшированное
универсальное групповое членство для подтверждения подлинности пользователя. Если
пользователь ранее не входил на локальный контроллер домена, то эта информация будет
недоступна, и пользователь не сможет войти в систему.
Предостережение. Если пользователь входит в систему, используя кэшированную
информацию универсальной группы, но разрешения универсальной группы были изменены,
то новые разрешения не применятся к локальному пользователю до тех пор, пока
универсальная групповая информация не будет модифицирована с GC-сервера.
Active Directory Windows Server 2003 содержит большое количество встроенных учетных записей
групп в контейнере Users (Пользователи) и Builtin (Встроенный). Эти группы имеют
разнообразные цели и заданные по умолчанию разрешения в пределах домена. Только две группы
при установке домена содержат некоторых членов - локальная группа домена Administrators
(Администраторы) и глобальная группа Domain Admins (Администраторы домена). Учетная
запись Administrator, под которой создавался домен, добавляется к обеим группам, а группа
Domain Admins добавляется к группе Administrators. Если домен является первым доменом в лесе,
то учетная запись Administrator также добавляется к глобальной группе Enterprise Admins
(Администраторы предприятия) и к глобальной группе Schema Admins (Администраторы схемы).
Создание проекта группы безопасности
В реализации Active Directory проект группы безопасности является наиболее детальным в рамках
всего проекта. Его создание может быть очень обстоятельной и кропотливой работой, особенно в
большой организации. В данном разделе обсуждаются общие принципы создания проекта группы
безопасности для вашей организации.
На первом этапе создания проекта нужно определить область действия группы. Во многих
компаниях возникают серьезные дискуссии о том, как использовать различные группы. А
использовать группы в Active Directory можно очень гибко. Например, в единственном домене
пользователи могут быть добавлены к группе с любой областью действия в домене, группы могут
использоваться для назначения разрешений на любой ресурс, находящийся в домене. В среде с несколькими доменами имеется несколько вариантов
для использования универсальных, глобальных и локальных групп домена.
Для большинства компаний лучший способ использовать области действия групп состоит в
выполнении следующих действий.
• Добавьте пользователей к глобальным или универсальным группам.
• Добавьте глобальные или универсальные группы к локальным группам домена.
• Назначьте доступ к ресурсам, используя локальные группы домена.
Некоторых компании сопротивляются созданию групп домена, даже если речь идет об одной
группе, но имеются серьезные причины, по которым лучше использовать две группы.
Если нужно создать группы домена, то имейте в виду, что глобальные или универсальные группы
должны включать пользователей, имеющих что-либо общее. Обычно они создаются на базе
делового подразделения или на основе общей функциональной цели. Например, все члены
коммерческого отдела обычно имеют больше общего друг с другом, чем с членами других
отделов. Им требуется доступ к одним и тем же ресурсам и одинаковое программное обеспечение.
Групповое членство часто также организуется на функциональной основе. Все менеджеры могут
быть сгруппированы вместе независимо от того, к какому подразделению они принадлежат. Все
члены проектной группы, вероятно, будут нуждаться в доступе к одним и тем же ресурсам
проекта.
Доменные локальные группы обычно используются для назначения разрешений на доступ к
ресурсам. Во многих случаях разрешения тесно связаны с деловыми отделами или функциями.
Например, всем членам коммерческого отдела требуется доступ к одним и тем же общим папкам
продаж, всем членам проектной группы - к одной и той же проектной информации. В других
случаях доступ к ресурсам может пересекать обычные деловые или функциональные границы.
Компания может использовать общую папку, к которой каждый в компании имеет доступ Read
Only (Только для чтения), или нескольким отделам и проектным группам нужен доступ к одной и
той же общей папке. Создавая доменную локальную группу, которая относится к определенному
специфическому ресурсу, вы можете легко управлять доступом к нему: добавлять
соответствующие глобальные или универсальные группы к локальной группе домена.
Часто пользователям требуется различный уровень доступа к совместно используемым папкам.
Например, компания имеет общую папку Human Resource (Кадры), где хранится вся информация о
полисах служащих. Все пользователи должны иметь возможность читать информацию,
хранящуюся в папке, но только члены отдела кадров могут изменять эту информацию. В этом
случае создаются две доменные локальные группы для общей папки. Одной группе назначается
разрешение Read Only (Только для чтения), другой - Full Control (Полное управление) или Modify
(Изменение). Затем глобальная группа Human Resources может быть добавлена к доменной
локальной группе, которой было назначено разрешение Full Control, а все другие глобальные
группы, которые нуждаются только в доступе Read Only, - к доменной локальной группе Read
Only.
Использование глобальных и доменных локальных групп означает, что вы можете разделять
владение глобальными группами и доменными локальными группами. Важной проблемой
безопасности в любой большой корпорации является обеспечение того, чтобы только правильные
пользователи имели доступ к любой общей информации. Первый шаг заключается в создании
владельца (owner) группы, также известного как authorizer (уполномоченный). Только владелец
может разрешать любую модификацию в конфигурации группы. Владельцем глобальной группы
обычно является администратор отдела. Владельцем глобальной группы, основанной на участии в
проекте, — менеджер проекта. Только они могут разрешить любое изменение в списке членов.
Владельцем доменной локальной группы является владелец данных или ресурсов*. Если каждый
ресурс в вашей компании имеет владельца, являющегося единственным человеком, который
может разрешить модификации к разрешениям на доступ к общему ресурсу, то он также
становится владельцем доменной локальной группы, которая связана с ресурсом. Прежде чем
глобальная или универсальная группа будет добавлена к доменной локальной группе, этот
владелец должен одобрить модификацию.
Использование двух уровней групп особенно важно в сценариях, когда имеется несколько
доменов и пользователям каждого домена требуется доступ к общему ресурсу в одном из доменов.
Как показано на рисунке 10-6, вы можете создать глобальную группу в каждом домене, а затем
добавить эту глобальную группу к доменной локальной группе того домена, в котором
расположен ресурс.
Примечание. Windows NT использует глобальные и локальные группы, но не использует доменные
локальные группы. Если в домене имеются серверы-члены домена с системой Windows NT, вы
должны использовать локальные группы на каждом сервере. Если у вас имеются серверы с
системами Windows 2000 или Windows Server 2003, и ваш домен работает на функциональном
уровне Windows 2000 native, вы должны по возможности использовать доменные локальные
группы, которые в этом случае охватывают несколько серверов. Если вы используете доменные
локальные группы вместо локальных групп, вы можете переместить ресурс между серверами и
использовать для назначения разрешений ту же самую доменную локальную группу.
Рис. 10-6. Конфигурирование доступа к ресурсу с помощью глобальных и доменных
локальных групп с несколькими доменами
Одним из основных вопросов при создании проекта группы безопасности является вопрос о том,
когда использовать глобальные группы, а когда - универсальные. В некоторых случаях у вас нет
выбора. Например, в Exchange 2000 Server группы, поддерживающие электронную почту,
заменяют списки рассылки, используемые в Exchange Server 5.5 для группировки получателей
электронной почты и назначения доступа к общим папкам. Если вы используете группы,
поддерживающие электронную почту для Exchange 2000 Server, вы должны использовать универсальную группу. При переходе от Exchange Server 5.5 к Exchange 2000 Server следует заменить
каждый список рассылки из Exchange Server 5.5 универсальной группой, поддерживающей
электронную почту. Если имеется более одного домена, обязательно используйте универсальные
группы для групп, поддерживающих электронную почту.
В большинстве случаев наилучшей практикой при создании проекта универсальной группы в
Active Directory Windows 2000 являлась минимизация использования универсальных групп,
особенно если имелись сайты, связанные медленными сетевыми подключениями. Причина этого
была связана с проблемами репликации GC-каталога. Эта рекомендация все еще верна для леса,
работающего на функциональном уровне Windows 2000. Если ваш лес Windows Server 2003 был
переключен на уровень Windows Server 2003 или Windows Server 2003 interim (временный), то
проблема, связанная с репликацией, больше не существует. Кроме того, опция, включающая
кэширование GC-каталога, уменьшает потребность в развертывании GC-серверов в каждом сайте.
Поэтому решение, касающееся использования универсальных или глобальных групп, не особо
критично для Active Directory Windows Server 2003. В большинстве случаев можно использовать
глобальные и универсальные группы почти взаимозаменяемо.
Управление компьютерами
Еще один тип объектов Active Directory - это объект computer (компьютер). В Active Directory
имеется два типа таких объектов. Первый - это объект domain controller (контроллер домена),
который создается при назначении сервера контроллером домена. По умолчанию объекты domain
controller расположены в OU Domain Controllers. Вы можете перемещать контроллеры домена из
этой OU, но делать это следует с осторожностью. Многие параметры настройки безопасности
контроллера домена сконфигурированы в OU Domain Controllers, и перемещение контроллера
домена из этого контейнера может серьезно изменить настройку безопасности.
Второй тип объектов computer - это объекты, представляющие все прочие компьютеры, которые
являются членами домена. Учетные записи этих компьютеров создаются в Active Directory в
заданном по умолчанию контейнере Computers. Обычно объекты computer из этого контейнера
перемещаются в определенные OU, чтобы вы могли управлять компьютерами разными способами.
Например, будет различаться управление серверами и рабочими станциями вашей компании,
поэтому нужно создать две отдельных организационных единицы (OU). Зачастую рабочие
станции разбиваются на более мелкие группы. Рабочим станциям коммерческого отдела будут
требоваться приложения, отличные от приложений, необходимых рабочим станциям технического
отдела. Создавая две OU и помещая рабочие станции в соответствующие OU, вы
можете разными способами управлять двумя типами рабочих станций. Компьютерные учетные
записи создаются в домене при присоединении компьютера к домену, но могут создаваться и
предварительно.
Примечание. Все компьютеры, на которых выполняются системы Windows NT, Windows 2000,
Microsoft Windows XP Professional и Windows Server 2003, должны иметь компьютерную учетную
запись в домене. Компьютеры, на которых выполняются системы Microsoft Windows 95 или
Microsoft Windows 98, не имеют учетных записей.
Вы будете редко управлять компьютерными объектами в Active Directory напрямую. Если
щелкнуть правой кнопкой мыши на компьютерной учетной записи в Active Directory, вы увидите,
что имеется совсем немного опций управления. Одна из опций - переустановка учетной записи
компьютера. Используйте ее осторожно, потому что при переустановке нарушается связь
компьютера с определенным доменом, и компьютер должен заново присоединяться к домену.
Очень полезная опция позволяет любому компьютеру из Active Directory обратиться к
приложению Computer Management (Управление компьютером). Найдите компьютер в
инструменте Active Directory Users And Computers, щелкните правой кнопкой мыши на значке
нужной рабочей станции или сервера и выберите Manage (Управление). Откроется ММС-консоль
Computer Management, содержащая параметры выбранной вами рабочей станции или сервера.
Примечание. Тот факт, что вы не будете сильно заняты администрированием компьютерных
объектов в Active Directory, вовсе не подразумевает, что вы не будете использовать Active
Directory для управления компьютерами. Главы 11, 12 и 13 рассматривают с групповые политики,
обеспечивающие мощныее инструментальные средства управления компьютерами.
Управление объектами printer
Третья группа объектов Active Directory состоит из объектов printer. Вы можете создать объект
printer путем опубликования принтера в Active Directory, при этом сохраняются такие атрибуты
принтера, как место его расположения, а также свойства принтера (скорость печати, возможность
цветной печати и другие). Основанием для публикации объектов printer в Active Directory является
облегчение для пользователей поиска и соединения с сетевыми принтерами.
Публикация принтеров в Active Directory
По умолчанию любой принтер, установленный на сервере с Windows 2000 или Windows Server
2003, к которому разрешен общий доступ, автоматически публикуется в Active Directory. Если
этого не требуется, можно очистить опцию List In The Directory (Зарегистрировать в каталоге) в
окне Properties (Свойства) принтера. Однако если принтер расположен на сервере с системой
Windows NT или другой операционной системой, вы должны вручную опубликовать принтер в
Active Directory. Чтобы выполнить это, найдите объект container, в котором вы хотите
опубликовать объект printer, щелкните на нем правой кнопкой мыши и выберите New
(Новый)>Printer (Принтер). Затем напечатайте UNC-путь на общедоступный компьютер.
Совет. Если вы используете серверы печати Windows NT и не хотите модернизировать их до
Windows 2000 или Windows Server 2003, нужно вручную опубликовать все принтеры на серверах
печати Windows NT в Active Directory. Компания Microsoft создала сценарий с именем Pubprn.vbs,
предназначенный для автоматизации процесса публикации. Этот сценарий расположен в папке
%systemroot %\system32.
Публикация принтера в Active Directory нужна для поиска пользователями объектов printer в
Active Directory. После публикации принтера информация о нем автоматически регистрируется в
окне Properties (Свойства) принтера, доступного из инструмента Active Directory Users And
Computers. Эта информация нужна пользователю, который ищет определенный принтер,
например, цветной принтер, который печатает, по крайней мере, шесть страниц в минуту. Если эта
информация хранится в Active Directory, клиент может использовать опцию A Printer On The
Network (Сетевой принтер) операции Search (Поиск), выбранной из меню Start (Пуск), чтобы
найти все принтеры, удовлетворяющие этим требованиям. На рисунке 10-7 показано окно на
рабочей станции с системой Windows ХР Professional. Как только сетевой принтер найден,
пользователь может щелкнуть правой кнопкой мыши на принтере и выбрать Connect
(Подключить), чтобы установить принтер на машине клиента.
Если объекты printer опубликованы в Active Directory, для управления ими используется редактор
Group Policy Object Editor (см. рис. 10-8).
Две опции, которые вы можете конфигурировать, используя групповые политики, управляют
удалением принтера. Они касаются автоматического удаления объектов printer ТАЗ Active
Directory, если объект printer устаревает. Например, если принтер удален из сервера печати, или
если он больше недоступен на сервере для совместного пользования, удаление принтера удалит
объект printer. По умолчанию один из контроллеров домена Active Directory пробует входить в
контакт с каждым сервером печати каждые 8 часов, чтобы подтвердить правильность информации о принтере.
Если сервер печати не отвечает, объект printer удаляется из Active Directory. При каждом запуске
сервера печати Windows 2000, или более поздней версии, он автоматически повторно
регистрирует общие принтеры на сервере в Active Directory. Вы можете сконфигурировать
параметры удаления принтера, используя редактор Group Policy Object Editor.
Рис. 10-7. Поиск принтеров в Active Directory
Рис. 10-8. Конфигурирование параметров настройки принтера с помощью редактора Group
Policy Object Editor
Одна из наиболее интересных опций Active Directory, предназначенная для управления объектами
printer — это опция, позволяющая автоматически показывать местоположение принтера для
пользователей, выполняющих поиск принтера. Во многих компаниях, имеющих несколько
офисов, есть служащие, которые путешествуют между ними. Большинство компаний имеет
комнаты для собраний, которые находятся в различных частях здания. Всякий раз, когда
пользователи перемещаются из одной части компании в другую, они должны иметь возможность
печатать. Если пользователь не знает, где находятся принтеры, предназначенные для печати в
данном месте, то поиск ближайшего принтера может занять некоторое время.
Поиск принтеров можно упростить, назначая каждому принтеру место в Active Directory, а затем
используя расположение пользователя для предоставления списка принтеров, расположенных
близко к нему. Эти функциональные возможности основаны на конфигурации сайта в вашей сети.
Чтобы включить мониторинг места расположения принтера, выполните следующие действия.
1. Откройте инструмент Active Directory Sites And Services и найдите объект subnet (подсеть),
в котором включите мониторинг местоположения принтеров. Щелкните правой кнопкой
мыши на объекте subnet и выберите Properties (Свойства). Щелкните на вкладке Location
(Местоположение) и введите значение location (место расположения) для этой подсети.
Запись места расположения должна иметь формат: location/sublocation (Общее
расположение/детализированное расположение) (например, Главный офис/Третий этаж).
2. Используйте редактор Group Policy Object Editor для включения политики Pre-Popula-te
Printer Search Location Text (Предварительно заполнить текст, указывающий место
расположения принтера при поиске) для выбранного контейнера. В большинстве случаев
это делается на уровне домена.
3. На вашем сервере печати обратитесь к окну Properties для каждого принтера. На вкладке
General (Общее) вы можете заполнить место расположения принтера. Если первые два
шага этой процедуры завершены, можете щелкнуть на Browse (Просмотр), чтобы найти
место расположения принтера. Можно добавить больше деталей к описанию места
расположения принтера, чтобы оно было лучше определено (например, Главный
офис/Третий этаж/Внешняя комната для собраний 5).
4. После того как вы включили мониторинг места расположения принтеров, пользователи
могут легко находить ближайший к ним принтер. Когда пользователь запускает Add Printer
Wizard (Мастер добавления принтера) и ищет принтер в каталоге, атрибут Location (Место
расположения) заполняется в соответствии с текущим сайтом пользователя. На рисунке
10-9 показано окно клиента Windows ХР Professional. Пользователь может щелкнуть
Browse для нахождения более точного места расположения принтера.
Рис. 10-9. Поиск объекта printer в Active Directory с помощью атрибута Location
Управление опубликованными общими папками
Еще один объект, который можно публиковать в Active Directory - это объект shared folder (общая
папка). Чтобы опубликовать общую папку в Active Directory, найдите нужный контейнер.
Щелкните правой кнопкой мыши на контейнере и выберите New (HoBbm)>Shared Folder (Общая
папка). Затем напечатайте имя объекта Active Directory, а также UNC-путь для общей папки.
После того как в Active Directory будет создан объект shared folder, пользователи могут
просматривать и искать его в Active Directory. Найдя объект shared folder, пользователи щелчком
правой кнопкой мыши на объекте могут отобразить диск на общую папку.
Основное преимущество публикации общей папки в Active Directory состоит в том, что
пользователи могут искать общие ресурсы, основываясь на разнообразных свойствах. Когда вы
создаете объект shared folder, вы можете дать описание общей папки (см. рис. 10-10). После
создания общей папки откройте окно Properties (Свойства) для указания ключевых слов,
связанных с общей папкой. Когда клиентам потребуется найти общую папку, они могут сделать
поиск в Active Directory, используя параметр, основанный на имени объекта, ключевых словах или
описании.
Рис. 10-10. Публикация общей папки в Active Directory
Ограничение, связанное с публикацией общих папок в Active Directory, состоит в том, что, если
общая папка переместится на другой сервер, то все клиенты, имеющие диски, отображенные на
эту общую папку, обнаружат, что отображение больше не работает. Это произойдет, потому что
при отображении клиентского диска на общую папку в Active Directory используется UNC-путь к
ресурсу. Например, вы можете создать и опубликовать общую папку по имени Saleslnfo, которая
указывает на \\Server1\SalesInfo. Когда пользователь находит эту общую папку в Active Directory и
отображает диск, то для отображения диска используется синтаксис \\Serverl\SalesInfo. Если папка
переместится, отображение диска перестанет действовать, даже если вы сделаете изменения в
Active Directory так, чтобы объект указывал на новое место расположения.
Административные усовершенствования
службы Active Directory Windows Server 2003
Система Windows 2000 содержала первый выпуск Active Directory, и многие из средств
администрирования, которые поставлялись с Windows 2000, имели ограничения в некоторых
важных аспектах. Средства администрирования Windows Server 2003 обеспечивают
усовершенствованные функциональные возможности.
• Функциональность Drag and drop. Наиболее популярной новой функцией Active
Directory Windows Server 2003 является перетаскивание объектов в пределах инструментов
администрирования Active Directory. Теперь вы можете перемещать пользователя из одной
OU в другую путем перетаскивания значка учетной записи пользователя. Вы можете
добавить существующего пользователя к группе перемещением значка учетной записи
пользователя в учетную запись группы.
• Одновременное редактирование нескольких элементов. Еще одна новая функция —
возможность редактировать несколько объектов одновременно. В Active Directory
Windows 2000 вы можете изменять только один объект за раз. С помощью инструмента
администрирования Active Directory Users And Computers Windows Server 2003 можно
изменять одновременно большое число объектов. Предположим, что все пользователи
отдела Marketing (Маркетинг) переезжают в другое офисное здание, и вы должны заменить
адрес для всех учетных записей пользователей. Используйте средство поиска, чтобы найти
учетные записи пользователей, у которых атрибут Department установлен на значение
Marketing. Затем выделите все учетные записи в окне результатов поиска, щелкните на них
правой кнопкой мыши и выберите Properties (Свойства). Теперь вы можете изменять
общие атрибуты для всех учетных записей одновременно. Ваш домен должен работать на
функциональном уровне Windows Server 2003, чтобы позволить одновременное
редактирование нескольких элементов.
• Сохранение запросов. В больших организациях с тысячами пользователей
администраторы всегда находят объекты Active Directory с помощью поиска, а не
просмотра. Опция сохранения запросов означает, что вы можете однажды создать запрос
на поиск, а затем сохранить его для повторного использования в другое время. Возможно,
вы захотите выполнять ежемесячную проверку, чтобы узнать, какие учетные записи
пользователя не использовались для входа в домен в последние 30 дней. Щелкните правой
кнопкой мыши на контейнере Saved Query (Сохраненные запросы) и выберите New
(Новый)><Querу (Запрос), чтобы создать запрос для поиска этой информации, а затем один
раз в месяц просто щелкните на запросе, чтобы увидеть самый последний список.
• Инструменты командной строки Active Directory Windows Server 2003 включают
множество новых средств, предназначенных для управления объектами Active Directory:
утилиты Dsadd и Dsmod (для добавления или изменения объектов Active Directory
соответственно), Dsrm (для удаления объектов Active Directory), Dsmove (для перемещения
объектов из одного контейнера в другой), Dsquery (для поиска списка объектов) и Dsget
(для отображения атрибутов объекта). Смотрите Help And Support Center (Центр справки и
поддержки) для получения детальной информации о том, как использовать эти
инструменты.
Резюме
В этой главе приведен краткий обзор стандартных объектов Active Directory Windows Server 2003
и процедур, позволяющих ими управлять. Наибольшие административные усилия вы потратите на
управление этими объектами. В частности, вы будете управлять учетными записями
пользователей и групп по мере притока и оттока служащих из вашей компании или по мере
создания новых групп для защиты сетевых ресурсов. Одно из осложнений, с которыми вы
столкнетесь, - у вас может быть три различных объекта, представляющих индивидуальных
пользователей: объекты user, inetOrgPerson и contact. Кроме того, имеется два типа групп и три
области действия, с которыми вам придется работать. Ваше время будет также занято
управлением такими объектами как computer, printer или shared folder.
Глава 11. Введение в групповые политики
Одна из типичных тем разговора среди людей, оплачивающих установку инфраструктуры
корпоративной информационной технологии (IT-Inf ormation Technology), - это общая стоимость
компьютеров. Известно, что цена начальной закупки компьютера составляет лишь небольшую
часть стоимости управления и содержания этого компьютера в последующие годы эксплуатации.
Основная же часть — это затраты на персонал, управляющий компьютерами. Если управление
компьютерами клиентов осуществляется вручную, их стоимость может вырасти до недопустимого
уровня. Для многих компаний решение этой проблемы состоит в использовании автоматизации
при управлении компьютерами. В максимально возможной степени компании хотят
конфигурировать параметры настройки в одном центральном месте и применять их ко всем
компьютерам клиентов. Некоторые параметры позволяют блокировать компьютер, чтобы
пользователи не могли изменять свои настольные конфигурации. Определенные политики
используются для установки программного обеспечения на компьютерах конкретной группы.
Групповые политики в Microsoft Active Directory Windows Server 2003 предлагают инструменты
для понижения стоимости управления компьютерами клиентов. Используя групповые политики,
вы можете сконфигурировать их в службе каталога Active Directory, а затем применить к
отдельным (или всем) компьютерам вашей организации Эта глава содержит введение в групповые
политики и поясняет, как их конфигурировать в Active Directory Windows Server 2003. Главы 12 и
13 посвящены использованию групповых политик для выполнения определенных задач, таких как
управление рабочими столами пользователей и установка программного обеспечения.
Примечание. Групповые политики эффективны для компьютеров с операционной системой
Microsoft Windows 2000 и старше: Windows 2000 Server, Windows Server 2003, Windows 2000 и
Windows XP Professional. Их нельзя использовать для управления компьютерами-клиентами, на
которых выполняются системы Microsoft Windows NT, Windows 95 или Windows 98. Если вы уже
знакомы с групповыми политиками Active Directory в Windows 2000, то заметите, что
большинство концепций в обеих
версиях Active Directory одинаковы, но в Active Directory Windows Server 2003 имеется больше
доступных опций. Многие из новых параметров настройки имеют отношение к Windows XP
Professional и игнорируются клиентами Windows 2000.
Краткий обзор групповых политик
Групповые политики Active Directory Windows Server 2003 обеспечивают мощные
инструментальные средства, предназначенные для управления пользовательскими рабочими
столами. В таблице 11-1 показано многое из того, что можно делать с помощью групповых
политик.
Табл. 11-1. Опции групповых политик Опция
конфигурации
Объяснение
Инсталляция программ Используется для установки программного
и управление
обеспечения
на
компьютерах
и
его
обслуживания с помощью установки заплат или
обновлений.
Используется
также
для
деинсталляции пакетов программ. Программное
обеспечение может быть назначено и на
пользователей, и на компьютеры.
Сценарии
Используется для выполнения сценариев при
запуске и выключении компьютера, а также при
входе и выходе из системы. Сценарии могут
быть файлами MS-DOS .bat или файлами
Windows Script Host.
Перенаправление папки Используется для перенаправления некоторых
частей рабочей среды пользователя, таких как
My Documents (Мои документы), меню Start
(Пуск) или Desktop (Рабочий стол), к сетевому
ресурсу, на котором может быть сделана
резервная
копия.
Это
перенаправление
прозрачно для пользователя.
Конфигурация защиты Используется
для
конфигурирования
параметров настройки защиты. Некоторые из
этих параметров, такие как политики паролей и
учетных
записей,
должны
быть
сконфигурированы
на
уровне
домена,
остальные - на уровне любого контейнера.
Административные
Используется для создания административных
шаблоны
шаблонов установки значений системного
реестра, которые ограничивают модификации,
выполняемые
пользователями
на
своих
компьютерах.
Существует два типа групповых политик. Первый тип — это локальная групповая политика на
компьютере с системами Windows 2000, Windows XP и Windows Server 2003. Локальная групповая
политика может быть только одна, и это единственная групповая политика, доступная на
компьютере, не являющемся членом домена. Она применяется также на всех компьютерах,
которые являются частью домена. Многие из локальных политик те же самые, что и групповые
политики домена, но из-за того, что локальная групповая политика применяется первой,
групповые политики Active Directory часто отменяют многие параметры ее настройки.
Примечание. Локальный объект групповой политики (GPO -Group Policy Object) хранится на
локальном компьютере в папке %systemroot%\System32\GroupPolicy.
Второй тип групповой политики - э|го групповая политика Active Directory. Ее объекты хранятся в
Active Directory, и каждая политика разными способами управляет компьютерами домена. Когда
формируется домен Active Directory Windows Server 2003, создаются две групповые политики
Active Directory: Default Domain Policy (Заданная по умолчанию политика домена) и Default
Domain Controllers Policy (Заданная по умолчанию политика контроллеров домена). Default
Domain Policy устанавливает политики учетных записей и паролей и используется для
конфигурирования общих для домена параметров настройки. Политика Default Domain Controllers
Policy применяется в организационных единицах (OU) контроллеров домена и используется для
усиления некоторых параметров настройки защиты для контроллеров домена. В дополнение к
этой политике можно создавать столько групповых политик, сколько потребуется, и связывать их
с различными местами в структуре Active Directory. Групповые политики могут быть связаны с
контейнером сайта, контейнером домена или любым контейнером OU вашей организации.
Все политики Active Directory имеют две группы параметров настройки. Первая группа
параметров обращается к компьютерам, вторая - к учетным записям пользователя. Групповые
политики могут применяться только к компьютерам и пользователям. Группы Active Directory
используются для определения того, будет ли данная групповая политика применяться к
определенному пользователю.
Объекты GPO, основанные на Active Directory, фактически состоят из двух различных объектов.
Один из них — это объект контейнера групповой политики (GPC), к которому можно обратиться с
помощью инструмента Active Directory Users And Computers через контейнер System
(Система)\Policies (Политики). Если вы не видите системный контейнер, выберите Advanced
Features (Дополнительные свойства) из меню View (Вид) (см. рис. 11-1). Объект GPC содержит
следующую информацию.
• Информация о версии. Поддерживается как объектом GPC, так и шаблоном групповой
политики (GPT - Group Policy Template) и используется для проверки синхронизации этих
объектов.
• Список компонентов. Используется для указания того, параметры настройки какой
групповой политики (компьютера, пользователя или обеих) сконфигурированы в этом
объекте GPO.
•
Информация о состояния. Используется для указания того, является ли объект GPO
действующим, или он заблокирован.
Подробности, касающиеся объекта GPC, отражаются в свойствах объекта в инструменте ADSI
Edit, но модифицировать их можно только через редактор групповой политики Group Policy Editor.
Рис. 11-1. Поиск объектов GPC в Active Directory
Совет. На рисунке 11-1 показано, что глобально уникальные идентификаторы (GUID), которые
используются для идентификации объектов GPC в Active Directory, не всегда удобны. Для
определения отображаемого имени каждого из GPC-объектов используйте утилиту
ADSIedit.msc. Найдите GPC в Active Directory, используя ADSI Edit, а затем рассмотрите
атрибут display Name.
Второй объект, который входит в групповую политику, — это объект GPT, содержащий
большинство фактических параметров настройки для групповой политики и хранящийся в папке
Sysvol на каждом контроллере домена. Этот объект включает папки и информацию о содержимом (см. табл. 11-2).
Табл. 11-2. Содержание шаблона групповой политики
Место расположения
Содержание папки
Adm
Содержит файлы .adm, использующиеся для
конфигурирования административных шаблонов.
Scripts
Содержит сценарии, назначенные с помощью
групповых политик.
User
Содержит параметры настройки системного
реестра, применяемые политиками к данному
пользователю. Параметры настройки хранятся в
файле Registry.pol.
User\Applications
Содержит сценарии рекламы приложений для
всех
приложений,
развернутых
для
пользователей.
Machine
Содержит все параметры настройки системного
реестра, применяемые политикой к компьютеру.
Параметры настройки хранятся в файле
Registry.pol.
Machine\ Applications Содержит сценарии рекламы приложений для
всех приложений, развернутых для компьютеров.
{GUID}
Содержит файл Gpt.ini, в котором находится
номер версии GPO.
Оба GPO-компонента реплицируются на все контроллеры домена в домене. Объект каталога (GPC)
реплицируется как часть обычной репликации Active Directory. Объект Sysvol (GPT) реплицируется
службой репликации файлов (File Replication service - FRS).
Примечание. Если вы создали новый объект GPO или изменили существующий, политики должны
реплицироваться на все контроллеры домена в домене. Используйте монитор репликации Replication
Monitor для проверки статуса репликации. (Replication Monitor является инструментом Active Directory,
который устанавливается, когда вы дважды щелкаете на файле Suptools.msi, расположенном в папке
\Support\Tools на компакт-диске Windows Server 2003.) Откройте Replication Monitor и добавьте
контроллеры домена к списку Monitored Servers (Кон-троллируемые серверы). Затем щелкните правой
кнопкой мыши на имени контроллера домена и выберите Show Group Policy Object Status (Показать
состояние объекта групповой политики). На рисунке 11-2 показано, как выглядит реплицируемая
информация.
Рис. 11 -2. Просмотр статуса объекта групповой политики с помощью монитора репликации
Replication Monitor
Реализация групповых политик
Когда вы создаете новый объект GPO или модифицируете существующий, изменения по
умолчанию делаются на эмуляторе основного контроллера домена (PDC). В большинстве случаев
нужно принять это для уменьшения вероятности того, что несколько администраторов сделают
несовместимые изменения параметров настройки групповой политики. Однако если эмулятор
PDC недоступен в то время, когда нужно сделать изменения, вам необходимо выбрать
контроллера домена, с которым можно будет соединиться (см. рис. 11-3). (Вы можете
модифицировать то, какой контроллер домена будет изменен, обращаясь к тому же самому окну
через меню View (Вид)>БС Options (Выбор DC) в редакторе объектов групповой политики.) Если
вы выберете соединение с контроллером домена, имеющим лексему Operations Master (Хозяин
операций) для эмулятора PDC, то соединитесь с эмулятором PDC. Вы можете также делать
изменения на контроллере домена, с которым связаны в текущий момент, или на любом другом
контроллере домена.
Рис. 11 -3. Выбор контроллера домена, на котором будут сделаны изменения объекта GPO
Создание объектов GPO
Существует два способа создания новых объектов GPO. Первый способ заключается в
использовании инструмента Active Directory для поиска контейнера, в котором нужно создать
новый объект GPO. Затем нужно щелкнуть правой кнопкой мыши на контейнерном объекте и
выбрать Properties (Свойства). Выберите вкладку Group Policy (Групповая политика) (см. рис. 114). Чтобы создать новый объект GPO, который будет связан с этим контейнером, щелкните на New
(Новый).
Рис. 11 -4. Создание нового объекта GPO, связанного с OU
Второй способ — это создание собственной консоли ММС (Microsoft Management Console) и
добавление к ней оснастки Group Policy Object Editor (Редактор объектов групповой политики).
При выборе этой оснастки необходимо указать объект GPO, который вы планируете изменить. По
умолчанию оснастка загрузит Local Computer Policy (Локальная компьютерная политика).
Щелкните на кнопке Browse (Просмотр), чтобы загрузить любой объект GPO из вашего домена
или сайта. Используйте этот инструмент для изменения локального объекта GPO для любого
компьютера, на котором у вас есть административные права (см. рис. 11-5).
Рис. 11 -5. Выбор GPO-объекта при изменении политики путем добавления оснастки Group
Policy Object Editor к ММС-консоли
Чтобы создать новый объект GPO с помощью Welcome To The Group Policy Wizard (Мастер
групповой политики), перейдите в нужное место вашего домена и щелкните на кнопке Create New
Group Policy Object (Создать новый объект групповой политики).
Независимо от того, какой инструмент используется при создании нового объекта GPO, создается
новая групповая политика и связывается с объектом, в котором вы создаете GPO. На рисунке 11-6
показан недавно созданный объект GPO. Позже объект GPO можно изменить в соответствии с
вашими требованиями.
Администрирование объектов групповой политики
Как только объект GPO создан, вы можете изменять его конфигурацию. Большинство этих
модификаций будет осуществляться на вкладке Group Policy окна Properties (Свойства)
контейнерного объекта, с которым связан объект GPO (см. рис. 11-4). В таблице 11-3 объясняются
опции конфигурации, доступные в этом окне.
Рис. 11-6. Создание нового GPO-объекта загружает заданные по умолчанию параметры
настройки групповой политики
Табл. 11 -3. Конфигурирование параметров настройки GPO
Опция интерфейса
Пояснение
Add (Добавить)
Используется для связи предварительно
созданного объекта GPO с контейнерным
объектом. Когда вы щелкнете на кнопке Add,
появится окно, подобное окну на рисунке
11*5. Вы можете найти любой объект GPO в
вашей организации и связать его с этим
контейнером.
Используется для модификации опций
конфигурации
объекта
GPO,
изменяя
содержание GPO. Когда вы щелкнете на
кнопке Edit, появится соответствующее окно
(см. рис. 11-6).
Используется для конфигурирования опции
No Override (He подменять) и для отключения
объекта
GPO.
Они
будут
подробно
обсуждаться
в
разделе
«Наследование
групповой политики и применение» далее в
этой главе.
Edit (Редактирование)
Options (Опции)
Опция интерфейса
Delete (Удалить)
Пояснение
Используется для удаления объекта GP При
выборе этой опции вы можете или по
ностью удалить GPO из Active Directory, и.
удалить только связи с данным контейне
ным объектом.
Properties (Свойства)
Используется для конфигурирования то]
применяется ли этот объект GPO к компы
терам и пользователям или к обоим. Кро:
того, используется для конфигурирован:
опций защиты объекта GPO. Эти опции ко
фигурирования будут подробно обсуждать в
разделе «Фильтрация применения групп вой
политики» далее в этой главе.
Наследование групповой политики и ее применение
Объекты GPO могут быть связаны с объектами сайтов, доменов и объектами OU в Active
Directory. Групповые политики связываются только с этими контейнерами и не могут связываться
с контейнерами Users или Computers.
По умолчанию параметры настройки групповой политики наследуются от контейнеров высокого
уровня к контейнерам низкого уровня. Следовательно, групповые политики, назначенные
пользователю или компьютеру, применяются при каждом запуске компьютера или при каждом
входе пользователя в систему. Групповые политики применяются в следующем порядке.
1. Local group policy (Локальная групповая политика). Первой всегда применяется
локальная групповая политика.
2. Site-level group policies (Групповые политики уровня сайта). Эти групповые политики
связаны с объектом сайта в Active Directory.
3. Domain-level group policies (Групповые политики уровня домена). Эти групповые
политики связаны с объектом домена в Active Directory.
4. OU-level group policies (Групповые политики уровня OU). Если домен содержит
несколько уровней OU, вначале применяются групповые политики более высоких уровней
OU, а затем — OU низшего уровня.
Иногда на любом из уровней Active Directory может применяться свыше одной групповой
политики. В этом случае порядок их применения определяется порядком, в котором объекты GPO
перечислены в административном окне снизу вверх. На рисунке 11-7 показаны три групповые
политики, применяемые к OU. Сначала будет применяться Scripts Policy (Политика сценариев),
затем - Desktop Policy (Политика рабочих столов), а далее - Office Installation Policy (Политика
инсталляции офиса).
Рис. 11-7. Несколько групповых политик, связанных с одним и тем же контейнером,
применяются в порядке расположения в списке, снизу вверх
Порядок применения групповых политик важен, если они изменяют одни и те же параметры
настройки. Например, если объект GPO уровня домена удаляет команду Run со всех компьютеров,
а объект GPO организационной единицы более низкого уровня добавляет команду Run, то
команда Run будет доступна на всех компьютерах OU. Такой конфликт возникает, если две
политики изменяют одну и ту же установку. Иуш объект GPO более высокого уровня может быть
сконфигурирован для удаления команды Run, а объект GPO более низкого уровня — для удаления
значка конфигурации с панели управления. Поскольку нет никакого конфликта между этими
параметрами настройки, применятся обе настройки.
Большинство параметров настройки объекта GPO включает три опции конфигурации: Enabled
(Включен), Disabled (Заблокирован) и Not Configured (He сконфигурировано). Если установлена
опция Enabled, то независимо от того, какая групповая политика сконфигурирована, она будет
применена. Если установлена опция Disabled, то независимо от того, какая групповая политика
сконфигурирована, она будет заблокирована. Если установка была включена в объекте GPO,
который применялся ранее, она все равно будет изменена на Disabled. Например, вы можете
включить установку по удалению команды Run в объект GPO, связанный с OU высокого уровня.
Затем вы блокируете установку по удалению команды Run в OU более низкого уровня, после чего
команда Run будет доступна для всех пользователей в OU низшего уровня. Если установлено Not
Configured, параметры настройки политики не изменятся, и будут поддерживаться установки,
унаследованные от более высокого уровня.
Изменение заданного по умолчанию способа применения
групповых политик
По умолчанию все групповые политики для учетных записей компьютеров и пользователей
применяются
в
порядке
Локальный/Сайт/Домен/
Организационная
единица
(Local/Site/Domain/Organizational Unit -LSDOU). В пределах контейнера каждый пользователь и
компьютер будут затронуты групповой политикой. Однако в некоторых случаях этого
происходить не должно, и вы можете сконфигурировать исключения к заданному по умолчанию
способу применения групповых политик.
Групповые политики и проект OU
Как уже шворилось в гл. 5, основной движущей силой при создании проекта OU является
возможность применения групповых политик, особенно для OU низшего уровня. В большинстве
случаев этот проект должен использовать преимущества заданного по умолчанию наследования
параметров настройки групповой политики. В данном разделе конкретизируются способы
модифицирования заданного по умолчанию способа применения групповых политик, но одной из
целей вашего проекта должна быть минимизация использования этих опций.
Структура большинства крупных предприятий слишком сложна для того, чтобы использовать
заданное по умолчанию наследование. Например, вы можете создать проект OU, основанный на
деловых подразделениях, потому что большинство пользователей одного и того же подразделения
нуждаются в одинаковых параметрах настройки рабочего стола и в одинаковом наборе
приложений. Однако некоторые пользователи могут быть частью группы, пересекающей границы
отдела для участия в постоянных или специфических проектах. Остальные отделы могут иметь
свои требования к набору программ, так что пользователю необходим доступ к обоим наборам
приложений. Такие сложные конфигурации являются стандартными для большинства
предприятий, поэтому Active Directory Windows Server 2003 обеспечивает возможность изменения
заданного по умолчанию способа применения групповых политик.
Модификация способа наследования групповых политик
Есть два способа изменить заданное по умолчанию наследование групповой политики. Первый
вариант состоит в блокировании наследования политики на контейнерном уровне. Для этого
щелкните правой кнопкой мыши на контейнере, в котором вы хотите изменить наследование, и
выберите Properties (Свойства). Щелкните на вкладке Group Policy (Групповая политика) и
отметьте флажок Block Policy Inheritance (Блокировать наследование политики) (см. рис. 11-8).
Это означает, что параметры настройки групповой политики, унаследованные от контейнеров
более высокого уровня, будут блокированы. Опция блокировки наследования политики полезна,
когда ваша политика должна применяться к большой группе пользователей и компьютеров в
нескольких OU, но при этом вы не хотите применять ее к определенной группе пользователей.
Типичным примером является сценарий, в котором всем пользователям в организации нужно,
чтобы часть их рабочего стола (команда Run или редактор системного реестра) были
заблокированы, а сетевым администраторам требуется полный доступ ко всем инструментальным
средствам. В этом сценарии вы можете сконфигурировать такую групповую политику на уровне
домена, которая блокирует часть инструментов рабочего стола на всех компьютерах, затем создать
отдельную OU для учетных записей сетевых администраторов и блокировать наследование
групповой политики на этом уровне.
Рис. 11 -8. Блокирование наследования групповой политики на уровне 0U
Предостережение. Одно из ограничений блокировки наследования групповых политик состоит в
том, что после выбора блокировки все наследование групповой политики будет блокировано. Нет
никакого способа выборочно блокировать наследование только определенных групповых политик.
Второй способ изменять заданное по умолчанию наследование групповых политик состоит в
использовании опции No Override (He подменять). Эта опция используется для предписания
применения групповой политики даже в тех контейнерах, в которых установлена опция блоки-
ровки наследования групповой политики. Чтобы сконфигурировать групповую политику, не
подлежащую отмене, найдите контейнерный объект, с которым связана данная групповая
политика, а затем откройте окно Properties (Свойства) этого контейнера. Выберите вкладку Group
Policy, выберите политику группы, щелкните на кнопке Options и выберите опцию No Override
(см. рис. 11-9).
Рис. 11-9. Конфигурирование опции No Override для групповой политики
Опция No Override может быть полезна, когда ваша групповая политика применяется ко всем
пользователям независимо от того, где они расположены. Например, вы можете использовать
групповые политики для управления антивирусным программным обеспечением на всех
компьютерах-клиентах вашей организации. В этом случае нужно выбрать контейнер высокого
уровня, содержащий все компьютеры вашего домена, и применить политику на этом уровне. Затем
сконфигурируйте групповую политику опцией No Override, чтобы параметры настройки
применялись ко всем компьютерам клиентам.
Опция No Override устанавливается в том месте, где объект GPO связывается с контейнером, а не
в самом объекте GPO. Если вы связываете объект GPO с несколькими местами вашего домена и
конфигурируете одну из связей с применением опции No Override, другие связи не будут
сконфигурированы с этой опцией автоматически. Опция No Override устанавливается
применительно к одному объекту GPO, т.е. ее установка на одном объекте GPO, связанном с OU,
не затрагивает опцию No Override для других объектов GPO, связанных с этой же OU.
Примечание. Опция No Override заставляет применять параметры настройки групповой
политики, даже если наследование блокировано. Параметры настройки уровня домена типа
политики учетной записи и политики пароля применяются ко всем компьютерам и
пользователям в домене. Блокировка наследования политики никак не влияет на эту политику.
Фильтрация применения групповой политики
Третий способ изменения наследования групповых политик состоит в фильтрации применений
групповых политик с помощью групп Active
Directory. По умолчанию при создании групповой политики она применяется ко всем
пользователям и компьютерам в контейнере. Рассмотрите вкладку Security (Безопасность) для
недавно созданной групповой политики. Как показано на рисунке 11-10, вкладка Security для всех
объектов GPO сконфигурирована так, что группа Authenticated Users (Удостоверенные
пользователи) имеет разрешения Read (Чтение) и Apply Group Policy (Применение групповой
политики). Поэтому все удостоверенные пользователи, включая и компьютеры, и пользователей,
будут затронуты этой политикой.
Можно изменить воздействие групповой политики на компьютер или пользователя, модифицируя
установку разрешения Apply Group Policy для учетных записей. Для этого сначала удалите группу
Authenticated Users с вкладки Security или очистите флажок Apply Group Policy. Затем добавьте
соответствующие учетные записи к списку управления доступом (ACL) и предоставьте им
разрешения Read и Apply Group Policy. Можете изменить разрешения, добавляя какого-либо
участника безопасности, но наилучшая практика состоит в том, чтобы всегда использовать группы
Active Directory вместо учетных записей индивидуальных пользователей или компьютеров.
Рис. 11-10. Конфигурирование вкладки Security(Безопасность) в окне Properties (Свойства)
объекта GPO для изменения области применения объекта GPO
Совет. Можно использовать группы для фильтрации применения групповых политик, но нельзя
применять групповые политики к группам. Например, если вы связываете групповую политику с
контейнером, который содержит глобальную группу, но не содержит учетные записи
пользователей, являющихся членами глобальной группы, групповые политики будут
неэффективны. Пользовательские и компьютерные учетные записи должны находиться в
контейнерном объекте, чтобы применялась групповая политика.
Опция, предназначенная для применения групповых политик к выбранной группе, полезна во
множестве различных сценариев. Например, вы планируете установить специфический пакет
программ для группы пользователей, учетные записи которых рассеяны в различных OU по всему
домену. Чтобы инсталлировать приложение, используя групповые политики, свяжите объект GPO
с контейнерным объектом, который содержит учетные записи пользователей, а затем измените
защиту GPO-объекта так, чтобы групповая политика применялась только к указанной группе.
Другим примером является ситуация, когда имеется объект GPO, который назначен определенной
OU, но вы не хотите, чтобы этот объект применялся ко всем пользователям этой OU. В этом
случае вы можете, во-первых, создать группу, содержащую учетные записи пользователей,
которым требуется данная групповая политика, и сконфигурировать разрешение Apply Group
Policy только для этой группы. Во-вторых, вы можете создать группу, которая содержит все
учетные записи пользователей, которым не требуется данная групповая политика, и использовать
установку Deny (Запретить) на разрешении Apply Group Policy (Применить групповую политику)
для гарантии того, что групповая политика не будет применяться к этим пользователям.
Совет. Если вы удаляете разрешение Apply Group Policy для группы, вы должны также удалить
Read Access (Доступ для чтения). Если этого не сделать, то групповая политика будет читаться
каждый раз при запуске компьютера и входе в систему членов группы, даже если она не
применяется, и это окажет вредное воздействие на процессы запуска системы.
Совет. Active Directory Windows Server 2003 обеспечивает опцию фильтрации применения
групповых политик, основанную на фильтрах Windows Management Instrumentation (Аппаратура
управления Windows) (WMI). Фильтры WMI, написанные на языке WMI-запросов, могут
использоваться для более точного определения групповых политик, применяемых к компьютеру.
Например, можно использовать эту опцию для указания того, что пакет программ должен
устанавливаться только на компьютере, имеющем более 200 Мб доступного дискового
пространства, или на компьютере, имеющем более 64 Мб оперативной памяти. Подробности
смотрите в Центре справки и поддержки (Help And Support Center) и в комплекте WMI Software
Development Kit на веб-сайте Microsoft по адресу http: // msdn.microsoft.com/
library/default.asp?url=/library/en-us/wmidsk/wmi/ wmi_start_page.asp.
Применение групповых политик к пользователям и компьютерам
Можно сконфигурировать групповую политику так, чтобы она применялась только к
компьютерам или только к пользователям, а не к тем и другим. Чтобы сделать это, обратитесь к
окну Properties (Свойства) объекта GPO (см. рис. 11-11), в котором можно отключить или
компьютерные параметры настройки конфигурации, или пользовательские.
Рис. 11-11. Отключение компьютерных параметров настройки конфигурации для объекта GPO
Совет. Использования большинства опций, обсуждаемых в этом разделе и изменяющих заданное
по умолчанию применение групповых политик, следует избегать, так как это может привести к
сложной конфигурации групповых политик, с которой трудно работать. Опция, позволяющая
применять групповые политики только к пользователям или только к компьютерам, используется
чаще. В большинстве случаев групповые политики конфигурируются либо для тех, либо для
других, но не для обоих одновременно.
Отключение групповых политик
Еще одна опция, которую можно использовать для изменения области приложения групповых
политик, состоит в отключении групповой политики. Чтобы сделать это, обратитесь к окну
Properties (Свойства) объекта GPO и выберите Options (Опции) (см. рис. 11-9). Путем отключения
групповой политики можно предотвращать ее применение без необходимости изменять другие
параметры настройки. Например, у вас есть групповая политика, которую требуется применять
лишь время от времени, или групповая политика, которая находится в экспериментальной стадии.
Вы можете создать групповую политику, связать ее с соответствующим контейнером, а затем
отключить ее. При необходимости можно снова ее включить.
Обработка групповой политики
Теперь, когда вы знаете, как создавать объекты GPO и связывать их с контейнерами в пределах
Active Directory Windows Server 2003, следующий шаг состоит в понимании того, как на самом
деле групповые политики применяются к компьютерам. Когда компьютер запускается и
пользователь входит в систему, происходит применение групповых политик следующим образом.
1. Во время запуска компьютера клиента считывается системный реестр и определяется сайт,
в котором расположен компьютер. Компьютер посылает запрос DNS-серверу, запрашивая
IP-адреса контроллеров домена, расположенных в этом сайте.
2. Получив ответ DNS-сервера, компьютер клиента соединяется с контроллером домена в
своем сайте. В процессе опознания, проводимом контроллером домена, компьютер
клиента запрашивает список всех GPO-объектов, которые применяются к компьютеру.
3. Контроллер домена присылает клиенту список всех GPO-объектов в том порядке, в
котором политики должны применяться. Затем компьютер извлекает объект GPO с
контроллера домена и применяет политику. Порядок, в котором применяются групповые
политики, основан на LSDOU-конфигурации.
4. Когда пользователь входит в систему, компьютер клиента снова обращается к контроллеру
домена и запрашивает все объекты GPO, которые применяются к пользователям. В этом
случае они также применяются в соответствующем порядке.
Совет. Групповые политики применяются к клиентам с операционной системой Windows XP
асинхронно, а с системой Windows 2000 - синхронно, т.е. все компьютерные политики полностью
применяются до того, как появится пользовательский экран входа в систему, а все
пользовательские политики - до того, как появится рабочий стол пользователя. Асинхронное применение политик означает, что загрузка
системы Windows XP и вход пользователей в систему происходит более быстро.
Вы можете использовать групповые политики для модификации применения других групповых
политик. Опции конфигурации устанавливаются в папках UserConfiguration\Administrative
Templates\System\ Group Policy или Computer Configuration\Administrative Templates\ System\Group
Policy. На рисунке 11-12 показаны опции, имеющиеся в ветви Computer Configuration дерева
папок.
Рис. 11-12. Опции конфигурации групповой политики
Групповые политики применяются при запуске компьютера при входе пользователя в систему.
После входа они обновляются периодически, по умолчанию каждые 90 минут, с 30-ти минутной
вариацией для избежания перегрузки контроллера домена в ситуации, когда много клиентов
запрашивают обновление одновременно. Групповые политики на контроллерах домена
обновляются каждые 5 минут. Вы можете использовать параметры настройки конфигурации для
отключения всех фоновых обновлений групповых политик или для изменения времени
обновления групповой политики.
Существует две причины, которые могут изменить заданную по умолчанию обработку групповых
политик, применяемых к компьютерам и пользователям. Первая причина — это обнаружение
компьютером клиента медленного сетевого подключения в процессе запуска, в этом случае
применяются только выборочные части групповой политики (по умолчанию это параметры
настройки защиты и административные шаблоны).
Чтобы определить, используется ли медленное сетевое подключение, компьютер посылает пакет
утилиты ping с нулевым байтом контроллеру домена. Если время ответа составляет меньше десяти
миллисекунд, то сеть считается быстрой, и применяются все групповые политики. Если время
ответа составляет больше десяти миллисекунд, компьютер про-званивает контроллер домена три
раза с помощью утилиты ping с двух-килобайтными пакетами. Компьютер усредняет времена
ответов и использует это усредненное значение для определения сетевой скорости связи. Ecjfti
пропускная способность сетевого подключения составляет большее 500 Кб/с, то по умолчанию
применяются все групповые политики. Если компьютер обнаруживает сетевое подключение,
скорость которого меньше 500 Кб/с, то применяются только политики с параметрами настройки
защиты и административными шаблонами.
Можно изменить заданное по умолчанию определение медленной связи. Оно может быть
сконфигурировано для компьютеров в папке Computer Conf iguration\Administrative
Templates\System\Group Policy. Щелкните правой кнопкой мыши на Group Policy Slow Link
Detection (Обнаружение медленной связи для групповых политик) и выберите Properties
(Свойства) (см. рис. 11-13). Для изменения значения скорости передачи для медленной связи
выберите Enabled (Включено), а затем введите значение, которое вы хотите использовать.
Рис. 11-13. Конфигурирование параметров медленной связи
Если компьютер обнаруживает медленное сетевое подключение, то по умолчанию
обрабатываются только компоненты защиты и административных шаблонов, и нет никакого
способа выключить эти параметры настройки. Однако вы можете сконфигурировать другие
параметры так, чтобы они обрабатывались даже по медленному сетевому подключению. Папка
Computer Conf iguration\Administrative Templates\System\Group Policy содержит и другие опции.
Например, вы решите применить обработку политики обслуживания программы Internet Explorer
по медленному сетевому подключению. Щелкните правой кнопкой мыши на этой установке в
папке Group Policy (Групповая политика) и выберите Properties. Затем щелкните Enabled
(Включено) и выберите, как вы хотите применять эту политику (см. рис. 11-14).
Рис. 11-14. Конфигурирование обработки политики обслуживания программы Internet
Explorer по медленным сетевым подключениям
Чтобы применять эту политику независимо от сетевой пропускной способности, выберите Allow
Processing Across A Slow Network Connection (Разрешить обработку по медленному сетевому
подключению). Другие параметры настройки задают, будут ли параметры настройки
обрабатываться каждый раз, когда обновляется групповая политика, и будет ли политика
применяться в случае, если она не была изменена.
Второй способ изменения применения объекта GPO на компьютере состоит в использовании
опции loojpback. Эта опция изменяет заданное по умолчанию применение групповых политик, при
котором сначала устанавливается компьютерная политика, а затем политика пользователя,
переписывая все параметры настройки, противоречащие компьютерной политике. Вы можете
установить политику loopback, чтобы
компьютерная политика применялась последней и переписывала все политики, примененные к
пользователю. Групповая политика loopback устанавливается с помощью опции User group Policy
Loopback Processing Mode (Режим Loopback для пользовательских групповых политик) в
контейнере Computer Configuration\Administrative Templates\System\ Group Policy (см. рис. 11-15).
Рис. 11-15. Конфигурирование обработки loopback для групповых политик
Когда вы разрешаете обработку loopback, вам предоставляются две дополнительные опции
конфигурации. Первая опция Merge (Соединить) означает, что сначала применяется компьютерная
групповая политика, затем — пользовательская групповая политика, а затем компьютерная
групповая политика применяется снова. Некоторые из пользовательских параметров настройки
могут не изменяться компьютерной политикой. Переписываются только противоречивые
параметры настройки. Вторая опция Replace (Заменить) означает, что будет обработана только
компьютерная политика.
Опция loopback полезна во многих случаях. Например, нужно блокировать компьютер, который
расположен в общедоступном месте, и запретить служащим входить на него. Поскольку этот
компьютер общедоступен, вам нужна гарантия того, что он всегда будет блокирован, независимо
от того, кто войдет на этот компьютер. Вы можете включить блокировку, помещая
общедоступные компьютеры в OU и конфигурируя ограничительную групповую политику для
этой OU. Затем сконфигурируйте обработку loopback для этой OU. Теперь, когда пользователь
войдет в систему этого компьютера, он получит ограниченный рабочий
стол, поскольку групповая политика loopback защищает общественный компьютер.
Делегирование администрирования объектов GPO
Как говорилось в главе 9, одним из основных преимуществ Active Directory является функция
делегирования многих административных задач в пределах организации. Управление групповыми
политиками не является исключением - вы можете делегировать управление этим важным
административным инструментом.
Имеются три опции, позволяющие делегировать администрирование групповыми политиками. С
помощью первой опции можно делегировать разрешение создавать, удалять и изменять объекты
GPO. По умолчанию это право имеют только члены групп Domain Admins (Администраторы
домена) и Group Policy Creator Owners (Владельцы-создатели групповой политики). Группа Group
Policy Creator Owners имеет дополнительное ограничение, состоящее в том, что члены этой
группы имеют разрешение изменять параметры настройки только той групповой политики,
которую они создавали сами. Если вы создаете в своей организации специальную группу
администраторов, которые будут управлять групповой политикой, вы можете добавить этих
администраторов к одной из групп. Вы можете предоставить право создавать и удалять групповые
политики любой другой группе, но предоставить разрешения создавать или удалять объекты GPO
сложнее, чем большинство сценариев делегирования разрешений. Вы должны дать пользователю
разрешение создавать в Active Directory объекты GPO и разрешение записывать данные в папку
%systemroot%\Sysvol\domainname\ Policies, в которой хранятся объекты GPT. Вы можете дать
пользователям или группам разрешение изменять определенные объекты GPO, предоставляя им
разрешения Read (Чтение) и Write (Запись) для объектов GPO.
Вторая опция позволяет делегирбвать права управления связями групповой политики. Эта опция
не разрешает изменять какой-либо объект GPO, но позволяет добавлять или удалять связи
объектов GPO с контейнерным объектом. Самый простой способ состоит в использовании
Delegation Of Control Wizard (Мастер делегирования управления). В инструменте Active Directory
Users And Computers (Пользователи и компьютеры Active Directory) щелкните правой кнопкой
мыши на объекте, для управления которым вы хотите назначить другого пользователя или группу,
а затем щелкните Delegate Control (Делегировать управление), чтобы запустить мастер. При
запуске мастера на уровне OU одной из стандартных задач делегирования является разрешение на
управление связями групповой политики (см. рис. 11-16).
Третий способ делегирования состоит в предоставлении пользователям права генерировать
информацию Resultant Set of Policy (RSoP) (Результирующий набор политик). Используйте Delegation Of Control Wizard для предоставления
права генерировать инструмент RSoP в режиме регистрации или планирования (см. рис. 11-16).
Вы можете назначать эти разрешения, редактируя список ACL на контейнерном объекте,
предоставляя пользователю разрешение Write к атрибуту gPLink. Это фактически дает
пользователю разрешение конфигурировать блокирование групповых политик на контейнерном
уровне.
Рис. 11-16. Делегирование разрешений на управление связями групповой политики
Реализация групповых политик, действующих в нескольких
доменах и лесах
Вы можете использовать групповые политики Windows Server 2003 для предписания применения
политик, действующих в нескольких доменах и доверенных лесах. В обоих случаях имеются
некоторые проблемы, с которыми вы столкнетесь перед осуществлением такой групповой
политики.
После создания объекта GPO в Active Directory Windows Server 2003 вы можете связать его с
любым сайтом, доменом или OU. Основное ограничение состоит в том, что объекты GPO хранятся
только на контроллерах домена в том домене, где был создан объект GPO. Если вы захотите
связать объект GPO с контейнером, расположенным в другом домене, вы столкнетесь с
проблемами защиты и использованием пропускной способности сети. К примеру, все компьютеры
в OU должны иметь возможность соединяться с контроллером домена, расположенном в исходном домене GPO, для загрузки
групповой политики. Если один из контроллеров домена находится в том же сайте, где и
компьютеры-клиенты, это не очень сильно отразится на пропускной способности сети. Однако
если все контроллеры домена, имеющие копию GPO объекта, находятся в другом сайте,
соединенным медленным WAN-подключением, то применение групповой политики будет
происходить очень медленно и может серьезно воздействовать на пропускную способность. Кроме
того, если пользователи, принадлежащие одному домену, должны применять групповую
политику, созданную в другом домене, то пользователи и компьютеры, принадлежащие доменуадресату, должны иметь разрешение Read к объектам GPC в Active Directory и к объектам GPT в
папке Sysvol. В большинстве случаев наилучшей практикой является создание объектов GPO в
каждом домене вместо совместного использования одного объекта GPO в нескольких доменах.
Те же проблемы возникают при использовании групповых политик, действующих в нескольких
лесах. В Active Directory Windows Server 2003 имеется опция, предназначенная для совместного
использования групповых политик доверенными лесами. Она полезна в том случае, когда
пользователи путешествуют между различными офисами компании, находящимися в отдельных
лесах. В этом случае к пользователю, вошедшему на компьютер в другом лесу, могут применяться
групповые политики его домашнего домена. Другие функциональные возможности, доступные
нескольким лесам, включают следующее.
• Ресурсы, используемые для распределения программного обеспечения, могут находиться в
различных лесах.
• Сценарии входа в систему могут располагаться на контроллере домена другого леса и
читаться оттуда.
• Переадресованные папки и файлы профиля передвигающегося пользователя могут быть
расположены на компьютере другого леса.
• В каждом случае учет сетевой пропускной способности и проблемы защиты могут
подразумевать, что вы предпочтете реализовать отдельные объекты GPO в каждом лесу.
Инструментальные средства управления
групповыми политиками
Групповые политики обеспечивают большое количество возможностей и гибкость для управления
компьютерами клиента и серверами. До сих пор в этой главе рассказывалось только об одном из
инструментов управления групповыми политиками - редакторе Group Policy Object Editor. В этом
разделе будут представлены другие средства.
Инструмент RSoP
Конфигурирование групповых политик является сложным делом. Например, трудно определить
точно, какая политика применяется к определенному пользователю или группе. Если вы создали
несколько объектов GPO и связали их с различными контейнерами в вашем домене, то непросто
понять, какими являются результирующие параметры установки групповой политики, и от какого
объекта GPO происходит установка определенного параметра. Одним из инструментов для
решения этой задачи является инструмент RSoP, позволяющий точно определить, какова
результирующая политика, применяемая к любому пользователю или компьютеру.
Инструмент RSoP может использоваться в двух режимах: в режиме регистрации и планирования.
В режиме регистрации инструмент используется для поиска и перечисления всех групповых
политик, которые применяются к компьютеру или учетной записи пользователя. В режиме
планирования он определяет влияние на данного пользователя или компьютер модификации
конфигурации групповой политики. Она может включать перемещение пользователя из одного
контейнера в другой или добавление пользователя (или компьютера) к разным группам
безопасности.
Чтобы использовать инструмент RSoP, создайте собственную ММС-консоль и добавьте оснастку
Resultant Set of Policy (Результирующий набор политик). Затем щелкните правой кнопкой мыши
на Resultant Set Of Policy и выберите Generate RSoP Data (Сгенерировать данные RsoP). Resultant
Set Of Policy Wizard даст вам возможность выполнить инструмент в одном из двух режимов. В
режиме регистрации вы выбираете компьютер и пользователя. Затем инструмент вычисляет все
параметры настройки групповых политик, которые применяются к ним. Вместе с каждой
установкой инструмент определяет, какой объект GPO поставляет фактическую информацию для
этой установки.
В режиме планирования вы выбираете пользователя, компьютер, или то и другое; контейнерный
объект для пользовательской или компьютерной учетной записи, или для обоих (см. рис. 11-17).
После этого можно проверить различные сценарии изменения пользовательских или
компьютерных объектов. Например, определить, какая фактическая групповая политика будет
применяться, если пользователь будет подключен к домену по медленной связи, или как повлияет
на пользователя использование установки loopback. Вы можете определить, как повлияет на
пользователя перемещение его или компьютера в другой контейнер Active Directory или
добавление пользователя или компьютера к другой группе безопасности. Инструмент вычислит
фактическую групповую политику для пользователя и компьютера в новой конфигурации.
Рис. 11-17. Выбор объектов пользователя и компьютера в режиме планирования в
инструменте RSoP
Инструмент GPResult
GPResult - это инструмент командной строки, обеспечивающий часть функциональных
возможностей инструмента RSoP. Если вы выполните команду Gpresult без каких-либо
параметров, то получите информацию о групповой политике для компьютера, на котором вы
выполнили команду, и для того пользователя, который вошел в систему. Информация включает
групповые политики, применяющиеся к компьютерам, пользователям и группам, к которым
принадлежит каэядый объект. Команда может выполняться в подробном режиме, т.е. результаты
будут включать все фактические параметры настройки групповой политики, а также привилегии,
которые имеет пользователь. Инструмент можно также выполнять с одного компьютера для
анализа фактической групповой политики другого пользователя или компьютера. Инструмент
GPResult установлен на всех компьютерах, на которых выполняются системы Windows XP
Professional и Windows Server 2003. Полную информацию по инструменту GPResult смотрите в
Центре справки и поддержки (Help And Support Center).
Инструмент GPUpdate
Инструмент командной строки GPUpdate заменяет команду Secedit/ refreshpolicy, которая имеется
в Active Directory Windows 2000. Она используется для принудительного выполнения обновления групповых политик для компьютера или
пользователя. Если вы напечатаете gpupdate в командной строке, то обновятся и компьютерная, и
пользовательская групповые политики на местном компьютере. Инструмент используется также
для обновления групповых политик на других компьютерах. Одно из преимуществ команды
Gpupdate состоит в том, что эта команда может использоваться для выхода пользователей из
системы или даже для перезапуска компьютера после обновления групповой политики, что
полезно при обновлении групповых политик, которые применяются только при входе
пользователя в систему или при перезапуске компьютера. Например, политики распределения
программного обеспечения и политики переназначения папок применяются только при запуске
компьютера или входе в систему. Используя параметры /logoff или /ЪФОГ, ВЫ можете вызвать
применение этих политик в любое время.
Консоль управления групповой политикой
Использование встроенных инструментов для управления групповой политикой подходит для
маленькой организации, где имеется только несколько групповых политик и простая иерархия OU,
в которых групповые политики применяются только на одном или двух уровнях. Однако в
больших предприятиях, где существует множество групповых политик и мест, в которых
политика связана с контейнерами, управление групповыми политиками значительно усложняется.
Поэтому компания Microsoft разработала новый инструмент — консоль управления групповой
политикой (GPMC - Group Policy Management Console) (см. рис. 11-18).
Рис. 11-18. GPMC является инструментом, предназначенным для управления всеми
групповыми политиками
Примечание. Во время написания этой книги компания Microsoft объявила, что инструмент
GPMC будет доступен бесплатно вскоре после отправки покупателям Windows Server 2003.
Этот раздел основан на бета-версии 2 инструмента GPMC. Часть функциональных
возможностей в заключительном выпуске может отличаться от тех, которые показаны здесь.
GPMC является отдельным инструментом, который используется для управления всеми
конфигурациями групповых политик всей организации. В таблице 11-4 показаны все
функциональные возможности инструмента GPMC.
Табл. 11 -4. Опции конфигурирования инструмента GPMC
Функциональные
возможности
GPO
Settings
(Параметры
настройки GPO)
GPO Links (Связи
GPO)
Опции конфигурирования
Используются для конфигурирования
параметров настройки GPO.
всех
Используются для просмотра и изменения всех
мест, где объект GPO связан с контейнерными
объектами.
GPO
Delegation Используется для просмотра и изменения
(Делегирование GPO) делегирования
создания,
удаления
и
модификации
связей
GPO
объектов
и
разрешений на генерацию данных RSoP.
Security
Filtering Используется для просмотра и модификации
(Фильтрация защиты) всей фильтрации, основанной на группах
безопасности.
RSoP Planning (RSoP Назван
как
«Group
Policy
Modeling
планирование)
(Моделирование групповой политики)», но
использует мастер режима планирования в
инструменте RSoP.
RSoP Logging (RSoP Назван как «Group Policy Results (Результаты
регистрация)
групповой политики) », но использует мастер
режиме регистрации в инструменте RSoP.
Modify
Inheritance Используется
для
установки
параметров
(Изменить
настройки No Override (He подменять) и Block
наследование)
Inheritance (Блокировка наследования).
Search (Поиск)
Используется для поиска любых типов объектов,
связанных с групповой политикой. Например,
можное найти все объекты GPO, в которых
включена
опция
Folder
Redirection
(Переназначение папки).
Backup And Restore Используется для резервного копирования и
GPOs
(Резервное восстановления индивидуальных объектов GPO
копирование
и или всех объектов GPO в домене. Без этого
восстановление
инструмента единственным способом резервного
объектов GPO)
копирования и восстановления объектов GPO
является копирование данных состояния системы
на контроллере домена.
Scripting
Interface Инструмент GPMC представляет несколько
(Интерфейс создания СОМ-объектов, которые могут использоваться
сценариев)
для написания сценариев управления групповыми
политиками. Для получения дополнительной
информации обратитесь в веб-сайту Microsoft по
адресу
http://
www.microsoft.com/windowsserver2003/gpmc/
default.mspx.
Как видите, GPMC представляет собой мощный инструмент управления групповыми политиками
в среде предприятия.
Проектирование групповой политики
Групповые политики являются мощным средством, предназначенным для управления
конфигурацией компьютеров в вашей сети. Реализация групповых политик может быть
достаточно сложной, и если она выполнена неправильно, групповая политика может сильно
воздействовать на рабочую среду пользователей организации. В данном разделе описываются
методики, позволяющих разработать реализацию групповой политики в вашей сети.
Дополнительная информация. Главы 12 и 13 описывают так же методики использования
групповых политик для распределения программного обеспечения и управления рабочим
столом.
Один из важных вопросов, с которыми вы столкнетесь при проектировании конфигурации
групповой политики, состоит в том, сколько групповых политик вам следует реализовать.
Поскольку все параметры настройки групповой политики доступны в каждом объекте GPO, вы
теоретически можете сконфигурировать их в единственном объекте GPO или развернуть
отдельный объект GPO для каждой установки, которую нужно сконфигурировать. В любом случае
оптимальное количество объектов GPO будет расположено между этими крайностями, и никакое
решение не будет верным для всех ситуаций. Когда запускается компьютер клиента и
пользователь входит в систему, все применяемые объекты GPO должны быть загружены и применены к местному компьютеру. Поэтому меньшее
количество групповых политик улучшает запуск и производительность входа в систему. Однако
наличие только нескольких групповых политик, выполняющих множество различных функций,
является более трудным для документирования и управления. Если ваша групповая политика
имеет только несколько параметров настройки, ее легче использовать повторно для нескольких
OU. Хорошей практикой является использование объекта GPO для конфигурирования только
одной группы параметров настройки. Например, вы можете использовать один объект GPO для
установки конфигурации защиты, другой -для установки административных шаблонов, еще один для установки пакета программ.
Другая проблема проектирования связана с тем, где вы хотите развернуть групповую политику.
Обычно у вас есть возможность развернуть групповые политики на высшем уровне OU
подразделений, а затем можно использовать фильтрацию rpytm и блокирование групповой
политики, чтобы групповые политики применялись к соответствующим компьютерам или
пользователям. Вы можете также применять большинство групповых политик ниже в иерархии,
чтобы избежать конфигурации со сложным наследованием. В большинстве случаев комбинация
этих стратегий дает правильный ответ. Если ваша политика должна применяться ко всем
пользователям в вашем домене, установите ее настолько высоко, насколько это возможно. По мере
продвижения вниз по иерархии групповые политики будут гораздо более специфичными.
Резюме
Эта глава объясняет опции конфигурации групповых политик в Active Directory Windows Server
2003, создавая предпосылки для понимания последующих глав. В ней обсуждаются вопросы
создания и управления групповыми политиками с помощью инструментов, поставляемых вместе с
Windows Server 2003, вопросы наследования групповых политик и применения их к компьютерам
клиентов. Вы можете использовать заданную по умолчанию модель наследования групповой
политики, установленной высоко в иерархии OU, и получить параметры настройки GPO для
многих объектов домена. Вы можете также изменить заданное по умолчанию наследование
параметров настройки групповой политики, блокируя или фильтруя наследование. Главы 12 и 13
посвящены тому, что вы фактически можете делать с групповой политикой. Глава 12 показывает,
как использовать групповые политики при распространении программного обеспечения на
компьютеры-клиенты, глава 13 — как использовать групповые политики для управления
разнообразными опциями конфигурации рабочего стола.
Глава 12. Использование групповых политик
для управления программным обеспечением
В главе 11 был сделан краткий обзор основных функций групповых политик и способов развертывания и
управления групповыми политиками в Adive Directory Microsoft Windows Server 2003. В этой главе
обсуждается использование групповых политик для управления программным обеспечением на
компьютерах клиентов, в главе 13 — пути управления рабочими столами пользователей.
Управление программным обеспечением на компьютерах клиентов - это одна из наиболее важных задач,
которую вы будете выполнять при управлении корпоративной сетью. Программное обеспечение,
установленное на компьютерах клиентов, включает инструментальные средства пользователей для
выполнения своей работы. Во многих компаниях компьютеры пользователей содержат стандартный набор
офисных приложений, таких как Microsoft Office, и других приложений, специфичных для их бизнеса.
Стандартному клиентскому компьютеру требуются также приложения для сжатия файлов и антивирусное
программное обеспечение.
Управление программным обеспечением на пользовательских рабочих столах может стать очень
трудоемкой задачей, если администратор будет посещать каждый рабочий стол всякий раз при установке
или модернизации нового пакета программ. В большой компании только для решения проблем, связанных с
ошибками приложений, может потребоваться несколько администраторов на полный рабочий днеь. В
некоторых случаях обновления программ должны выполняться ежедневно или еженедельно, по крайней
мере, для антивирусного программного обеспечения.
Использование групповых политик для управления программным обеспечением может значительно
уменьшить усилия, которые требуются для управления пользовательскими рабочими столами. Фактически
серьезное уменьшение затрат, получаемое от развертывания службы каталога Active Directory и групповых
политик, находится в области управления программным обеспечением.
Управление программным обеспечением в корпоративной среде предполагает гораздо больше дел, чем его
простое развертывание. Многие компании имеют четко определенный процесс управления жизненным
циклом программ, который включает покупку (или создание) и испытание приложения в маленькой группе
пользователей, затем крупномасштабное развертывание приложения, его обслуживание и, наконец,
удаление. Групповые политики в Active Directory решают эти задачи более эффективно.
Технология инсталлятора Windows
В большинстве случаев управление программным обеспечением через групповые политики полагается на
технологию инсталлятора Windows от Microsoft. Технология инсталлятора Windows используется для
установки, управления и удаления программного обеспечения на рабочих станциях Windows. Она включает
два компонента.
• Пакетный файл установки программ (.msi-файл). Пакетный файл .msi состоит из
информационной базы данных, которая содержит все команды, необходимые для установки и
удаления приложений.
• Служба инсталлятора Windows (Msiexec. exe). Эта служба управляет фактической инсталляцией
программного обеспечения на рабочей станции. Служба использует файл библиотеки динамической
компоновки (DLL) с именем Msi.dll для чтения файлов пакета .msi. В зависимости от содержимого
пакетного файла инсталляции программ служба копирует файлы приложений на локальный
жесткий диск, создает ярлыки, изменяет записи системного реестра и выполняет все задачи,
перечисленные в файле msi.
Использование технологии инсталлятора Windows имеет множество преимуществ. Одно из наиболее
важных состоит в том, что любое приложение может самовосстанавливаться. Поскольку файл .тэЛюдержит
всю информацию, необходимую для установки приложения, то он может также использоваться для
восстановления приложения, которое вышло из строя. Например, если приложение перестало работать из-за
удаления критического файла, то оно не сможет запуститься в следующий раз, когда пользователь выберет
это приложение. Если приложение было установлено с помощью инсталлятора Windows, то файл .msi,
который использовался для установки приложения, будет использоваться для его восстановления путем
повторной установки отсутствующего файла. Файл .msi файл также допускает очистку путем деинсталляции
приложений.
Примечание. Технология инсталлятора Windows не является специфичной для систем Windows
Server 2003, Microsoft Windows XP Professional или Microsoft Windows 2000, хотя служба
инсталлятора Windows в этих операционных системах установлена по умолчанию. Используя
технологию инсталлятора Windows, приложения могут быть установлены на других
компьютерах. Вы можете установить службу инсталлятора Windows на компьютерах с
системами Microsoft Windows NT, Windows 95 и Windows 98. Однако использовать групповые
политики для распределения программного обеспечения можно только на компьютерах с
системами Windows Server 2003, Windows XP Professional и Windows 2000.
Сейчас производители программного обеспечения поставляют пакетный файл .msi для
инсталляции программ со всеми новыми программными продуктами. Он известен как файл
«родного» (native) инсталлятора Windows.
Создание файла .msi
В некоторых случаях файл «родного» инсталлятора Windows может от-сутстврвать, например, у
более старого приложения. Если необходимо использовать технологию инсталлятора Windows для
развертывания приложений, можно создать файл .msi для распределения программного
обеспечения.
Чтобы создать файл .msi, выполните следующие действия.
• Выполните чистую инсталляцию операционной системы там, где вы собираетесь создавать
пакетный файл инсталляции программ. В этой операционной системе не должно быть
установлено никакого дополнительного программного обеспечения. Операционная
система на этом компьютере должна быть той же самой, что и на компьютере, где вы
устанавливаете приложение. Если устанавливаете приложение в системах Windows 2000 и
Windows XP, то создаются два отдельных файла .msi.
• Используйте инструмент для упаковки программного обеспечения, чтобы зафиксировать
состояние операционной системы, прежде чем вы установите программное обеспечение.
Существует несколько таких инструментов (например, Wise).
• Установите приложение на рабочей станции. Обычно используется «родной» процесс
инсталляции программ.
• После того как вы установили приложение, настройте его по вашему желанию. Например,
можно создать или удалить ярлыки, добавить шаблоны или настроить инструментальную
панель приложения. В некоторых случаях нужно хотя бы раз открыть приложение, чтобы
полностью установить все компоненты.
• Используйте инструменты для упаковки программного обеспечения, чтобы во второй раз
зафиксировать состояние операционной системы рабочей станции. Этот процесс создает
упаковочный файл инсталляции программ .msi.
Как только вы создали .msi файл, используйте процесс Group Policy Software Installation
(Инсталляция программного обеспечения с помощью групповых политик) для распределения
программного обеспечения на рабочие станции.
Развертывание программного обеспечения с
использованием групповых политик
После создания файла инсталлятора Windows вы можете развертывать приложения, используя
групповые политики Active Directory Windows Server 2003. Групповые политики обеспечивают
средства, позволяющие публиковать приложение или делать его доступным для инсталляции на
рабочих станциях. После конфигурации соответствующей групповой политики при последующей
загрузке компьютера или входе пользователя в систему на компьютере появится извещение о
новом пакете программ, и затем приложение может быть установлено.
Прежде чем вы сможете опубликовать приложение для пользователей сети, нужно скопировать
инсталляционные файлы программ, включая .msi-файл, на доступный сетевой ресурс. Необходима
гарантия того, что все пользователи или компьютеры имеют соответствующий доступ к ресурсу.
Если вы назначаете приложение для компьютеров, компьютерные учетные записи должны иметь
доступ Read (Чтение). Если вы назначаете или публикуете приложение для пользователей, то
пользователи должны иметь доступ Read. (Смотрите следующий раздел для сравнения деталей
назначения приложений и публикации приложений.)
Развертывание приложений
После создания сетевого ресурса и копирования на него инсталляционных файлов вы готовы к
реализации объектов групповой политики GPO, которые будут публиковать приложение для
клиентов. Вы можете создать новый объект GPO или изменить существующий. При
конфигурировании GPO вы должны сначала определить, необходимо ли публиковать приложение
для компьютеров или пользователей. Используйте контейнер Computer Configuration\Software
Settings в Group Policy Object Editor (Редактор объектов групповой политики), и приложение будет
установлено на рабочей станции, когда она перезагрузится в следующий раз. Если вы решите
публиковать приложение для пользователей, используйте контейнер User Conf iguration\Sof tware
Settings в редакторе объектов групповой политики, и приложение будет доступно пользователю
при его следующем входе в систему.
Примечание. В главе 11 была представлена консоль управления групповыми политиками Microsoft
Group Policy Management Console (GPMC), являющаяся мощным инструментом для управления
всеми конфигурациями групповых политик целой организации. Поскольку консоль разработана как
отдельный инструмент, предназначенный для управления групповой политикой, то ее
пользовательский интерфейс сильно отличается от интерфейса, используемого в других
инструментах администрирования Active Directory. Однако поскольку GPMC-консоль не является
обязательным дополнением, то информация, данная в главах 11, 12 и 13, базируется на
использовании только тех инструментов администрирования и оснасток, которые
поставляются как часть инсталляционного компакт-диска Windows Server 2003.
Когда вы используете групповую политику для инсталляции приложений, у вас имеется два
варианта извещения о приложении для клиента. Первый вариант состоит в назначении
приложения, которое может адресоваться или компьютеру, или пользователю. Второй вариант
состоит в публикации приложения, которая делает его доступным, но только для учетных записей
пользователей.
Когда вы назначаете приложение компьютеру, оно будет полностью установлено при следующей
загрузке компьютера, что означает, что приложение будет установлено для всех пользователей
компьютера, когда они в следующий раз войдут в систему.
Когда вы назначаете приложение пользователю, оно будет опубликовано, когда пользователь в
следующий раз войдет в сеть. Можно сконфигурировать то, каким образом это будет происходить,
но обычно приложение добавляется к меню Start (Пуск). Приложение будет также добавлено к
списку опубликованных приложений в панели управления Add Or Remove Programs (Добавление
или удаление программ). По умолчанию приложение устанавливается не при входе пользователя в
систему, а при активации из меню Start или через панель Add Or Remove Programs. Можно
сконфигурировать такую логику установки, что приложение установится, когда пользователь
попытается открыть файл с расширением, которое ассоциировано с данным приложением.
Например, приложение Microsoft Word отсутствует на компьютере пользователя. Если он щелкнет
два раза на файле с расширением .doc, то Word будет автоматически установлен. Этот процесс
часто называют активацией расширений (extension activation).
Одна из новых функций в Active Directory Windows Server 2003, отсутствующая в Active Directory
Windows 2000, — возможность полной установки программного приложения при входе
пользователя в систему вместо установки его в результате активации файла. Выбор этой опции
означает, что процесс входа в систему займет больше времени, поскольку произойдет установка
приложения, но затем приложение будет доступно клиенту для использования. Эта опция
доступна только в том случае, когда приложение назначено пользователю. Опубликованные
приложения не будут установлены полностью, пока они не инсталлируются через панель Add Or
Remove Programs или через активацию расширения. Эта опция не используется, если приложение
назначено компьютеру, потому что приложение полностью устанавливается только при
перезагрузке компьютера.
Когда вы публикуете приложение для пользователей, оно извещает о себе при следующем входе
пользователя в сеть. В этом случае приложение появляется только в панели управления Add Or
Remove Programs. Чтобы установить приложение, пользователь должен выбрать его в этой панели.
По умолчанию опубликованные приложения устанавливаются также через активацию
расширения.
В большинстве случаев публикация приложения является наилучшим вариантом, если данное
приложение требуется только некоторым пользователям. Например, имеется графическое
приложение типа Microsoft Visio, которое постоянно используют только сетевые архитекторы.
Однако некоторым другим пользователям также может потребоваться Visio. Публикуя
приложение для пользователей, вы не устанавливаете его на их рабочих столах и не добавляете
его к их ярлыкам, а делаете его доступным для тех, кто в нем нуждается.
Для публикации приложения с помощью групповой политики используйте следующую
процедуру.
1. Скопируйте инсталляционные файлы программы на сетевой ресурс. Сконфигурируйте
разрешения на доступ к ресурсу, гарантируя, что все нужные пользователи и компьютеры
имеют доступ Read (Чтение) для чтения инсталляционных файлов.
2. Найдите контейнер: сайт, домен или организационную единицу (OU), в котором вы хотите
опубликовать приложение, и обратитесь к свойствам контейнера. Щелкните на вкладке
Group Policy (Групповая политика). Создайте новый объект GPO или щелкните на кнопке
Edit (Правка) для изменения свойств существующего объекта GPO.
3. Если вы публикуете приложение для учетных записей пользователей, раскройте контейнер
User Conf iguration\Sof tware Settings (Конфигурирование пользователей\Параметры
настройки программ) в редакторе объектов групповых политик, щелкните правой кнопкой
мыши на кнопке Software Installation (Инсталляция программ), выберите New (Новый), а
затем выберите Package (Пакет). Если вы публикуете приложение для компьютерных
учетных записей, то раскройте контейнер Computer Configuration\Software Settings
(Конфигурирование компьютеров\Параметры настройки программ) в редакторе GPO,
щелкните правой кнопкой мыши на кнопке Software Installation (Инсталляция программ),
выберите New (Новый), а затем выберите Package (Пакет).
4. Найдите место в сети или напечатайте сетевой путь к месту расположения
инсталляционных файлов. Вы должны использовать место в сети, а не локальное имя
диска на сервере, потому что для клиентских компьютеров публикуется место в сети.
Выберите соответствующий файл .msi.
Примечание. Если вы выберете неправильное сетевое место или измените его после
развертывания, нужно обновить пакет программ. Нет никаких средств, позволяющих изменить
инсталляционный путь для пакета программ.
5. При выборе файла .msi вы можете указать способ, которым вы хотите публиковать пакет
программ. На рисунке 12-1 показаны способы публикации приложения для учетных
записей пользователя. Если вы публикуете приложение для, компьютеров, можно только
назначать приложение.
Рис. 12-1. Опции для публикации пакета программ
6. Если вы хотите назначить или опубликовать приложение, щелкните на кнопке ОК. Если
вы выберете опцию Advanced (Дополнительно), появится окно свойств данного пакета
Properties, опции которого обсуждаются в разделе «Конфигурирование свойств пакета
программ» далее в этой главе.
Как только объект GPO сконфигурирован, приложение будет опубликовано для всех клиентов
контейнерного объекта. По умолчанию программный инсталляционный компонент групповой
политики применяется только при входе пользователя в систему (если политика применяется к
учетным записям пользователей) или при перезагрузке компьютера (если политика применяется к
компьютерным учетным записям). Инструмент командной строки GPUpdate, который имеется на
всех компьютерах с системами Windows XP Professional и Windows Server 2003, может вызвать
принудительный выход из системы или перезагрузку на рабочей станции как часть обновления,
связанного с групповой политикой. Чтобы вызвать выход из системы или перезагрузку,
используйте команду gpupdate /logoff или gpupdate /reboot.
Распределение программного обеспечения и пропускная способность сети
Один из наиболее трудных аспектов управления распределением программного обеспечения с
помощью групповых политик состоит в управлении использованием сети. Если вы назначите
большое приложение размером в несколько мегабайт на большую группу пользователей, и все они
начнут устанавливать его одновременно, эта установка займет часы из-за существенного
увеличения объема сетевого трафика. Есть множество опций, позволяющих управлять сетевой
пропускной способностью. Одна из опций состоит в назначении приложения на компьютеры с
просьбой к пользователям перезагрузить компьютеры в конце дня. Вы можете также вынуждать
перезагрузку рабочей станции, используя команду GPUpdate. Если вы примените эту команду
одновременно лишь к нескольким рабочим станциям, влияние на сеть может быть сведено к
минимуму. Другая опция состоит в назначении приложения маленькой группе пользователей за
один раз. В большинстве случаев старайтесь избежать назначения приложений, которые будут
полностью устанавливаться при входе пользователя в систему. Если вы публикуете приложение,
но позволяете пользователю инициировать инсталляцию, появится возможность, по крайней мере,
растянуть инсталляцию программного обеспечения на некоторое время. Хотя ни одна из этих
опций не является идеальной, их можно использовать, чтобы до некоторой степени управлять
пропускной способностью сети.
Другой способ управлять использованием сети для нескольких сайтов состоит в том, чтобы
применить распределенную файловую систему (Distributed File System - DFS). С помощью DFS
можно создать структуру логического каталога, не зависящую от того, в каком месте сети
фактически хранятся файлы. Например, можно создать корень DFS с именем \\serverl\softinst, а
затем для всех приложений создать подкаталоги ниже этой общей точки. С помощью системы
D*FS можно найти подкаталоги на нескольких серверах и сконфигурировать физические связи к
одним и тем же логическим каталогам. Если вы используете интегрированную систему DFS,
можно сконфигурировать автоматическую репликацию содержания папки между копиями одного
и того же каталога. Система DFS является приложением, учитывающим наличие сайтов, т.е. если у
вас имеется несколько сайтов, то компьютеры клиентов будут всегда подключаться к копии DFS
папки, расположенной в их собственном сайте, вместо того чтобы пересекать глобальную сеть
WAN для обращения к папке, расположенной в другом сайте.
Трудно предсказать, каким будет эффект сетевой инсталляции. Одно из преимуществ
использования групповых политик для установки программного обеспечения состоит в том, что
можно легко выполнить тестирование, чтобы увидеть ожидаемый эффект. Например, можно
сконфигурировать объект GPO, который включает пакет программ, но не
связан ни с какой OU, затем создать временную OU, добавить несколько пользовательских или
компьютерных учетных записей и связать GPO-объект с OU. Эта конфигурация может
использоваться для проверки того, сколько времени потребуется для установки приложения в
маленькой группе пользователей. Можно также запустить программное распределение, связав
объект GPO с производственной OU, используя фильтрацию группы для ограничения количества
пользователей или компьютеров, к которым применяется GPO-объект.
Независимо от количества усилий, предпринятых вами для минимизации влияния на сеть,
развертывание объемного приложения для большого количества пользователей всегда оказывает
воздействие на сеть, поэтому нужно запланировать выполнение инсталляции в течение несколько
дней.
Использование групповых политик для распределения
приложений с помощью инсталлятора, не принадлежащего
платформе Windows
В некоторых случаях вы можете не создавать файла .msi для установки приложения, а
использовать групповые политики для его распределения. Например, простое приложение должно
быть установлено на нескольких рабочих станциях, оно не требует никакой настройки и
модернизации. Можно создать и использовать файл параметров настройки инсталляции
программы (.zap) для установки этого приложения.
Файл . zap является текстовым файлом, который содержит команды, предназначенные для
установки приложения. В большинстве случаев .zap-файл будет содержать только следующие
строки:
[Application]
FriendlyName = "applicationname"
SetupCommand = "\\servername\sharename\installapplication.exe""
Значение FriendlyName является именем, отображаемым в панели управления Add Or Remove
Programs на компьютере клиента. Значение SetupCommand ~ путь к инсталляционному файлу для
приложения. Можно использовать UNC-путь или отображенный диск для значения
SetupCommand. Если приложение обеспечивает средства для настройки инсталляции с
использованием параметров установки, можно включить эти параметры в значение
SetupCommand, указывая его вслед за параметром, определяющим путь установки, заключенным в
двойные кавычки. Например:
SetupCommand = "\\servername\sharename\se\up.exe" /parameter
Обратите внимание, если командная строка включает параметр, то путь установки использует
одинарный набор двойных кавычек вместо двойного набора двойных кавычек, которые
требовались в предыдущем примере.
После создания файла .zap и копирования инсталляционных файлов приложения на сетевой ресурс
можно опубликовать приложение для пользователей. Приложение добавляется к списку
доступных приложений в панели управления Add Or Remove Programs, и пользователи могут
выбрать его для установки. Приложения, которые распределяются через файлы .zap, не могут быть
назначены ни компьютерам, ни пользователям, их нельзя устанавливать с помощью активации
расширения.
Использование файла .zap имеет несколько важных ограничений по сравнению с использованием
файлов инсталлятора Windows. Во-первых, инсталляция приложения с помощью файла .zap
запускает нормальную инсталляционную программу для приложения, т.е. нельзя настраивать
инсталляцию, если приложение не обеспечивает параметры установки для этого. Далее,
инсталляция приложения с помощью файла .zap не может выполняться с разрешениями,
включенными в процессе инсталляции, т.е. для установки приложения пользователь должен быть
местным администратором. Приложения, которые были установлены с помощью файла .zap, не
могут самовосстанавливаться. Если приложение перестанет работать из-за порчи или удаления
файла, пользователю придется снова выполнить первоначальную инсталляционную процедуру
вручную для повторной установки приложения. Кроме того, приложение, которое было
установлено с помощью файла .zap, не может быть легко модернизировано или исправлено. Из-за
перечисленных недостатков технология инсталляции программ имеет ограниченную пригодность
и должна использоваться только тогда, когда вы устанавливаете простое приложение, которое
вряд ли будет обновляться.
Конфигурирование свойств пакета программ
После создания пакета программ можно изменись его свойства. Для этого щелкните правой
кнопкой мыши на пакете и выберите Properties. На рисунке 12-2 показана вкладка Deployment
(Развертывание). В таблице 12-1 описаны опции окна Properties.
Табл. 12-1. Опции развертывания для пакета программ
Параметры настройки
Объяснение
Deployment
Type
(Тип
развертывания)
Auto-Install This Application By
File
Extension
Activation
(Автоматически установить это
приложение путем активации
расширения файла)
Используется для указания того, как
приложение
будет
публиковаться
для
клиентов.
Используется для включения или блокировки
функции, устанавливающей программное
обеспечение, когда пользователь открывает
файл с определенным расширением. Эта опция
недоступна, если вы назначаете приложение.
Uninstall This Application When
It Falls Out Of The Scope Of
Manage
ment
(Деинсталлировать
приложение, когда оно выходит
из контекста управления )
Используется для управления ситуацией, когда
групповая политика более не применяется к
пользователю или компьютеру. Например,
если групповая политика связана с учетными
записями пользователя в какой-либо OU,
выбор этой опции означает, что приложение
будет деинсталлироваться, если учетная
запись пользователя переместится из этой
организационной единицы.
Do Not Display This Package In Используется для управления отображением
The Add/ Remove Programs приложения в панели управления Add/ Remove
Control Panel (He отображать Programs (Добавление/Удаление программ).
этот пакет в панели управления
Add/Remove Programs )
Install This Application At Logon Используется
для
полной
установки
(Установить это приложение приложения при входе пользователя в систему
при входе в систему)
вместо того, чтобы ожидать инициацию
инсталляции пользователем. Эта опция
недоступна, когда приложение опубликовано.
Installation
User
Interface Используется для управления тем, какая
Options
(Опции информация
будет
отображаться
при
пользовательского интерфейса установке программного обеспечения. Выбор
во время инсталляции)
опции Basic (Основной) означает, что будут
отображены только сообщения об ошибках и о
завершении инсталляции. Выбор опции
Maximum (Максимум) означает отображение
всех экранов установки программы.
Advanced
(Дополнительные Используется
для
конфигурирования
опции)
дополнительных параметров настройки пакета
программного обеспечения. Опции включают
инсталлирование 32-битных приложений в 64битных операционных системах, установку
приложения, даже если оно использует язык,
отличающийся от языка операционной
системы адресата, и включение в пакет СОМкомпонент, чтобы клиент мог устанавливать
компоненты из Active Directory (см. рис. 12-3).
Рис. 12-2. Изменение свойств развертывания для пакета программ
Рис. 12-3. Использование окна Advanced Deployment Options (Дополнительные опции
развертывания) для конфигурации групповой политики, предназначенной для инсталляции
программного обеспечения
Установка заданных по умолчанию свойств процесса инсталляции
программ
Когда вы готовитесь установить программное обеспечение, используя групповые политики,
можно сконфигурировать параметры, заданные по умолчанию для всех пакетов программ,
развертываемых с помощью определенного объекта GPO. Откройте соответствующее окно, щелкнув правой кнопкой мыши на
контейнере Software Installation (Инсталляция программ) и выбрав Properties (Свойства) (см. рис.
12-4).
Рис. 12-4. Конфигурирование заданных по умолчанию параметров настройки, используемых при
инсталляции программ
Вы можете использовать эту процедуру для установки опций, отображаемых при создании нового
пакета программ с данным объектом GPO. Можно установить заданное по умолчанию место
расположения инсталляционных файлов и сконфигурировать параметры настройки
инсталляционного интерфейса пользователя.
Установка настраиваемых пакетов программ
Иногда компании может понадобиться настройка инсталляции пакета программ, даже если он
поставляется с «родным» пакетом инсталлятора Windows. Например, требуется создать
настроенную инсталляцию своего приложения, предназначенного для обработки текстов, чтобы
включить в него собственные словари или шаблоны. Или настроить инсталляцию приложения
Microsoft Office, чтобы на каждом рабочем столе устанавливались только Microsoft Word и
Microsoft Excel, а полный пакет развертывался лишь для определенных пользователей. Если вы
работаете в международной компании, вам потребуется развернуть одно и то же приложение на
нескольких языках.
Вы можете настроить инсталляцию пакета программ, создавая файл преобразования (.mst). В
дополнение к файлу .msi файл преобразования содержит команды настройки инсталляции. Самый
легкий способ создания файла .mst состоит в использовании специально предназначенных для этого инструментов,
если они предоставлены изготовителем программы. Например, Microsoft включает Custom
Installation Wizard (Мастер выборочной инсталляции) в комплекты ресурсов Microsoft Office 2000
Resource Kit и Microsoft Office XP Resource Kit. После запуска мастера нужно выбрать файл .msi,
имя и место расположения файла .mst. Тогда мастер представляет все опции, предназначенные для
настройки заданной по умолчанию инсталляции программного обеспечения. Вы можете настроить
практически каждый аспект инсталляции, включая удаление предыдущих версий Microsoft Office,
выбор устанавливаемых компонент и место установки компонентов. Можно переносить
пользовательские параметры настройки, если инсталляция представляет собой обновление
существующего программного обеспечения, или выборочно сконфигурировать персональные
параметры настройки и параметры настройки защиты. Можно добавлять дополнительные файлы к
инсталляции (например, собственные шаблоны), Создавать или удалять ключи системного
реестра, добавлять или удалять ярлыки к приложениям Microsoft Office и конфигурировать
параметры настройки электронной почты клиента.
После создания файла преобразования нужно создать новый пакет программ для развертывания
выборочной инсталляции. Для этого при выборе метода развертывания выберите опцию Advanced
(Дополнительно) для добавления файла преобразования, прежде чем создание пакета будет
закончено. В окне Properties (Свойства) пакета программ выберите вкладку Modifications
(Модификации), а затем добавьте файлы преобразования. На рисунке 12-5 показана вкладка
Modifications.
Рис. 12-5. Добавление файлов преобразования к пакету программ
Когда вы применяете к пакету программ файл преобразования, все клиенты, инсталлирующие
приложение в пределах объекта GPO, установят настроенную версию. С пакетом программ можно
включать несколько файлов преобразования. В этом случае файлы преобразования применяются,
начиная с вершины списка, т.е. те файлы, которые применяются в инсталляционном процессе
позже, могут записываться поверх более ранних модификаций.
Обновление существующего пакета программ
Еще одна полезная функция, доступная при использовании групповых политик для установки
программного обеспечения, предназначена для обновления существующего пакета программ.
Имеется два способа обновления: внесение исправлений (заплаток) или установка сервисного
пакета (service pack) на существующее приложение и обновление приложения до новой версии.
Если у вас работает Microsoft Office 2000, то установка пакета Service Release I for Office 2000
является примером первого типа модификации, а инсталляция программы Office XP дает пример
второго типа.
Эти методы обновления программного обеспечения требуют применения различных процедур.
Если вы применяете заплатки (patch file) или сервисный пакет к существующему приложению,
сначала нужно получить файл .msi или patch-файл (.msp) для обновленного приложения. (В
идеальном случае этот файл поставляется изготовителем программы, но вы можете создать свой
собственный.) Скопируйте новый файл .msi и другие инсталляционные файлы в ту же самую
папку, в которой находится оригинальный файл .msi, записывая любые дублированные файлы
поверх старых. Затем повторно разверните приложение. Чтобы это сделать, щелкните правой
кнопкой мыши на пакете программ в редакторе объектов групповой политики, выделите All Tasks
(Все задачи), а затем выберите Redeploy Application (Повторно развернуть приложение). Пакет
программ будет повторно развернут для всех пользователей и компьютеров, находящихся под
управлением этой групповой политики. При обновлении существующего приложения до новой
версии программного обеспечения вам потребуется другой подход. Нужно будет создать новый
пакет программ для развертывания приложения. Затем можно обратиться к свойствам пакета
программ нового приложения и выбрать вкладку Upgrades (Обновления). Используя параметры
настройки, представленные на этой вкладке, создайте ссылку на существующий пакет в новом
пакете распределения программного обеспечения. Щелкнув на кнопке Add (Добавить) во вкладке
Upgrades, выберите пакет программ, который будет модернизирован с помощью нового пакета.
Вы сможете также сконфигурировать, должно ли старое приложение деинсталлироваться, прежде
чем будет установлено новое приложение. На рисунке 12-6 показан пример обновления
приложения Office 2000.
Рис. 12-6. Обновление существующего пакета программ
Когда связь с обновлением создана, вкладка Upgrades показывает новую информацию (см. рис. 127). С помощью вкладки Upgrades можно сделать это обновление обязательным. В этом случае все
программное обеспечение, распределенное предыдущим объектом GPO, будет обновлено во время
следующей перезагрузки компьютера или при следующем входе пользователя в систему. Если
обновление не сделать обязательным, пользователь сможет выбирать время установки нового
приложения, активизируя приложение в меню Start (Пуск) или через панель управления Add Or
Remove Programs (Установка и удаление программ). Если для пакета обновления программного
обеспечения и для начального приложения вы используете один и тот же объект GPO, то
первоначальный пакет программ покажет, что новый пакет его модернизирует.
Планирование. Тот факт, что модернизировать приложение, используя групповые политики,
очень просто, не означает, что обновление пройдет легко. Перед развертыванием обновления вы
должны его протестировать для гарантии того, что оно не создаст проблем при
взаимодействии с существующими приложениями. Нужно протестировать процесс обновления и
удостовериться, что он будет работать гладко в вашей организации. Когда вы убедитесь в
этом, нужно будет управлять развертыванием. Если приложение, которое вы модернизируете,
было развернуто для нескольких тысяч пользователей, и вы решите сделать это обновление
обязательным, то пользователям, возможно, придется ждать много времени, пока инсталляция
будет закончена. Нужно управлять развертыванием обновления, чтобы свести к минимуму
воздействие на пропускную способность сети.
Рис. 12-7. Вкладка Upgrades в окне Properties (Свойства) пакета программ
Управление категориями программного обеспечения
В большой организации можно развернуть множество приложений, используя групповые
политики. Если вы захотите опубликовать большинство этих приложений на верхнем уровне в
иерархии домена, где объект GPO применяется к большинству пользователей, то пользователи
будут видеть длинный список доступных приложений, открывая панель управления Add Or
Remove Programs, что может привести к замешательству. Чтобы свести его к минимуму,
используйте программные категории, дающие пользователям более простое представление о тех
приложениях, которые они могут установить.
С помощью программных категорий можно представлять пользователю сгруппированные списки
приложений. Например, на рисунке 12-8 показано, что вы можете создать категорию для каждой
группы деловых приложений. Если пользователь находится в подразделении Administration
(Администрация), он может выбрать категорию Administration и брать оттуда приложения для
инсталляции.
Active Directory Windows Server 2003 поставляется без каких-либо предопределенных
программных категорий, так что можно создать любые. Чтобы создать категорию, откройте любой
существующий объект GPO, щелкните правой кнопкой мыши на Software Installation
(Инсталляция программного обеспечения) в разделе Computer Configuration или User
Configuration, выберите Properties, а затем выберите вкладку Categories (Категории) (см. рис. 12-9).
Программные категории применяются не к индивидуальным GPO-объектам, а ко всем GPO-объектам в домене. После создания
программных категорий вы можете связывать каждый из пакетов развертывания программного
обеспечения с соответствующей категорией.
Рис. 12-8. Отображение программных категорий в панели Add Or Remove Programs
Рис. 12-9. Конфигурирование программных категорий на GPO-объектах
Конфигурирование активации расширения файла
Одним из средств, с помощью которых пользователь может начать инсталляцию приложения,
является активация расширения файла. В большинстве случаев с каждым определенным
расширением файла связано только одно приложение. Однако в некоторых случаях можно иметь
более одного приложения. Например, обновить Word 2000 до Word XP и в течение нескольких
месяцев держать обе версии программного обеспечения доступными для инсталляции. В этом
случае можно сконфигурировать, какая из двух версий приложения будет устанавливаться, когда
пользователь начнет его установку через активацию расширения файла. Для этого в редакторе
Group Policy Object Editor обратитесь к окну Software Installation Properties (рвойства
инсталляционных программ) в разделе Computer Configuration или User Configuration. Выберите
вкладку File Extensions (Расширения файла) (см. рис. 12-10). При активизации расширения файла
будет установлено приложение, которое указано первым в списке.
РИС. 12-10. Конфигурирование активизации расширения файла
Удаление программного обеспечения через групповые
политики
Групповая политика может использоваться не только для установки приложения, но и для его
удаления. Имеются три опции удаления программного обеспечения с помощью групповой
политики.
1. Удаление программного обеспечения в качестве предварительного шага перед установкой
более новой версии того же программного обеспечения.
2. Удаление программного обеспечения, когда пользователь или компьютер выведены за
пределы области управления.
3. Удаление программное обеспечение при удалении пакета программ.
Первые две опции обсуждались ранее в этой главе. Последняя опция требует некоторого
объяснения. Когда вы удаляете пакет программ из объекта GPO, существует возможность выбора
способа управления программным обеспечением, установленным под управлением этого объекта
GPO. Щелкните правой кнопкой мыши на пакете программ, находящемся в списке в Software
Installation (Инсталляция программ), выберите All Tasks (Все задачи), а затем выберите Remove
(Удалить). На рисунке 12-11 показано диалоговое окно, которое появляется при выборе удаления
инсталляционного пакета. Если будет выбрана опция Immediately Uninstall The Software From
Users And Computers (Деинсталлировать программное обеспечение у пользователей и на
компьютерах), то программное обеспечение будет деинсталлироваться при следующей
перезагрузке компьютера или при следующем входе пользователя в систему. Если будет выбрана
опция Allow Users To Continue To Use The Software, But Prevent New Installations (Разрешить
пользователям продолжать использование программного обеспечения, но предотвратить новые
инсталляции), приложение не будет удалено с рабочих станций, но пользователи больше не
смогут установить приложение, используя этот GPO-объект.
Рис. 12-11. Конфигурирование удаления программного обеспечения при удалении пакета
программ
Использование групповых политик для
конфигурирования инсталлятора Windows
Поскольку большинство приложений, которые вы будете устанавливать с помощью групповых
политик, будут использовать технологию инсталлятора Windows, вам, возможно, понадобится
сконфигурировать установку приложений, имеющих Windows Installer. Active Directory Windows
Server 2003 имеет несколько опций, предназначенных для этого. Большинство параметров
настройки можно сконфигурировать, открыв объект GPO в редакторе объектов групповой
политики и развернув Computer Configuration (Конфигурация компьютера). Далее выберите
Administrative Templates (Административные шаблоны), потом выберите Windows Components
(Компоненты Windows), затем - Windows Installer (Инсталлятор Windows) (см. рис. 12-12).
Некоторые параметры настройки расположены в другом месте: User Configuration\ Administrative
Templates\Windows Components\Windows Installer. В таблице 12-2 объясняется назначение этих
опций.
Рис. 12-12. Конфигурирование
компьютерных объектов
параметров
настройки
инсталлятора
Windows
Табл. 12-2. Опции параметров настройки групповой политики для инсталлятора Windows
Параметр настройки
Disable Windows Installer (Отключение
инсталлятора
Windows)
(Только
конфигурация компьютера)
Объяснение
Используется
для
включения
или
отключения инсталляции программного
обеспечения с помощью инсталлятора
Windows. Если вы включите политику, то
затем можно или полностью отключить
инсталлятор Windows, или включить его для
всех приложений, или отключать для тех
приложений, которые не распределяются
через групповые политики.
Always Install With Elevated Privileges
(Всегда устанавливать с привилегиями)
(Компьютерная
и
пользовательская
конфигурация)
Используется
для
разрешения
пользователям устанавливать приложения,
которые требуют доступа к каталогам или
ключам системного реестра, к которым
пользователь обычно не может обращаться.
Включение этой опции означает, что
инсталлятор Windows будет использовать
системные разрешения для установки
программного обеспечения.
Используйте эту опцию для того, чтобы
отключить
заданное
по
умолчанию
поведение
инсталлятора
Windows
создающего
файлы,
которые
могут
использоваться для ««тката» неполной
инсталляции.
Используется для отключения кнопки
Browse (Обзор), когда пользователь захочет
установить новую функцию, используя
инсталлятор Windows. Включение этой
опции отключает кнопку Browse, т.е.
пользователь может пользоваться только
источниками,
сконфигурированными
администратором.
Prohibit Rollback (Запретить «откат»)
(Компьютерная
и
пользовательская
конфигурация)
Remove Browse Dialog Box For New
Source (Удаление диалогового окна обзора
для
нового
источника)
(Только
компьютерная конфигурация)
для
Prohibit
Patching
(Запретить Используется для запрета установки
использование
«заплат»)
(Только пользователями заплат к программам,
компьютерная конфигурация)
использующим
инсталлятор
Windows.
Включение этой опции обеспечивает
усовершенствованную защиту, потому она
не позволяет пользователям устанавливать
заплаты, которые могли бы изменять
системные файлы.
Disable IE Security Prompt For Windows Используется
для
отключения
Installer Scripts (Отключить IE подсказку предупреждений, которые получает клиент,
защиты для сценариев инсталлятора устанавливая программное обеспечение
Windows)
(Только
компьютерная через интерфейс браузера типа Microsoft
конфигурация)
Internet Explorer. Эту опцию можно
использовать, если большая часть вашего
программного обеспечения распределена
через веб-сайт.
Enable User Control Over Installs Используется для увеличения степени
(Включить контроль пользователя над контроля за инсталляцией приложения. Если
инсталляцией) (Только компьютерная опция включена, процесс инсталляции будет
конфигурация)
останавливаться на каждом экране, чтобы
пользователь мог изменять параметры
установки.
Enable User To Browse For Source While Используется для поиска альтернативных
Elevated (Дать возможность пользователю инсталляционных
источников,
если
просмотреть источники, если он имеет приложение
устанавливается
с
повышенные
разрешения)
(Только повышенными разрешениями.
компьютерная конфигурация)
Enable User To Use Media Source While
Elevated (Дать возможность пользователю
использовать
сменные
носители
информации, если он имеет повышенные
разрешения)
(Только
компьютерная
конфигурация)
Используется для разрешения использовать
сменные носители информации в качестве
инсталляционного
источника,
если
приложение
устанавливается
с
повышенными разрешениями.
Enable-User To Patch Elevated Products
(Дать
возможность
пользователю
применять
заплаты,
если имеются
повышенные
разрешения)
(Только
компьютерная конфигурация)
Используется для разрешения пользователю
устанавливать заплаты, когда инсталляция
выполняется
с
повышенными
разрешениями.
Allow Admin To Install From Terminal
Services
Session
(Разрешить
администратору инсталляцию из сеанса
службы
терминала)
(Только
компьютерная конфигурация)
Используется
для
разрешения
администраторам
службы
терминала
устанавливать
и
конфигурировать
программное обеспечение, используя сеанса
службы терминала.
Cache Transforms In Secure Location On
Workstation
(Кэши-ровать
файл
преобразования в безопасном месте на
рабочей станции) (Только компьютерная
конфигурация)
Используется для кэширования файлов
преобразования,
используемых
при
инсталляции настраиваемых приложений на
местной
рабочей
станции.
Файл
преобразования
требуется
для
восстановления
или
повторения
инсталляции программ.
Logging
(Регистрация)
компьютерная конфигурация)
(Только Используется
для
конфигурирования
инсталлятора Windows на увеличение
заданного
по
умолчанию
уровня
регистрации
процесса
инсталляции
программ.
Prohibit
User
Installs
(Запретить Используется для управления тем, будут ли
пользовательские инсталляции) (Только установлены приложения, назначенные
компьютерная конфигурация)
пользователю. Если опция включена, можно
сконфигурировать параметры установки
так,
чтобы
устанавливались
только
приложения, назначенные для компьютеров.
Эта установка может быть полезна, если
компьютер подсоединен к интернету или
является общедоступным компьютером.
Применяется только к клиентам, имеющим
инсталлятор Windows v2.0 (или более
позднюю версию).
Turn Off Creation Of System Restore
Checkpoints
(Выключите
создание
контрольных
точек
восстановления
системы)
(Только
компьютерная
конфигурация)
Используется для изменения заданного по
умолчанию поведения на компьютерах с
системой Windows XP Professional, где
перед любой инсталляцией автоматически
создается контрольная точка System Restore
(Восстановление системы).
Search Order (Порядок поиска) (Только Используется для изменения заданного по
пользовательская конфигурация)
умолчанию порядка поиска, при котором
инсталлятор
Windows
ищет
инсталляционные файлы. По умолчанию
инсталлятор Windows будет просматривать
сеть,
затем
—
съемные
носители
информации, а затем - URL интернета.
Prevent Removable Media Source For Any
Install (Запретить использование съемных
носителей информации для инсталляции)
(Только пользовательская конфигурация)
Используется для запрета^использова-ния
инсталлятора Windows для установки
приложений
со
съемных
носителей
информации.
Планирование распределения программ через
групповые политики
Использование групповых политик для управления программным обеспечением может уменьшить
усилия, необходимые для распределения и обслуживания программного обеспечения на
компьютерах клиента. Однако извлечение выгоды от применения этого инструмента усложняется
для большой компании с несколькими различными программными конфигурациями
пользовательских рабочих столов. Развертывание групповых политик для наиболее эффективного
управления программным обеспечением требует осторожного планирования. Этот раздел
посвящен тому, что вы должны учитывать при выполнении этого планирования.
Один из факторов, который вы должны учитывать при развертывании приложений, необходимость публикации приложения пользователям или компьютерам. Если большинство
компьютеров являются общедоступными и каждый пользователь требует специфического пакета
программ, то вы должны назначить политику на компьютеры. При назначении политики
программное обеспечение полностью установится на рабочую станцию при ее следующей
перезагрузке и будет доступно всем пользователям. Назначение пакета программ на компьютеры
обеспечивает больше опций для управления пропускной способностью сети. Используя эту
опцию, можно сконфигурировать групповую политику в течение дня, а затем попросить
пользователей (или использовать удаленный инструмент), чтобы они перезагрузили рабочие
станции в конце обычного рабочего времени.
Если какой-либо пакет программ требуется только нескольким пользователям, то более
эффективным является назначение или публикация приложения для учетных записей
пользователей. В некоторых случаях пакет программ должен быть распределен пользователям,
принадлежащим нескольким OU. Наилучшим способом для этого является назначение групповой
политики на высшем уровне иерархии Active Directory с последующей фильтрацией применения
объекта GPO с помощью групп защиты.
Другое важное решение, которое надо принять при планировании распределения программ
состоит в том, сколько объектов GPO следует использовать. Одна из крайностей состоит в том,
что можно использовать один объект GPO для распределения всего программного обеспечения в
пределах определенного контейнера, это улучшит выполнение входа в систему клиента, но может
создать сложные конфигурации GPO-объектов. Другая крайность состоит в использовании
множества GPO-объектов, каждый из которых распределяет единственное приложение. Это может
оказать влияние на процесс входа в систему клиентов, потому что компьютер должен читать
множество объектов GPO. Компании используют разнообразные подходы для решения этой
проблемы. Типичный подход состоит в том, чтобы создать один объект GPO для установки
стандартного набора приложений, в которых каждый нуждается, и которые редко изменяются.
Дополнительные объекты GPO создаются для приложений, которые часто обновляются (типа
антивирусного программного обеспечения), и для приложений, которые используются
маленькими группами пользователей.
Возможно, что вам придется планировать распределение программного обеспечения по сети с
низкой пропускной способностью. Во многих компаниях имеются удаленные офисы или
удаленные пользователи, которые подключаются к Active Directory, используя медленные сетевые
подключения. По умолчанию компонент групповой политики, предназначенный для
распределения программного обеспечения, не применяется, если клиент соединяется через сетевое
подключение со скоростью передачи меньше 500 Кб/с. Если рабочие станции вашей сети обычно
подключены к локальной сети (LAN) и только иногда соединяются через медленное сетевое
подключение, это заданное по умолчанию значение приемлемо. Однако если ваши сетевые
клиенты соединяются через медленное сетевое подключение, их нужно подготовить, выполнив
дополнительное конфигурирование.
Одна из опций оставляет заданное по умолчанию распределение программного обеспечения
таким, как оно есть, инициируя полную инсталляцию программного обеспечения, когда
пользователь соединяется с LAN. Используйте эту опцию, если клиенты изредка соединяются с
вашей LAN. Если клиенты никогда не соединяются с LAN, для распределения программного
обеспечения используйте средства вне Active Directory. Например, используя сменные носители
информации или через безопасный веб-сайт, если у клиентов есть быстрое подключение к
интернету.
У большинства крупных компаний есть способы автоматизировать процесс, предназначенный для
компоновки рабочих станций. Компании используют технологии клонирования диска или службу
удаленной инсталляции (RIS — Remote Installation Services) для быстрой компоновки
стандартного рабочего стола пользователей. Можно использовать эту технологию в комбинации с
групповыми политиками, чтобы оптимизировать распределение программного обеспечения.
Например, если вы используете инструмент клонирования диска для компоновки рабочих станций
клиентов, скомпонуйте компьютер клиента, а затем используйте групповую политику для
установки стандартного набора приложений на рабочей станции. Когда это изображение будет
развернуто на рабочих станциях, ими можно управлять с помощью групповых политик. Если вы
используете RIS для инсталляции программ на клиентских компьютерах, включите управляемое
приложение в RIS-изображение для каждого отдела.
Наиболее важный шаг в подготовке к использованию групповой политики для развертывания
программного обеспечения состоит в тщательном тестировании каждого программного
распределения перед его развертыванием. Большинство компаний поддерживают лабораторию
для тестирования распределений, которая содержит рабочие станции, представляющие аналоги
тех рабочих станций, которые имеются в производственной среде. Вы можете создать
испытательную OU в Active Directory и переместить сюда учетные записи этих компьютеров и
некоторые тестируемые учетные записи пользователей. Используйте эту испытательную среду для
проверки каждого программного распределения.
Службы обновления программного обеспечения альтернатива обновлению компьютеров.
Одной из критических задач, выполняемых сетевым администратором, является обслуживание
заплат на уровне операционной системы для всех компьютеров в сети. Из-за масштаба
необходимых для этого усилий некоторые компании вообще не обновляют настольные
компьютеры или применяют только наиболее критические модификации. Они обычно обновляют
все серверы, но для защиты рабочих станций полагаются на брандмауэр интернета и антивирусное
программное обеспечение. Некоторые компании применяют другой подход и конфигурируют все
компьютеры своих клиентов на использование сайта Windows Update (Обновление Windows) для
загрузки заплат. Эти компании, возможно, даже позволяют обычным деловым пользователям
самим управлять применением заплат. Использование групповых политик может облегчить
управление заплатами, но оно не решит проблему. Компания Microsoft создает .msi файлы только
для существенных модификаций типа сервисных пакетов, так что управление заплатами попрежнему связано с большим количеством работы. Поэтому компания Microsoft создала службу
обновления программного обеспечения (Software Update Service — SUS) как альтернативное
средство, предназначенное для развертывания обновлений на рабочих станциях.
Служба SUS состоит из серверного компонента и компонента клиента. Чтобы включить службу
SUS, вы должны установить серверный компонент на компьютере с системой Windows 2000 или
Windows Server 2003. Затем сконфигурируйте серверный компонент службы для загрузки всех
критических модификаций с сайта Windows Update. Эта загрузка может быть автоматической или
ручной. Как только модификации будут загружены и проверены, можно сконфигурировать службу
для распределения модификаций всем клиентам. Клиентский компонент службы SUS можно
устанавливать на компьютерах с системами Windows 2000 Professional и Server (с Service Pack 2
или более поздним), Windows XP Professional или Windows Server 2003. Системы Windows 2000
Service Pack 3 и Windows XP Professional Service Pack 1 включают клиентский SUS-компонент.
Компьютер клиента использует клиентский компонент службы SUS для соединения с серверным
компонентом службы SUS, чтобы загрузить и установить заплаты.
Служба SUS может управляться с помощью групповых политик. В редакторе объектов групповой
политики используйте параметры настройки, расположенные в разделе Computer Configuration,
выберите Administrative Templates, далее выберите Windows Components, а затем — Windows
Update для конфигурирования управления автоматическими модификациями на рабочих станциях
(см. рис. 12-13). Вы можете использовать групповые политики для определения того, с каким SUSсервером будут соединяться рабочие станции.
Рис. 12-13. Конфигурирование клиентского компонента для автоматических модификаций
Чтобы узнать больше об использовании службы SUS и ее интеграции с групповой политикой,
загрузите
с
веб-сайта
Microsoft
статью,
расположенную
по
адресу
http://www.microsoft.com/windows2000/ windowsupdate/sus/susoverview.asp.
Ограничения на использование групповых
политик для управления программным
обеспечением
Хотя групповые политики обеспечивают мощные механизмы управления программным
обеспечением на компьютерах клиентов, у этой технологии имеются некоторые ограничения. Эти
ограничения очевидны при сравнении групповых политик с инструментами управления
программным обеспечением Microsoft Systems Management Server (SMS) или LANDesk от Intel.
Одно из ограничений для многих компаний состоит в том, что групповые политики могут
использоваться только для распределения программного обеспечения на клиентские компьютеры
с системами Windows 2000 или Windows XP Professional. Хотя большинство компаний перешло на
самые последние операционные системы, многие все еще используют системы Windows NT
Workstation, Windows 95 или Windows 98 на клиентских компьютерах. Если такие компании
захотят использовать
групповые политики для распределения программного обеспечения клиентам с более новыми
системами, они все равно будут поддерживать альтернативный метод для более старых клиентов.
Более существенное ограничение состоит в недостатке гибкости групповых политик при
назначении графика инсталляции программного обеспечения. Приложения не публикуются на
рабочей станции до тех пор, пока пользователь не сделает новый вход в систему или пока не
произойдет перезагрузка компьютера. Инструментальные средства распределения программ,
обладающие полным набором функций, такие как SMS, имеют и другие опции. Например, вы
можете сконфигурировать SMS или LANDesk для запуска компьютера в течение ночи, используя
технологию wake-on-LAN, устанавливающую программное обеспечение с последующим
выключением компьютера. Распределение программного обеспечений может быть намечено на
любое время в течение дня, пользователю не обязательно даже выходить из системы, он может и
не знать, что идет распределение программного обеспечения.
Еще одно ограничение, связанное с использованием групповой политики, состоит в том, что она
не поддерживает возможностей мультиве-щания в сети. Большая часть сетевого трафика
представляет собой однонаправленный трафик, то есть трафик, который течет между двумя
определенными компьютерами. При мультивещании сервер выпускает один поток сетевого
трафика, а несколько клиентских компьютеров получают одни и те же данные. Поскольку каждое
распределение программы инициируется действием клиента, то оно не может использовать
мультивещание. Использование мультивещания сохраняет высокую пропускную способность
сети. Например, если в вашей компании имеется несколько тысяч клиентов, и нужно распределить
срочную антивирусную модификацию, используя решение с однонаправленной передачей данных,
тем самым снизится пропускная способность даже самой быстрой сети. При использовании
мультивещания все сетевые клиенты получат модификацию, хотя пакет программ посылается
только один раз.
И еще одно ограничение состоит в недостаточном количестве функций, сообщающих о
результатах. Служба Active Directory не позволяет определить, успешно ли установлено
программное обеспечение на рабочей станции или нет, она не сообщает об успехах или отказах
инсталляции.
При использовании групповой политики для распределения программного обеспечения нельзя
указать, какие именно клиенты должны получить пакет программ иным способом, кроме как через
назначение объекта GPO на контейнерном уровне или через фильтрацию, основанную на группах.
Более полнофункциональные инструменты распределения программного обеспечения (например,
SMS и LANDesk) создают опись всех клиентских компьютеров. Она включает также такие
компьютерные атрибуты, как объем пространства жесткого диска, характеристики процессора и
оперативной памяти, а также список программного обеспечения, установленного на компьютерах. Используйте эту опись для указания того, какие
клиентские компьютеры получат определенный пакет программ. Например, вы могли бы
устанавливать самую последнюю версию приложения Office только на рабочих станциях,
имеющих необходимое пространство на жестком диске и достаточный объем оперативной памяти.
Проблемы, связанные с распределением программ, возникают также при наличии
«отсоединенных» клиентов. В некоторых компаниях имеется много клиентских компьютеров,
соединяющихся с корпоративной сетью только иногда и только через модемную связь или VPNподключение. Полнофункциональный инструмент распределения программного обеспечения
осуществляет многостороннюю поддержку таких клиентов. Одна из опций состоит в обеспечении
веб-сайта, который используется для установки программного обеспечения и управления им после
инсталляции. Другая опция — разумное управление распределением программ, когда клиент
находится на связи. Например, можно распределять программное обеспечение всем клиентам с
модемной связью, но строго ограничивать объем пропускной способности сети, которую
использует этот процесс. Процесс распределения программ может также обнаруживать нарушения
сетевого подключения и при следующем соединении пользователя с сетью запускать
распределение программ с того места, в котором подключение было нарушено.
Таким образом, использование групповых политик для управления программным обеспечением не
поддерживает желаемый набор функций. Однако для маленьких компаний и компаний среднего
размера, у которых на большинстве компьютеров установлены системы Windows 2000 или
Windows XP Professional, групповые политики могут решить многие проблемы, связанных с
распределением программного обеспечения. И цена использования групповых политик
безусловно оправдана, если сравнить ее с довольно дорогими затратами по лицензированию
клиентов при использовании других инструментальных средств.
Резюме
Групповые политики в Active Directory Windows Server 2003 обеспечивают мощные
инструментальные средства для развертывания и управления программным обеспечением на
рабочих станциях. Используя групповые политики и технологию инсталлятора Windows, вы
можете развертывать программное обеспечение на рабочих станциях, а затем управлять этим
программным обеспечением в течение всего жизненного цикла программы. В этой главе
рассмотрены вопросы, касающиеся использования групповых политик для развертывания
программного обеспечения и управления им.
Глава 13. Использование групповых политик
для управления компьютерами
В главе 12 описан один из спосебов использования групповой политики в службе каталога Active
Directory системы Microsoft Windows Server 2003 для управления вашей сетью — использование
групповой политики для управления программным обеспечением, которое устанавливается на
рабочих станциях вашей сети. Использование централизованного инструмента для управления
программным обеспечением клиентов дает существенную выгоду для организации. Однако с
управлением компьютерами клиентов связано много хлопот, включающих защиту настольных
компьютеров, управление профилями пользователей и данными, блокировку пользовательских
рабочих столов для уменьшения количества изменений, которые могут делать пользователи на
своих компьютерах. В этой главе объясняется, как использовать групповые политики для
управления компонентами рабочих столов компьютеров клиентов.
В больших организациях администрирование компьютеров клиентов - это одна из самых
серьезных задач в управлении. Установка и развертывание компьютеров требуют больших
усилий, но и управление рабочими станциями после развертывания является не менее трудоемкой
задачей. В крупных компаниях имеется целый сервисный отдел, посвященный решению проблем,
с которыми сталкиваются пользователи. Часто этот отдел подкрепляется группой поддержки
рабочих станций, которая может посещать компьютеры клиентов, если проблему нельзя решить
по телефону.
Звонок в сервисный отдел обычно связан с тем, что пользователь сделал что-то такое, что вызвало
проблемы. Пользователь может изменить установки системы так, что больше не сможет
соединяться с сетью. Другие звонки связаны с конфигурированием рабочих станций, например,
параметры настройки были неправильно заданы при установке рабочей станции или приложения и
после инсталляции должны быть изменены. Групповые политики могут использоваться для
уменьшения количества таких звонков, позволяя централизовано управлять компьютерами вашей
компании. Вы можете использовать групповые политики, чтобы запретить пользователям
изменения на своих рабочих станциях, нарушающие правильное функционирование. Можно также использовать групповые политики для
централизованного конфигурирования многих параметров настройки рабочих станций вашей
компании.
Практический
опыт.
Индивидуальные
предпочтения
против
централизованного управления компьютерными рабочими столами
В большинстве случаев управление рабочими столами пользователей требует
равновесия
между
централизованным
управлением
компьютерами
и
удовлетворением потребностей пользователей, которые хотят иметь полный
контроль над своими рабочими столами. Если реализовать все опции управления,
обсуждаемые в этой главе, можно полностью блокировать пользовательские
рабочие столы, чтобы пользователи гарантировано не смогли сделать никаких
неправомочных изменений. Многие администраторы думают, что предоставление
пользователям возможности изменять параметры настройки означает только то, что
они сконфигурируют что-либо неправильно, и это приведет к увеличению объема
работы для администратора. Многие пользователи, с другой стороны, во всех
попытках управления их рабочими столами видят вторжение в их личное
пространство. С точки зрения пользователя рабочая станция является частью
индивидуальной рабочей среды, и любые попытки управления этой рабочей средой
вызывают решительное сопротивление.
Решение о правильном балансе между централизованным управлением рабочими
столами и контролем их со стороны конечного пользователя в разных компаниях
различно. Некоторые компании уже имеют опыт использования системной политики
в Microsoft Windows NT 4 или групповых политик в Active Directory Microsoft Windows
2000, и их конечные пользователи уже приучены к некоторому уровню блокирования
рабочего стола. В таких компаниях можно вводить новые ограничения без особого
беспокойства. Однако во многих компаниях раньше не существовало никаких
ограничений, поэтому первая же попытка реализовать ограничение вызовет
активное сопротивление.
Для большинства компаний наилучшим подходом к управлению рабочими столами
является медленный старт и создание благоприятного первого впечатления. Это
означает, что вы используете групповые политики для решения проблем,
раздражающих конечных пользователей. Если вы покажете конечным
пользователям, что управление рабочими столами фактически сделает их работу
более легкой, они более охотно согласятся на дополнительное управление. С
другой стороны, если первые результаты вызовут сотни звонков в сервисный отдел,
то вы лишитесь поддержки для реализации любого управления рабочими столами.
Другим важным компонентом для успешной реализации групповых политик
является помощь со стороны управленческого аппарата. В большинстве компаний дирекция идет навстречу всему, что уменьшает стоимость
управления рабочими станциями. Если вы сумеете доказать, что уменьшение
стоимости работ является конечным результатом вашей реализации управления
рабочими столами, то вы наверняка получите поддержку дирекции в улаживании
жалоб, поступающих от конечных пользователей, не желающих, чтобы их рабочими
столами управляли.
Управление рабочими столами с
использованием групповых политик
Служба Active Directory Windows Server 2003 имеет множество опций групповых политик,
которые мржно использовать для конфигурирования компьютеров. Параметры настройки
расположены в нескольких местах в структуре Group Policy. Поэтому перед началом детального
описания некоторых из параметров настройки в этом разделе дается краткий обзор доступных
параметров настройки. На рисунке 13-1 показано расширенное представление опций управления
рабочими столами в пределах отдельного объекта групповой политики GPO. В таблице 13-1 дано
краткое пояснение для контейнеров высшего уровня.
Рис. 13-1. Контейнеры высшего уровня в Default Domain Policy (Заданная по умолчанию
политика домена)
Табл. 13-1. Контейнеры высшего уровня в заданной по умолчанию политике домена
Контейнер
Дочерние контейнеры
Содержимое
высшего уровня
Computer
Software Settings (Параметры Содержит параметры настройки для
Configuration
and настройки
программного пакетов программного обеспечения,
User Configuration обеспечения)
используемых для распределения
(Компьютерная и
программ.
пользовательская
конфигурация)
Computer
Windows
Settings\
Scripts Содержит сценарии запуска и
Configuration
and (Параметры
настройки выключения для компьютеров и
User Configuration Windows\Сценарии)
сценарии входа в систему и выхода
(Компьютерная и
из нее для пользователей.
пользовательская
конфигурация)
Computer
Windows
Settings\
Security Содержит параметры настройки,
Configuration
and Settings (Параметры настройки используемые
для
User Configuration Windows\
Параметры конфигурирования
защиты
(Компьютерная и настройки защиты)
компьютера. Некоторые параметры
пользовательская
настройки
специфичны
для
конфигурация)
доменного уровня, а некоторые
можно установить на контейнерном
уровне. Большинство параметров
настройки
защиты
конфигурируются
в
разделе
компьютерной конфигурации
User Configuration Windows
Settings\
Folder
(Пользовательская Redirection
(Параметры
конфигурация)
настройки Windows \Переназначение папки)
Содержит параметры настройки,
которые
переадресовывают
пользовательские папки, такие как
папки
My
Documents
(Мои
документы), на сетевой ресурс.
User Configuration Windows
Settings\
Remote Содержит
отдельную
опцию
(Пользовательская Installation Services (Параметры конфигурации
для
службы
конфигурация)
настройки Windows \Служба удаленной инсталляции (RIS).
удаленной инсталляции)
User Configuration Windows
Settings\
Internet
(Пользовательская Explorer
Maintenance
конфигурация)
(Параметры
настройки
Windows\Обслуживание
Internet
Explorer)
Содержит параметры настройки для
управления
конфигурацией
приложения
Microsoft
Internet
Explorer
на
пользовательских
рабочих столах.
Computer
Administrative
Templates
Configuration
and (Административные шаблоны)
User Configuration
(Компьютерная
конфигурация
и
пользовательская
конфигурация)
Содержит большое количество
конфигурационных
параметров
настройки,
которые
могут
использоваться
для
конфигурирования
системного
реестра компьютера.
Последующий материал содержит детальное описание многих контейнеров высшего уровня.
Управление данными пользователей и
параметры настройки профиля
Одна из проблем, с которыми сталкиваются сетевые администраторы, состоит в управлении
пользовательскими данными и пользовательскими профилями. Данные, с которыми работают
пользователи, часто являются критическими с точки зрения бизнеса, они должны
соответствующим образом защищаться и управляться. В большинстве случаев они должны
храниться централизовано с поддержкой регулярного резервного копирования. Имеется много
способов обращения с этими данными. Обычно данные всех пользователей хранятся на сетевом
ресурсе. Однако многие пользователи хранят некоторые данные, которые нужны в случае
отсутствия сети, на своих компьютерах, особенно на портативных
Другой аспект управления рабочими столами компьютеров состоит в управлении
пользовательскими профилями, которые часто больше беспокоят конечных пользователей, чем
администраторов. Некоторые пользователи проводят значительное время, конфигурируя свои
приложения и рабочие столы для удовлетворения собственных предпочтений. Для этих
пользователей конфигурация рабочего стола очень важна, и они хотят, чтобы данный рабочий
стол появлялся независимо от того, с какого компьютера они войдут в систему.
До появления Active Directory основным методом управления пользовательскими данными и
параметрами настройки была реализация пользовательских профилей. Некоторые компании
реализовывали роу-минговые профили пользователя, которые сохранялись на сетевом ресурсе и были доступны пользователям с любой рабочей станции в организации. Некоторые
компании налагают ограничения на профили своих пользователей, реализуя принудительные
профили. Используя принудительные профили, администратор может создать стандартный
профиль для пользователя или группы пользователей, а затем сконфигурировать профиль так,
чтобы пользователи не могли его изменять.
Роуминговые и принудительные пользовательские профили могут быть реализованы, используя
Active Directory, а некоторые из параметров настройки, предназначенные для управления ими,
могут быть сконфигурированы через групповые политики. В дополнение к пользовательским
профилям Active Directory обеспечивает также переназначение папки для управления
пользовательскими данными и параметрами настройки, что создает существенные выгоды для
пользовательских профилей.
Управление пользовательскими профилями
Пользовательский профиль содержит всю конфигурационную информацию для рабочего стола
пользователя. Эта информация включает содержание поддерева HKEY_CURRENT_USER в
системном реестре (хранящееся как файл Ntuser.dat), который включает параметры настройки
конфигурации для приложений и рабочего стола. Кроме того, профиль содержит папки My
Documents (Мои документы), Start Menu (Меню Пуск), Desktop (Рабочий стол) и Application Data
(Данные приложений). На рисунке 13-2 показано содержимое пользовательского профиля на
компьютере с системой Windows Server 2003.
Рис. 13-2. Пользовательский профиль содержит все пользовательские
настройки рабочего стола и папки для пользовательских данных
параметры
Пользовательский профиль создается на каждом компьютере, когда пользователь первый раз
входит в систему. Начальный профиль основан на заданном по умолчанию пользовательском
профиле, который хранится в папке %systemdrive%\Documents And Settings. Когда пользователь
выходит из системы, профиль пользователя, включая любые сделанные им изменения к заданному
по умолчанию, сохраняется в папке с именем, под которым пользователь входил в систему, в
папке Documents And Settings (Документы и параметры настройки). Когда пользователь снова
войдет на тот же самый компьютер, его профиль будет найден, и пользователю будет представлен
тот же самый рабочий стол, который был перед выходом из системы. Некоторые компании
реализовали роу-минговые профили пользователя. Роуминговые пользовательские профили
хранятся на сетевом ресурсе, чтобы быть доступными пользователю, когда он перемещается
между компьютерами. Когда пользователь, для которого сконфигурирован роуминговый профиль,
впервые входит на компьютер, этот профиль загружается с сетевого ресурса и применяется к
компьютеру. Когда пользователь выходит из системы, сделанные им изменения к
пользовательскому профилю копируются назад на сетевой ресурс. Копия профиля также
кэшируется на местной рабочей станции. Если пользователь уже входил на рабочую станцию
прежде, то временная метка профиля, хранящегося на местной рабочей станции, сравнится с
временной меткой профиля, хранящегося на сетевом ресурсе. В системах Windows 2000 и
Windows XP Professional временная метка на индивидуальных файлах используется для
определения того, какой из файлов профиля является более новым. Если профиль, хранящийся на
сервере, новее, чем местный профиль, то весь профиль будет скопирован с сервера на местную
рабочую станцию. Включить роуминговый профиль пользователя можно, конфигурируя путь
профиля на вкладке Profile (Профиль) окна Properties (Свойства) учетной записи пользователя в
инструменте Active Directory Users And Computers (Пользователи и компьютеры Active Directory).
Некоторые компании реализуют принудительные профили. В большинстве случаев
принудительные профили используются в комбинации с роуминговыми профилями для создания
стандартной настольной конфигурации для группы пользователей. Например, вы имеется группа
пользователей, исполняющих одни и те же функции и нуждающихся в очень ограниченной
конфигурации рабочего стола. Если вы являетесь членом групп Account Operators (Операторы
учетных записей), Domain Admins (Администраторы домена) или Enterprise Admins
(Администраторы предприятия), вы можете создать один стандартный рабочий стол для этой
группы пользователей и использовать принудительные профили, чтобы помешать изменению
конфигурации. Чтобы включить опцию принудительных профилей, сначала создайте желательную
стандартную конфигурацию рабочего стола. Затем сохраните все содержимое пользовательского
профиля на сетевом ресурсе и переименуйте файл
Ntuser.dat в Ntuser.man. Далее сконфигурируйте всех необходимых пользователей, чтобы этот
профиль был их роуминговым профилем. Когда пользователи войдут в сеть, им будет представлен
стандартный профиль, и поскольку этот профиль является принудительным, они не смогут
сохранить никакие изменения, сделанные к нему.
Роуминговые пользовательские профили существуют и в Windows Server 2003. Если в вашей
компании реализованы роуминговые или принудительные пользовательские профили, можно
продолжать их использование. Для управления пользовательскими профилями используются
групповые политики. Большинство пользовательских параметров настройки профиля
расположено в папке Computer Configuration\ Administrative Templates\ System\User Profiles.
Дополнительные параметры настройки расположены в подпапке того же названия в разделе
параметров User Configuration. В таблице 13-2 объясняются опции конфигурации.
Табл. 13-2. Конфигурирование пользовательских профилей с помощью редактора объектов
групповой политики
Опция конфигурации
Пояснение
Do Not Check For User
Ownership Of Roaming
Profile
Folders
(He
проверять
право
собственности
пользователя на папки
роу-минговых профилей)
Используется для конфигурирования действий в
случае, если папка роуминговых профилей
пользователя уже существует и рабочие станции
модернизированы до Microsoft Windows 2000 Service
Pack 4 или Microsoft Windows XP Professional Service
Pack. Эти новые сервисные пакеты увеличивают
заданную по умолчанию защиту пользовательских
профилей. Включение этой опции означает, что
поддерживается более ранняя защита.
Используется для удаления в местном масштабе
кэшированной
копии
роумингового
профиля
пользователя, когда пользователь выйдет из системы.
Не включайте эту опцию, если вы используете
функцию обнаружения медленных связей в системах
Windows 2000 или Windows XP Professional, потому
что этой функции требуется локально кэшированная
копия пользовательского профиля.
Delete Cached Copies Of
Roaming Profiles (Удалить
кэширован-ные
копии
роуминго-вых профилей)
Do Not Detect Slow
Network Connections (He
обнаруживать медленные
сетевые подключения)
Slow Network Connection
Timeout For User Profiles
(Лимит
времени
в
медленном
сетевом
подключении
для
пользовательских
профилей)
Wait For Remote User
Profile (Ждать удаленный
пользовательский
профиль)
Prompt User When Slow
Link
Is
Detected
(Предупредить
пользователя,
если
обнаружены медленные
связи)
Используется для предотвращения использования
функции обнаружения медленных связей при
конфигурировании
способов
управления
роуминговыми профилями пользователя. Если опция
включена, то роуминговые профили пользователей
будут загружаться всегда, независимо от скорости
передачи в сети.
Используется для определения медленного сетевого
подключения. Если опция включена, то заданное по
умолчанию определение медленного сетевого
подключения - менее 500 Кб/с, или (для
компьютеров, не использующих IP-адрес) если
серверу на ответ требуется более 120 мс.
Используется для того, чтобы всегда загружать
роуминговый профиль пользователя с сервера. Если
опция включена, рабочая станция загрузит
пользовательский профиль, даже если будет
обнаружено медленное сетевое подключение.
Используется для предупреждения об обнаруженном
медленном сетевом подключении, чтобы дать
пользователю возможность выбора между загрузкой
местного профиля или профиля, расположенного на
сервере. Если опция не включена, местный профиль
будет загружен без уведомления пользователя.
Timeout For Dialog Boxes Используется для конфигурирования времени
(Лимит
времени
для ожидания система после того, как пользователь будет
диалоговых окон)
предупрежден об обнаружении медленного сетевого
подключения. Если лимит времени истекает, то
применяется заданное по умолчанию значение или
действие, связанное с диалоговым окном.
Log Users Off When
Roaming
Profile
Fails
(Предотвратить
вход
пользователей,
если
роуминговый профиль не
доступен)
Используется для запрета входа пользователей в
систему, если роуминговый профиль недоступен.
Если опция не включена, будет загружен профиль,
котируемый в местном масштабе, если он доступен.
(Иначе загружается местный заданный по умолчанию
пользовательский профиль.)
Maximum
Retries
To
Unload And Update User
Profile
(Максимальное
количество
повторных
попыток для выгрузки и
обновAdd The Administrators
Security Group To Roaming
User Profiles (Добавьте
группу
безопасности
администраторов
к
роуминговым профилям
пользователей)
Используется для конфигурирования количества
попыток системы обновить файл Ntuser.dat, когда
пользователь выходит из системы и обновление
терпит неудачу. По умолчанию система будет
пробовать обновить файл один раз в секунду в
течение 60 с.
Используется
для
конфигурирования
административного доступа к пользовательским
профилям. По умолчанию в системах Windows 2000 и
Windows
XP
Professional
учетной
записи
пользователя дается полное управление профилем, а
администраторы не имеют никакого доступа
Prevent Roaming Profile
Changes From Propagating
To
The
Server
(Предотвратить
перемещение изменений
роумингового профиля на
сервер)
Only Allow Local User
Profiles (Разрешить только
местные пользовательские
профили)
Используется для конфигурирования действий при
выходе пользователя из системы. Если эта опция
включена, то роуминговый профиль на сервере не
модифицируется, когда пользователь выходит из
системы.
Connect Home Directory To
Root
Of
The
Share
(Подключить домашний
каталог к корню ресурса)
(в
разделе
User
Configuration)
Используется для конфигурирования отображения
домашнего диска так, как он был сконфигурирован в
Windows NT. Если опция включена, то домашним
диском' для всех пользователей будет сетевой ресурс,
на
котором
расположены
домашние
папки
пользователей. Если опция отключена (задано по
умолчанию), домашние диски б^удут отображать
специфичные для пользователя папки, а не ресурс
более высокого уровня.
Используется для конфигурирования того, будут ли
роуминговые профили пользователя скопированы с
сервера. Если опция включена, роуминговый
профиль пользователя не будет применяться
Limit
Profile
Size
(Ограничить
размер
профиля) (в разделе User
Configuration)
Используется для ограничения размера роумингового
профиля
пользователя,
а
также
для
конфигурирования того, какое предупреждение
получит пользователь, если размер его профиля будет
превышен.
Exclude Directories In Используется для предотвращения включения
Roaming
Profile определенных
пользовательских
каталогов
в
(Исключить каталоги из роуминговый профиль пользователя.
роуминговых профилей)
(в
разделе
User
Configuration)
Как показано в таблице 13-2, Active Directory Windows Server 2003 имеет мощные возможности
для управления роуминговыми профилями пользователя. Они используются для проектирования
специфичных конфигураций пользователей в вашей компании. Например, для большинства
пользователей вашей компании, которые входят в домен через быстрые сетевые подключения,
можно изменить некоторые параметры настройки роуминговых профилей, таких как ограничение
размера профиля, но принять остальные значения заданными по умолчанию. Для тех
пользователей, которым требуются специальные конфигурации рабочего стола, могут
понадобиться особенные параметры настройки, например, запрет на загрузку роуминговых
профилей пользователя или обязательная загрузка профиля. Для тех пользователей, которые
входят в сеть через медленные сетевые подключения, нужно сконфигурировать параметры
медленных сетевых подключений. Создавая структуру организационных единиц (OU), которая
соответствует требованиям пользовательских профилей, можно реализовать особые конфигурации
роуминговых профилей пользователя.
Роуминговые пользовательские профили полезны для компаний, в которых пользователи не
пользуются все время одним и тем же компьютером. Когда функция роуминговых профилей
включена, рабочая среда пользователя остается одной и той же, независимо от того, в каком месте
пользователь входит в систему. Однако роуминговые профили пользователя имеют некоторые
ограничения. Самая большая проблема состоит в том, что пользовательский профиль может стать
очень большим. Например, пользователь хранит большинство своих документов в папке My
Documents (Мои документы) или на рабочем столе. Временные интернет-файлы могут вырастать
до размеров, составляющих десятки мегабайт. Все эти файлы сохраняются в пользовательском
профиле. Проблема заключается в том, что весь профиль должен быть скопирован на локальную
рабочую станцию всякий раз, когда пользователь входит в систему, и компьютер обнаруживает,
что профиль, находящийся на сервере, новее, чем профиль, находящийся на локальной рабочей
станции. Если пользователь делает изменения профиля, то при выходе профиль копируется назад
на сервер. Этот процесс создает существенный объем сетевого трафика.
Переназначение папки
Active Directory Windows Server 2003 обеспечивает переназначение папки как способ получения
выгоды от использования роуминговых профилей при уменьшении пропускной способности сети.
Если включена функция переназначения папки, то папки, которые обычно являются частью
местного пользовательского профиля, перемещаются из местного профиля и сохраняются на
сетевом ресурсе. Например, одна из типичных папок, которая конфигурируется для
переназначения папки, — это папка My Documents. Во многих компаниях эта папка является логической
папкой, использующейся для переадресования, так как она представляет собой заданное по умолчанию
место для хранения пользовательских файлов. Когда эта папка конфигурируется для переназначения, вы
сохраняете ее на сетевом ресурсе, где централизованно поддерживается ее резервное копирование и
одновременно обслуживается среда конечного пользователя. Переназначение папки полностью прозрачно
для конечного пользователя, единственный способ узнать, что папка была переадресована, - посмотреть
свойства папки My Documents.
Другая причина переназначения папки состоит в том, что вы можете использовать эту опцию для
развертывания стандартной среды рабочего стола вместо использования принудительных пользовательских
профилей. Например, можно переадресовать папки Start Menu или Desktop на сетевой ресурс, затем
сконфигурировать группу пользователей, использующих одну и ту же папку. Давая всем пользователям
разрешения Read (Чтение) к этим папкам, но не давая разрешения Write (Писать), вы можете
сконфигурировать стандартный рабочий стол для группы пользователей.
Можно переназначить четыре различные папки в Active Directory Windows Server 2003: Application Data,
Desktop, My Documents и Start Menu Переназначение папки конфигурируется в редакторе объектов
групповых политик выбором User Configuration (Конфигурация пользователя), далее - Windows Settings
(Параметры настройки Windows), затем - Folder Redirection (Перенаправление папаки). Папки перечислены
таким образом, что можно сконфигурировать каждую папку отдельно.
Чтобы сконфигурировать папку My Documents для переназначения, найдите объект My Documents в папке
Folder Redirection (Переназначение папки), щелкните на нем правой кнопкой мыши, а затем выберите
Properties (Свойства). Первая вкладка листа Properties объекта - это вкладка Target (Цель) (см. рис. 13-3).
На этой вкладке имеется три конфигурационные опции. По умолчанию опция Setting (Параметры
установки) установлена как Not Configured (He конфигурирована), т.е. папка не переадресована на сетевой
ресурс. Две другие опции, предназначенные для конфигурирования, следующие.
• Basic - Redirect Everyone's Folder To The Same Location (Основная -переадресовать все папки в
одно и то же место). Используется в том случае, если вы хотите создать одно место, куда будут
переадресованы все папки. Например, папки всех пользователей, на которых действует эта
•
политика, будут расположены на сетевом ресурсе \ \servernam е \sharenam е.
Advanced - Specify Locations For Various User Groups (Расширенная -указать местоположение для
различных групп пользователей). Используется для конфигурирования альтернативных
местоположений для переадресованной папки в зависимости от того, какой группе Active
Directory принадлежит пользователь. Если опция выбрана, можно
альтернативное целевое место расположения папки для каждой группы.
назначать
Рис. 13-3. Конфигурирование целевого места расположения папки при ее переназначении
Совет. Нельзя использовать опцию Advanced для назначения альтернативных мест
расположения папки для индивидуальных учетных записей пользователя. Помните, что эта
групповая политика применяется только к учетным записям пользователя, которые находятся в
контейнере, в котором вы конфигурируете групповую политику. Если вы конфигурируете опцию
Advanced, чтобы переадресовать групповую папку в определенное место, установка применится
только к тем учетным записям пользователей данной группы, которые расположены в данном
контейнере. Если группа содержит пользователей из других контейнеров, переназначение папки к
ним применяться не будет.
Как только выбраны параметры настройки для переадресования папок, можно сконфигурировать
целевое место расположения папки. Имеется несколько опций, предназначенных для выбора места
хранения папки.
• Redirect To The User's Home Directory (Переадресовать в основной каталог
пользователя). Используется для переадресации папки My Documents в основной
(домашний) каталог пользователя, который определен в свойствах учетной записи
пользователя. Используйте эту опцию, только если вы уже создали основной каталог. Если
основной каталог не создан, конфигурирование этой опции его не создаст. Опция доступна
только для папки My Documents.
• Create a Folder For Each User Under The Root Path (Создать папку для каждого
пользователя в корневом каталоге). Используется для указания корневого каталога, в
котором будут храниться папки. Когда вы выбираете эту опцию, папка будет создана в
корневом каталоге каждого пользователя. Имя папки будет основано на переменной входа
в систему %username %.
• Redirect To The Following Location (Переадресовать по следующему адресу).
Используется для указания корневого каталога и места расположения папки для каждого
пользователя. Вы можете использовать UNC-путь или путь к локальному диску.
Используйте переменную %username % для создания индивидуальных папок. Эта опция
используется также для переадресации нескольких пользователей к одной и той же папке.
Например, если нужно сконфигурировать стандартное Start Menu для группы
пользователей, можно указать для всех один и тот же файл.
•
Redirect To The Local Userprofile Location (Переадресовать в место расположения
локального профиля пользователя). Эта установке является заданной по умолчанию
конфигурацией, если никакие политики не включены. После установки опции папки не
будут переадресовываться на сетевой ресурс.
Вы можете также сконфигурировать другие параметры настройки для переадресованных папок.
Чтобы сделать это, щелкните на вкладке Settings в окне Properties объекта (см. рис. 13-4).
Рис. 13-4. Конфигурирование параметров настройки переназначения папки
Вкладка Settings (Параметры настройки) имеет несколько опций конфигурации.
• Grant The User Exclusive Rights To foldername (Предоставить пользователю
исключительные права на имя папки). Предоставляет пользователю и системной учетной
записи полный контроль над папкой. Учетная запись Administrator (Администратор) не
будет иметь никакого доступа к этой папке. Если вы очистите флажок, то разрешения на
доступ к папке будут сконфигурированы на основе унаследованных разрешений.
• Move The Contents Of foldername To The New Location (Переместить содержимое папки
имя папки в новое место). Перемещает текущее содержимое переадресованной папки в
целевое место расположения. Если опция не выбрана, содержимое текущей папки не будет
скопировано в целевое место расположения.
• Policy Removal (Удаление политики). Используется для выбора действий в случае
удаления политики. Если вы примете заданную по умолчанию опцию Leave The Folder In
The New Location When Policy Is Removed (Оставить папку в новом месте, когда политика
удалена), то содержимое переадресованной папки не будет перемещено в локальный
пользовательский профиль, если политика удалена. Выбор опции Redirect The Folder Back
To The Local Userprof ile Location When Policy Is Removed (Переадресовать папку назад к
месту расположения локального профиля пользователя, когда политика удалена)
переместит содержимое папки, когда политика будет удалена.
• My Pictures Preferences (Предпочтения, касающиеся папаки My Pictures). Эта установка
используется для конфигурирования того, будет ли папка My Pictures включена в
переназначение папки My Documents.
Когда вы используете переназначение, чтобы переадресовать папку My Documents, содержимое
папки не копируется на сервер и обратно, как это делается в случае с роуминговыми
пользовательскими профилями. Содержимое папки расположено на сервере, как и любые другие
данные сетевого ресурса. Следовательно, часть содержимого папки пересекает сеть только тогда,
когда пользователь открывает файл в папке. Это справедливо и для папки Desktop (Рабочий стол).
Если на рабочем столе имеется большой файл, то этот файл хранится на сетевом ресурсе и
копируется на компьютер клиента, когда пользователь открывает файл. Тот факт, что данные
пересекают сеть только по требованию, может значительно улучшать выполнение входа в
систему, особенно если у вас имеется большое количество пользователей, одновременно
загружающих свои роуминговые профили.
Одно из преимуществ использования пользовательских профилей для сохранения папок типа
папки My Documents состоит в том, что после начального входа в систему на рабочей станции
копия пользовательского профиля всегда сохраняется в местном масштабе, т.е. если сервер
профиля недоступен или рабочая станция отключена от сети, то профиль, укомплектованный
папкой My Documents, будет доступен на рабочей станции. Когда рабочая станция повторно
связывается с сетью, изменения, сделанные к пользовательскому профилю, копируются на сервер.
Вы можете достичь этого, комбинируя переназначение папки с автономными файлами.
Автономные файлы доступны на рабочих станциях с системами Windows 2000, или более
поздними, и могут использоваться для поддержки синхронизированной копии общей папки между
локальной рабочей станцией и сетевым ресурсом. По умолчанию переадресованные папки
сконфигурированы для автономного использования с клиентами, имеющими систему Windows XP
Professional. Если имеются клиенты с системой Windows 2000, можно щелкнуть правой кнопкой
мыши на папке My Documents, расположенной на рабочем столе, и выбрать Make Available Offline
(Сделать доступным в автономном режиме). Включение автономных файлов означает, что
переадресованная папка будет скопирована клиентам, делая папку доступной даже в том случае,
если сетевое место, в которое была переадресована папка, недоступно.
Конфигурирование параметров настройки
защиты с помощью групповых политик
Один из критических моментов в управлении пользовательским рабочим столом состоит в
конфигурировании на них защиты. Поддержание согласованной конфигурации защиты для тысяч
рабочих столов почти невозможно без центрального управления. Для обеспечения
централизованного управления могут использоваться групповые политики. Некоторые параметры
настройки защиты, сконфигурированные с помощью групповых политик, могут быть реализованы
только на уровне домена, некоторые - на любом контейнерном уровне.
Конфигурирование политики безопасности на уровне домена
Account Policies (Политики учетных записей), расположенные в контейнере Computer Conf
iguration\ Windows Settings\Security Settings, содержат параметры настройки защиты, которые
могут быть сконфигурированы только на уровне домена. Account Policies включает три группы
политик: Password Policy (Политика паролей), Account Lockout Policy (Политика блокировки
учетных записей) и Kerberos Policy (Политика Kerberos) (см. рис. 13-5). Эти политики, за
исключением Kerberos Policy, применяются ко всем пользователям в домене, независимо от того, с
какой рабочей станции пользователи вошли в сеть. Политика Kerberos Policy применяется только
на тех компьютерах домена, на которых выполняются системы Windows 2000, Windows XP Professional или Windows Server 2003.
Рис. 13-5. Отображение политик безопасности уровня домена Политика паролей
Опции конфигурации политики паролей содержат параметры настройки для истории пароля, его
длины и сложности. В таблице 13-3 описывается каждая установка.
Табл. 13-3. Политики паролей
Параметры
установки Описание
конфигурации
Значение по умолчанию
Enforce Password History Определяет количество новых
(Предписанная история уникальных паролей, которые
пароля)
должны быть введены, прежде
чем
пользователь
сможет
повторно использовать старый
пароль. Возможные значения:
от 0 до 24
Maximum Password Age Определяет количество дней, в
(Максимальное
время течение
которых
может
использования пароля)
использоваться пароль, прежде
чем пользователь должен будет
его
изменить.
Чтобы
сконфигурировать пароль для
бесконечно
долгого
использования,
установите
число дней на 0. Возможные
значения: от 0 до 999
24 пароля запоминается
для контроллеров домена
и
компьютеров-членов
домена;
0
для
автономных серверов.
Minimum Password Age Определяет количество дней, в
(Минимальное
время течение которых пароль должен
использования пароля)
использоваться,
прежде
чем пользователь сможет его
изменить. Чтобы позволить
немедленное изменение пароля,
установите это значение на 0.
Возможные значения: от 0 до
998
1 день для контроллеров
домена и компьютеровчленов домена; 0 -для
автономных серверов.
Minimum Password Length Определяет
наименьшее
(Минимальная
длина количество
символов,
пароля)
требуемых для пароля. Если
никакого пароля не требуется,
установите значение на 0.
Возможные значения: от 0 до
14
Passwords Must Meet Увеличение сложности пароля
Complexity Requirements за
счет
предписания
:
(Пароли
должны условия, что пароль не должен
удовлетворять
содержать какую-либо часть
требованиям
имени пользователя этой
определенной сложности) учетной
записи,
должен
содержать по крайней мере 6
символов, содержать символы,
принадлежащие
трем
из
четырех перечисленных ниже
категорий:
английские
прописные буквы, английские
буквы
нижнего
регистра,
цифры от 0 до 10, специальные
символы (типа !, $,#)
7
символов
для
контроллеров домена и
компьютеров-членов
домена;
0
для
автономных серверов.
42 дня.
Включено
для
контроллеров домена и
компьютеров-членов
домена. Выключено для
автономных серверов.
Store Password Using
Reversible
Encryption
(Хранить
пароль,
используя
обратимое
кодирование)
Использование этой установки Заблокировано.
означает то же самое, что и
сохранение паролей в открытом
тексте.
Эта
политика
обеспечивает поддержку для
приложений, которые требуют
доступа
к
паролю
для
аутентификации.
Политика блокировки учетных записей
Опции конфигурации политики блокировки учетных записей содержат параметры настройки для
порога и продолжительности блокировки пароля, а также для повторной устаовки пароля. В
таблице 13-4 описаны все установки.
Табл. 13-4. Политики блокировки учетных записей
Параметры настройки Объяснение
конфигурации
Значение по умолчанию
Account
Lockout
Duration
(Продолжительности
блокировки
учетной
записи)
Никакого
значения.
Установите значение на
30 минут, если порог
блокировки
учетной
записи установлен на 1,
или больше.
Account
Threshold
блокировки
записи)
Lockout
(Порог
учетной
Reset Account Lockout
Counter After (Сброс
счетчика
блокировки
учетной записи)
Определяет количество минут, в
течение
которых
заблокированная учетная запись
остается заблокированной. После
указанного числа минут учетная
запись будет автоматически
разблокирована. Разблокировать
учетную
запись
должен
администратор, установив это
значение на 0. Любое значение,
отличное от нуля должно быть
равно или больше, чем значение,
установленное в опции Reset
Account Lockout Counter After.
Возможные значения: от 0 до
99999
Определяет
количество
неудавшихся попыток входа в
систему, которое позволяется
сделать, прежде чем учетная
запись
пользователя
будет
заблокирована.
Значение
0
означает, что учетная запись
никогда не будет заблокирована.
Возможные значения: от 0 до 999
Определяет
число
минут,
которые должны пройти после
неудавшейся попытки входа в
систему, прежде чем счетчик
неудачных входов в систему
будет сброшен на 0. Любое
значение, отличное от нуля,
должно быть равно или меньше,
чем значение, заданное для
Account
Lockout
Duration.
Возможные значения: от 1 до
99999
0 недопустимых попыток
входа в систему.
Никакого
значения.
Установите значение на
30 минут, если порог
блокировки
учетной
записи установлен на 1
или больше.
Политики Kerberos
Опции конфигурации политик Kerberos содержат параметры настройки билета Kerberos TicketGranting Ticket (TGT), сроков службы билета сеанса и параметров настройки временной метки. В
таблице 13-5 описаны все установки.
Табл. 13-5. Политики Kerberos
Параметры настройки Объяснение
конфигурации
Enforce User Logon
Restrictions (Предписать
выполнение
ограничений на вход
пользователей
в
систему)
Значение по
умолчанию
Требует, чтобы центр распределения Включено.
ключей (Key Distribu tion Center - KDC)
подтверждал каждый запрос на билет
сеанса по отношению к политике User
Rights (Права пользователя) целевого
компьютера
Maximum Lifetime For
Service
Ticket
(Максимальный
срок
пригодности
билета
службы)
Определяет максимальное время в минутах, 600 минут (10 часов).
в течение которого билет службы пригоден
для обращения к ресурсу. Возможные
значения: 10, вплоть до значений, меньших
или равных значению в минутах параметра
Maximum Lifetime For User Ticket, но не
превышающих 99999. Значение 0 приведет
к тому, что время пригодности билета
станет бесконечным, значение Maximum
Lifetime
For
User
Ticket
будет
установлено^на 1, a значение Maximum
Lifetime For User Ticket Renewal будет
установлено на 23
Maximum Lifetime For Определяет максимальное время в часах, в 10 часов.
User
Ticket течение которого может использоваться
(Максимальный
срок билет TGT. Когда это время истекает,
службы
рабочая станция должна получить новый
пользовательского
билет TGT. Возможные значения: от 0 до
билета)
99999. Значение 0 указывает, что срок
службы билета не будет истекать, а опция
Maximum Lifetime For User Ticket Renewal
будет установлена на значение Not Defined
Maximum Lifetime For
User Ticket Renewal
(Максимальный срок, в
течение
которого
пользовательский билет
может
быть
возобновлен)
Определяет время в днях, в течение 7 дней.
которого билет TGT пользователя может
быть возобновлен вместо получения нового
билета. Значение 0 указывает, что
возобновление билета заблокировано
Maximum Tolerance For
Computer
Clock
Synchronization
(Максимальный допуск
в
синхронизации
компьютерных часов)
Определяет различие между временем на 5 минут.
компьютере клиента и временем на часах
сервера в минутах, которое допускает
протокол Kerberos. Обратите внимание, что
эта установка переустанавливается на
заданное по умолчанию значение при
каждом перезапуске компьютера
Политики учетных записей должны быть установлены на уровне Domain Security Policy (Политики
безопасности домена) на контроллере домена. Эти параметры настройки затрагивают всех
пользователей и все компьютеры в домене. Хотя эти политики могут быть сконфигурированы на
уровне OU, они не будут влиять на тех, кто входит в систему домена. Если вы устанавливаете
политику для OU, она затронет только местную базу данных безопасности для компьютеров,
входящих в эту OU. Когда эти политики сконфигурированы на уровне OU, они применяются
только тогда, когда пользователи входят в систему в местном масштабе. Когда пользователи
входят в домен, политики домена всегда подменяют локальную политику.
Конфигурирование других параметров безопасности
В дополнение к политике безопасности уровня домена групповые политики обеспечивают
большое количество связанных с безопасностью параметров настройки. Как и в случае с
политиками Account Policies, многие из этих параметров настройки конфигурируются при выборе
контейнера Computer Conf iguration\Windows Settings\Security Settings. Некоторые дополнительные
параметры настройки конфигурируются при выборе контейнера User Configuration\Windows
Settings\Security Settings. На рисунке 13-6 показаны опции, находящиеся в каждой из папок
Security Settings (Параметров настройки безопасности), в таблице 13-6 они суммированы для
каждого заголовка.
Рис. 13-6. Дополнительные политики, имеющиеся в папке Security Settings
Использование групповых политик для настройки безопасности компьютеров вашей сети
значительно облегчает создание и поддержание безопасной сетевой среды. Намного легче
конфигурировать безопасность, используя групповые политики, чем иметь дело с каждой рабочей
станцией индивидуально. Все, что вы должны сделать, - это создать централизованные политики
безопасности, сконфигурировать их в объекте GPO и связать его с контейнерным объектом Active
Directory. В следующий раз, когда будет применяться объект GPO, защита будет
сконфигурирована на всех компьютерах в контейнере. Использование групповых политик
облегчит постоянное управление параметрами настройки защиты для ваших компьютеров.
Параметры настройки защиты, которые устанавливаются политиками, непрерывно обновляются.
Даже если пользователь изменит конфигурацию защиты на рабочей станции, политика будет
повторно применена в следующем цикле обновления. Изменить параметры настройки защиты
просто, потому что вы можете изменить групповую политику и применить параметры настройки
ко всем компьютерам, на которые воздействует данная политика.
Табл. 13-6. Параметры настройки защиты в групповых политиках
Опция конфигурации
Local
Policies\Audit
Policy
(Локальные
политики\Политика
аудита)
Local
Policies\User
Rights
Assignment
(Локальные
политики\Назначение
прав
пользователей)
Пояснение
Используется для конфигурирования параметров
настройки аудита. Можно устанавливать политику
аудита для таких опций, как действия по управлению
учетными записями, события входа в систему,
изменения политик, использование привилегий и
системных событий.
Используется
для
конфигурирования
прав
пользователей
на
компьютерах,
подверженных
воздействию этой политики. Можно устанавливать
разнообразные политики, включая конфигурирование
локального входа в систему, доступа к компьютеру из
сети, резервного копирования файлов и папок, входа в
систему для служебных целей и т.п.
Local
Policies\Security
Options
(Локальные
политики\Опции
безопасности)
Используется
для
конфигурирования
опций
безопасности
для
компьютеров,
на
которые
воздействует эта политика. Можно конфигурировать
переименование
учетной
записи
локального
администратора, управление установкой принтера,
установкой драйверов, не имеющих подписи,
возможностью хранения паспорта Microsoft .NET на
рабочих станциях и т.п.
Event Log (Журнал Используется для конфигурирования параметров
регистрации событий) журнала регистрации событий для всех компьютеров,
на которые воздействует данная политика. Можно
конфигурировать максимальный размер журнала,
разрешение на просмотр, сохранение всех журналов.
Restricted
Groups Используется для ограничения членства локальных
(Ограниченные группы) групп
на
компьютерах,
которые
повержены
воздействию данной политики. Эта опция обычно
используется для конфигурирования членства в группе
локальных администраторов на компьютерах с
системами Windows 2000 или более поздних. Если эта
опция используется для конфигурирования членства
локальной группы, то все пользователи или группы,
которые являются частью локальной группы, но не
входят в список членов, подверженных влиянию этой
политики, будут удалены при следующем обновлении
политики.
System
Services Используется
для
управления
службами
на
(Системные службы)
компьютерах:
для
определения
автоматически
запускаемых службы или для выключения служб.
Registry
реестр)
(Системный Используется для конфигурирования защиты на ключах
системного реестра. Вы можете добавить любой ключ
системного реестра к политике, а затем применит
определенную защиту к этому ключу.
File
System(Файловая Используется для конфигурирования защиты на файлах
система )
и папках. Можно добавить любые файлы или папки к
политике, а затем применить управление доступом и
аудит для этих объектов файловойсистемы.
Wireless Network (IEEE
802.11)
Policies
(Политика
беспроводных сетей)
Public
Key
Policies
(Политика
открытых
ключей). Эта установка
включена как в раздел
Computer Configuration,
так и в раздел User
Configuration.
Раздел
User
Configuration
включает только опцию
Enterprise
Trust
(Доверительные
отношения
предприятия).
IP Security Policies On
Active
Directory
(domainname) (Политика
IP безопасности в Active
Directory)
Используется для создания беспроводных сетевых
политик, которые затем могут использоваться для
управления
требованиями
безопасности
для
компьютеров, использующих беспроводные сетевые
подключения.
Используется
для
конфигурирования
политик,
связанных с цифровыми сертификатами и с
управлением сертификатами. Можно также создавать
агентов восстановления данных, использующихся для
восстановления файлов, которые были зашифрованы на
локальных рабочих станциях с помощью системы
шифрования файлов (Encrypting File System - EFS).
Используется для конфигурирования политик IPбезопасности
(IP Security
- IPSec).
Можно
сконфигурировать политику, точно определяющую,
какой сетевой трафик должен быть защищен с
помощью IPSec, на каком компьютере она должна
использоваться в обязательном порядке.
Примечание. Политики Software Restriction (Ограничения программного обеспечения) включены в
раздел Security Settings как для параметров настройки User Configuration, так и для Computer
Configuration. Они будут подробно рассмотрены в следующем разделе.
Политики ограничения программного обеспечения
В Active Directory Windows Server 2003 имеется один специальный тип конфигурации защиты,
которого не было в Active Directory Windows 2000 -это политики ограничения программного
обеспечения. Одно из самых больших беспокойств связано с пользователями, запускающими
неизвестное или%е пользующееся доверием программное обеспечение. Во многих случаях
пользователи запускают потенциально опасное программное обеспечение непреднамеренно.
Например, миллионы пользователей запускали вирусы или устанавливали приложения типа
«троянский конь», не имея ни малейших намерений выполнять опасное программное обеспечение.
Политика ограничения программного обеспечения предназначена для предотвращения таких
случаев.
Политика ограничения программного обеспечения защищает ваших пользователей от выполнения
опасных программ, определяя, какие приложения можно выполнять, а какие -нет. Эта политика
позволяет выполняться любому программному обеспечению, за исключением того, которое вы
специально заблокируете. Или можно определить политику, не позволяющую выполнять никакое
программное обеспечение за исключением того, которое вы явно позволите выполнять. Хотя
вторая опция более безопасна, усилия, необходимые для перечисления всех приложений, которым
позволяется выполняться в среде Сложного предприятия, слишком серьезны. Большинство
компаний выберут первую опцию, разрешающую выполнение всего программного обеспечения и
блокирующую только избранное программное обеспечение. Однако если вы развертываете среду с
высоким уровнем безопасности, примените более безопасную опцию.
При создании политики ограничения программного обеспечения можно сконфигурировать пять
типов правил, характеризующих приложения, на которые воздействует данная политика.
• Hash rules (хэш-правила). Хэш-правило — это криптографический идентификатор,
который уникально идентифицирует определенный файл приложения независимо от
имени файла или его местоположения. Если в папке Security Levels (Уровни безопасности)
был выбран объект Unrestricted (He ограничен), и нужно ограничить выполнение
определенного приложения, создайте хэш-правило, используя политику ограничения
программного обеспечения. Когда пользователь попытается выполнить это приложение,
рабочая станция проверит его хэш-значение и предотвратит выполнение. Если политика
блокирует выполнение всех приложений, используйте хэш-правило для допуска
определенных приложений.
• Certificate rules (Правила сертификата). Можно создавать правила сертификата так, что
критерием выбора приложений будет сертификат издателя программного обеспечения.
Например, если у вас есть собственное приложение, которое вы сами разработали,
назначьте сертификат этому приложению, а затем сконфигурируйте правило ограничения
программного обеспечения, состоящее в доверии соответствующему сертификату.
• Path rules (Правило путей). Можно создавать правила, основанные на пути,
характеризующем место, где расположено выполняемое приложение. Если вы выберете
папку, то это правило будет распространяться на приложения, расположенные в этой
папке. Можно использовать переменные среды (типа %systemroot %), чтобы определить
путь и подстановочные знаки (типа *.vbs).
• Registry path rules (Правило пути системного реестра). Можно создавать правила,
основанные на месте расположения системного реестра, которые использует данное
приложение. Каждое приложение имеет заданное по умолчанию место расположения в
пределах системного реестра, где оно хранит специфическую для приложения
информацию, позволяющую создавать правила, блокирующие или разрешающие
выполнение приложений, основанные на этих ключах системного реестра. В меню не
имеется никакой опции, специфичной для системного реестра, предназначенной для
создания правил пути системного реестра, но опция New Path Rule (Новое правило пути)
позволяет создавать этот уникальный набор правил. При создании новой политики
ограничения программного обеспечения формируются четыре заданных по умолчанию
правила пути системного реестра. Эти правила конфигурируют неограниченную
программную групповую политику для приложений, расположенных в системной
корневой папке и в заданной по умолчанию папке программных файлов.
• Internet zone rules (Правило зон интернета). Заключительный тип правил основан на
интерне-зоне, из которой было загружено программное обеспечение. Например, нужно
сконфигурировать правило, позволяющее выполнение всех приложений, загруженных из
зоны Trusted Sites (Доверенные сайты), или правило, предотвращающее выполнение
любого программного обеспечения, загруженного из зоны Restricted Sites (Ограниченные
сайты).
Если вы сконфигурируете свое ограничение так, что все приложения должны выполняться, за
исключением указанных приложений, то эти правила определят те приложения, которые не будут
выполняться. Если вы создаете более ограничительное правило, блокирующее все приложения, то
оно определяет те приложения, которым позволено выполняться.
Политики ограничения программного обеспечения могут быть определены для компьютеров в
разделе Computer Configuration\Windows Settings\Security Settings, для пользователей - в разделе
User Configuration\Windows Settings\Security Settings. По умолчанию в Active Directory не ус
танавливается политики ограничения программного обеспечения. Чтобы создать политику,
щелкните правой кнопкой мыши на папке Software Restrictions Policies (Политики ограничений
программного обеспечения) и выберите New Software Restrictions Policy (Новая политика). В
результате будет создана заданная по умолчанию политика (см. рис. 13-7).
Рис. 13-7. Создание новой политики ограничения программного обеспечения
Папка Security Levels (Уровни безопасности) используется для определения заданного по
умолчанию уровня защиты. Внутри папки имеются два объекта: Disallowed (Запрещенный) и
Unrestricted (Неограниченный). Если нужно сконфигурировать защиту так, чтобы выполнялись
все приложения за исключением специально указанных, щелкните правой кнопкой мыши на
объекте Unrestricted и выберите Set As Default (Установить по умолчанию). Если вы хотите задать
более ограничительную установку, щелкните правой кнопкой мыши на Disallowed и установите
его заданным по умолчанию.
Папка Additional Rules (Дополнительные правила) используется для конфигурирования правил
ограничений программного обеспечения. Чтобы сконфигурировать правило, щелкните правой
кнопкой мыши на папке Additional Rules и выберите тип правила, которое вы хотите создать.
Например, для нового хэш-правила выберите New Hash Rule. Чтобы создать новое хэш-правило,
щелкните на кнопке Browse (Обзор) и найдите файл, который вы хотите идентифицировать хэшзначением. При выборе файла хэш-значение файла будет создано автоматически. Затем можно сконфигурировать, будет ли это приложение разрешено для выполнения или
заблокировано (см. рис. 13-8).
Рис. 13-8. Конфигурирование хэш-правила
Объект Enforcement (Принуждение) используется для определенного указания приложения, на
которое оказывается воздействие. Можно сконфигурировать правила, которые будут применяться
или ко всем приложениям, или ко всем приложениям, кроме DLL. Правила могут применяться или
ко всем пользователям, или ко всем пользователям, кроме местных администраторов.
Объект Designated File Types (Отмеченные типы файлов) определяет все расширения файлов,
которые рассматриваются как расширения исполняемых файлов и поэтому подчиняются этой
политике. Вы можете добавлять или удалять файловые расширения из этого списка.
Объект Trusted Publishers (Доверенные издатели) используется для определения того, кто может
выбирать, является ли издатель доверенным или нет. Вы можете указать всех пользователей,
только локальных администраторов или только администраторов предприятия. Вы можете также
сконфигурировать, должна ли рабочая станция проверять факт возможной отмены действия
сертификата перед выполнением приложения.
Шаблоны защиты
Как показано в предыдущих разделах, существуют сотни опций, предназначенных для
конфигурирования безопасности с использованием
групповых политик в сети Windows Server 2003. На первый взгляд можете показаться, что
количество опций непомерно велико. Трудно даже определить, с него начать конфигурирование
опций безопасности. К счастью, компания Microsoft разработала шаблоны защиты, которые
позволяют справиться с этой задачей.
Шаблоны защиты предопределяют наборы конфигураций защиты, которые вы можете применять
к компьютерам вашей сети. Вместо того чтобы просматривать каждый параметр защиты, можно
выбрать шаблон защиты, соответствующий тому, чего вы хотите добиться, а затем применить этот
шаблон, используя групповые политики. Например, если вы развертываете рабочие станции в
среде, где требуются строгие параметры настройки защиты, выберите один из шаблонов сильной
защиты. Если вы развертываете рабочие станции, которые нуждаются в меньшей защите, то для
этих рабочих станций выберите другой шаблон. Шаблоны защиты можно модифицировать. Если
вы не найдете шаблон защиты, который точно отвечает вашим потребностям, можно выбрать один
из предопределенных шаблонов, а затем изменить несколько параметров настройки.
Почти все параметры настройки защиты, сконфигурированные с помощью групповых политик,
могут быть сконфигурированы с использованием шаблон защиты. (Исключения составляют
политики IPSec и политики открытых ключей.) Вы можете создать ваш собственный шаблон
защиты или использовать один из предопределенных шаблонов. Если вы изменяете шаблон,
сохраните его так, чтобы он был доступен другим объектам GPO. При сохранении шаблона он
записывается в виде текстового .inf файла.
Предопределенные шаблоны защиты
Чтобы облегчить применение защиты, компания Microsoft создала разнообразные
предопределенные шаблоны защиты. Эти шаблоны сконфигурированы в соответствии с
категориями защиты, такими как default (заданная по умолчанию), secure (безопасная) и high
security (сильная защита). Шаблоны хранятся в папке %systemroot %\security\templates. Когда вы
устанавливаете на компьютере системы Windows Server 2003 или Windows XP Professional, к
компьютеру применяется шаблон Setup Security.inf. Этот шаблон различен для рабочих станций и
серверов, он также зависит от того, была ли ваша операционная система установлена как
обновление или как чистая инсталляция. Вы можете повторно применять шаблон защиты в любое
время после начальной инсталляции. Например, если изменяются параметры настройки защиты на
компьютере и нужно вернуть заданные по умолчанию параметры, можно повторно применить
этот шаблон. Он создается в процессе установки для каждого компьютера и должен применяться
только локально. Он содержит много параметров настройки, которые не конфигурируются в
составе какого-либо другого шаблона. Следовательно, не нужно использовать групповые политики для развертывания заданного по умолчанию шаблона. Их можно
использовать для развертывания дополнительных шаблонов защиты, которые могут изменять
некоторые параметры настройки, сконфигурированные в заданном по умолчанию шаблоне.
Если вы устанавливаете на компьютере системы Windows Server 2003 или Windows XP
Professional как обновление предыдущей операционной системы, заданные по умолчанию
шаблоны на компьютере не применяются. Это гарантирует, что после обновления будут
поддерживаться любые предыдущие конфигурации защиты.
Если заданные по умолчанию параметры настройки защиты не отвечают вашим потребностям,
примените другие конфигурации защиты, используя шаблоны. Они предназначены для
использования на тех компьютерах, где уже выполняются заданные по умолчанию шаблоны
защиты. Компания Microsoft включила следующие шаблоны в систему Windows Server 2003.
• Compatwsinf. Этот шаблон может применяться к рабочим станциям или серверам.
Windows Server 2003 сконфигурирован так, чтобы быть более безопасным, чем
предыдущие версии Windows. Это означает, что некоторые приложения, работающие в
предыдущих операционных системах, не будут выполняться в системах Windows Server
2003 или Windows XP Professional. Особенно справедливо это для несер-тифицированных
приложений, которым требуется доступ пользователя к системному реестру. Один из
способов выполнить такие приложения состоит в том, чтобы сделать пользователя членом
группы Power Users (Полномочные пользователи), которая имеет более высокий уровень
разрешений, чем обычный пользователь. Другой вариант состоит в том, чтобы ослабить
параметры настройки защиты на выбранных файлах и ключах системного реестра так,
чтобы группа Users (Пользователи) имела больше разрешений. Шаблон Compatws.inf
может использоваться для применения второго варианта. Применение этого шаблона
изменяет заданный по умолчанию файл и разрешения системного реестра так, чтобы
члены группы Users могли выполнять большинство приложений.
• Securewsinf и Securedcinf. Эти шаблоны обеспечивают усиленную защиту для политики
учетных записей, аудита и разрешения на доступ к системному реестру. Они ограничивают
использование NTLM-аутентификации, включая подписи на серверах пакетов блока
серверных сообщений (Server Message Block - SMB). Шаблон Securews.inf применим для
любой рабочей станции или сервера, а шаблон Securedcinf - только для контроллеров
домена.
• Hisecwsinf и Hisecdc.inf. Эти шаблоны последовательно увеличивают защиту, которая
создается другими шаблонами. Защита усиливается в областях, затрагивающих сетевые
протоколы связи. Они должны использоваться только в сетях, включающих компьютеры с
системами Windows Server 2003, Windows 2000 или Windows XP, и должны быть
протестированы и применены на всех компьютерах, чтобы убедиться, что все они
работают на одном и том же уровне защиты. Шаблон Hisecws.inf применяется для любой
рабочей станции или сервере, а шаблон Hisecdc.inf - только для контроллеров домена.
• DC security.inf. Этот шаблон применяется автоматически всякий раз, когда сервер-член
домена с системой Windows Server 2003 назначается контроллером домена. Он дает
возможность администратору повторно применить начальную защиту контроллера домена,
если возникает такая потребность.
• Notssid.inf. Этот шаблон удаляет идентификатор безопасности SID группы безопасности
Terminal Users (Пользователи терминала) из всех «тисков управления разграничительным
доступом DACL на сервере. Используется для повышения безопасности терминальных
серверов, потому что все пользователи терминального сервера будут иметь разрешения,
полученные через членство индивидуальных пользователей и групп, а не через общую
группу безопасности Terminal Users. Этот шаблон включен только в Windows Server 2003,
который сконфигурирован как терминальный сервер в режиме приложений.
• Rootsec.inf. Этот шаблон переустанавливает заданные по умолчанию разрешения
системной корневой папки и распространяет унаследованные разрешения на все подпапки
и файлы, расположенные в корневой папке. Применение этого шаблона не изменяет явные
разрешения, назначенные на файлы.
После того как вы решили, какой шаблон защиты использовать, ими можно управлять через
редактор объектов групповых политик. Если нужно установить один из настроенных шаблонов,
щелкните правой кнопкой мыши на папке Security Settings и выберите Import Policy (Импорт
политики). По умолчанию диалоговое окно откроет папку %systemroot %\Security\Templates, где
расположены предопределенные шаблоны защиты. Когда вы выберете один из шаблонов, он
загрузится в редактор объектов групповых политик. Затем можно применить эту групповую
политику к выбранному контейнерному объекту. Вы можете изменить импортированный шаблон
защиты так, чтобы он точно удовлетворял вашим требованиям. После этого экспортируйте
шаблон, чтобы он был доступен для импортирования в другую групповую политику.
Дополнительная конфигурация защиты и инструментальные средства
анализа
Система Windows Server 2003 обеспечивает инструментальные средства, которые могут
использоваться для управления шаблонами защиты. Одно из этих средств - оснастка Security
Configuration And Analysis (Конфигурация защиты и анализ), которая используется для создания или изменения существующих
шаблонов защиты. Затем шаблон загружается в оснастку Security Configuration And Analysis и
используется для анализа определенных компьютеров. Например, можно загрузить шаблон
сильной защиты, а затем проанализировать, имеются ли различия между шаблоном и текущей
компьютерной конфигурацией. На рисунке 13-9 показан пример результатов такого анализа.
Вы можете использовать этот инструмент и для применения шаблона защиты к компьютеру.
Щелкните правой кнопкой мыши на Security Configuration And Analysis и выберите Configure
Computer Now (Сконфигурировать компьютер сейчас). Все параметры настройки защиты на
компьютере будут изменены в соответствии с шаблоном защиты.
Рис. 13-9. Анализ конфигурации защиты компьютера с помощью оснастки Security
Configuration And Analysis
Оснастка Security Configuration And Analysis не предназначена для использования с групповыми
политиками. Этот инструмент использует те же самые предопределенные шаблоны защиты, что и
редактор объектов групповых политик, но он предлагает альтернативные средства для
развертывания шаблонов. Он предназначен прежде всего для использования с автономными
компьютерами.
Инструмент командной строки Secedit обеспечивает похожие функциональные возможности. С
помощью него можно анализировать параметры настройки компьютера, основанные на шаблоне, а
затем применять эти параметры. Одна из полезных функций инструмента командной строки
Secedit состоит в том, что вы можете использовать его для генерации отката конфигурации перед применением шаблона защиты. Эта опция обеспечивает
простой план возврата, если применяемый вами шаблон защиты окажется неподходящим.
Административные шаблоны
Одна из наиболее мощных опций, предназначенных для управления рабочими столами
пользователей с помощью групповых политик, состоит в использовании административных
шаблонов. Административные шаблоны применяются для конфигурирования параметров
настройки системного реестра на компьютерах с системами Windows 2000 Server, Windows 2000
Professional, Windows XP Professional или Windows Server 2003. Административные шаблоны
могут использоваться для конфигурирования большого количества разнообразных параметров
настройки, которых существует более 700. Их так много, что этот раздел, возможно, не сможет
охватить их все. В таблице 13-7 приводится краткий обзор только нескольких административных
шаблонов, чтобы вы почувствовали силу групповых политик. Административные шаблоны
имеются также и в Active Directory Windows 2000, но в Windows Server 2003 добавлено около 150
новых параметров настройки. В таблице 13-7 перечисляются также некоторые новые функции,
которые доступны в Active Directory Windows Server 2003 клиентам с Windows XP Professional.
Табл. 13-7. Образец административных шаблонов
Место
расположения
административного шаблона
Computer Conf iguration\
Administrative Templates\
System\Net Logon
Пояснение
Обеспечивает разнообразные параметры
настройки,
управляющие
местом
расположения клиентского компьютера и
кэшированием записей DNS контроллера
домена.
Computer Configuration\
Administrative Templates\
System\Remote Assistance
Обеспечивает параметры настройки для
функции Remote Assistance (Удаленная
помощь), имеющейся в системе Windows ХР
Professional.
Computer Conf iguration\
Обеспечивает параметры настройки, которые
Administrative Templates\ Windows могут использоваться для конфигурирования
Components\ Terminal Services
служб терминала Terminal Services на
сервере и на клиентах.
User Conf iguration\ Administrative Обеспечивает конфигурирование параметров
Templates\ Network\Network
настройки, предназначенных для управления
Connections
сетевыми связями, и ограничения доступа
пользователей к сетевым подключениям.
User Conf iguration\ Admin istrative
Templates\Control Panel
User Conf iguration\ Administrative
Templates\ Windows Components\
Internet Explorer
Обеспечивает конфигурацию частей панели
управления и возможности пользователей по
изменению параметров настройки через
панель управления.
Обеспечивает разнообразные параметры
настройки, предназначенные для управления
конфигурацией приложения Internet Explorer.
Требуется Internet Explorer версии 5.01 или
более поздней.
Дополнительная информация. Полный список всех параметров настройки групповых
политик смотрите по адресу http:// www.microsoft.com/windowsxp/prdytechinfo/administration/
policy /winxpgpset.xls.
Одно из усовершенствований Active Directory Windows Server 2003 — это улучшенная справка по
административным шаблонам. Теперь Active Directory поставляется с полным набором
справочных файлов, детализирующих каждую подборку административных шаблонов. Чтобы
получить доступ к расширенной справке по административным шаблонам, щелкните правой
кнопкой мыши на папке Administrative Templates в редакторе объектов групповой политики и
выберите Help (Справка). Затем выберите подходящую категорию административного шаблона.
На рисунке 13-10 показаны детали, касающиеся категории System (Система).
Системные политики в Windows NT обеспечивают функциональные возможности, подобные
функциональности административных шаблонов в Active Directory Windows Server 2003. Оба
инструмента позволяют делать изменения системного реестра в системе клиентов для
модификации конфигурации рабочей станции. Однако административные шаблоны обеспечивают
существенные преимущества по сравнению с системными политиками. Одно из самых больших
преимуществ состоит в том, что они не оставляют неудаляемых следов в системном реестре, как
это делают системные политики. Когда вы делаете изменение, используя системную политику,
оно записывается в системный реестр, и для того чтобы изменить эту установку снова, надо делать
это вручную или использовать системную политику. Если вы удалите системную политику,
изменения, сделанные к системному реестру, не будут удалены.
В Active Directory изменения системного реестра, сделанные административными шаблонами,
записываются в специальные подключи в системном реестре. Любые изменения, сделанные в
разделе User Configuration, записываются в ключе HKEY_CURRENT_USER и сохраняются в
папке \Software\Policies или \Software\Microsoft\Windows\CurrentVersion\Policies. Изменения,
сделанные в разделе Computer Configuration, сохраняются под теми же самыми подключами в
ключе НКЕY_LOCAL_MACHINE. При начальной загрузке компьютера или при входе
пользователей в систему загружаются обычные параметры настройки системного реестра, а затем
эти ключи исследуются на наличие дополнительных параметров настройки. Если эти параметры
будут найдены, то они загрузятся в системный реестр, записываясь поверх существующих
записей, если такие записи имеются. Если административный шаблон удален, или компьютер
(пользователь) будет перемещен в другой контейнер, где данный шаблон не применяется,
информация в ключах Policies удаляется. Это означает, что административные шаблоны больше не
применяются, но обычные параметры настройки системного реестра будут применяться.
Рис. 13-10. В Центре справки и поддержки имеется детальное описание каждой опции
административного шаблона
Административные шаблоны хранятся в нескольких текстовых файлах .adm. По умолчанию эти
файлы расположены в папке %systemroot %\Inf . В таблице 13-8 перечислены файлы
административных шаблонов, которые по умолчанию устанавливаются с системой Windows
Server 2003.
Табл. 13-8. Заданные по умолчанию шаблоны, загружаемые в систему Windows Server 2003
Административный
шаблон
Параметры настройки конфигурации
System.adm
Системные параметры настройки.
Inetres.adm
Параметры настройки приложения Internet
Explorer.
Параметры настройки приложения Microsoft
Windows Media Player.
Параметры настройки приложения Microsoft
NetMeeting.
Параметры настройки Windows Update.
Wmplayer.adm
Conf.adm
Wuau.adm
Файлы административных шаблонов состоят из записей, определяющих опции, которые доступны
через данный шаблон. Каждая запись в файле .adm выглядит так как показано на рисунке 13-11. В
таблице 13-9 поясняются записи, относящиеся к шаблону.
Рис. 13-11. Одна из записей в файле System.adm
Административные шаблоны для каждой групповой политики хранятся в папке Sysvol,
расположенной на контроллере домена, и реплицируются на все другие контроллеры домена в
домене. Шаблоны хранятся в файле Registry.pol, расположенном в папке %systemroot%\ SYSVOL\
sysvol\ domainname\ Policies\ GroupPolicyGUID\ Machine для компьютерной конфигурации и в
папке %systemroot%\ SYSVOL\ sysvol\ domainname\ Policies\ GroupPolicyGUID\ User для
пользовательской конфигурации.
Табл. 13-9. Компоненты опции шаблона
Компонент шаблона Объяснение
Policy
(Политика) Идентифицирует название политики.
Keyname (Ключ)
Идентифицирует ключ системного реестра,
который изменяется с помощью этой установки.
Компонент шаблона
Объяснение
Supported
(Поддержанный)
Идентифицирует поддерживаемые рабочие
станции или версии программного обеспечения,
необходимые для этой установки. Включают
поддержку Windows XP Professional, Windows
2000 или Windows 2000 с сервисным пакетом,
Microsoft Windows Media Player, версия 9.
Explain (Объяснение) Идентифицирует текст, который объясняет
параметры настройки политики. Фактический
текст дан ниже в файле .adm.
Part (Часть)
Идентифицирует записи, которые можно
сконфигурировать для этой политики.
Valuename (^Значение) Идентифицирует значение системного реестра,
которое будет заполнено информацией из этого
параметра настройки.
Административные шаблоны имеют большое количество административных опций. Только
анализ всех политик и выделение тех, которые необходимы для вашей организации, может стать
совершенно обескураживающей задачей. В большинстве случаев лучшим подходом к
использованию административных шаблонов является медленное и осторожное начало.
Возможно, вы захотите сконфигурировать некоторые основные параметры настройки, например,
запретить пользователям использование инструментов редактирования системного реестра и
изменение системы через большую часть панелей управления. Другой способ определить, какие
параметры настройки являются наиболее критическими для вашей организации, состоит в том,
чтобы проследить звонки, поступающие в сервисный отдел. Просматривая их, можно
идентифицировать многие проблемы. Затем можно определить, имеется ли такой
административный шаблон, который можно использовать для изменения этой установки или
предотвращения возможного ее изменения пользователями после того, как вы сами ее
сконфигурировали. Таким образом, вы сможете медленно внедрить политику административного
шаблона, которая сможет справиться с наиболее критическими проблемами, возникающими в
вашей сети.
Использование сценариев для управления
средой пользователя
Другой инструмент, который используется для управления пользовательскими рабочими столами
- это сценарии. Наиболее типичное использование сценариев состоит в создании простой рабочей
среды пользователя. Обычно сценарии входа в систему используются для отображения
сетевых дисков или принтеров. Они помогают упростить среду конечного пользователя.
Пользовательские сценарии входа в систему были доступны в системе Windows NT. Однако
использование сценариев в Active Directory Windows Server 2003 обеспечивает множество
существенных преимуществ по сравнению с Windows NT 4, включая следующие.
• Возможность назначать сценарии для запуска и завершения работы системы. В
Active Directory можное назначать выполнение сценариев на момент запуска и
выключения компьютеров. В системе Windows NT сделать это было очень трудно. Эти
сценарии выполняются в контексте безопасности учетной записи LocalSystem.
• Возможность назначать сценарии для пользовательского входа в систему и выхода из
системы. Система Windows NT обеспечивала только сценарии входа в систему. В Active
Directory можно также выполнять сценарии выхода из системы.
• Возможность назначать сценарии на контейнеры вместо отдельных индивидуумов.
Это одно из самых больших преимуществ использования Active Directory для назначения
сценариев. В Windows NT единственным вариантом выполнения сценариев являлось
назначение индивидуальных сценариев входа в систему на учетные записи пользователя.
Когда вы назначаете сценарий на контейнер в Active Directory, сценарий применяется ко
всем пользователям или компьютерам, находящимся внутри контейнера.
• Наличие «родной» поддержки для сценариев Windows Script Host. В системе Windows
NT большинство клиентов выполняли только пакетные файлы MS-DOS для реализации
сценариев входа в систему. В системах Windows Server 2003, Windows XP и Windows 2000
клиенты обеспечивают родную поддержку для сценариев Windows Script Host (WSH). При
конфигурировании пользовательских рабочих столов сценарии WSH оказываются гораздо
более гибкими и мощными. С помощью WSH сценарии могут использоваться в более
широких целях, чем простое отображение сетевых дисков. Служба Active Directory
Windows Server 2003 поддерживает личные сценарии входа в систему, назначенные на
индивидуальные учетные записи пользователя. Если в вашей сети имеются клиенты с
системой Windows NT Workstation, используйте их для входа в систему. Клиенты с
системами Windows 2000 и Windows XP Professional также могут обработать
индивидуальные сценарии входа в систему. Если вы имеете индивидуальные сценарии
входа в систему, назначенные учетным записям пользователя, они будут выполняться
после выполнения сценариев запуска компьютера и пользовательских сценариев входа в
систему, назначенных групповыми политиками.
Чтобы сконфигурировать сценарий для Active Directory, нужно его создать, а затем скопировать на
контроллер домена. Сценарии можно хранить в любом месте на сервере, доступном для клиентов.
Типичное место хранения сценариев - папка %systemroot %\SYSVOL\sysvol\ domainname\scripts.
Она открыта для общего доступа под сетевым именем NETLOGON, и является заданным по
умолчанию местом, в котором клиенты низкого уровня ищут сценарии входа в систему. Вы
можете хранить сценарии входа в систему в папке %systemroot %\SYSVOL\
sysvol\domainname\GlobalPolicy
GUID\Machine\Scripts
или
в
папке
%systemroot
%\SYSVOL\sysvol\domainname\GlobalPolicy GUID\User\ Scripts. После копирования файлов
сценария на сервер откройте объект GPO и найдите папку Scripts (Startup/Shutdown) (Сценарии
(Запуск/ Завершение), расположенную в папке Computer Conf iguration\ Windows Settings, или
папку Scripts (Logon/Logoff) (Сценарии (Вход в систему/ выход из системы)), расположенную в
папке User Conf iguration\Windows Settings. Например, чтобы создать запись для сценария запуска,
разверните цапку Scripts (Startup/Shutdown) и дважды щелкните на Startup. Затем можно добавлять
любые сценарии запуска к объекту GPO. Active Directory Windows Server 2003 обеспечивает
множество административных шаблонов, которые использоваться для конфигурирования
сценариев на рабочих станциях клиентов. Большинство параметров настройки расположено в
папке Computer Configuration\ Administrative Templates\System\Scripts, а некоторые - в nanKeUser
Conf iguration\ Administrative Templates\System\Scripts. Опции конфигурации включают опцию,
позволяющую выполнять сценарии запуска асинхронно, т.е. несколько сценариев запуска смогут
выполняться одновременно. Можно выполнять сценарии входа в систему синхронно, т.е. все
сценарии запуска завершаются, прежде чем появится рабочий стол пользователя. Вы можете
также сконфигурировать максимальное время ожидания окончания выполнения всех сценариев.
И, наконец, можно сконфигурировать, будут ли сценарии выполняться в фоновом режиме, чтобы
быть незаметными, или они будут видимыми при выполнении.
Резюме
В Active Directory Windows Server 2003 имеется множество инструментальных средств и опций,
предназначенных для управления рабочими столами пользователей. Групповые политики могут
использоваться для управления данными и профилями пользователей, чтобы обеспечить им
знакомую рабочую среду, оставляя централизованным управление некоторыми данными. Они
применяются также для конфигурирования параметров настройки защиты, чтобы все компьютеры,
на которые воздействует данная групповая политика, имели стандартную и постоянную
конфигурацию защиты. Групповые политики используются для определения административных
шаблонов, которые могут конфигурировать параметры настройки системного реестра для
управления рабочими столами пользователей. В этой главе дан краткий обзор того, как можно
реализовать эти варианты управления рабочими столами пользователей.
Часть IV. Обслуживание Active
Directory Windows Server 2003
Части I, II и III этой книги дали вам понятие об основных концепциях и компонентах,
проектировании и реализации службы каталога Active Directory в системе Microsoft Windows
Server 2003, а также ознакомили с управлением пользователями и компьютерами вашей сети. Эта
заключительная часть книги подготовит вас к обслуживанию инфраструктуры Active Directory
после ее развертывания. В главе 14 детально рассказывается, как следить за состоянием Active
Directory, включая информацию о мониторинге эксплуатационных качеств Active Directory и ее
репликации. Обсуждается также управление базой данных Active Directory. В главе 15
обсуждается создание резервной копии и восстановление Active Directory. Active Directory — это
критическая служба в вашей сети, и вы должны уметь восстанавливать ее после любых видов
сбоя, которые могут произойти во время работы.
Глава 14. Мониторинг и обслуживание Active
Directory
Даже прекрасно разработанная, спланированная и реализованная инфраструктура Active Directory
не будет оставаться в оптимальном состоянии без повседневного мониторинга и обслуживания.
Active Directory представляет собой сложную распределенную сетевую службу, в больших
организациях она будет подвержена тысячам изменений каждый день (создание или удаление
учетных записей пользователя и их атрибутов, группового членства и разрешений). Для гарантии
того, что эти изменения в сети и рабочей среде не будут отрицательно влиять на работу Active
Directory, нужно ежедневно предпринимать профилактические действия. В этой главе
исследуются два фундаментальных элемента поддержки инфраструктуры Active Directory:
мониторинг контроллеров домена и обслуживание базы данных Active Directory.
Мониторинг Active Directory
Мониторинг состояния Active Directory необходим для поддержания надежного уровня службы
каталога вашей организации. Ваши пользователи полагаются на эффективное функционирование
службы каталога и считают само собой разумеющимся то, что они имеют возможность войти в
сеть, обратиться к общедоступным ресурсам, получить и послать электронную почту. Их
деятельность целиком зависит от здорового состояния и функциональности службы каталога
Active Directory.
Отдельного инструмента или пакета программ, предназначенного для мониторинга Active
Directory, не существует. Скорее мониторинг здорового состояния Active Directory является
комбинацией задач, имеющих общую цель - измерение текущей характеристики некоторого
ключевого индикатора (занимаемый объем диска, степень использования процессора, период
работоспособного состояния службы и т.д.) по сравнению с известным состоянием (отправная
точка). Поэтому ваш мониторинг службы каталога будет состоять из различных задач и инструменов. (Существуют наборы инструментов, которые могут соединить мониторинг этих ключевых
индикаторов вместе в легко управляемый
интерфейс, и для больших организаций наличие таких средств очень существенно, но они дороги,
сложны и требуют много ресурсов.) В этой главе обсуждается, что именно вы должны
отслеживать, и рассматриваются некоторые инструменты для этих целей, доступные в системе
Microsoft Windows Server 2003. Вы сами можете решить, какие из этих инструментальных средств
управления службой Active Directory удовлетворят ваши потребности.
Чтобы разбираться в мониторинге Active Directory, вы должны знать, почему его следует
проводить, как это делать и что конкретно нужно отслеживать. Чтобы сохранить максимальную
производительность службы каталога, необходимо также знать, что предпринимать в ответ на
проведенный мониторинг. Цель этой главы состоит в том, чтобы вы могли делать все
необходимое, что требуется для поддержания функционального состояния службы в пределах
нормальных рабочих параметров, которые вы установили. Например, если мониторинг
функционирования службы показывает, что диск, на котором расположена база данных Active
Directory, фрагментирован, вы должны его дефрагментировать.
Почему следует проводить мониторинг Active Directory?
Традиционная причина проведения мониторинга Active Directory состоит в том, что он
идентифицирует потенциальные проблемы прежде, чем они проявятся и закончатся длительными
периодами простоя службы. Мониторинг дает возможность поддерживать соглашение об уровне
сервиса (service-level agreement - SLA) с вашим клиентом (пользователем сети). В любом случае
вы должны следить за «здоровьем» Active Directory, чтобы разрешать возникающие проблемы как
можно скорее, до того, как произойдет прерывание работы службы.
Примечание. Соглашение SLA - это контракт между провайдером услуг (вы) и сообществом
пользователей, который определяет обязанности каждой из сторон и представляет
обязательства, обеспечивающие определенную степень качества и количества уровню
функционирования службы. В контексте Active Directory соглашение SLA между отделом
информационных технологий (IT ) и сообществом пользователей может содержать такие
параметры, как максимально приемлемый уровень времени простоя системы, время входа в
систему и время получения ответа на справочный запрос. В обмен на обязательства провайдера
услуг обеспечивать определенные стандарты производительности и функциональности
системы, сообщество пользователей обязуется придерживаться определенных объемов
использования системы, например, иметь не более 10000 пользователей в лесу Active Directory.
Еще одна причина для проведения мониторинга Active Directory состоит в том, что нужно
отслеживать изменения инфраструктуры. Увеличился ли размер базы данных вашей Active
Directory с прошлого года? Все ли ваши серверы глобального каталога (GC) работают в
интерактивном режиме? Сколько времени требуется для того, чтобы изменения, сделанные на
контроллере домена во Франции, были реплицированы на контроллер домена в Австралии?
Возможно, эта информация не поможет вам предотвратить возникновение сегодняшней ошибки,
но она обеспечит вас ценными данными, с которыми вы сможете строить планы на будущее.
Выгоды от мониторинга Active Directory
Выгоды, которые можно получить от проведения мониторинга Active Directory, включают
следующее.
• Способность поддерживать SLA-соглашение с пользователями, избегая простоя службы.
• Достижение высокой производительности службы Active Directory путем устранения
«узких мест» в работе, которые иначе нельзя обнаружить.
• Снижение административных затрат с помощью профилактических мер в обслуживании
системы.
• Повышенная компетентность при масштабировании и планировании будущих изменений
инфраструктуры в результате глубокого знания компонентов Active Directory, их
функциональных возможностей и текущего уровня использования.
• Увеличение доброжелательности в отношении IT-отдела в результате удовлетворения
клиентов.
Затраты на мониторинг Active Directory
Мониторинг инфраструктуры вашей службы Active Directory связан с затратами. Ниже
перечислены некоторые затраты, необходимые для его эффективной реализации.
• Для проектирования, развертывания и управления системой мониторинга требуются
человеко-часы.
• На приобретение необходимых средств управления, на обучение и на аппаратные средства,
которые предназначены для реализации мониторинга, требуются определенные фонды.
• Часть пропускной способности вашей сети будет использоваться для мониторинга
«здоровья» Active Directory на всех контроллерах домена предприятия.
•
Для выполнения приложений-агентов на целевых серверах и на компьютере, являющемся
центральным пультом мониторинга, используются память и ресурсы процессора.
Стоит отметить, что стоимость мониторинга быстро повышается, когда вы перемещаетесь на
платформу глобального мониторинга предприятия типа Microsoft Operations Manager (MOM).
Инструментальные средства MOM дороги, требуют обучения оператора и расходуют большее
количество системных ресурсов в отличии от мониторинговых решений Windows Server 2003, но
они являются проверенными, интегрированными и поддерживаемыми продуктами.
Уровень вашего мониторинга будет зависеть от результатов анализа выгод и затрат. В любом
случае стоимость ресурсов, которые вы задействуете в системе мониторинга, не должна
превышать ожидаемую от мониторинга экономию. По этой причине большие организации находят
более рентабельным вкладывать капитал в комплексные решения по управлению предприятием.
Для менее крупных организаций более оправдано использовать инструментальные средства
мониторинга, встроенные в систему Windows Server 2003.
Дополнительная информация. MOM включает управление событиями, мониторинг служб
и предупреждений, генерацию отчетов и анализ тенденций. Это делается через центральный
пульт, в котором агенты, выполняющиеся на управляемых узлах (серверах, являющихся
объектами мониторинга), посылают данные, которые будут проанализированы, отслежены и
отображены на едином пульте управления. Эта централизация дает возможность сетевому
администратору управлять большой совокупностью серверов из одного места с помощью
мощных инструментов, предназначенных для удаленного управления серверами. Системы
MOM используют пакеты управления для расширения базовой информации, касающейся
определенных сетевых услуг, а также серверных приложений. Пакет управления Base
Management Pack содержит характеристики всех служб сервера Windows Server 12003,
включая Active Directory, службу доменных имен (DNS) и интернет-службу Microsoft
Internet Information Services (IIS). Пакет управления Application Management Pack включает
характеристики серверов Microsoft .NET Enterprise Servers, таких как Microsoft Exchange
2000 Server и Microsoft SQL Server 2000. Дополнительную информацию о MOM смотрите на
сайте http://www.microsoft.com/mom.
Как осуществлять мониторинг Active Directory
Осуществляя мониторинг Active Directory, вы будете отслеживать ключевые индикаторы
производительности и сравнивать их с базовыми показателями, которые представляют работу
службы в пределах нормальных параметров. Когда индикатор работоспособности превышает
указанный порог, выдается предупреждение, уведомляющее администрацию сети (или оператора
мониторинга) о текущем состоянии системы. Предупреждение может также инициировать
автоматические действия, направленные на решение проблемы или уменьшение дальнейшего
ухудшения «здоровья » системы и т.де.
Ниже приводится схема процесса мониторинга службы Active Directory высокого уровня.
1. Определите, какой из индикаторов функционирования службы вы должны отслеживать.
(Начните с просмотра своих SLA-соглашений с клиентами.)
2. Выполните мониторинг индикаторов функционирования службы, чтобы установить и
задокументировать свой базовый уровень.
3. Определите свой пороги для этих индикаторов функционирования. (Другими словами,
определите, при каком уровне индикатора вы должны принимать меры, предотвращающие
расстройство функционирования службы.)
4. Спроектируйте необходимую аварийную систему, предназначенную для обработки
событий достижения порогового уровня. Ваша аварийная система должна включать:
• уведомления оператора;
• автоматические действия, если они возможны;
• действия, инициируемые оператором.
5. Спроектируйте систему создания отчета, фиксирующую историю системного «здоровья»
Active Directory.
6. Реализуйте свое решение, чтобы измерять выбранные ключевые индикаторы в
соответствии с расписанием, отражающим изменения данных индикаторов и их
воздействие на «здоровье» Active Directory.
Далее в разделе исследуется каждое из этих действий. Идентификация индикаторов
функционирования описана в разделе «Что следует отслеживать».
Установление базовых уровней и порогов
После определения индикаторов функционирования, которые следует подвергнуть мониторингу,
нужно собрать базовые данные для этих индикаторов. Базовый уровень представляет собой
уровень индикатора функционирования, соответствующий пределам нормальной работы системы.
Пределы нормальной работы должны включать и низкие, и высокие значения, которые ожидаются
для определенного счетчика. Чтобы точнее фиксировать базовые данные, вы должны собирать
информацию о работе системы в течение достаточно длительного периода времени, чтобы
отразить диапазон значений. Например, если вам требуется установить базовый уровень
производительности для аутентификационных запросов, убедитесь, что вы отслеживали значения
этого индикатора в те периоды времени, когда большинство ваших пользователей входит в
систему.
При определении своих базовых значений документируйте эту информацию и дату создания
данной версии документа. В дополнение к тому, что эти значения используются для установки
порогов, через какое-то время они будут полезны для определения тенденций в
функционировании системы. Для документирования хорошо подходит таблица со столбцами,
содержащими низкое, среднее и высокое значения для каждого счетчика, а также пороги для
предупреждений.
Совет. Когда изменяется среда вашей службы Active Directory (например, если увеличивается
количество пользователей или производится изменение аппаратуры на контроллерах домена),
установите заново свои базовые значения. Базовые значения должны всегда отражать самое
современное состояние Active Directory, выполняющейся в пределах нормы. Устаревшие базовые
значения бесполезны для анализа текущих данных о фун-кционировании системы.
После того как вы определили базовые значения, определите пороговые значения, которые
должны вызывать предупреждения. Кроме рекомендаций, сделанных компанией Microsoft, не
существует никакой волшебной формулы для этого. Основываясь на инфраструктуре вашей сети,
вы должны определить, какое значение счетчика указывает на то, что тенденция в
функционировании службы направлена на прекращение ее работы. При установлении своих
порогов для начала будьте консервативны. (Используйте или значения, рекомендуемые Microsoft,
или даже более низкие значения.) В результате вам придется обрабатывать большое количество
предупреждений. По мере того как вы соберете больше данных о счетчике, вы сможете поднять
порог для уменьшения количества предупреждений. Этот процесс может занимать несколько
месяцев, но, в конечном счете, вы настроите свою реализацию службы Active Directory.
Счетчики производительности и пороги
Следующие таблицы перечисляют ключевые счетчики производительности и пороговые значения,
которые полезны для мониторинга Active Directory, в соответствии с рекомендациями компании
Microsoft. Имейте в виду, что среда каждого предприятия будет иметь свои уникальные
характеристики, которые влияют на применимость этих значений. Считайте эти пороги отправной
точкой и с помощью описанного ранее мониторинга уточните, чтобы они отражали особенности
вашей среды.
Производительность Active Directory
Счетчики производительности (см. табл. 14-1) выполняют мониторинг основных функций и служб
Active Directory. Если не указано другого, пороги определяются в результате мониторинга базовых
значений. Чтобы получить доступ к этим счетчикам, откройте Start (Пуск) >Administrative
Tools (Средства администрирования)>Регfоmance(Производительность), а затем щелкните на кнопке Add
(Добавить) над диаграммой. Разделы, данные после этой таблицы, описывают установку свойств счетчика.
Табл. 14-1. Основные функции и службы Active Directory
Объект
NTDS
Счетчик
Интервал
DS Search subКаждые 15
operations/sec
минут
(DS поисковые
подоперации/сек
унда)
Почему этот счетчик важен
Запросы на поиск поддеревьев очень
интенсивно используют ресурсы
системы. Любое его увеличение
может указывать на проблемы с
производительностью
контроллера
домена. Проверяйте, происходят ли
случаи неправильного обращения
приложений к контроллеру домена.
Процесс
% Processor
Time(Instance=ls
ass) (% времени
процессора)
LDAP Searches/
sec (LDAP
поиск/ секунда)
Каждую
минуту
Указывает процент от времени
процессора, используемого службой
Active Directory.
Каждые 15
минут
Является хорошим индикатором
объема использования контроллера
домена. В идеале он должен иметь
одинаковые значения для всех
контроллеров домена. Увеличение
значения указывает на то, что
новое приложение обращается к
этому контроллеру домена, или что
больше клиентов было добавлено к
сети.
Каждые 5
минут
Указывает
текущее
количество
клиентов, связанных с контроллером
домена. Его увеличение указывает на
то, что другие машины не выполняют
свою работу, перегружая этот
контроллер домена. Обеспечивает
полезной информацией о том, в какое
время
дня
пользователи
преимущественно выходят в сеть, и
максимальном
числе
клиентов,
связывающихся с сетью каждый день.
NTDS
NTDS
LDAP Client
Sessions (LDAP
сеансы
клиентов)
Процесс
Private Bytes
Каждые 15
(Instance=lsass) минут
(Личные байты)
Отслеживает
объем
памяти,
используемой контроллерами домена.
Непрерывный
рост
значения
указывает на увеличение потребности
рабочей станции за счет поведения
приложений
(оставляют
дескрипторы) или на увеличение
числа
рабочих
станций,
обращающихся
к
контроллеру
домена.
При
значительном
отклонении значения этого счетчика
от
нормального
значения,
соблюдаемого на других, равных по
положению, контроллерах домена, вы
должны исследовать причину этого.
Процесс
Handle Count
(Instance=lsass)
Счетчик
дескрипторов)
Каждые 15
минут
Процесс
Virtual Bytes
(Instance=lsass)
(Виртуальные
байты)
Каждые 15
минут
Полезен для обнаружения плохого
поведения
приложения,
не
закрывающего дескрипторы должным
образом. Значение этого счетчика
увеличивается линейно по мере
добавления
клиентских
рабочих
станций.
Используется для определения того,
что Active Directory выполняется при
нехватке виртуального адресного
пространства памяти, что называет на
утечку памяти. Убедитесь, что у вас
выполняется
самый
последний
сервисный пакет (service pack), и
наметьте перезагрузку на ближайшие
нерабочие часы, чтобы избежать
простоя системы. Этот счетчик может
использоваться для определения того,
что остаются доступными менее 2-х
гигабайт виртуальной памяти.
Счетчики, характеризующие функционирование репликации
Счетчики (см. табл. 14-2) отслеживают количество реплицируемых данных. Пороги определяются
по базовым значениям, установленным ранее, если не указано ничего другого.
Табл. 14-2. Счетчики, характеризующие репликацию
Объект Счетчик
Рекомен Почему этот счетчик важен
дуемый
интервал
NTDS
DRA
Inbound Каждые
Bytes Compressed 15 минут
(DRA входящие
сжатые
байты)
(Между сайтами
после
сжатия/
секунды)
Указывает
количество
репли-цируемых
данных, входящих в этот сайт. Изменение
значения этого счетчика указывает на
изменение топологии репликации или на то,
что существенные данные были добавлены
или изменены в Active Directory.
NTDS
DRA
Outbound Каждые
Bytes Compressed 15 минут
(DRA исходящие
сжатые
байты)
(Между сайтами
после
сжатия/
секунды)
Указывает
количество
реплици-руемых
данных, выходящих из этого сайта.
Изменение
значения
этого
счетчика
указывает на изменение топологии ответа
или на то, что существенные данные были
добавлены или изменены в Active Directory.
NTDS
DRA
Outbound Каждые Указывает
количество
репли-цируемых
Bytes
Not 15 минут данных, выходящих из этого контроллера
Compressed
домена, но адресованных в пределах сайта.
(Исходящие
несжатые
DRA
байты )
NTDS
DRA
Outbound Каждые
Bytes
Total/sec 15 минут
(Общее
количество
исходящих DRA
байтов/ секунда)
Указывает
количество
реплици-руемых
данных, выходящих из этого контроллера
домена. Изменение значения этого счетчика
указывает
на
изменение
топологии
репликации или на то, что существенные
данные были добавлены или изменены в
Active Directory. Это важный счетчик,
который следует отслеживать.
Работа подсистемы защиты
Счетчики (см. табл. 14-3) отслеживают ключевые объемы, связанные с защитой. Пороги
определены в результате мониторинга базовых значений, если не указано другого.
Табл. 14-3. Ключевые объемы, связанные с защитой
Объект Счетчик
Рекоменду Почему этот счетчик важен
емый
интервал
NTDS
NTLM
Каждые 15 Указывает количество клиентов в секунду,
Authentications
минут
которые
аутенти-фицируются
на
(NTLM
контроллере домена, используя NTLM
аутентификации)
вместо Kerberos (клиенты, имеющие более
ранние, чем Windows 2000, системы или
аутентификация между лесами).
NTDS
KDC AS Requests Каждые 15 Указывает количество билетов сеанса,
(Запросы
KDC минут
выпускаемых
в
секунду
центром
AS)
распределения ключей (KDC). Позволяет
наблюдать воздействие изменения срока
службы билета.
NTDS
Kerberos
Каждые 15 Указывает количество нагрузки, связанной
Authentications
минут
с аутентификацией, получаемой центром
(Аутентификации
KDC. Позволяет наблюдать тенденции
Kerberos)
роста.
NTDS
KDC
TGS Каждые 15 Указывает количество TGT билетов,
Requests (Запросы минут
выпускаемых службой KDC. Используется
KDC TGS)
для наблюдения за изменением срока
службы билета.
Функционирование ядра операционной системы
Счетчики (см. табл. 14-4) отслеживают индикаторы, характеризующие работу ядра операционной
системы, они прямо воздействуют на производительность Active Directory.
Табл. 14-4. Основные индикаторы операционной системы
Объект
Счетчик
Memory
(Память)
Physical
Disk
(Диск)
Порог
Значимость
превышения
порогового значения
Page Faults/ sec
Каждые 5
(Ошибки страницы/ минут
секунды)
700/с
Высокая степень ошибок
страницы указывает на
недостаточную физическую
память.
Current DiskQueue
«length (Текущая
длина очереди к
Диску)
Удвоенное
среднее
значение в
течение трех
интервалов
Отслеживает объемы файлов
Ntds.dit и .log. Указывает, что
имеется отставание дисковых
запросов ввода/ вывода.
Рассмотрите возможность
увеличения диска и
производительности контроллера.
Processor % DPC Time
Каждые 15
(Процессо (Instance=_Total) (% минут
р)
времени DPC)
10
Указывает отложенную работу,
из-за занятости контроллера
домена. Превышение порогового
значения указывает на возможную
перегрузку процессора.
System
Processor Queue
Каждую
(Система) Length (Длина
минуту
очереди к процессоРУ)
Шесть
средних
значений в
течение пяти
интервалов
Процессор недостаточно быстр,
чтобы обрабатывать запросы по
мере их поступления. Если
топология репликации правильна,
и данное состояние не вызвано
отказами другого контроллера
домена, рассмотрите возможность
обновления процессора.
Memory
(Память)
4 Мб
Указывает, что система исчерпала
доступную память. Вероятен
надвигающийся отказ в работе
службы.
Available MBytes
(Доступные
мегабайты)
Интервал
Каждую
минуту
Каждые 15
минут
Processor % Processor Time
Каждую
(Процессо (Instance=_Total) (% минуту
р)
времени процесора)
85 % от
следнего
значения в
течение трех
интервалов
Указывает на перегрузку
центрального процессора.
Определите, вызвана ли
перегрузка процессора службой
Active Directory, исследуя объект
Process, счетчик % Processor Time,
Isass instance.
System
Context Switches/sec Каждые 15
(Система) (Переключение
минут
контекста/ секунда)
70000
Указывает на чрезмерное
количество переходов. Возможно,
что работает слишком много
приложений шщ служб, или их
нагрузка на систему слишком
высока. Рассмотрите возможность
разгрузки системы от части этих
требований.
System
System Up Time
(Система) (Время работы
системы)
Каждые 15
минут
Важный счетчик, показывающий
надежность контроллера домена.
Предостережение. Приведенные выше значения основаны на пороговых значениях,
которые были рекомендованы компанией Microsoft на момент печати этой книги, и должны
рассматриваться как предварительные значения. Информация содержится в руководстве
Directory Services Guide комплекта Microsoft Windows Server 2003 Resource Kit. Свежую
информацию о выпуске комплекта ресурсов смотрите по адресу http://
www.microsoft.com/windowsserver2003/techinfo/reskit/reso urcekit.mspx.
Проектирование предупреждений
Предупреждение определяется как уведомление, которое вызывается автоматически, когда
значение счетчика достигает порогового уровня. Используя инструмент администрирования
Performance, имеющийся в системе Windows Server 2003, вы может сконфигурировать
предупреждение для любого доступного счетчика функционирования системы.
Примечание. Когда Active Directory Installation Wizard устанавливает Active Directory, он
конфигурирует счетчики функциональности в объекте NTDS Performance, который
обеспечивает статистику деятельности службы каталога. Эти счетчики применимы ко всему
каталогу, включая глобальные каталоги GC.
Счетчики функционирования базы данных Active Directory для базы данных ESENT (Ntds.dit) не
устанавливаются во время инсталляции Active Directory. Вы должны добавить их вручную. Чтобы
найти автоматизированный сценарий, который устанавливает счетчики функционирования базы
данных Active Directory, смотрите статью Install Active Directory Database Performance Counters
(Установка счетчиков функционирования базы данных Active Directory) в Центре сценариев
Microsoft по адресу http://www.microsoft.com/technet/treeview/defa ult.asp? url —/technet/scriptcenter
/monitor/ScrMonO8.asp. Вы можете скопировать этот сценарий в текстовой файл, дать файлу свое
название и расширение .vbs, а затем выполнить его для установки счетчиков функционирования базы
данных ESENT.
Чтобы создать предупреждение по поводу превышения числа аутен-тификационных запросов протокола
Kerberos (порог равен 20-ти запросам в секунду) на контроллере домена, выполните следующие шаги.
1.
2.
3.
Откройте Performance (Производительность) в папке Administrative Tools (Средства
администрирования).
Дважды щелкните на Performance Logs And Alerts (Журналы работы и предупреждения), а затем
щелкните на Alerts (Предупреждения).
Из меню Action (Действия) выберите New Alert Settings (Параметры настройки новых
предупреждений).
В поле Name (Имя) напечатайте название предупреждения, а затем щелкните на кнопке
ОК. Это название будет показано в контейнере Performance Logs And Alerts, поэтому
используйте такое имя, которое определяет отслеживаемый счетчик.
5. На вкладке General (Общее) дайте комментарий к вашему предупреждению, а затем
щелкните на кнопке ADD (Добавить), чтобы добавить необходимый объект Performance и
счетчики (см. рис. 14-1).
4.
Рис. 14-1. Добавление счетчика к новому предупреждению
6.
Введите пороговый предел, запускающий предупреждение. Установите интервал времени
для выборки данных функционирования службы (см. рис. 14-2).
Рис. 14-2. Установка порогового предела и интервала выборки
7.
На вкладке Action (Действия) определите события, которые должны происходить, когда
значение счетчика достигнет порогового значения. Чтобы определить время, когда служба
должна начать просматривать предупреждения, используйте вкладку Schedule
(Расписание). Вкладка Action показывает, что предупреждение может вызвать несколько
действий, включая следующие (см. рис. 14-3):
• создание записи в прикладном журнале регистрации событий;
• генерирование предупреждающего сообщения. Это сообщение может быть послано
или по IP- адресу или на имя компьютера;
•
•
запуск регистрации характеристик функционирования службы;
выполнение программы.
Рис. 14-3. Определение действий, запускаемых новым предупреждением
В дополнение к опциям, указанным на вкладке Actions, для эффективного мониторинга
желательно иметь готовый план действий в ответ на предупреждение. После того как вы
определите ваши счетчики, а также базовые и пороговые значения, обязательно задокументируйте
корректирующие действия, которые вы предпримите для того, чтобы вернуть индикатор в
пределы нормы. Они могут включать поиск неисправностей (например, возвращение контроллера
домена в интерактивный режим) или передачу роли хозяина операций. Если ваша система
достигла своих максимальных возможностей, возможно, для исправления текущего состояния
придется добавить дополнительное дисковое пространство или память. Другие предупреждения
потребуют от вас выполнения действий по обслуживанию Active Directory, таких как дефрагментация файла базы данных Active Directory. Эти ситуации обсуждаются далее в этой главе в разделе «Автономная дефрагментация базы данных Active Directory».
Отслеживание «здоровой»
системного монитора
функциональности
сервера
с
помощью
Инструмент System Monitor (Системный монитор) включен в средства администрирования
Performance. Используя этот инструмент, можно собирать и рассматривать в реальном масштабе
времени данные функционирования местного компьютера или нескольких удаленных
компьютеров. Системный монитор дает графическое представление тех же самых данных,
которые отслеживаются с помощью инструмента Performance Logs And Alerts. Этот инструмент
значительно облегчает определение тенденций в работе службы.
Ниже перечислены три счетчика функционирования, заданных по умолчанию в системном
мониторе.
• Memory\Pages/sec (Память\Страницы/с).
• PhysicalDisk (_Total)\Avg. Disk Queue Length (Физический диск (__Тotа1)\средняя длина
очереди к диску).
• Processor (_Total)\%Processor Time (Процессор (_Totа1)\Время процессора).
Примечание. Слева от обратной наклонной черты находится объектом функционирования, в
круглых скобках дан экземпляр объекта (если имеется). Счетчик указан справа от наклонной
черты.
Каждый из этих счетчиков показан в системе координат «время/работа» линией своего цвета. Они
очень полезны для мониторинга системного «здоровья» сервера (в данном случае контроллера
домена). На рисунке 14-4 показано заданное по умолчанию представление системного монитора.
Вы можете сконфигурировать несколько полезных опции для системного монитора.
Чтобы оптимизировать представление определенного счетчика, выберите описание счетчика,
расположенное в нижней части окна, и щелкните на кнопке Highlight (Выделить) на
инструментальной панели. Так вы измените график, соответствующий выбранному счетчику,
представив его полужирной белой линией, чтобы его было легче рассматривать.
Вы можете переключаться между такими представлениями данных, как график, гистограмма и
отчет, выбирая соответствующую кнопку на инструментальной панели.
Можно сохранить параметры настройки графика системного монитора в виде HTML-страницы.
Для этого сконфигурируйте график необходимыми счетчиками, щелкните правой кнопкой мыши
на графике и выберите Save As (Сохранить как). График будет сохранен в виде файла HTML,
который вы сможете открыть в браузере. Когда вы открываете
HTML-версию графика, дисплей замораживается. Чтобы перезапустить мониторинг, щелкните на
кнопке Freeze Display, расположенной на инструментальной панели Performance в браузере.
Рис. 14-4. Счетчики функционирования, заданные по умолчанию в системном мониторе
Вы можете импортировать сохраненный график назад в системный монитор, перемещая файл HTML в окно
System Monitor. Этот способ удобен для сохранения и перезагрузки часто используемых графиков
функционирования службы.
В системе Windows Server 2003 имеются две новые группы безопасности, которые гарантируют, что только
надежные пользователи могут получить доступ и управлять данными функционирования службы: группы
Performance Log Users (Пользователи, регистрирующие работу) и Performance Monitor Users (Пользователи,
выполняющие мониторинг).
Чтобы добавить дополнительные счетчики к системному монитору, выполните следующие действия.
1. Щелкните правой кнопкой мыши на панели деталей системного монитора, затем щелкните на Add
Counters (Добавить компьютеры).
2. В диалоговом окне Add Counters щелкните на Use Local Computer Counters (Счетчики локального
компьютера пользователя), чтобы отслеживать работу компьютера, на котором выполняется
консоль мониторинга. Чтобы отслеживать работу определенного компьютера независимо
от того, где выполняется консоль мониторинга, щелкните на Select Counters From Computer
(Выбрать счетчик на компьютере) и укажите имя компьютера или его IP-адрес.
3. Выберите нужный объект Performance, а затем щелкните на счетчике, который вы хотите
добавить. Здесь используется тот же самый интерфейс, который использовался для
добавления счетчиков к новому предупреждению, описанный ранее.
4. Щелкните на кнопке Add (Добавить), а затем щелкните на Close (Закрыть).
5.
Мониторинг Active Directory с помощью инструмента Event Viewer
В дополнение к использованию инструмента Performance для мониторинга Active Directory вы
должны периодически рассматривать содержимое журналов регистрации событий, используя
инструмент администрирования Event Viewer (Средство просмотра событий). По умолчанию
средство просмотра событий отображает следующие три регистрационных журнала.
•
Application log (Журнал приложений). Содержит события, зарегистрированные
приложениями или программами.
• System log (Системный журнал). Содержит правомерные и неправомерные попытки входа
в систему, а также события, связанные с использованием ресурсов, такие как создание,
открытие и удаление файлов или других объектов.
• Security log (Журнал безопасности). Содержит события, зарегистрированные
компонентами системы Windows.
Для серверов, сконфигурированных как контроллеры домена, на которых выполняется система
Windows Server 2003, будут отображаться следующие журналы регистрации событий.
• Directory Service log (Журнал регистрации службы каталога). Содержит события,
зарегистрированные службой Active Directory.
• File Replication Service log (Журнал регистрации службы репликации файлов) Содержит
события, зарегистрированные службой репликации файлов.
Если контроллер домена с системой Windows Server 2003 является также сервером DNS, то будет
отображаться следующий журнал регистрации.
• DNS Server log (Журнал сервера DNS). Содержит события, зарегистрированные службой
сервера DNS.
Для просмотра журнала регистрации событий выберите инструмент Event Viewer из папки
Administrative Tools. Выберите журнал регистрации событий, предназначенный для той службы, работу которой вы хотите отслеживать. Левая
область окна на рисунке 14-5 показывает все журналы событий для контроллеров домена с
системой Windows Server 2003, которые являются также серверами DNS.
Рис. 14-5. Инструмент администрирования Event Viewer с журналами регистрации событий
В журнале регистрации событий рассмотрите типы событий Errors (Ошибки) и Warnings
(Предупреждения). Чтобы отобразить детали событий в журнале регистрации, дважды щелкните
на этом событии. На рисунке 14-6 показаны детали события Warnings (ID-событие 13562) из
журнала File Replication Service (Служба репликации файлов).
Что следует отслеживать
Для мониторинга общего системного «здоровья» Active Directory нужно отслеживать работу,
связанную со службой, и индикаторы функционирования, связанные с сервером, а также события.
Вы должны гарантировать, что Active Directory и контроллеры домена, на которых она
выполняется, работают в оптимальном режиме. При проектировании своей системы мониторинга
планируйте наблюдение за следующими областями работы.
Рис. 14-6. Окно Event Properties (Свойства событий) для записи в журнал событий
•
•
•
•
•
•
•
•
Репликация Active Directory. Функционирование репликации существенно для
обеспечения сохранности данных в пределах домена.
Службы Active Directory. Эти индикаторы функционирования отслеживаются с помощью
счетчиков NTDS в инструменте администрирования Performance.
Хранилище базы данных Active Directory. Дисковые тома, которые содержат файл базы
данных Active Directory Ntds.dit и файлы журналов .log, должны иметь достаточно
свободного пространства, чтобы допускать нормальный рост и функционирование.
Функционирование службы DNS и «здоровье» сервера. Поскольку Active Directory
полагается на DNS при поиске ресурсов в сети, то сервер DNS и сама служба должны
работать в нормальных пределах, чтобы Active Directory удовлетворяла заданному уровню
качества обслуживания.
Служба репликации файлов (File Replication Service - FRS). Служба FRS должна
работать в пределах нормы, чтобы гарантировать, что общий системный том (Sysvol)
реплицируется по всему домену.
«Здоровье» системы контроллера домена. Мониторинг этой области должен охватывать
все аспекты здоровья сервера, включая счетчики, характеризующие использование памяти,
процессора и разбиение на страницы.
«Здоровье» леса. Эта область должна отслеживаться для того, чтобы проверить
доверительные отношения и доступность сайта.
Хозяева операций. Отслеживайте каждого хозяина операций FSMO, чтобы гарантировать
«здоровье» сервера. Кроме того, проводите мониторинг для обеспечения доступности GCкаталога, позволяющего пользователям входить в систему и поддерживать членство
универсальных групп.
•
Мониторинг репликации
Один из критических компонентов Active Directory, за работой которого вы должны наблюдать, это репликация. В отличие от мониторинга контроллера домена, который использует инструмент
Performance Monitor, репликация между контроллерами домена чаще всего отслеживается с
помощью инструмента из набора Windows Server 2003 Support Tools (Средства обслуживания
Windows Server 2003): Repadmin.exe, Dcdiag.exe и журнала регистрации событий службы каталога
(см. выше). Repadmin представляет собой инструмент командной строки, который сообщает об
отказах репликационных связей между двумя партнерами по репликации. Следующая команда
вызывает отображение партнеров по репликации и все отказы репликационных связей для
контроллера домена DC1, расположенного в домене Contoso.com:
repadmin/showreps dd .contoso.com
Dcdiag - это инструмент командной строки, который может проверять DNS-регистрацию
контроллера домена. Он отслеживает наличие идентификаторов защиты (SID) в заголовках
контекста именования (naming context) соответствующие разрешения для репликации,
анализирует состояние контроллеров домена в лесе или предприятии и многое другое. Для
получения полного списка опций Dcdiag напечатайте dcdiag/?. С помощью следующей команды
можно проверить наличие ошибок репликации между контроллерами домена:
dcdiag/test: replications
И, наконец, журнал службы каталога сообщает об ошибках репликации, которые происходят
после установления репликационной связи. Нужно просматривать журнал регистрации событий
службы каталога в поисках событий репликации, имеющих тип Error (Ошибка) или Warning
(Предупреждение). Далее приводится два примера типичных ошибок репликации в том виде, как
они отображены в журнале регистрации событий службы каталога.
• Событие ID 1311. Информация о конфигурации репликации, имеющаяся в инструменте
Active Directory Sites And Services (Сайты и службы Active Directory), не отражает точно
физическую топологию сети. Эта ошибка указывает на то, что один или более
контроллеров домена или сервер-плацдарм (bridgehead) находятся в автономном режиме,
или что серверы-пладармы не содержат нужных контекстов именования (NC).
• Событие ID 1265 (Access denied — Доступ запрещен). Эта ошибка может возникать в том
случае, если локальный контроллер домена не сумел подтвердить подлинность своего
партнера по репликации при создании репликационной связи или при попытке
реплицировать по существующей связи, она возникает тогда, когда контроллер домена был
отсоединен от остальной части сети в течение долгого времени, и его пароль учетной
записи компьютера не синхронизирован с паролем учетной записи компьютера,
хранящимся в каталоге его партнера по репликации.
Обслуживание базы данных Active Directory
Одним из важных элементов управления службой Active Directory является обслуживание базы
данных Active Directory. При нормальных обстоятельствах вам редко придется управлять базой
данных Active Directory напрямую, потому что регулярное автоматическое управление
поддерживает «здоровье» вашей базы данных во всех ситуациях. Эти автоматические процессы
включают онлайновую дефрагментацию базы данных Active Directory, а также процесс сборки
мусора, очищающий удаленные элементы. Для тех редких случаев, когда вы действительно будете
напрямую управлять базой данных Active Directory, Windows Server 2003 включает инструмент
Ntdsutil.
Сборка мусора
Один из автоматических процессов, который обычно используется для обслуживания базы данных
Active Directory, — это сборка мусора. Сборка мусора - это процесс, который выполняется на
каждом контроллере домена каждые 12 часов. В процессе сборки мусора восстанавливается
свободное пространство в пределах базы данных Active Directory.
Процесс сборки мусора начинается с удаления объектов-памятников (tombstone) из базы данных.
Объекты-памятники являются остатками объектов, которые были удалены из Active Directory. При
удалении учетной записи пользователя она не удаляется немедленно. Вместо этого атрибут
isDeleted этой записи устанавливается на true, она помечается как объект-памятник, и
большинство атрибутов этого объекта удаляются. Остается несколько атрибутов, необходимых
для идентификации объекта: как глобально-уникальный идентификатор (GUID), идентификатор
SID, порядковый номер обновлений (USN) и отличительное имя. Этот объект-памятник затем
реплицируется на другие контроллеры домена в домене. Каждый контроллер домена
поддерживает копию объекта-памятника до тех пор, пока не истечет срок его службы. По
умолчанию срок службы объекта-памятника установлен на 60 дней. В следующий раз, когда
процесс сборки мусора будет запущен после истечения срока службы объекта-памятника, этот
объект будет удален из базы данных.
После удаления объектов-памятников процесс сборки мусора удаляет все ненужные файлы с
журналами транзакций. Всякий раз, когда делается изменение в базе данных Active Directory, оно записывается в журнал транзакций, а затем
передается в базу данных. Процесс сборки мусора удаляет все журналы транзакций, которые не
содержат непере-данных в базу данных транзакций.
Процесс сборки мусора выполняется на каждом контроллере домена с двенадцатичасовым
интервалом. Можно изменять этот интервал, модифицируя атрибут garbageCollPeriod в
глобальном для предприятия объекте DS конфигурации (NTDS). Чтобы изменить эти параметры
настройки, можно использовать инструмент Adsiedit.msc. Откройте ADSI Edit (Редактирование
ADSI) из диалогового окна Run (Выполнить) и выберите объект CN=Directory
Service,CN=Windows NT, CN=Services, CN=Configuration, DC=f orestname. Затем найдите атрибут
garbageCollPeriod и установите его значение так, чтобы оно удовлетворяло вашим требованиям. В
большинстве случгмвв вам не придется1 изменять эту установку. На рисунке 14-7 показан этот
атрибут в инструменте ADSI Edit.
Рис. 14-7. Атрибут garbageCollPeriod в инструменте ADSI Edit
Онлайновая дефрагментация
Заключительный шаг в процессе сборки мусора — это онлайновая дефрагментация базы данных
Active Directory. Она освобождает место в пределах базы данных и перестраивает расположение
хранящихся объектов Active Directory в пределах базы данных так, чтобы улучшить ее
эффективность. Во время нормального функционирования база данных Active Directory
оптимизирована так, чтобы можно было делать изменения в ней как можно быстрее. При
удалении объекта из Active Directory страница базы данных, на которой он хранится, загружается
в память компьютера, и объект удаляется с этой страницы. При добавлении объектов к Active
Directory они записываются на страницу базы данных без учета оптимизации последующего
поиска этой информации. После нескольких часов активного внесения изменений в базу данных
способ хранения данных перестает быть оптимизированным. База данных может содержать
пустые страницы, страницы, на которых удалены некоторые элементы. Объекты Active Directory,
которые логически должны храниться вместе, могут храниться на нескольких различных
страницах, расположенных по всей базе данных.
Процесс онлайновой дефрагментации чистит базу данных и возвращает ее в оптимизированное
состояние. Если некоторые записи были удалены с какой-либо страницы, то записи, находящиеся
на других страницах, перемещаются на нее для оптимизации хранения и поиска информации. Те
объекты, которые логически должны храниться вместе, перемещаются на одну и ту же страницу
базы данных или на смежные. Одно из ограничений процесса онлайновой дефрагментации
состоит в том, что он не сокращает размер базы данных Active Directory. Если вы удалили
большое количество объектов из Active Directory, то онлайновая дефрагментация создаст много
пустых страниц, которые она не сможет удалить. Для этого используется процесс автономной
дефрагментации.
Процесс онлайновой дефрагментации выполняется каждые 12 часов как часть процесса сборки
мусора. Когда процесс онлайновой дефрагментации закончен, в журнал службы каталога
записывается событие, указывающее, что процесс завершился успешно. На рисунке 14-8 показан
пример такого сообщения в журнале регистрации событий.
Рис. 14-8. Сообщение
дефрагментацию
журнала
службы
каталога,
указывающее
на
успешную
онлайновую
Автономная дефрагментация базы данных Active Directory
Как говорилось выше, процесс онлайновой дефрагментации не может сократить размер базы
данных Active Directory. При нормальных обстоятельствах это не является проблемой, потому что
страницы базы данных, которые очищены в процессе онлайновой дефрагментации, просто снова
используются по мере добавления новых объектов к Active Directory. Однако, в некоторых
случаях, можно использовать автономную дефрагмен-тацию для сокращения полного размера
базы данных. Например, если вы удаляете GC-каталог из контроллера домена, нужно выполнить
автономную дефрагментацию в базе данных, чтобы очистить место, которое ис-пользовалось в
базе данных для хранения информации GC. Потребность в автономной дефрагментации
существует в среде, состоящей из нескольких доменов, где GC каталог может стать очень
большим.
Чтобы выполнить автономную дефрагментацию, выполните следующие шаги.
1. Сделайте резервную копию информации Active Directory на контроллер домена (см. гл.
15).
2. Перезагрузите контроллер домена. Во время загрузки сервера нажмите клавишу F8, чтобы
отобразить меню дополнительных параметров Windows. Выберите режим Directory
Services Restore (Восстановление службы каталога) (Только для контроллеров домена с
системой Windows).
3. Войдите в систему, используя учетную запись Administrator (Администратор).
Используйте пароль, который вы вводили как пароль режима восстановления службы
каталога, когда назначали контроллер домена.
4. Откройте командную строку и напечатайте ntdsutil.
5. В командной строке утилиты Ntdsutil напечатайте files.
6. В командной строке утилиты File Maintenance (Обслуживание файлов) напечатайте info.
Эта опция отображает текущую информацию о пути и размере базы данных Active
Directory и ее журналов.
7. Напечатайте compact to drive:\directory. Выберите диск и каталог, которые имеют
достаточно места для хранения всей базы данных. Если название пути каталога содержит
пробелы, путь должен быть заключен в кавычки.
8. Процесс автономной дефрагментации создает новую базу данных по имени Ntds.dit в
указанном вами месте. По мере копирования базы данных в новое место она
дефрагментируется.
9. Когда дефрагментация закончена, напечатайте дважды quit, чтобы возвратиться к
приглашению ко вводу команды.
10. Скопируйте дефрагментированный файл Ntds.dit поверх старого файла Ntds.dit в место
расположения базы данных Active Directory.
11. Перезагрузите контроллер домена.
Примечание. Если вы дефрагментировали базу данных, потому что было удалено много
объектов из Active Directory, вы должны повторить эту процедуру на всех контроллерах домена.
Управление базой данных Active Directory с помощью утилиты
Ntdsutil
Утилиту Ntdsutil можно использовать не только для дефрагментации базы данных своей службы
Active Directory в автономном режиме, но и для управления базой данных Active Directory.
Инструмент Ntdsutil выполняет несколько низкоуровневых задач, возникающих при
восстановлении базы данных Active Directory. Все опции восстановления базы данных являются
неразрушающими, т.е. средства восстановления будут пробовать исправить проблему, возникшую
в базе данных Active Directory, только не за счет удаления данных.
Восстановление журналов транзакций
Восстановить журналы транзакций означает заставить контроллер домена заново запустить работу
журнала транзакций. Эта опция автоматически выполняется контроллером домена, когда он
перезапускается после принудительного выключения. Вы можете также выполнять мягкое
восстановление, используя инструмент Ntdsutil.
Примечание. В главе 15 подробно описывается, как используется журнал транзакций в Active
Directory.
Чтобы восстановить журнал транзакций, выполните следующие действия.
1. Перезагрузите сервер и выберите загрузку в режиме восстановления службы каталога. Это
требуется для работы инструмента Ntdsutil.
2. Откройте командную строку и напечатайте ntdsutil.
3. В командной строке утилиты Ntdsutil напечатайте files.
4. В командной строке File Maintenance напечатайте recover.
Запуск опции восстановления всегда должен быть первым шагом при любом восстановлении базы
данных, это гарантирует, что база данных совместима с журналами транзакций. Как только
восстановление закончится, можно выполнять другие опции базы данных, если это необходимо.
Проверка целостности базы данных
Проверка целостности базы данных означает, что база данных проверена на низком (двоичном)
уровне на предмет ее искажений. Процесс проверяет заголовки базы данных и все таблицы на
непротиворечивость. Поскольку во время этого процесса проверяется каждый байт базы данных, то работа с большой базой данных требует много времени. Чтобы выполнить проверку
целостности, напечатайте integrity в командной строке File Maintenance утилиты Ntdsutil.
Семантический анализ базы данных
Семантический анализ базы данных отличается от проверки целостности тем, что он не исследует
базу данных на двоичном уровне. Вместо этого проверяется непротиворечивость семантики базы
данных Active Directory. Семантический анализ базы данных исследует каждый объект в базе
данных для гарантии того, что каждый объект имеет GUID, правильный SID и правильные
репликационные метаданные.
Чтобы сделать семантический анализ базы данных, выполните следующие действия.
1. Откройте командную строку и напечатайте ntdsutil.
2. В командной строке утилиты Ntdsutil напечатайте semantic database analysis.
3. В командной строке Semantic Checker (Проверка семантики) напечатайте verbose on. Эта
установка конфигурирует утилиту Ntdsutil для выведения на экран дополнительной
информации при выполнении семантической проверки.
4. В командной строке Semantic Checker напечатайте go.
Примечание. Если вы использовали Active Directory в системе Windows 2000, то, возможно,
видели, что Windows 2000 включает опцию Repair (Восстановление). Эта опция, выполняющая
потенциально разрушающее восстановление базы данных Active Directory, отсутствует в
системе Windows Server 2003.
Перемещение базы данных и места расположения журналов транзакций
Инструмент Ntdsutil может также использоваться для перемещения базы данных Active Directory и
журналов транзакций. Например, если журналы транзакций и база данных находятся на одном и
том же жестком диске, вы можете переместить один из компонентов на другой жесткий диск. Если
жесткий диск, содержащий файл базы данных, заполнится, нужно будет переместить базу данных.
Чтобы переместить базу данных и журнал транзакций в новое место, выполните следующие
действия, когда сервер находится в режиме восстановления службы каталога.
1. Откройте командную строку и напечатайте ntdsutil.
2. В командной строке Ntdsutil напечатайте files.
3. Чтобы увидеть, где находятся файлы в настоящее время, в командной строке Ntdsutil
напечатайте info. Эта команда покажет места расположения файлов базы данных и всех
журналов регистрации.
4. Чтобы переместить файл базы данных, в командной строке File Maintenance напечатайте
move db to director, где dirеctorу задает новое место для файлов. Эта команда перемещает
базу данных в указанное место и реконфигурирует системный реестр так, чтобы
обращаться к файлу по его правильному месту расположения.
5. Чтобы переместить журнал транзакций, в командной строке File Maintenance напечатайте
move logs to directory.
Резюме
В этой главе были представлены некоторые инструменты, которые необходимы для мониторинга
Active Directory и «здоровья» систем контроллеров домена, на которых она выполняется.
Выполняя регулярный мониторинг работы службы, вы сможете идентифицировать потенциально
разрушительные и дорогостоящие «узкие места» системы и другие проблемы ее
функционирования, прежде чем они произойдут. Эффективный мониторинг Active Directory
обеспечит вас ценными данными о тенденциях функционирования системы, чтобы вы могли
подготовиться к будущим системным усовершенствованиям. Мониторинг является одним из
способов запустить выполнение необходимых задач обслуживания службы каталога, которые
нужно выполнять, чтобы сохранить инфраструктуру вашей Active Directory на высоком рабочем
уровне. Даже при отсутствии ошибок и предупреждений в журнале регистрации событий вы все
равно должны регулярно выполнять программу обслуживания базы данных, чтобы сохранить ее
эффективное функционирование. В этой главе описан также процесс онлайновой и автономной
дефрагментации, а также процесс сборки мусора, предназначенный для удаления из Active
Directory объектов-памятников.
Глава 15. Восстановление службы каталога в
случае сбоя
Служба каталога Active Directory — это наиболее критическая сетевая служба, которую вы
разворачиваете в вашей сети. Если инфраструктура Active Directory будет неудачной,
пользователи сети будут чрезвычайно ограничены в том, что они смогут делать в сети. Почти все
сетевые службы в Microsoft Windows Server 2003 выполняют аутентификацию пользователей в
Active Directory, прежде чем они получат доступ к какому-либо сетевому ресурсу. Поэтому вы
должны подготовиться к предотвращению отказов и ее восстановлению на том же самом уровне,
на каком вы готовитесь к восстановлению любых других сетевых ресурсов. При развертывании
Active Directory Windows Server 2003 важно подготовиться к защите базы данных Active Directory
и осуществить план по восстановлению базы данных в случае критического отказа.
Эта глава начинается с обсуждения основных методов обеспечения избыточности и защиты Active
Directory. Далее обсуждаются компоненты базы данных Active Directory и их оптимальные
конфигурации для гарантии функциональных возможностей восстановления службы в случае
сбоя. В основной части этой главы обсуждаются опции и процедуры по созданию резервной копии
и восстановления базы данных Active Directory.
Примечание. В этой главе обсуждается восстановление после сбоя только Active Directory. Глава
не касается вопросов, связанных с восстановлением серверов с системами Windows Server 2003.
Она посвящена только восстановлению Active Directory, после того как вы восстановили сервер.
Подготовка к отказам
Первые шаги в восстановлении системы после отказа выполняются намного раньше, чем случится
сам отказ. Если вы не подготовились к потенциальному бедствию надлежащим образом, то
проблема поломки аппаратного компонента на контроллере домена может превратиться в
реальную катастрофу, вместо того чтобы просто вызвать небольшое неудобство.
Подготовка к бедствию включает просмотр всех элементов, составляющих нормальную сетевую
инфраструктуру, а также некоторые специфичные для Active Directory вещи. Перечисленные ниже процедуры являются критически
важными.
• Разработайте последовательное создание резервной копии и восстановите управление
контроллеров домена. Первый шаг в любом плане восстановления состоит в установке
соответствующих аппаратных средств и программного обеспечения для поддержки
создания резервных копий контроллеров домена. Затем вы должны создать и
протестировать план резервирования и восстановления.
• Проверьте свой план резервирования до и после развертывания Active Directory. После
развертывания Active Directory ваши пользователи будут требовать, чтобы она была
доступна все время. Нужно неоднократно протестировать свой план восстановления.
Наилучшим образом управляемая сетевая среда имеет последовательную процедуру
тестирования восстановления, в которой каждую неделю тестируется какой-либо
компонент этой процедуры. Если бедствие действительно произойдет, вы будете
вынуждены восстановить Active Directory настолько быстро, насколько это возможно. Это
не должен быть тот случай, когда вы используете процедуру восстановления Active
Directory в первый раз.
• Разверните контроллеры домена Active Directory с аппаратной избыточностью.
Большинство серверов можно заказывать с некоторым уровнем аппаратной избыточности
при небольшой дополнительной стоимости. Например, сервер с двойным источником
питания, избыточными сетевыми картами и избыточной аппаратной системой жесткого
диска должен быть стандартным оборудованием для контроллеров домена. Если эта
избыточность предохранит вас хотя бы от одной трудовой ночи по восстановлению
контроллера домена, то это будет лучшая инвестиция, которую вы когда-либо делали. Во
многих больших компаниях аппаратная избыточность поднята на такой уровень, когда все
контроллеры домена связаны с различными цепями питания и подключены к различным
•
коммутаторам Ethernet или сетевым сегментами
Во всех сетях, кроме самых маленьких, вы должны развернуть, по крайней мере, два
контроллера домена. Active Directory использует циркулярную (circular) регистрацию для
своих журналов регистрации событий, и этот заданный по умолчанию порядок не может
быть изменен. Циркулярная регистрация означает, что с единственным контроллером
домена вы можете потерять данные Active Directory в случае аварии на контроллере
домена, и будете восстанавливать его из резервной копии. Даже в маленькой компании
важно иметь несколько контроллеров домена. Если вы хотите, чтобы все пользователи
большую часть времени использовали один контроллер домена, вы можете изменить
записи DNS, регулируя приоритет каждого контроллера домена. Тогда второй контроллер
домена может выполнять другие функции и использоваться только для создания резервной
копии на случай аварии на первом контроллере домена.
Хранение данных в Active Directory
Как говорилось в гл. 2, база данных Active Directory хранится в файле по имени Ntds.dit, который
по умолчанию расположен в папке %systemroot %\NTDS. Эта папка содержит также следующие
файлы.
• Edb.chk - файл контрольных точек, который указывает, какие транзакции из журналов
регистрации были записаны в базу данных Active Directory.
• Edb.log - журнал регистрации текущих транзакций. Имеет фиксированную длину - 10 Мб.
• Edbxxxxx.log. После того как Active Directory проработала некоторое время, могут
появиться один или более журналов, у которых часть имени файла, обозначенная как
ххххх, представляется собой увеличивающийся шестнадцатеричный порядковый номер.
Эти журналы являются предшествующими журналами; всякий раз, когда текущий журнал
заполнен, он переименовывается в следующий предшествующий журнал, и создается
новый журнал Edb.log. Старые журналы автоматически удаляются по мере того, как
изменения, представленные в журналах, переносятся в базу данных Active Directory.
Каждый из этих журналов также занимает 10 Мб.
• Edbtemp.log - временный журнал, который используется тогда, когда заполнен текущий
журнал (Edb.log). Новый журнал создается под именем Edbtemp.log, в нем хранятся все
транзакции, а затем журнал Edb.log переименовывается в следующий предшествующий
журнал. Далее журнал Edbtemp.log переименовывается в журнал Edb.log.
• Resl.log и Res2.log — резервные журналы, которые используются только в ситуации, когда
на жестком диске заканчивается свободное пространство. Если текущий журнал заполнен,
а сервер не может создать новый журнал, потому что на жестком диске нет свободного
пространства, сервер подавит любые транзакции Active Directory, находящиеся в
настоящее время в памяти, использует место для резервных журналов, а затем завершит
работу Active Directory. Размер каждого из этих журналов также 10 Мб.
Совет. Если вы работали с какой-либо из недавних версий Microsoft Exchange Server, то это
обсуждение компонентов и процессов базы данных Active Directory будет звучать для вас очень
знакомым. База данных Active Directory - это та же самая база данных, которая развертывается
с Exchange Server 4 или более поздними версиями.
Каждая модификация к базе данных Active Directory называется транзакцией. Транзакция может
состоять из нескольких шагов. Например, когда пользователь перемещается из одной
организационной единицы (OU) в другую, в OU-адресате должен быть создан новый объект, а в
OU-источнике удален старый объект. Чтобы транзакция была закончена, оба шага должны быть
выполнены, если один из шагов потерпит неудачу, вся транзакция должна получить откат, чтобы
никакой шаг не был засчитан. Когда все шаги в транзакции выполнены, транзакция считается
законченной. Используя модель транзакций, система Windows Server 2003 гарантирует, что база
данных всегда остается в согласованном состоянии.
Всякий раз, когда в базе данных Active Directory делается какое-либо изменение (например,
изменяется номер телефона пользователя), оно сначала записывается в журнал транзакций.
Поскольку журнал транзакций является текстовым файлом, в котором изменения записываются
последовательно, то запись в журнал транзакций происходит намного быстрее, чем запись в базу
данных. Поэтому использование журналов транзакций улучшает работу контроллера домена.
Как только транзакция была записана в журнал транзакций, контроллер домена загружает
страницу базы данных, содержащую пользовательский объект, в память (если она еще не
находится в памяти). Все изменения к базе данных Active Directory делаются в памяти
контроллера домена. Контроллер домена использует максимально доступный объем памяти, и
хранит в памяти максимально большую часть базы данных Active Directory. Контроллер домена
удаляет страницы базы данных из памяти только тогда, когда свободная память становится
ограниченной, или когда контроллер домена выключается. Изменения, сделанные к страницам
базы данных, переписываются в базу данных только тогда, когда сервер мало используется или
при его выключении.
Журналы транзакций не только улучшают работу контроллера домена, обеспечивая место для
быстрой записи изменений, но и обеспечивают возможность восстановления данных в случае
отказа сервера. Например, если было сделано изменение, относящееся к Active Directory, то оно
записывается в журнал транзакций, а затем на страницу базы данных, находящуюся в памяти
сервера. Если в этот момент сервер неожиданно выключается, то изменения не будут переданы из
памяти сервера в базу данных. Когда контроллер домена будет перезапущен, он найдет в журнале
все транзакции, которые еще не были переданы в базу данных. Затем эти изменения применятся к
базе данных при запуске служб контроллера домена. В процессе этого восстановления
используется файл контрольной точки. Файл контрольной точки является указателем на то, какие
транзакции из имеющихся в журнале транзакций, были переписаны в базу данных. В процессе
восстановления контроллер домена читает файл контрольной точки, определяя, какие транзакции
были переданы базе данных, а затем он добавляет в базу данных изменения, которые еще не были
переданы.
Планирование. Использование журналов транзакций улучшает работу контроллеров домена и
увеличивает возможность восстановления данных в случае неожиданного выключения сервера.
Эти преимущества максимальны, если журнал транзакций и база данных расположены на
отдельных жестких дисках.
Служба Active Directory Windows Server 2003 сконфигурирована для циркулярной (circular)
регистрации, и эта конфигурация не может быть изменена. При циркулярной регистрации
сохраняются только те предшествующие журналы, содержащие транзакции, которые не были
переписаны в базу данных. По мере передачи информации из предшествующего журнала в базу
данных журнал удаляется. Циркулярная регистрация предотвращает потерю данных в случае сбоя
на жестком диске вашего контроллера домена, когда вы будете восстанавливать базу данных из
резервной копии. Предположим, что вы выполняете резервное копирование Active Directory
каждую ночь, но жесткий диск вашего контроллера домена сломался в 17:00, после того как вы
сделали несколько сотен изменений к базе данных в течение дня. По мере выполнения изменений
предшествующие журналы транзакций удалялись, поскольку информация из них передавалась в
базу данных Active Directory. Когда вы восстановите базу данных к состоянию, соответствующее
резервной копии предыдущей ночи, все изменения, которые вы сделали в течение дня, будут
потеряны.
Единственный способ предотвратить эту потерю данных состоит в развертывании, по крайней
мере, двух контроллеров домена, которые реплицируют информацию друг другу в течение дня.
Если произойдет сбой на одном из ваших контроллеров домена, то вы сможете восстановить на
нем базу данных из резервной копии, а все вы изменения, сделанные в течение дня, будут
скопированы на восстановленный сервер.
Создание резервной копии Active Directory
Проект Active Directory налагает некоторые важные ограничения на создание резервной копии
Active Directory. Наиболее важное из этих ограничений состоит в том, что Active Directory может
копироваться только как часть данных системного состояния контроллера домена. Данные
системного состояния контроллера домена включают:
• базу данных Active Directory и журналы транзакций;
• системные файлы и файлы запуска, находящиеся под защитой Windows;
• системный реестр контроллера домена;
• всю зонную информацию DNS, интегрированную с Active Directory;
• папку Sysvol;
•
•
базу данных регистрации классов СОМ+;
базу данных службы сертификатов (если контроллер домена является также сервером
службы сертификатов);
• информацию кластерной службы;
• метакаталоги информационной интернет-службы Microsoft (IIS) (если служба IIS
установлена на компьютере).
Все эти компоненты должны копироваться и восстанавливаться целиком из-за их тесной
интеграции. Например, если на сервере службы сертификатов был создан сертификат, который
был назначен на объект Active Directory, то база данных службы сертификатов (содержащая
запись о создании объекта) и объект Active Directory (содержащий запись о том, что сертификат
назначен на объект) должны быть сохранены. Если восстановлен только один из этих
компонентов, вы будете иметь противоречивую информацию.
Программы резервного копирования (backup) могут делать различные типы резервных копий,
включая нормальные, добавочные, дифференцированные и т.д. Резервное копирование системного
состояния контроллера домена всегда является нормальным копированием, когда все файлы,
относящиеся к System State (Состояние системы) копируются и отмечаются как копируемые.
Примечание. По умолчанию только члены группы Administrators (Администраторы) и группы
Backup Operators (Операторы резервного копирования) имеют разрешение делать резервное
копирование контроллеров домена.
Какой из контроллеров домена следует копировать? Общая практика состоит в том, что все
контроллеры домена должны участвовать в цикле регулярного резервного копирования. Одно
исключение к этому правилу можно сделать, если у вас имеется несколько контроллеров домена,
расположенных в одном офисе. В этом случае вы можете осуществлять такую процедуру
восстановления контроллеров домена, в которой вначале будет устанавливаться новый контроллер
домена, а затем заполняться его каталог путем репликации. Однако даже в этом сценарии следует
создавать резервные копии, по крайней мере, некоторых контроллеров домена на случай такой
катастрофы, при которой будут выведены из строя все контроллеры домена в офисе. В любом
случае вы должны создать резервные копии хозяина операций.
Другая проблема, которую нужно рассмотреть в связи с резервным копированием контроллера
домена - это частота создания резервной копии. Служба Active Directory предполагает, что
давность резервной копии не может превышать время жизни объектов-памятников, которая
сконфигурирована для вашего домена. По умолчанию время жизни объекта-памятника составляет
60 дней. Причина этого ограничения связана с тем способом, которым Active Directory использует
объекты-памятники. Когда объект удален, он фактически не удаляется из каталога до тех пор, пока
не истечет время жизни объекта-памятника. Вместо этого объект маркируется как объектпамятник, и большинство его атрибутов удаляются. Затем объект-памятник копируется на все
другие контроллеры домена. По истечении времени жизни объекта-памятника он, наконец, удаляется из
каталога на каждом контроллере домена. Если восстановить контроллер домена из резервной
копии, давность которой превышает время жизни объекта-памятника, то в каталоге можно
обнаружить информацию, несогласованную между контроллерами домена. Допустим, что
пользователь был удален из каталога через день после создания резервной копии, а
соответствующий объект-памятник оставался в каталоге 60 дней. Если бы резервная копия была
восстановлена на контроллере домена более, чем через 60 дней, после того как объект стал
объектом-памятником, то на восстановленном контроллер домена был бы этот пользовательский
объект, и поскольку объект-памятник более не существует, то контроллер домена не стал бы его
удалять. В таком сценарии восстановленный контроллер домена имел бы копию объекта, который
не существует ни в каком другом каталоге. По этой причине система резервирования и программа
восстановления предотвращают попытки восстановления каталога из резервной копии,
хранящейся дольше, чем период удаления объектов-памятников.
Хотя время жизни объектов-памятников накладывает жесткое ограничение на частоту резервного
копирования, вы, очевидно, должны создавать резервные копии контроллеров домена гораздо
чаще, чем каждые 60 дней. Возникнет много проблем, если вы попробуете восстанавливать
контроллер домена из резервной копии, более давней, чем пара дней. Поскольку восстановление
Active Directory включает восстановление всей информации о состоянии системы, то эта
информация будет восстановлена до предыдущего состояния. Если сервер является также
сервером службы сертификатов, то все удостоверения, выпущенные до того, как была создана
резервная копия, не будут включены в базу данных службы сертификатов. Если вы обновили
драйверы или установили какие-либо новые приложения, они не смогут работать, потому что
будет сделан откат системного реестра к предыдущему состоянию. Почти все компании
поддерживают такой режим резервного копирования, в котором некоторые серверы копируются
каждую ночь. Контроллеры домена должны включаться в такой режим резервирования.
Восстановление Active Directory
Есть две причины, по которым вам придется восстанавливать Active Directory. Первая причина
возникнет, когда ваша база данных станет непригодной для использования, потому что на одном
из ваших контроллеров домена произошел отказ в работе жесткого диска, или база данных
испорчена до такой степени, что ее больше не удается загрузить. Вторая причина возникнет, когда
в результате ошибки кто-то удалил OU, содержащую несколько сотен учетных записей
пользователей и групп. В этом случае вы скорее захотите восстановить информацию, чем вводить
ее повторно.
Если вы восстанавливаете Active Directory, потому что базу данных на одном из ваших
контроллеров домена больше нельзя использовать, у вас есть два варианта. Первый вариант
состоит в том, чтобы вообще не восстанавливать Active Directory на отказавшем сервере, а создать
еще один контроллер домена, назначив другой сервер, на котором выполняется система Windows
Server 2003, контроллером домена. Таким способом вы восстановите функциональные
возможности контроллера домена, а не службу Active Directory на определенном контроллере
домена. Второй вариант состоит в восстановлении отказавшего сервера и последующем
восстановлении базы данных Active Directory на этом сервере. В этом случае вы выполните
восстановление при отсутствии полномочий (nonauthoritative). При таком восстановлении база
данных Active Directory восстанавливается на контроллере домена, а затем все изменения,
сделанные к Active Directory после создания резервной копии, реплицируются на
восстановленный контроллер домена.
Если вы восстанавливаете Active Directory, потому что кто-то удалил большое количество
объектов из каталога, у вас есть только один способ. Вы должны восстановить базу данных Active
Directory на одном из контроллеров домена, используя резервную копию, которая содержит
удаленные объекты. Затем вы должны сделать восстановление при наличии полномочий
(authoritative), в процессе которого все восстановленные данные отмечаются так, чтобы они
реплицировались на все другие контроллеры домена, перезаписывая удаленную информацию.
Восстановление Active Directory путем создания нового
контроллера домена
Один из вариантов восстановления функциональности Active Directory состоит в создании нового
контроллера домена, заменяющего отказавший контроллер домена. Если один контроллер домена
выйдет из строя, вы можете создать другой сервер, на котором будет выполняться Windows Server
2003 и Active Directory 2003, или назначить контроллером домена один из уже имеющихся
серверов. Затем можно использовать обычную репликацию Active Directory для заполнения базы
данных Active Directory нового контроллера домена. Создание нового контроллера домена
является наилучшим решением в следующих ситуациях.
• В дополнение к отказавшему серверу у вас имеется еще один доступный контроллер
домена - это необходимое требование. Если нет другого контроллера домена, который
доступен как партнер по репликации, то остается единственный вариант восстановления
базы данных Active Directory на новом или на отремонтированном контроллере домена.
• На создание нового контроллера домена и репликацию информации с другого контроллера
домена требуется значительно меньше времени, чем на ремонт отказавшего контроллера
домена и на восстановление базы данных. Этот расчет зависит от размера базы данных
Active Directory, скорости сетевой передачи данных между вашими контроллерами домена
и скоростью, с которой вы можете создавать и восстанавливать контроллеры домена. Если
база данных Active Directory относительно мала (менее 100 Мб), а второй контроллер
домена находится в той же самой локальной сети, то создание другого контроллера домена
и репликация базы данных пройдет быстрее, чем ремонт и восстановление отказавшего
контроллера домена. Если ваша база данных велика или единственный доступный партнер
по репликации отказавшего контроллера домена связан с ним через медленную
глобальную сеть (WAN), то ремонт вышедшего из строя контроллера домена и
восстановление базы данных будет более быстрым способом.
• Вы не можете отремонтировать отказавший контроллер домена. Возможно восстановление
Windows Server 2003 и базы данных Active Directory на сервере, имеющем аппаратные
средства, отличные от первоначального контроллера домена, однако этот процесс обычно
труден и занимает много времени. Если вы не можете воссоздать отказавший сервер так,
чтобы он имел похожие аппаратные средства, то создание другого контроллера домена
займет меньше времени.
Планирование. Варианты восстановления, перечисленные выше, не потребуются, если вы
сможете отремонтировать отказавший контроллер домена без необходимости создавать его
заново и восстанавливать. Система Windows Server 2003 обеспечивает несколько
усовершенствованных опций поиска неисправностей, таких как Last Known Good Configuration
(Последняя известная хорошая конфигурация) и Safe Mode (Безопасный режим). Используйте эти
инструментальные средства, чтобы попробовать вернуть контроллер домена в рабочее
состояние, прежде чем начнете выполнять полное восстановление.
Чтобы создать дополнительный контроллер домена, который заменит отказавший сервер,
используйте уже имеющийся сервер с системой Windows Server 2003 (или создайте новый сервер)
и назначьте его контроллером домена. В процессе назначения сервера контроллером домена
каталог будет реплицирован с одного из других контроллеров домена. Если отказавший
контроллер домена служил сервером глобального каталога (GC) или выполнял роль одного из
хозяев операций, вы должны подумать о том, как восстановить эти функциональные возможности.
Восстановление GC-серверов и серверов хозяев операций описано подробно далее в этой главе.
Как говорилось в главе б, Windows Server 2003 обеспечивает опцию установки нового контроллера
домена и загрузки базы данных Active Directory из восстановленной резервной копии вместо
использования обычного процесса репликации. Эта опция очень полезна при создании
контроллера домена в удаленном офисе, связанном с центральным офисом через медленную
сетевую связь, потому что полный объем данных, связанных с начальной репликацией, не должен
пересекать глобальную связь WAN. Если вы имеете хорошую резервную копию отказавшего
контроллера домена в удаленном офисе, можно использовать такую же методику для создания
нового контроллера домена.
Если вы решите восстанавливать функциональные возможности Active Directory через создание
нового контроллера домена, вы все равно должны будете удалить старый контроллер домена из
каталога и из DNS. Если вы планируете использовать имя отказавшего контроллера домена для
восстановленного контроллера домена, вы должны очистить каталог перед началом
восстановления. Если вы используете другое имя для нового контроллера домена, нужно очистить
каталог после инсталляции.
Чтобы очистить каталог, выполните следующие действия на любой рабочей станции или сервере с
системой Windows 2000, на рабочей станции Windows XP Professional или на сервере Windows
Server 2003 /который является членом домена.
Откройте командную строку и напечатайте ntdsutil.
В командной строке утилиты Ntdsutil напечатайте metadata cleanup.
В окне Metadata Cleanup (Очистка мета-данных) напечатайте connections. Эта команда
используется для соединения с текущим контроллером домена с целью удаления
отказавшего контроллера домена.
В окне Server Connections (Подключение к серверу) напечатайте connect to server servername
(соединиться с сервером servername), где servername - имя доступного контроллера
домена. Если вы войдет в систему под учетной записью с административными правами в
Active Directory, вы подключитесь к этому контроллеру домена. Если вы не имеете
административных прав, используйте команду set creds domain username password, чтобы
ввести «верительные грамоты» пользователя, имеющего разрешения уровня домена. Если
вы напечатаете help в окне Server Connections, то увидите, что одна из опций ваших команд
— это connect to server %s (соединиться с сервером %s). Переменная %s должна всегда
заменяться значением, имеющим тип символьной строки. В этом случае строка является
или DNS-именем контроллера домена, или IP-адресом сервера.
В окне Server Connections напечатайте quit, чтобы возвратиться в окно Metadata Cleanup.
Напечатайте select operation target (выбрать адресата операции). Эта команда используется для
выбора домена, сайта и контроллера домена, чтобы вы могли удалить контроллер домена.
В окне Select Operation Target напечатайте list domains (перечислить домены). Все домены
вашего леса перечисляются с назначенными каждому их них номерами.
Напечатайте select domain number (выбрать номер домена), где number указывает домен,
содержащий отказавший контроллер домена. Если вы напечатаете help перед тем, как
напечатать select domain number, то увидите, что одна из опций команды -select domain %d
(выбрать домен %d). Переменная %d должна всегда заменяться числом.
Напечатайте list sites (перечислить сайты). Будут перечислены все сайты леса.
Напечатайте select site number (выбрать номер сайта), чтобы выбрать сайт, содержащий
контроллер домена, который вы должны удалить.
Напечатайте list servers in site (перечислить серверы в сайте). Все контроллеры домена,
имеющиеся в выбранном сайте, будут перечислены. Используйте команду select server
number, чтобы выбрать контроллер домена, который вы должны удалить. Утилита Ntdsutil
покажет*выбранный домен, сайт и контроллер домена (см. рис. 15-1.)
Рис. 15-1. Отображение домена, сайта и контроллера домена в утилите Ntdsutil
Напечатайте quit. Вы вфнетесь в окно Metadata Cleanup.
Напечатайте remove selected server (удалите выбранный сервер). Вас попросят подтвердить,
что вы хотите удалить сервер из каталога. Щелкните на Yes (Да).
Чтобы выйти из утилиты Ntdsutil, печатайте quit в каждой командной строке, пока не выйдите
из программы.
Инструмент Ntdsutil
В главе 14 были показаны примеры использования утилиты Ntdsutil для управления базой данных
Active Directory. Ntdsutil - это инструмент командной строки, который применяется для
управления некоторыми компонентами Active Directory и базой данных. Ntdsutil является мощным
инструментом, им надо пользоваться с осторожностью.
Запустите инструмент Ntdsutil, напечатав в командной строке ntdsutil. Инструмент выдает
приглашение к вводу команд Ntdsutil. Вы можете вводить разнообразные команды в зависимости
от того, что вы хотите
сделать. Если вы напечатаете help в любой командной строке, то получите список всех команд,
которые можно использовать в этом положении. На рисунке 15-2 показан список команд,
доступных из окна Ntdsutil.
Рис. 15-2. Список команд, доступных из командной строки в утилите Ntdsutil
Далее вы увидите еще несколько примеров использования утилиты Ntdsuti для управления
службой Active Directory. Более детальную информацию по использованию утилиты Ntdsutil
смотрите в Help And Support Center.
После очищения каталога от ненужных объектов с помощью Ntdsutil нужно очистить также DNSзаписи отказавшего контроллера домена. Удалите все DNS-записи из DNS, включая все записи,
касающиеся контроллера домена, записи GC-сервера и записи эмулятора основного контроллера
домена (PDC). (Две последних записи существуют только в том случае, если контроллер домена
был сконфигурирован на выполнение этих ролей.) Если вы не очистите записи DNS, клиентьТ
продолжат получать информацию DNS и будут соединяться с этим контроллером домена.
Нужно также удалить вышедший из строя контроллер домена из сайта и домена. Для этого
используйте инструмент Active Directory Users And Computers (Пользователи и компьютеры Active
Directory) и удалите объект, связанный с этим компьютером, из OU Domain Controllers
(Контроллеры домена). В инструменте Active Directory Sites And Services (Сайты и службы Active
Directory) удалите объект, связанный с этим компьютером, из контейнера Servers (Серверы) того
сайта, в котором он был расположен.
Выполнение неофициального восстановления
Вторая опция по восстановлению базы данных Active Directory состоит в ремонте отказавшего
контроллера домена с последующим восстановлением базы данных. Вместо восстановления
отказавшего контроллера домена можно восстановить базу данных на новый сервер.
Восстановление базы данных на новом или исправленном сервере является наилучшим выбором
при следующих обстоятельствах.
• Сервер является единственным контроллером домена в домене. Если дело обстоит так, у вас
нет выбора, как восстанавливать службу Active Directory. Вы должны восстановить базу данных
на новом или исправленном сервере.
•
Репликация информации с другого контроллера домена займет слишком много времени. В
некоторых случаях вы восстановите отказавший контроллер домена и базу данных быстрее, чем
инсталлируете новый контроллер домена и создадите базу данных путем репликации. Такая
ситуация реализуется почти всегда, если отказавший контроллер домена связан медленными
сетевыми связями с любым другим контроллером домена. Даже если он связан с другими
контроллерами через более быструю сетевую связь, вам все-таки может быть выгоднее
восстанавливать базу данных.
Планирование. Без тестирования различных вариантов в вашей конкретной среде трудно
сказать, что является более быстрым: восстановление контроллера домена с резервной
магнитной ленты или восстановление Active Directory путем создания дополнительного
контроллера домена. Иногда совершенно ясно, что на создание нового контроллера домена уйдет
меньше времени, если имеется сервер с системой Windows Server 2003, установленный на
быстром сегменте сети, который вы можете сделать контроллером домена, и размер вашей
базы данных Active Directory меньше, чем 100 Мб. В других случаях совершенно ясно, что меньше
времени займет ремонт отказавшего контроллера домена и восстановление доменной
информации с резервной копии, если ваша база данных имеет размер в несколько сотен мегабайт,
и все другие контроллеры домена связаны медленными сетевыми связями. Однако большинство
сетевых сценариев находится между этими двумя крайностями. Единственный способ узнать,
какой вариант является более быстрым в вашей среде, состоит в тестировании обоих варианта
задолго до того, как вам придется делать выбор.
Чтобы восстановить базу данных Active Directory, вы должны иметь хорошую резервную копию
контроллера домена. Если потерпит аварию жесткий диск, содержащий только базу данных Active
Directory, вы сможете загрузиться в режим восстановления Active Directory и восстановить данные
состояния системы. Если потерпит аварию также и системный диск, вы должны починить
аппаратные средства, а затем восстановить сервер.
В некоторых случаях вы будете восстанавливать контроллер домена на сервере, который
использует другой набор аппаратных средств, чем тот, который был доступен на первоначальном
сервере. Хотя вполне возможно восстановить Windows Server 2003 на аппаратных средствах,
отличающихся от аппаратных средств сервера, с которого было сделана резервная копия, этот
процесс чреват проблемами. Если вы попробуете восстановить Windows Server 2003 на сервере с
отличающимися аппаратными средствами, выберите аппаратные средства, которые будут
максимально совместимы. Гарантируйте, что уровень аппаратного абстрагирования (hardware
abstraction layer - HAL), видеокарты и сетевые платы идентичны. Кроме того, конфигурация
жесткого диска на новом сервере должна быть такой же, как на отказавшем. Даже если вы будете
соблюдать эти предосторожности, восстановление системы Windows Server 2003 на сервер с
другими аппаратными средствами труден, и успех не гарантирован. Возможная альтернатива
состоит в создании контроллера домена из резервной копии. В этом случае вы сможете
воспользоваться преимуществом чистой инсталляции системы Windows Server 2003, и в то же
время сможете создать начальную копию базы данных из резервной копии, а не через репликацию.
Автоматизированное восстановление системы
Один из вариантов резервирования и восстановления в Windows Server 2003 - это
автоматизированное восстановление системы (Automated System Recovery - ASR). Эта опция
упрощает процесс восстановления данных состояния системы. Прежде чем вы будете
использовать ASR, создайте ASR-копию, т.е. помощью инструмента Backup сделайте резервную
копию данных состояния системы и создайте загрузочный диск ASR. Загрузочный диск содержит
файлы, необходимые для загрузки сервера, а также информацию о конфигурации жесткого диска
на сервере и резервную копию состояния системы. Если сервер выйдет из строя, эта ASR-копия
может использоваться для частичной автоматизации восстановления сервера.
Если вы сделали какие-либо изменения к Active Directory после создания резервной копии, то они
будут отсутствовать в копии. Однако другие контроллеры домена в домене будут иметь самую
современную информацию. Если вы восстанавливаете контроллер домена в связи с поломкой
сервера, то контроллер домена должен получить изменения от своих партнеров по репликации
после того, как закончится восстановление. Для этого сделайте восстановление без полномочий.
Чтобы сделать восстановление без полномочий, выполните следующие действия.
Восстановите отказавший контроллер домена и повторно установите на сервере систему
Windows Server 2003. После восстановления сер1. вера перезапустите его и нажмите клавишу F8, чтобы загрузить Windows Advanced Options
Menu (Меню дополнительных параметров Windows).
2. Выберите загрузку контроллера домена в режиме восстановления службы каталога
Directory Services Restore Mode (Windows Domain Controllers Only) (Только контроллеры
домена с системой Windows)). После этого контроллер домена загрузится в безопасном
режиме, но не будут загружены компоненты Active Directory.
3. Выберите операционную систему, которую вы хотите запустить.
4. Войдите на сервер, используя учетную запись Administrator с паролем Directory Services
Restore (Восстановление службы каталога), который был сконфигурирован на контроллере
домена при инсталляции Active Directory.
5. Испсшьзуйте программку создания резервной копии и восстановления системы, чтобы
восстановить данные System State (Состояние системы) на сервере.
6. После восстановления данных перезагрузите контроллер домена.
7. После перезагрузки контроллер домена свяжется со своими партнерами по репликации и
начнет обновлять собственную базу данных, чтобы отразить все изменения доменной
информации, сделанные с момента создания резервной копии.
Примечание. Восстанавливать информацию Active Directory могут только локальные
администраторы. Эта учетная запись создается при инсталляции Active Directory на
контроллере домена. Пароль для нее конфигурируется в это же время. Пароль может быть
переустановлен только через утилиту Ntdsutil.
Выполнение восстановления с полномочиями
В некоторых случаях восстановление без полномочий не годится для решения проблемы, с
которой вы имеете дело. Например, если кто-то только что удалил OU, содержащую несколько
сотен пользователей, не нужно, чтобы контроллер домена просто перезагрузился после
выполнения восстановления, а затем начал репликацию с других контроллеров домена. Если вы
так сделаете, то контроллер домена получит информацию об удалении OU от своих партнеров по
репликации, и к тому времени, как вы откроете инструмент Active Directory Users And Computers,
OU будет удалена снова.
В этом сценарии нужно использовать восстановление с полномочиями для гарантии того, что
восстановление OU будет реплицировано на другие контроллеры домена. Когда вы делаете это
восстановление, восстанавливается резервная копия Active Directory, которая была сделана до
того, как данные были удалены, а затем делаете принудительную
репликацию этих данных на другие контроллеры домена. Принудительная репликация делается
путем манипулирования порядковым номером обновления (USN) для восстановленной
информации. По умолчанию, когда вы делаете восстановление с полномочиями, номер USN на
восстановленных объектах увеличивается на 100000, чтобы восстановленный объект стал
полномочной копией для всего домена.
Проблемы восстановления с полномочиями
Есть несколько существенных проблем восстановления с полномочиями. Наиболее важная
проблема имеет отношение к групповому членству. В некоторых случаях восстановление с
полномочиями может приводить к неправильному групповому членству на контроллерах домена,
которые не были восстановлены с полномочиями. Неправильное членство возникает, когда
объект, восстановленный с полномочиями (например, OU), содержит учетные записи групп и
пользователей. При восстановлении с полномочиями объект OU и объекты пользователей и групп
реплицируются на все другие контроллеры домена. Неправильное членство получается, когда
восстановленная информация о группе реплицируется на контроллер домена-адресата, прежде чем
реплицируется пользовательская информация. Когда контроллер домена-адресата получает
группу, он замечает, что одна или более учетных записей пользователей, перечисленных в группе,
не имеет правильной учетной записи пользователя, и он удаляет пользователей из группы. Когда
затем на контроллер домена-адресата реплицируется учетная запись пользователя, она не
добавляется назад к группе. Если пользовательская информация реплицируется перед
информацией группы, то члены группы будут назначены правильно. К сожалению, нет никакого
способа управлять очередностью реплицирования объектов.
Единственный способ исправить эту потенциальную ошибку состоит в том, чтобы создать
временную учетную запись и добавить ее к каждой группе, на которую воздействует
восстановление с полномочиями. Вы должны сделать это после того, как контроллер домена
перезагрузился, и завершилась начальная полномочная репликация. Добавление члена к группе
заставляет контроллер домена копировать список членов группы на все другие контроллеры
домена. Если эти контроллеры домена удалили учетную запись пользователя из группы, то они
восстановят ее после получения модифицированного списка членов группы.
Другая потенциальная проблема, касающаяся группового членства, может произойти в том случае,
если групповое членство было изменено на другом контроллере домена до или в процессе
официального восстановления. В этом случае измененное групповое членство могло бы
реплицироваться на все контроллеры домена, кроме контроллера домена, выполняющего
официальное восстановление. Официальное восстановление устанавливает номер USN для
восстановленных объектов выше, чем USN, приписанный только что измененному групповому
членству.
Таким образом, контроллер домена, выполняющий восстановление с полномочиями, никогда не
получит модифицированную информацию о членстве группы, и информация каталога не будет
согласована между различными контроллерами домена. Эта несогласованность может быть
обнаружена только при рассмотрении списка членов каждой группы. Самый простой способ
решения этой проблемы состоит в обновлении списков членов группы вручную.
Третья проблема имеет отношение к домену и доверительным отношениям компьютеров. Когда к
домену добавляется компьютер, на котором выполняется система Microsoft Windows NT, Windows
2000, Windows XP Professional или Windows Server 2003, то создается пароль, известный только
контроллеру домена и добавленному компьютеру-члену домена. Этот пароль используется для
поддержания доверительных отношений между компьютером и доменом. По умолчанию пароль
изменяется каждые семь дней. Если вы выполняете восстановление с полномочиями, то будут
восстановлены пароли, которые были в использовании при создании резервной копии. Если
компьютер-член домена уже получил другой пароль, то доверительные отношения между
доменом и компьютером-членом домена не будут функционировать. Доверительные отношения
NTLM между доменами Active Directory и доменами Windows NT используют похожие правила,
поэтому они также могут перестать работать, если будет восстановлен старый пароль.
Доверительные отношения домена можно восстановить, удаляя старые доверительные отношения
и создавая их заново. Доверительные отношения рабочей станции с доменом можно восстановить,
используя инструмент командной строки NetDom или удаляя рабочую станцию из домена, а затем
добавляя ее назад.
Предостережение. Проблемы, которые возникают в результате использования восстановления с
полномочиями, предполагают его использование с осторожностью. Эти проблемы показывают
важность регулярного создания резервных копий ваших контроллеров домена. Чем старее
резервная копия каталога, тем более вероятно, что вы столкнетесь с этими проблемами. Кроме
того, вы должны иметь хорошо спроектированную и отработанную программу восстановления
после сбоя для восстановлений. Чем быстрее вы можете восстановить каталог, тем меньше
проблем вы будете иметь.
Процедура восстановления с полномочиями
Наиболее типичным вариантом восстановления с полномочиями, вероятно, будет восстановление
только части каталога. Например, если кто-то случайно удалит OU, вы должны восстановить с
полномочиями только эту OU, а не весь каталог.
Чтобы выполнить восстановление с полномочиями, сделайте следующее.
1. Выполните шаги с первого по пятый процедуры восстановления без полномочий; не
перезагружайте сервер, когда восстановление закончено.
2. Откройте командную строку и напечатайте ntdsutil.
3. В окне Ntdsutil напечатайте authoritative restore (восстановление с полномочиями).
4. В окне Authoritative Restore напечатайте restore subtree objectname (восстановление
поддерева objectname). Например, чтобы восстановить OU Managers в домене
NWTraders.com, нужно напечатать restore subtree ou=managers ou,dc~nwtraders,dc=com.
Вы можете также восстановить индивидуальную группу, учетные записи пользователей
(например, restore subtree en—managerl,ou—managers ou, dc—nwtraders,dc=com)
или раздел приложений.
5. Чтобы восстановить с полномочиями весь каталог, напечатайте restore database
(восстановить базу данных) в окне команды Authoritative Restore.
6. Выйдите из утилиты Ntdsutil и перезагрузите сервер.
Предостережение. В некоторых случаях потребуется восстановление всей базы данных
Active Directory, используя восстановление с полномочиями. Такое восстановление всего
каталога - это очень важная операция, она должна выполняться только в тех случаях, когда
была разрушена база данных или произошла какая-то другая очень серьезная ошибка.
Восстановление с полномочиями всего каталога увеличивает номер USN на каждом объекте
в домене и в разделах конфигурации каталога на 100000. Раздел схемы не может быть
восстановлен такими образом.
Восстановление информации Sysvol
До настоящего момента эта глава была посвящена восстановлению базы данных Active Directory,
содержащей учетные записи и параметры настройки для домена или леса. Однако папка Sysvol на
каждом контроллере домена тоже содержит критическую информацию, касающуюся домена,
такую как шаблоны групповых политик и сценарии, используемые компьютерами или
пользователями в сети. Поэтому восстановление информации Sysvol может быть столь же
важным, как и восстановление базы данных Active Directory.
Резервная копия папки Sysvol создается как часть информации о состоянии системы, касающейся
контроллера домена, т.е. если контроллер домена выйдет из строя, то информация Sysvol может
быть восстановлена как часть обычного процесса восстановления контроллера
домена. Кроме того, если вы не хотите восстанавливать контроллер домена, а только восстановить
его функциональные возможности, создавая другой контроллер домена в домене, то информация
Sysvol будет реплицироваться с любых существующих контроллеров домена. Это происходит при
помощи службы репликации файлов (File Replication Service - FRS), а не в процессе репликации
Active Directory.
Потенциально может возникнуть одно осложнение, если вам надо выполнить восстановление с
полномочиями для контейнера Sysvol. Например, если кто-то удалил все сценарии входа в
систему, находившиеся в папке Sysvol, вы захотите восстановить сценарии, вместо того чтобы
заново создавать их. Проблема состоит в том, что, если удаление было реплицировано на все
другие контроллеры домена, то оно будет иметь более довременное репликационное значение, чем
на восстановленном контроллере домена. Поэтому если вы выполните просто обычное
восстановление контроллера домена, то он реплицирует удаление с другого контроллера домена.
Решение проблемы состоит в том, чтобы выполнить основное (primary) восстановление
информации Sysvol. Если вы используете системную резервную копию сервера Windows Server
2003 и программу восстановления, то будет выполняться обычное восстановление без
полномочий, но при выполнении программы восстановления не следует принимать заданные по
умолчанию параметры настройки восстановления. Вместо этого в окне Advanced Restore Options
(Дополнительные опции восстановления) мастера восстановления выберите опцию When Restoring
Replicated Data Sets, Mark The Restored Data As The Primary Data For All Replicas (При
восстановлении наборов реплициру-емых данных отмечать восстановленные данные как основные
для всех реплик) (см. рис. 15-3). В результате папка Sysvol на этом контроллере домена будет
отмечена, как основной контейнер для репликации Sysvol.
Рис. 15-3. Выполнение основного восстановления для Sysvol информации
Восстановление хозяев операций и серверов глобального
каталога
Роли серверов-хозяев операций требуют дополнительных соображений при планировании
восстановления каталога после сбоя. Роли хозяев операций могут быть распределены между
несколькими контроллерами домена, но в каждый момент времени каждая роль может
удерживаться только одним контроллером домена в домене или лесе. Поэтому восстановление
этих ролей отличается от восстановления контроллеров домена, которым не назначены роли
хозяев операций. Восстановления контроллеров домена состоит, по существу, из таких же
процедур, как и восстановления любого другого контроллера домена. Различие состоит в
планировании того, что должно входить в восстановление после сбоя. Поскольку только один
контроллер домена может удерживать определенную роль, то вы должны определить, как долго
сеть будет работать без этого хозяина операций. В некоторых случаях отсутствие хозяина
операций не причинит никаких неприятностей в течение нескольких дней, в других случаях отказ
в выполнении функций этой роли может дать немедленный эффект. Если вы сможете
восстановить контроллер домена, прежде чем понадобится роль хозяина операций, то вы можете
восстановить контроллер домена и выполнить восстановление без полномочий сервера. Хозяин
операций будет восстановлен после восстановления сервера.
Иногда вы можете решить, что восстановление отказавшего контроллера домена займет больше
времени, чем время, в течение которого ваша сеть может обходиться без этого хозяина операций.
Или вы решите, что вообще не хотите восстанавливать этот контроллер домена, но предпочли бы
создать новый и передать роль хозяина операций ему. Передача роли хозяина операций проста,
если оба контроллера домена находятся в интерактивном режиме, потому что они оба могут
гарантировать, что завершат репликацию прежде, чем была передана роль хозяина операций.
Однако если хозяин операций вышел из строя, и вы должны переместить его роль на другой
контроллер домена, то нужно захватить эту роль.
Планирование. Из-за важности ролей, которые играют серверы-хозяева операций в сети, вы
должны тщательно планировать размещение и управление этими ролями. Хозяин операций
должен всегда включаться в регулярный режим резервного копирования. Он должен быть
расположен в том же самом сайте, где находится, по крайней мере, один контроллер домена,
содержащий информацию, имеющуюся у хозяина операций.
Например, если пользователь только что изменил свой пароль, используя клиента низкого уровня,
то это изменение было сделано на эмуляторе PDC. Эмулятор PDC будет реплицировать это
изменение партнеру по репликации, расположенному в том же самом сайте, в пределах 15 секунд.
Если в этом сайте нет партнера по репликации, то репликация пароля не произойдет до
следующей запланированной репликации между сайтами. Если контроллер домена выйдет из
строя перед этим запланированным временем, то изменение пароля не будет реплицироваться на
другие сайты. Если контроллер домена находится там же, где сервер хозяина операций, то
вероятность неполной репликации гораздо меньше. Контроллер домена, находящийся в том же
сайте, где расположен хозяин операций, является также наилучшим кандидатом на захват роли
хозяина операций, потому что он имеет самую свежую информацию от хозяина операций. Если у
вас имеется больше одного дополнительного контроллера долена в том же самом сайте, где
расположен отказавший хозяин операций, то вы можете использовать команду repadmin/
showvector namingcontext, чтобы определить, какой из контроллеров домена имеет самые свежие
обновления с вышедшего из строя контроллера домена.
Чтобы захватить роли хозяина операций, вы можете использовать утилиту Ntdsutil или инструмент
Active Directory Users And Computers (чтобы захватить роли эмулятора PDC и хозяина
инфраструктуры). Роли хозяина RID, хозяина схемы и хозяина именования доменов можно
захватить только с помощью утилиты Ntdsutil.
Чтобы захватить роли хозяина операций с помощью утилиты Ntdsutil, выполните следующие
действия.
1. Откройте командную строку и напечатайте ntdsutil.
2. В окне команд Ntdsui^l напечатайте roles (роли).
3. В окне койанд Fsmo Maintenance (Обслуживание Fsmo) напечатайте connections
(подключения).
4. В окне команд Server Connections (Подключения сервера) напечатайте connect to server
servername.domainname (соединиться с сервером servername.domainname), где servername контроллер домена, на котором вы хотите захватить роль хозяина операций. Напечатайте
quit (выход).
5. В окне команд Fsmo Maintenance напечатайте seize operations_master_role (захватить роль
хозяина операций). Где operations_master_role — это роли, которые вы хотите захватить:
schema master (хозяин схемы), domain naming master (хозяин именования доменов),
infrastructure master (хозяин инфраструктуры), RID-master (хозяин RID) или PDC.
6. Примите предупреждение. Сервер сначала будет пробовать выполнить нормальную
передачу роли хозяина операций. Если это не получится, потому что с вышедшим из строя
контроллером домена нельзя войти в контакт, то роль будет захвачена. На рисунке 15-4
смотрите пример захвата роли хозяина RID.
Рис. 15-4. Вывод утилиты Ntdsutil при захвате роли хозяина RID
7. Напечатайте quit (выход) в каждой командной строке, пока не выйдете из утилиты Ntdsutil.
Эмулятор PDC и роль хозяина инфраструктуры могут быть захвачены также через инструмент
администрирования Active Directory Users And Computers. Откройте инструмент Active Directory
Users And Computers и используйте опцию Connect To Domain Controller (Подключиться к
контроллеру домена), чтобы удостовериться, что он связан с контроллером домена, на котором вы
хотите захватить роль. Затем щелкните правой кнопкой мыши на имени домена и выберите
Operations Masters (Хозяева операций). Если вы попробуете захватить роль, получите
предупреждающее сообщение (см. рис. 15-5). Если вы выберите вынужденную передачу, то роль
хозяина операций будет захвачена. Только эмулятор PDC и роль хозяина инфраструктуры могут
быть захвачены таким образом, т.е. попытки передать любую другую роль хозяина операций с
помощью другого инструмента, кроме утилиты Ntdsutil, потерпят неудачу.
Рис. 15-5. Предупреждающее сообщение, полученное при захвате роли хозяина операций
через инструмент Active Directory Users And Computers
Эмулятор PDC
В большинстве сетей отказ эмулятора PDC обычно вызывает немедленный отклик, чем отказ
любого другого хозяина операций. В домене, который работает на функциональных уровнях
Windows 2000 mixed (смешанный) или Windows Server 2003 interim (временный), эмулятор PDC
является основным (primary) партнером по репликации для всех резервных копий контроллеров
домена Windows NT (BDC). Пока не восстановлен эмулятор PDC BDC-контроллеры не будет
получать модифицированную информацию. Кроме того, низкоуровневые клиенты типа Windows
NT, Windows 95 и Windows 98 (не имеющие клиентов службы каталога) должны соединяться с
эмулятором PDC, чтобы пользователь имел возможность изменять свой пароль. Даже в домене,
работающем на функциональном уровне Windows 2000 native (естественный) или на более
высоком, эмулятор PDC играет роль основного партнера по репликации для замен пароля.
Эмулятор PDC является также предпочтительным сервером для создания каких-либо изменений к
групповым политикам. Если эмулятор PDC недоступен, когда вы пытаетесь просмотреть
групповые политики, вы получите предупреждающее сообщение. Поскольку эмулятор PDC
поддерживает все эти службы, то восстановление роли эмулятора PDC в сети должно иметь
высокий приоритет.
Хотя эмулятор PDC играет важнейшую роль в домене, захват этой роли другим контроллером
домена, в то время как оригинальный эмулятор PDC недоступен, имеет свои ограничения.
Фактически, захват этой роли подобен захвату роли PDC в домене Windows NT. Если PDC когдалибо выходил из строя в домене Windows NT, вы могли выбирать другой контроллер домена и
конфигурировать его так, чтобы он был PDC-KOH-троллером. Те же самые функциональные
возможности существуют в Windows Server 2003. Если эмулятор PDC выходит из строя, вы
должны передать эту роль на другой контроллер домена. Даже если контроллер домена будет
недоступен только в течение пары часов, все равно нужно передать эту роль. Когда оригинальный
эмулятор PDC будет восстановлен и снова связан с сетью, он обнаружит присутствие нового
эмулятора PDC и уступит ему эту роль.
Хозяин схемы
Хозяин схемы играет важнейшую роль в домене сервера Windows Server 2003, но эта роль
используется очень редко. Хозяин схемы является единственным контроллером домена, в котором
может быть изменена схема. Если этот сервер выйдет из строя, вы не сможете делать изменения к
схеме, пока сервер не будет восстановлен или пока эта роль не будет захвачена другим
контроллером домена.
Функциональные возможности хозяина схемы используются редко, потому что в большинстве
сетей схема изменяется редко. Требуется проводить испытание для гарантии того, что изменение
схемы совместимо с текущей схемой. Это означает, что изменение схемы было запланировано
на определенное время, и в большинстве случаев задержка в развертывании изменений схемы до
того времени, пока не будет восстановлен хозяин схемы, не должна вызывать проблем. Однако
если вы не планируете восстанавливать хозяина схемы, можно захватить эту роль другим
контроллером домена, используя утилиту Ntdsutil. Если вы захватываете роль хозяина схемы
другим контроллер домена, то первоначальный хозяин схемы более не должен восстанавливаться
в сети.
Совет. Для всех ролей хозяев операций, кроме эмулятора PDC и хозяина инфраструктуры,
примите следующую рекомендацию. Если вы захватили эту роль, передав ее другому контроллеру
домена, то вы не должны восстанавливать в сети первоначального хозяина операции, потому
что существует риск создания несовместимых изменений в сети. Например, если захватывается
роль хозяина схемы, а затем делаются изменения к схеме, то первоначальный хозяин схемы не
получит эти изменения. Если вы не делаете никаких изменений к схеме, то нет проблем. Однако
если не планируются изменения к схеме, в то время как хозяин схемы находится в автономном
режиме, то в действительности и нет необходимости захватывать его роль.
Хозяин именования доменов
Хозяин именования доменов — это еще одна роль, которая редко используется. Он необходим
только при добавлении или удалении доменов. Если этот контроллер домена недоступен в течение
короткого периода времени, то в устойчивой производственной среде это не вызовет серьезных
последствий. Однако если вам нужно добавить или удалить домен, и у вас нет времени на
восстановление хозяина именования доменов, то вы можете захватить эту роль. Как и в случае с
хозяином схемы, если вы захватите роль хозяина именования доменов, передав ее на другой
контроллер домена, первоначальный хозяин этой операции уже не должен возвращаться в
интерактивный режим, если только на этом сервере не была заново инсталлирована операционная
система, устранившая с него сервера роль хозяина именования доменов.
Примечание. В большинстве сетей роли хозяина схемы и хозяина именования доменов
используются настолько редко, что если эти контроллеры домена выходят из строя, их не
нужно захватывать, передавая их другому серверу. Однако эти контроллеры домена обычно
располагаются в корневом домене леса, а контроллеры домена корня леса имеют важное
значение. Если у вас имеется только один контроллер домена корня леса и он выходит из строя,
это, безусловно, окажет воздействие на сеть. Любой тип деятельности, охватывающий
несколько доменов, такой как вход на другие домены, кроме вашего домашнего домена, или доступ к ресурсам, расположенным в другом
домене, будет вызывать отказ, если отсутствуют другие корневые контроллеры домена (кроме тех
случаев, когда существует другой путь через доверительные отношения между доменами). Таким
образом, хотя хозяин схемы и хозяин именования доменов не обязательно должны быть всегда
доступны, но в вашем корневом домене должен быть всегда доступен, по крайней мере, один
контроллер домена.
Хозяин инфраструктуры
Роль хозяина инфраструктуры наименее существенна с точки зрения восстановления системы
после сбоя. Хозяин инфраструктуры следит за изме-нением отображаемых имен для учетных
записей пользователей и групп в среде, состоящей из нескольких доменов. Эта деятельность
прозрачна для обычных пользователей, и может стать проблемой только тогда, когда
администраторы рассматривают членство группы. Поэтому захват роли хозяина инфраструктуры
должен иметь довольно низкий приоритет из-за того, что эта роль не оказывает влияния на какиелибо сетевые службы.
Если вы решите захватить роль хозяина инфраструктуры и передать ее на другой контроллер
домена в среде, состоящей из нескольких доменов, вы должны гарантировать, что контроллер
домена-адресата не является GC-сервером. Впоследствии можно восстановить первоначального
хозяина инфраструктуры.
Хозяин RID
Хозяин RID - это хозяин операций уровня домена, который назначает RID-пулы другим
контроллерам домена по мере создания новых участников безопасности. Если хозяин RID
недоступен в течение длительного периода времени, то у контроллеров домена могут закончиться
относительные идентификаторы RID, необходимые для назначения их новым участникам
безопасности. Каждый раз, когда у контроллера домена заканчиваются свободные
идентификаторы RID, он запрашивает дополнительные пулы идентификаторов RID у хозяина RID.
Затем хозяин RID выдает дополнительный пул, состоящий из 512 идентификаторов RID. Если
хозяин RID недоступен, то контроллер домена не разрешит создание новых участников
безопасности, пока не получит дополнительные идентификаторы RID у хозяина RID. Хозяин RID
важен и при перемещении участников безопасности между доменами. В этом случае, если хозяин
RID недоступен, то перемещение учетных записей немедленно потерпит неудачу.
Если ваш контроллер домена, являющийся хозяином RID выходит из строя, вы должны решить,
нужно ли вам захватывать эту роль, передавая ее другому серверу. Если вам требуется создать
большое количество участников безопасности или перемещать пользователей между доменами,
прежде чем восстановится хозяин RID, то вы должны захватить эту роль. Кроме того, если не
планируется восстанавливать оригинального хозяина RID, вы также должны захватить эту роль. Если вы решите захватить роль
хозяина RID, то оригинальный хозяин RID не должен возвращаться в интерактивный режим из-за
потенциальной возможности выдачи дублирующих идентификаторов защиты (SID).
GC-серверы
Серверы глобального каталога (GC) также требуют некоторого дополнительного планирования
для восстановления их в случае сбоя, несмотря на то, что нет никаких специальных требований
для создания их резервных копий. Единственная проблема, о которой вы должны позаботиться,
состоит в том, что для нескольких доменов леса база данных каталога на GC-сервере будет
значительно больше, чем база данных на других контроллерах домена. Если вы решите
восстанавливать GC-сервер, восстанавливая базу данных на контроллере домена, то сервер будет
автоматически сконфигурирован как GC-сервер. Если вы решите восстанавливать
функциональные возможности Active Directory, назначая другой сервер контроллером домена, вы
должны сконфигурировать этот сервер как GC-сервер.
Наличие GC-сервера в сети является критическим для обслуживания входа в систему клиентов в
домене, работающем на функциональном уровне Windows 2000 native (или на более высоком) или
при использовании основных имен пользователя (UPN). Наличие GC-сервера критично, если вы
развернули Microsoft Exchange Server 2000. В этом случае вам придется сконфигурировать
дополнительные GC-серверы в этом месте, пока не воссоздадите отказавший контроллер домена.
Например, если выйдет из строя единственный GC-сервер, расположенный в сайте, где у вас
работает Exchange Server 2000, то вам придется сконфигурировать один из других контроллеров
домена, расположенных в том же сайте, как GC-сервер, и восстановить как можно быстрее
отсутствующие функциональные возможности.
Резюме
Эта глава охватывает важнейшую тему восстановления службы Active Directory сервера Windows
Server 2003 после сбоя. Восстановление после сбоя — это одна из сетевых задач
администрирования, с которой вы надеетесь никогда не сталкиваться. Однако, как знает любой
опытный администратор, с высокой степенью вероятности когда-нибудь вам придется
воспользоваться процедурой восстановления системы после сбоя. В начале этой главы были
обсуждены основные элементы данных в Active Directory, затем методы создания резервной копии
службы каталога Active Directory. Большая часть этой главы посвящена объяснению процедуры
восстановления Active Directory в разных режимах. При восстановлении системы после сбоя
придется также управлять ролями хозяев операций и решать специальные задачи
предварительного планирования, связанные с их восстановлением.