Академический Документы
Профессиональный Документы
Культура Документы
Малкер
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 и сайты.
Часть III. Администрирование службы каталога Active Directory Windows Server 2003.
Глава 8. Защита Active Directory.
Глава 9. Делегирование администрирования службы Active Directory.
Глава 10. Управление объектами Active Directory.
Глава 11. Введение в групповые политики.
Глава 12. Использование групповых политик для управления программным
обеспечением.
Глава 13. Использование групповых политик для управления компьютерами.
Структура книги
Технический справочник по 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.
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.
Иерархии Х.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.
Централизованный каталог
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 работает рука об руку с подсистемой безопасности 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 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-
процедурой. Это действие разрушительно с точки
зрения доступа к сети, для завершения операции каждый контроллер домена и каждый сервер
домена должны быть перезагружены.
Резюме
В этой главе вы узнали, как за эти годы развивалась служба каталога 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. Хорошее понимание физической структуры службы каталога
важно, но знание логической структуры является непременным условием успешной реализации и
управления инфраструктурой вашей службы. Именно с логической структурой службы каталога
вы будете ежедневно взаимодействовать.
Контроллеры домена
По определению любой компьютер, на котором выполняется Windows Server 2003, и который
поддерживает копию базы данных службы Active Directory, является контроллером домена. Все
контроллеры домена создаются равными за несколькими исключениями, которые будут
рассмотрены далее в этой главе. При использовании процесса репликации с несколькими
хозяевами домена (multimaster), описанного в гл. 4, каждый контроллер домена в домене
поддерживает новейшую копию базы данных домена и способен создавать изменения в ней.
В дополнение к контроллерам домена, которые содержат службу Active Directory, имеется
несколько контроллеров домена специального назначения, которые требуются службе Active
Directory для выполнения определенных функций. Они являются серверами глобального каталога
(GC) и хозяевами операций (operations masters).
Функциональные уровни
В Windows Server 2003 каждому лесу и каждому домену в пределах леса может быть назначен
определенный функциональный уровень. Функциональные уровни используются для того, чтобы
разрешать функции, которые реализованы на комбинациях операционных систем. Когда для
домена устанавливается функциональный уровень, то он применяется только к данному домену.
Если не определено иначе, домены создаются на функциональном уровне mixed (смешанный)
системы Windows 2000; леса создаются на функциональном уровне Windows 2000.
В таблице 2-1 показаны функциональные уровни доменов и операционные системы,
поддерживаемые на контроллерах домена.
Прежде чем повышать функциональный уровень леса до уровня 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 в контейнере схемы.
Хозяин инфраструктуры
Хозяин инфраструктуры ответственен за обновление справочников групповой принадлежности
пользователей в пределах домена. Роль хозяина операций гарантирует, что изменения, сделанные
в названиях учетной записи пользователя, будут отражены в информации группового членства для
групп, расположенных на различных доменах. Хозяин инфраструктуры поддерживает новейший
список этих справочников и реплицирует эту информацию на все другие контроллеры домена в
домене. Если хозяин инфраструктуры недоступен, справочники групповой принадлежности
пользователей в пределах домена устаревают.
Схема
Схема определяет каждый тип объекта, который можно сохранять в 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.
Домены
Домен является основным строительным блоком в модели службы 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 показана
модель доменов, равных по положению.
Деревья доменов
Домены, которые создаются в инфраструктуре Active Directory после создания корневого домена,
могут использовать существующее пространство имен Active Directory совместно или иметь
отдельное пространство имен. Чтобы выделить отдельное пространство имен для нового домена,
нужно создать новое дерево домена. Независимо от того, используется ли единственное
пространство имен или несколько, дополнительные домены в том же самом лесу функционируют
совершенно одинаково. Создание дополнительных деревьев доменов связано исключительно с
организационными проблемами и проблемами именования, оно никак не затрагивает
функциональные возможности. Дерево доменов содержит, по крайней мере, один домен. Даже
организация с единственным доменом имеет дерево доменов. Использование нескольких деревьев
вместо дочерних доменов влияет на конфигурацию DNS, об этом вы узнаете в гл. 3.
Дерево доменов образуется в том случае, когда организация создает домен вслед за созданием
корневого домена леса (forest root domain), но не хочет использовать существующее пространство
имен. В случае Contoso, если существующее дерево доменов использует пространство имен
Contoso.com, может быть создан новый домен, который использует совершенно другое
пространство имен, например, Fabrikam.com. Если в дальнейшем потребуется создание доменов,
чтобы удовлетворить потребностям единицы Fabrikam, они могут создаваться как дочерние от
дерева доменов Fabrikam. На рисунке 2-7 показана схема организации Contoso с несколькими
доменными деревьями.
Доверительные отношения
По умолчанию домен является границей доступа к ресурсам в организации. Имея
соответствующие разрешения, любой участник безопасности (например, учетная запись
пользователя или группы) может обращаться к любому общедоступному ресурсу в том же самом
домене. Для получения доступа к ресурсам, которые находятся за пределами домена,
используются доверительные отношения службы Active Directory. Доверительные отношения
представляют собой опознавательную связь между двумя доменами, с помощью которой
участники безопасности могут получать полномочия на доступ к ресурсам, расположенным на
другом домене. Есть несколько типов доверительных отношений, включающих:
• транзитивные доверительные отношения;
• односторонние доверительные отношения;
• доверительные отношения леса;
• доверительные отношения области.
Сайты
Все логические компоненты 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.
Групповые политики чаще назначаются на уровне 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.
Табл. 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 в инструменте администрирования DNS. Записи DNS
могут быть сохранены в стандартном текстовом формате. Например, стандартная запись хоста для
сервера по имени Webl.Contoso.com может быть записана как Webl.Contoso.com IN A
192.168.1.100.
Зоны полномочий
Чтобы полностью понимать 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. Его поведение заложено в проекте и, как показывает
обсуждение примера в разделе «Практический опыт», это дает определенное преимущество в
безопасности.
Второй метод, который может применить 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.
По сути, информация в этой записи говорит, что если клиент ищет сервер облегченного протокола
службы каталогов (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. О них более подробно вы узнаете в разделе «Раздел приложений каталога»
этой главы.
DS_PDC_REQUIRED _ldap._tcp.pdc._msdcs.domainname
DS_GC_SERVER_REQUIRED _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, то он не
сможет выполнять запросы на специфическую для сайта информацию о контроллерах домена.
Совершенствование 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).
Сокращенные зоны
Сокращенные зоны (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. Создание новой сокращенной зоны
• То 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
(Администраторы предприятия).
Резюме
Служба 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 использует
срочную репликацию (urgent replication), при которой контроллер домена передает изменения
своим партнерам по репликации немедленно. Любой контроллер домена, получивший срочное
обновление, отправит изменение немедленно. Таким образом, все контроллеры домена в сайте
обновят информацию в течение нескольких секунд. Срочные репликации могут быть вызваны
следующими типами изменений.
• Изменение политики блокировки учетных записей для домена.
• Изменение политики паролей домена.
• Перемещение роли хозяина относительного идентификатора (RID) на новый контроллер
домена.
• Изменение безопасности локальных средств защиты (LSA - Local Security Authority),
например, когда изменяется пароль компьютера контроллера домена.
По умолчанию срочные обновления применяются только к внутренней репликации и не
применяются к репликации между сайтами. Политика применения срочных обновлений может
быть изменена путем разрешения уведомлений для репликации между сайтами.
Пользовательские изменения пароля реплицируются по другой модели. Когда пользователь
изменяет пароль на контроллере домена, это
изменение немедленно копируется прямо в PDC-эмулятор. Эта репликация пересекает границы
сайта и не использует серверы-плацдармы сайтов. Вместо этого контроллер домена, на котором
было сделано изменение, для обновления пароля использует RPC-подключение к PDC-эму-лятору.
Затем PDC-эмулятор обновляет все другие контроллеры домена через нормальный процесс
репликации. Если пользователь попытается войти на контроллер домена, который еще не получил
новый пароль, контроллер домена, прежде чем отклонить вход в систему, проверит PDC-эмулятор,
на предмет наличия обновлений, касающихся изменения пароля этого пользователя.
Объекты связи
При создании топологии репликации служба КСС создает ряд объектов связи (connection object),
которые хранятся в разделе конфигурации каталога Active Directory. Объекты связи являются
прямыми логическими соединениями между контроллерами домена, которые используются для
репликации информации каталога. Как уже говорилось, КСС создает топологию репликации,
которая является эффективной и терпимой к ошибкам. КСС строит столько объектов связи,
сколько для этого требуется.
Объекты связи всегда создаются как односторонние pull («тянущие») соединения между двумя
контроллерами домена, потому что нормальный процесс репликации является pull-операцией, в
которой контроллер-адресат запрашивает данные у контроллера-отправителя информации. В
большинстве случаев КСС строит два односторонних соединения между контроллерами домена
так, чтобы информация могла реплицироваться в обоих направлениях.
Примечание. С помощью инструмента Replication Monitor (Монитор репликации) вы можете
создать push («толкающую») репликацию для раздела каталога. Нормальный процесс репликации
всегда является pull-операцией. (Смотрите детали, касающиеся установки и использования
монитора репликации в разделе «Мониторинг и поиск неисправностей при репликации» далее в
этой главе.)
В большинстве случаев объекты связи, автоматически созданные КСС, оптимизированы, и вам не
нужно делать никаких изменений. Однако, в некоторых случаях вы, возможно, захотите их
изменить. Например, вы пожелаете, чтобы контроллеры домена хозяев операций всегда были
прямыми партнерами по репликации тех контроллеров домена, которых вы назначили резервными
хозяевами операций на случай отказа основного хозяина. Создавая соглашение о подключении, вы
можете гарантировать оптимальную топологию репликации для некоторого определенного набора
контроллеров домена.
Вы можете изменить заданные по умолчанию объекты связи двумя способами: изменяя некоторые
параметры настройки на объектах связи, созданных КСС, и добавляя новые объекты связи.
КСС создает кольцо репликации (см. рис. 4-2), в котором каждый контроллер домена
сконфигурирован с двумя входящими связями репликации. Если одна из связей недоступна, то
обновление может передаваться по другой связи. Кроме того, каждый контроллер домена
сконфигурирован как контроллер-источник для двух других контроллеров домена. Это создает
избыточное кольцо для каждого контроллера домена.
По мере увеличения количества контроллеров домена с репликой определенного раздела
становится важным второй принцип создания свя-
зей. Служба КСС всегда создает топологию репликации, в которой каждый контроллер домена в
сайте удален от любого другого контроллера домена не более чем на три ретрансляции (hop).
Когда количество контроллеров домена в сайте становится больше семи, создаются
дополнительные объекты связи для уменьшения потенциального числа ретрансляций до трех или
меньшего количества. Например, сайт на рисунке 4-3 имеет девять контроллеров домена. Он будет
иметь топологию репликации, включающую, по крайней мере, одну дополнительную связь.
Кольца репликации основываются на разделах каталога. Это означает, что КСС вычисляет кольцо
репликации для каждого раздела каталога. Например, организация имеет несколько доменов в
единственном сайте и раздел приложений каталога, который копируется на несколько
контроллеров домена в сайте. В этом случае конфигурация могла быть задана так, как показано на
рисунке 4-4. В предложенном сценарии (см. рис. 4-4) возможно создание колец репликации,
представленных в табл. 4-1.
На рисунке 4-8 показан более сложный пример создания GC и его репликации. В этом случае
сконфигурирован объект связи, направленный от контроллера домена каждого домена на каждый
GC-сервер. DCl.Contoso.com имеет входящий объект связи от контроллеров DC2.Contoso.com,
DC4.Fabrikam.com и DC6.NWTraders.com. Этот объект связи используется для создания
глобального каталога на DCl.Contoso.com. Все другие GC-серверы имеют подобный набор
объектов связи. Кроме того, создано также отдельное кольцо для репликации раздела GC между
всеми 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. Администраторы могут
изменять это поведение, особенно для репликации между сайтами. Эти вопросы будут
обсуждаться далее в этой главе.
Процесс репликации
Выше обсуждались детали создания топологии репликации в 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). Эти компоненты обсуждаются далее.
Значения уровней
Значения уровней (high-watermark values) используются для управления тем, какая информация
реплицируется между контроллерами домена. Каждый контроллер домена поддерживает свой
собственный набор уровней для каждого из своих прямых партнеров по репликации. Уровень -это
последнее значение uSNChanged, которое контроллер домена получил от определенного партнера
по репликации. Когда контроллер домена посылает модификацию партнеру по репликации,
значение uSNChanged посылается вместе с модификацией. Контроллер домена адресата сохраняет
его как значение уровня для партнера по репликации.
Значения уровней используются во время процесса репликации. Когда один контроллер домена
запрашивает обновление у другого контроллера домена, то контроллер-адресат посылает свое
значение уровня контроллеру-отправителю. Контроллер-отправитель использует значение уровня
контроллера-адресата для фильтрации всех потенциальных обновлений и посылает только те
изменения, которые имеют более высокое значение uSNChanged.
Примечание. Значение уровня поддерживается отдельно для каждого раздела каталога на
контроллере домена и для каждого прямого партнера по репликации.
Связи сайта
Соединения 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, если это подключение функционирует.
Когда трафик репликации проходит по нескольким связям сайта, графики связей сайта и
интервалы репликации объединяются для определения эффективного окна репликации и
интервала. Например, эффективная репликация между сайтами 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.
Резюме
Ключевым аспектом управления службой 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.
Назначенным корневым доменом управлять легче, чем корневым доменом, содержащим много
объектов. Поскольку база данных каталога будет мала, достаточно просто поддерживать и
восстанавливать контроллеры корневого домена. Между контроллерами корневого домена
практически нет трафика репликации, так что не сложно расположить контроллеры домена в
нескольких офисах компании для гарантии избыточности. Это облегчит также перемещение
корневого домена в другое место. Использование назначенного корневого домена облегчает
ограничение членства в административных группах уровня леса. Назначенный корневой домен
никогда не устаревает, особенно если домену дают групповое (generic) имя.
По этим причинам большинство компаний, выбирающие несколько доменов, должны
развертывать назначенный корневой домен. Даже компании, планирующие только один домен,
должны рассмотреть преимущества, связанные с развертыванием назначенного корневого домена.
Назначенный корневой домен требует конфигурирования, которое не применяется к другим
доменам леса. Поскольку корневой домен содержит хозяина операций леса, контроллеры домена
для корневого домена должны быть защищены в максимально возможной степени. Домен леса
также содержит группы, которые могут изменять лес и схему. Члены административных групп в
корневом домене должны иметь более высокий уровень доверия, чем в случае с любым другим
доменом. Вы, вероятно, захотите использовать опцию Restricted Group (Ограниченная группа) в
политике Domain Security Policy (Политика безопасности домена) для управления членством этих
групп. Конфигурация DNS корневого домена должна быть настолько безопасной, насколько это
возможно. Поскольку установка в корневом домене какого-либо дополнительного компьютера
маловероятна, вы должны включить безопасные динамические обновления для корневого домена
зоны DNS на время инсталляции контроллеров домена, а затем динамические обновления для этой
зоны следует отключить.
При планировании дополнительных доменов в лесу границы домена обычно определяются или
географическим местом расположения корпорации, или деловыми подразделениями. В
большинстве случаев предпочтительны домены, основанные на географии. Доменную
конфигурацию трудно изменять после развертывания, а домены, основанные на географии, вряд
ли будут требовать модификации. Кроме того, в большинстве случаев сетевая топология
соответствует географической конфигурации, так что если вы будете создавать дополнительные
домены для управления трафиком репликации, то домены, основанные на географии, вероятно,
будут наилучшим вариантом. Доменный проект, основанный на деловых подразделениях,
выбирается только в том случае, если эти подразделения достаточно автономны. Если каждое
деловое подразделение управляет своей собственной службой каталога, то домены, основанные на
деловых подразделениях, имеют смысл.
Рис. 5-3. Обновление доменов Windows NT 4 до Active Directory Windows Server 2003
Однако это пространство имен 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 путем добавления дочерних доменов к существующим
доменам
Проектирование структуры OU
В большинстве компаний модель OU имеет большую гибкость. При этом следует учесть
множество факторов.
Практический опыт. Структура компании и проектирование OU
Первой мыслью при создании структуры организационных единиц становится
подражание организационной схеме компании. В некоторых случаях это работает, в
некоторых — нет. Организационная схема компании обычно основана на деловых
подразделениях без учета того, где фактически располагаются пользователи.
Возможно, что члены деловых подразделений рассеяны по всему миру.
Группировка этих пользователей в единственную OU может быть весьма
неэффективной. Исследование структуры компании и ее организационной модели -
это хорошая отправная точка для проектирования OU. Если компания
централизована и иерархична, то структура OU, вероятно, отразит эту модель. Если
компания представляет большую автономию деловым подразделениям или
географическим местам, то проект OU должен отразить этот подход. При
исследовании структуры компании исследуйте также структуру управления
информационными технологиями (IT). В некоторых компаниях отдельным деловым
подразделениям дается большая автономия для управления бизнесом по их
собственному усмотрению, но ГГ-управле-ние может оставаться централизованным.
В этом случае необходимо проектировать структуру OU, базируясь на структуре 1Т-
управления, а не на структуре управления бизнесом.
Создание проекта 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 высшего уровня, основанные на географии
корпорации. Организационные единицы высшего уровня, основанные на географии, могут
использоваться для делегирования административных задач.
Размещение 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.
Совет. Развертывание Exchange Server 2000 создает большую нагрузку на GC-серверах. Exchange
Server 2000 не имеет своей собственной службы каталога, так что он зависит от GC. Когда клиент
просматривает GAL, он видит всех получателей почты, перечисленных в GC. Когда Exchange
Server 2000 надо найти адрес пользователя, чтобы доставить электронную почту, он делает запрос
каталогу GC. Если вы развертываете Exchange Server 2000, вы должны расположить GC в каждом
месте, где выполняется Exchange Server 2000, и увеличить общее количество 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,
будет зависеть от количества объектов в домене и от того, является ли данный контроллер домена
сервером глобального каталога (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.
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).
Административные разрешения
Чтобы устанавливать или удалять 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).
Из окна 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 (Мастер
конфигурирования сервера) обеспечит защищенную от ошибок установку этой службы.
5. В окне Summary Of Selections (Резюме выбранных опций) подтвердите выбор роли сервера
и щелкните на кнопке Next. Для конфигурирования выбранных услуг появится окно
Applying Selections (Применение выбранных опций).
6. При создании роли контроллера домена появляется окно Welcome (Приветствие) мастера
инсталляции Active Directory (см. рис. 6-5). После этого будет выполняться тот же процесс,
как если бы вы запустили мастера инсталляции Active Directory из командной строки или
командой Run (Выполнить). Подробное описание ответов на вопросы мастера инсталляции
Active Directory дано в следующем разделе. Завершите мастера инсталляции Active
Directory, а затем щелкните на кнопке Finish (Готово). После того как служба Active
Directory установлена и сконфигурирована, появится напоминание о том, что нужно
перезапустить ваш сервер.
Табл. 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-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-х байтов.
После того как вы указали имя DNS для домена, необходимо задать имя NetBIOS (см. рис. 6-10).
Имя NetBIOS используется более ранними версиями системы Windows для идентификации имени
домена. Лучше всего принять автоматическое имя NetBIOS, полученное из ранее введенного
имени DNS. Единственное ограничение на имя NetBIOS состоит в том, что оно не должно
превышать четырнадцать символов. Кроме того, имя NetBIOS должно быть уникальным.
Рис. 6-10. Окно NetBIOS Domain Name (Имя NetBIOS домена)
Рис. 6-11. Окно Database And Log Folders (Папки базы данных и регистрационных журналов)
Заданное по умолчанию место для базы данных каталога и журналов — папка %systemroot
%\system32. Однако для обеспечения лучшей производительности нужно сконфигурировать Active
Directory так, чтобы хранить файл базы данных и журналы на отдельных жестких дисках.
Заданное по умолчанию место общей папки Sysvol - %systemdrive %\Windows. Единственное
ограничение на выбор места для общей папки Sysvol состоит в том, что она должна храниться в
разделе с файловой системой NTFS v5. В папке Sysvol хранятся все файлы, которые должны быть
доступны клиентам домена Active Directory, например, сценарии входа в систему (см. рис. 6-12).
Рис, 6-13. Окно DNS Registration Diagnostics (Диагностика регистрации DNS) мастера
инсталляции Active Directory
Дополнительная информация. Когда служба DNS сервера устанавливается мастером инсталляции
Active Directory, то зона DNS создается как интегрированная зона Active Directory. Для получения
дополнительной информации о конфигурировании интегрированной зоны Active Directory см. гл.
3.
Какую опцию выбрать? Если ваша сетевая среда будет включать серверы Windows NT, а также
службы или приложения, которые требуют защиты Windows NT для пользователей и групп, вы
должны принять заданную по умолчанию: Permissions Compatible With Pre-Windows 2000 Server
Operating Systems. Если ваша сетевая среда включает только Windows 2000 или Windows Server
2003, если в ней не будут выполняться программы, разработанные для более ранних, чем Windows
2000, систем, выберите Permissions Compatible Only With Windows 2000 Or Windows Server 2003
Operating Systems. Имейте в виду, что с заданной по умолчанию опцией анонимные пользователи
будут способны обращаться к данным Active Directory, нарушая защиту.
После того как вы модернизируете все серверы в домене до Windows 2000 или Windows Server
2003, нужно заново установить разрешения Windows Server 2003 для групповых и
пользовательских объектов. Для этого просто удалите всех членов локальной группы Pre-Windows
2000 Compatible Access (Доступ, совместимый с системами, разработанными до Windows 2000). В
домене Windows Server 2003 членами будут идентификаторы SID групп Everyone (Все) и
Anonymous Logon (Анонимный вход в систему).
Чтобы удалить членов этой группы с помощью инструмента администрирования Active Directory
Users And Computers (Пользователи и компьютеры Active Directory), откройте контейнер Builtin
(Встроенные объекты), а затем дважды щелкните на группе Pre-Windows 2000 Compatible Access
(раскройте столбец Name (Имя) в случае необходимости). На вкладке Members (Члены) окна
групповых свойств выберите оба идентификатора SID и щелкните на кнопке Remove (Удалить).
Для удаления членов этой группы из командной строки напечатайте следующую команду:
net localgroup "Pre-Windows 2000 Compatible Access" Everyone "Anonymous Logon"
/delete
Рис. 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, является также сервером DNS, то
там будут находиться, по крайней мере, два раздела приложений каталога, в которых хранятся
зонные данные. На рисунке 6-17 смотрите пример разделов приложений DNS каталога, найденных
при деинсталляции Active Directory.
После того как вы подтвердите удаление прикладного раздела каталога, вас попросят ввести
новый пароль для локальной учетной записи администратора. Затем появится окно Summary
(Резюме), и удаление
Active Directory завершится. Для окончания этого процесса вы должны перезапустить компьютер.
После перезапуска компьютера он будет играть роль сервера-члена домена или автономного
сервера.
Рис. 6-17. Удаление разделов приложений DNS в каталоге
Резюме
В этой главе обсуждались решения, которые вы должны принять в процессе инсталляции 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. Он объединяет преимущества первого и второго
пути, которые будут рассмотрены далее. В последующих разделах объясняются достоинства и
недостатки каждого из трех путей.
Обновление 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 2003 и Active Directory, затратьте
достаточно усилий на его планирование, будь то оперативное обновление контроллеров домена
или полная реструктуризация доменной модели. Конечным результатом будет полное описание
всех задач, которые нужно выполнить в процессе модернизации. После проверки этот план будет
служить сценарием, по которому вы выполните многочисленные и разнообразные задачи
модернизации своего домена.
Обновление домена
Обновление домена - это вторая стадия процесса перехода к 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 (или более поздний) перед обновлением
операционной системы.
Подготовка леса
Чтобы подготовить лес 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,
вы можете начинать.
Реструктурирование домена
Путь реструктуризации домена наиболее часто выбирается организациями, которые нуждаются в
изменении структуры своей службы 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? Тогда рассмотрите только содержимое, имеющее отношение к объектам
каталога, которые вы должны перенести. Это полезно только для обсуждения порядка
перемещения объектов и выполнения процесса модернизации.
Совет. При установке Active Directory в чистый лес в окне Permissions (Разрешения) мастера
инсталляции Active Directory выберите опцию Permissions Compatible With Pre-Windows 2000
Server Operating Systems (Разрешения, совместимые с операционными системами,
предшествующими Windows 2000). Эта установка позволяет анонимным учетным записям
пользователя обращаться к информации домена и требуется для клонирования участников
безопасности. Чтобы получить доступ к этой опции, вы должны выбрать опцию Custom
configuration (Выборочная конфигурация) в окне Custom Options (Выборочные опции) мастера
конфигурирования сервера.
После того как вы реализуете структуру своего целевого домена, нужно выполнить несколько
действий для подготовки к перемещению учетных записей.
Процесс реструктуризации домена требует, чтобы был включен аудит отказов и успехов операций
управления учетными записями и в исходном, и в целевом доменах.
Чтобы разрешить аудит в целевом домене 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 создаст группу
автоматически при первом запуске, если вы не создадите ее заранее.
5. Выберите вариант, создавать ли доверительные отношения только для этого домена или
также для другого домена. (Эти два домена -корневые домены леса для каждого леса.)
Доверительные отношения леса могут быть установлены только между корневыми
доменами леса (см. рис. 7-6). Если нужно установить обе стороны доверительных
отношений одновременно, впечатайте имя и пароль для учетной записи Enterprise Admins
(Администраторы предприятия), которая существует в другом лесу. Если нужно
установить доверительные отношения только для этого домена, напечатайте пароль,
который будет использоваться для установки начального доверительного отношения.
Затем это пароль должен использоваться для конфигурирования доверительных
отношений в корневом домене леса другого леса.
Рис. 7-6. Выбор конфигурирования одной или обеих сторон доверительных отношений
Резюме
В этой главе были рассмотрены различные пути перехода от службы каталога 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 посвящены групповым
политикам, в них объясняется, как использовать эти инструментальные средства, чтобы
осуществить распределение программ и управление клиентскими компьютерами.
Аутентификация
Чтобы процессы защиты, включающие использование идентификаторов 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, то эти опознавательные опции обсуждаться не
будут.
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.
6. Служба KDC расшифровывает билет TGT, используя свой долгосрочный ключ. Затем она
извлекает ключ сеанса из билета TGT и расшифровывает временную метку, чтобы
убедиться, что клиент использует правильный ключ сеанса, и гарантировать, что
временная метка допустима. Если ключ сеанса и временная метка приемлемы, то KDC
готовит билет сеанса для доступа к сетевой службе.
7. Билет сеанса включает две копии ключа сеанса, который клиент будет использовать для
соединения с требуемым ресурсом. Первая копия ключа сеанса зашифрована, используя
ключ сеанса клиента, полученный в процессе начального входа в систему. Вторая копия
ключа сеанса предназначена для сетевой службы и включает информацию о доступе
пользователя. Эта часть билета сеанса зашифрована, используя секретный ключ сетевой
службы, который неизвестен рабочей станции клиента, но известен и службе KDC и
сетевой службе, потому что сервер, на котором расположен ресурс, является членом сферы
KDC.
8. Рабочая станция клиента кэширует обе части билета сеанса в памяти.
Примечание. Процесс, описанный в шагах с 5-го по 8-ой, использует подпротокол Ticket-Granting
Service Exchange (Коммутатор службы предоставления билетов ). Запрос на билет сеанса,
посланный клиентом, называется сообщением KRB_TGS_REQ; ответ сервера - сообщением
KRB_TGS_REP.
9. Теперь клиент предъявляет билет сеанса сетевой службе для получения доступа (см. рис.
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 и получает билет сеанса для доступа к этому ресурсу. Билет сеанса включает
лексему доступа пользователя. Когда эта лексема предъявляется серверу, на котором расположен
ресурс, сервер определяет уровень доступа к ресурсу, который должен иметь данный
пользователь.
Делегирование аутентификации
Одна из причин сложности доступа к сетевым службам состоит в том, что сетевая служба может
быть распределена между несколькими серверами. Например, клиент для получения информации
соединяется с крайним сервером внешнего интерфейса цепочки серверов, который должен
подключиться к серверу базы данных, являющимся другим концом этой цепочки. Чтобы
пользователь получил доступ только к санкционированной информации, для обращения к
крайнему серверу базы данных должны использоваться «верительные грамоты» пользователя
(вместо «верительных грамот» сервера внешнего интерфейса). В системе 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), которым
компьютер может представлять делегированные «верительные грамоты».
Интеграция со смарт-картами
Смарт-карты обеспечивают другой способ объединения инфраструктуры 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.
Совет. Установка входа в систему вашей сети с использованием смарт-карты требует
значительного объема работы. Прежде всего, нужно развернуть СА-власти для выпуска
сертификатов. Затем установить станции регистрации смарт-карт, где пользователи смогут
получать свои смарт-карты, и где смарт-картам могут быть назначены правильные
сертификаты и ключи. После начального развертывания нужно решить административные
задачи, связанные с потерянными или забытыми картами. Смарт-карты обеспечивают
превосходную дополнительную защиту вашей сети, но эта дополнительная защита связана со
значительными административными усилиями.
Резюме
В этой главе сделан краткий обзор основных концепций безопасности службы 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 в разделе
домена каталога, обратитесь к вкладке Security (Безопасность) в окне Properties (Свойства)
нужного объекта в инструменте Active Directory Users And Computers. (Если вкладка Security не
видна, выберите Advanced Features (Дополнительные функции) в меню View (Вид), повторно
выберите объект и откройте окно Properties). Вкладка Security(Безопасность) показывает
стандартные разрешения, которые доступны для каждого объекта (см. рис. 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=Personal-
Information, 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 сбрасывает разрешения,
установленные на объекте к разрешениям, заданным по умолчанию.
Это окно перечисляет все АСЕ-записи для объекта. Во многих случаях одни и те же участники
безопасности могут быть перечислены в нескольких записях АСЕ. Например, группе Authenticated
Users (Удостоверенные пользователи) дано разрешение Read Permissions (Читать разрешения),
Read General Information (Читать информацию общего характера), Read Personal Information
(Читать личную информацию), Read Web Information (Читать веб-информацию) и Read Public
Information (Читать открытую информацию) в отдельных записях АСЕ.
Вы можете добавлять и удалять участников безопасности или редактировать текущие разрешения,
предоставленные участнику безопасности, используя окно Advanced Security Settings
(Дополнительные параметры настройки защиты). Если вы добавляете или редактируете
разрешения, предоставленные участнику безопасности, вам дается два способа для назначения
разрешений. На рисунке 9-3 показан первый способ назначения разрешений на объект.
Вкладка Object (Объект) используется для назначения разрешений, которые применяются только к
объекту, ко всем дочерним объектам или к определенным дочерним объектам. Например, на
уровне OU можно предоставлять разрешения, которые применяются к объекту (OU), к объекту и
всем его дочерним объектам, ко всем дочерним объектам или к определенным дочерним объектам
(таким как учетные записи пользователя, группы и компьютера). Список разрешений изменяется в
зависимости от типа объекта, с которым вы работаете.
Второй способ назначения разрешений предназначен для управления параметрами настройки
свойств объекта (см. рис. 9-4).
Рис. 9-4. Конфигурирование разрешений, применяемых к свойствам объектов
После строк такого типа информации инструмент 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. Выбор опции, позволяющей копировать или удалять разрешения при
блокировании наследования разрешений
Административные привилегии
Административные разрешения являются специфическими для объектов Active Directory и
определяют, какие действия администратор может выполнять с этими объектами. Разрешения,
которые обсуждались до сих пор, основаны на списках ACL, приложенных к каждому объекту
Active Directory. Пользовательские привилегии отличаются тем, что они применяются к учетным
записям пользователя. Пользовательские привилегии пользователь получает за то, кем он
является, а не за то, что он имеет разрешения изменять специфический объект Active Directory.
Например, есть два способа дать пользователю (или группе) право добавлять рабочие станции к
домену. Один способ состоит в том, чтобы дать пользователю (или группе) разрешение Create
Computer Objects (Создание компьютерных объектов) на уровне OU или контейнера Computers
(Компьютеры). Это позволит пользователю добавить необходимое количество рабочих станций к
домену в указанном контейнере.
Другой способ состоит в том, чтобы дать пользователю привилегию добавления компьютеров к
домену. Она является частью политики Default Domain Controllers Policy (Заданная по умолчанию
политика контроллеров домена). Любой пользователь, имеющий эту привилегию, может добавить
к домену до десяти рабочих станций. По умолчанию это разрешение предоставляется группе
Domain Users (Пользователи домена).
Если нужно производить аудит изменений для объектов 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.
Планирование делегирования
администрирования
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-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 (Учетная Определяет время окончания срока
запись недействительна) действия учетной записи.
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.
Управление группами
Основная функция 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, остальная часть этой главы будет посвящена группам безопасности.
Одним из основных вопросов при создании проекта группы безопасности является вопрос о том,
когда использовать глобальные группы, а когда - универсальные. В некоторых случаях у вас нет
выбора. Например, в 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 рассматривают с групповые политики,
обеспечивающие мощныее инструментальные средства управления компьютерами.
Одна из наиболее интересных опций 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, состоит в том, что, если
общая папка переместится на другой сервер, то все клиенты, имеющие диски, отображенные на
эту общую папку, обнаружат, что отображение больше не работает. Это произойдет, потому что
при отображении клиентского диска на общую папку в 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.
Существует два типа групповых политик. Первый тип — это локальная групповая политика на
компьютере с системами 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 показано, что глобально уникальные идентификаторы (GUID), которые
используются для идентификации объектов GPC в Active Directory, не всегда удобны. Для
определения отображаемого имени каждого из GPC-объектов используйте утилиту
ADSIedit.msc. Найдите GPC в Active Directory, используя ADSI Edit, а затем рассмотрите
атрибут display Name.
Второй объект, который входит в групповую политику, — это объект GPT, содержащий
большинство фактических параметров настройки для групповой политики и хранящийся в папке
Sysvol на каждом контрол-
лере домена. Этот объект включает папки и информацию о содержимом (см. табл. 11-2).
Рис. 11 -2. Просмотр статуса объекта групповой политики с помощью монитора репликации
Replication Monitor
Рис. 11 -3. Выбор контроллера домена, на котором будут сделаны изменения объекта GPO
Создание объектов GPO
Существует два способа создания новых объектов GPO. Первый способ заключается в
использовании инструмента Active Directory для поиска контейнера, в котором нужно создать
новый объект GPO. Затем нужно щелкнуть правой кнопкой мыши на контейнерном объекте и
выбрать Properties (Свойства). Выберите вкладку Group Policy (Групповая политика) (см. рис. 11-
4). Чтобы создать новый объект GPO, который будет связан с этим контейнером, щелкните на New
(Новый).
Второй способ — это создание собственной консоли ММС (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 уровня домена удаляет команду 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, параметры настройки политики не изменятся, и будут поддерживаться установки,
унаследованные от более высокого уровня.
Опция No Override может быть полезна, когда ваша групповая политика применяется ко всем
пользователям независимо от того, где они расположены. Например, вы можете использовать
групповые политики для управления антивирусным программным обеспечением на всех
компьютерах-клиентах вашей организации. В этом случае нужно выбрать контейнер высокого
уровня, содержащий все компьютеры вашего домена, и применить политику на этом уровне. Затем
сконфигурируйте групповую политику опцией No Override, чтобы параметры настройки
применялись ко всем компьютерам клиентам.
Опция No Override устанавливается в том месте, где объект GPO связывается с контейнером, а не
в самом объекте GPO. Если вы связываете объект GPO с несколькими местами вашего домена и
конфигурируете одну из связей с применением опции No Override, другие связи не будут
сконфигурированы с этой опцией автоматически. Опция No Override устанавливается
применительно к одному объекту GPO, т.е. ее установка на одном объекте GPO, связанном с OU,
не затрагивает опцию No Override для других объектов GPO, связанных с этой же OU.
Примечание. Опция No Override заставляет применять параметры настройки групповой
политики, даже если наследование блокировано. Параметры настройки уровня домена типа
политики учетной записи и политики пароля применяются ко всем компьютерам и
пользователям в домене. Блокировка наследования политики никак не влияет на эту политику.
Совет. Можно использовать группы для фильтрации применения групповых политик, но нельзя
применять групповые политики к группам. Например, если вы связываете групповую политику с
контейнером, который содержит глобальную группу, но не содержит учетные записи
пользователей, являющихся членами глобальной группы, групповые политики будут
неэффективны. Пользовательские и компьютерные учетные записи должны находиться в
контейнерном объекте, чтобы применялась групповая политика.
Опция, предназначенная для применения групповых политик к выбранной группе, полезна во
множестве различных сценариев. Например, вы планируете установить специфический пакет
программ для группы пользователей, учетные записи которых рассеяны в различных 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
Групповые политики применяются при запуске компьютера при входе пользователя в систему.
После входа они обновляются периодически, по умолчанию каждые 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 (Включено), а затем введите значение, которое вы хотите использовать.
Инструмент 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 или
добавление пользователя или компьютера к другой группе безопасности. Инструмент вычислит
фактическую групповую политику для пользователя и компьютера в новой конфигурации.
Инструмент 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 или /ЪФОГ, ВЫ можете вызвать
применение этих политик в любое время.
Примечание. Во время написания этой книги компания Microsoft объявила, что инструмент
GPMC будет доступен бесплатно вскоре после отправки покупателям Windows Server 2003.
Этот раздел основан на бета-версии 2 инструмента GPMC. Часть функциональных
возможностей в заключительном выпуске может отличаться от тех, которые показаны здесь.
GPMC является отдельным инструментом, который используется для управления всеми
конфигурациями групповых политик всей организации. В таблице 11-4 показаны все
функциональные возможности инструмента GPMC.
Как видите, GPMC представляет собой мощный инструмент управления групповыми политиками
в среде предприятия.
Резюме
Эта глава объясняет опции конфигурации групповых политик в 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 решают эти задачи более эффективно.
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-объект.
Независимо от количества усилий, предпринятых вами для минимизации влияния на сеть,
развертывание объемного приложения для большого количества пользователей всегда оказывает
воздействие на сеть, поэтому нужно запланировать выполнение инсталляции в течение несколько
дней.
Вы можете использовать эту процедуру для установки опций, отображаемых при создании нового
пакета программ с данным объектом GPO. Можно установить заданное по умолчанию место
расположения инсталляционных файлов и сконфигурировать параметры настройки
инсталляционного интерфейса пользователя.
Когда связь с обновлением создана, вкладка Upgrades показывает новую информацию (см. рис. 12-
7). С помощью вкладки Upgrades можно сделать это обновление обязательным. В этом случае все
программное обеспечение, распределенное предыдущим объектом GPO, будет обновлено во время
следующей перезагрузки компьютера или при следующем входе пользователя в систему. Если
обновление не сделать обязательным, пользователь сможет выбирать время установки нового
приложения, активизируя приложение в меню Start (Пуск) или через панель управления Add Or
Remove Programs (Установка и удаление программ). Если для пакета обновления программного
обеспечения и для начального приложения вы используете один и тот же объект GPO, то
первоначальный пакет программ покажет, что новый пакет его модернизирует.
Планирование. Тот факт, что модернизировать приложение, используя групповые политики,
очень просто, не означает, что обновление пройдет легко. Перед развертыванием обновления вы
должны его протестировать для гарантии того, что оно не создаст проблем при
взаимодействии с существующими приложениями. Нужно протестировать процесс обновления и
удостовериться, что он будет работать гладко в вашей организации. Когда вы убедитесь в
этом, нужно будет управлять развертыванием. Если приложение, которое вы модернизируете,
было развернуто для нескольких тысяч пользователей, и вы решите сделать это обновление
обязательным, то пользователям, возможно, придется ждать много времени, пока инсталляция
будет закончена. Нужно управлять развертыванием обновления, чтобы свести к минимуму
воздействие на пропускную способность сети.
Табл. 12-2. Опции параметров настройки групповой политики для инсталлятора Windows
Параметр настройки Объяснение
Disable Windows Installer (Отключение Используется для включения или
инсталлятора Windows) (Только отключения инсталляции программного
конфигурация компьютера) обеспечения с помощью инсталлятора
Windows. Если вы включите политику, то
затем можно или полностью отключить
инсталлятор Windows, или включить его для
всех приложений, или отключать для тех
приложений, которые не распределяются
через групповые политики.
Enable User To Use Media Source While Используется для разрешения использовать
Elevated (Дать возможность пользователю сменные носители информации в качестве
использовать сменные носители инсталляционного источника, если
информации, если он имеет повышенные приложение устанавливается с
разрешения) (Только компьютерная повышенными разрешениями.
конфигурация)
Резюме
Групповые политики в Active Directory Windows Server 2003 обеспечивают мощные
инструментальные средства для развертывания и управления программным обеспечением на
рабочих станциях. Используя групповые политики и технологию инсталлятора Windows, вы
можете развертывать программное обеспечение на рабочих станциях, а затем управлять этим
программным обеспечением в течение всего жизненного цикла программы. В этой главе
рассмотрены вопросы, касающиеся использования групповых политик для развертывания
программного обеспечения и управления им.
Глава 13. Использование групповых политик
для управления компьютерами
В главе 12 описан один из спосебов использования групповой политики в службе каталога Active
Directory системы Microsoft Windows Server 2003 для управления вашей сетью — использование
групповой политики для управления программным обеспечением, которое устанавливается на
рабочих станциях вашей сети. Использование централизованного инструмента для управления
программным обеспечением клиентов дает существенную выгоду для организации. Однако с
управлением компьютерами клиентов связано много хлопот, включающих защиту настольных
компьютеров, управление профилями пользователей и данными, блокировку пользовательских
рабочих столов для уменьшения количества изменений, которые могут делать пользователи на
своих компьютерах. В этой главе объясняется, как использовать групповые политики для
управления компонентами рабочих столов компьютеров клиентов.
В больших организациях администрирование компьютеров клиентов - это одна из самых
серьезных задач в управлении. Установка и развертывание компьютеров требуют больших
усилий, но и управление рабочими станциями после развертывания является не менее трудоемкой
задачей. В крупных компаниях имеется целый сервисный отдел, посвященный решению проблем,
с которыми сталкиваются пользователи. Часто этот отдел подкрепляется группой поддержки
рабочих станций, которая может посещать компьютеры клиентов, если проблему нельзя решить
по телефону.
Звонок в сервисный отдел обычно связан с тем, что пользователь сделал что-то такое, что вызвало
проблемы. Пользователь может изменить установки системы так, что больше не сможет
соединяться с сетью. Другие звонки связаны с конфигурированием рабочих станций, например,
параметры настройки были неправильно заданы при установке рабочей станции или приложения и
после инсталляции должны быть изменены. Групповые политики могут использоваться для
уменьшения количества таких звонков, позволяя централизовано управлять компьютерами вашей
компании. Вы можете использовать групповые политики, чтобы запретить пользователям
изменения на своих рабочих станциях, наруша-
ющие правильное функционирование. Можно также использовать групповые политики для
централизованного конфигурирования многих параметров настройки рабочих станций вашей
компании.
Практический опыт. Индивидуальные предпочтения против
централизованного управления компьютерными рабочими столами
В большинстве случаев управление рабочими столами пользователей требует
равновесия между централизованным управлением компьютерами и
удовлетворением потребностей пользователей, которые хотят иметь полный
контроль над своими рабочими столами. Если реализовать все опции управления,
обсуждаемые в этой главе, можно полностью блокировать пользовательские
рабочие столы, чтобы пользователи гарантировано не смогли сделать никаких
неправомочных изменений. Многие администраторы думают, что предоставление
пользователям возможности изменять параметры настройки означает только то, что
они сконфигурируют что-либо неправильно, и это приведет к увеличению объема
работы для администратора. Многие пользователи, с другой стороны, во всех
попытках управления их рабочими столами видят вторжение в их личное
пространство. С точки зрения пользователя рабочая станция является частью
индивидуальной рабочей среды, и любые попытки управления этой рабочей средой
вызывают решительное сопротивление.
Решение о правильном балансе между централизованным управлением рабочими
столами и контролем их со стороны конечного пользователя в разных компаниях
различно. Некоторые компании уже имеют опыт использования системной политики
в Microsoft Windows NT 4 или групповых политик в Active Directory Microsoft Windows
2000, и их конечные пользователи уже приучены к некоторому уровню блокирования
рабочего стола. В таких компаниях можно вводить новые ограничения без особого
беспокойства. Однако во многих компаниях раньше не существовало никаких
ограничений, поэтому первая же попытка реализовать ограничение вызовет
активное сопротивление.
Для большинства компаний наилучшим подходом к управлению рабочими столами
является медленный старт и создание благоприятного первого впечатления. Это
означает, что вы используете групповые политики для решения проблем,
раздражающих конечных пользователей. Если вы покажете конечным
пользователям, что управление рабочими столами фактически сделает их работу
более легкой, они более охотно согласятся на дополнительное управление. С
другой стороны, если первые результаты вызовут сотни звонков в сервисный отдел,
то вы лишитесь поддержки для реализации любого управления рабочими столами.
Другим важным компонентом для успешной реализации групповых политик
является помощь со стороны управленческого аппарата. В боль-
шинстве компаний дирекция идет навстречу всему, что уменьшает стоимость
управления рабочими станциями. Если вы сумеете доказать, что уменьшение
стоимости работ является конечным результатом вашей реализации управления
рабочими столами, то вы наверняка получите поддержку дирекции в улаживании
жалоб, поступающих от конечных пользователей, не желающих, чтобы их рабочими
столами управляли.
Рис. 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\ Параметры конфигурирования защиты
(Компьютерная и настройки защиты) компьютера. Некоторые параметры
пользовательская настройки специфичны для
конфигурация) доменного уровня, а некоторые
можно установить на контейнерном
уровне. Большинство параметров
настройки защиты
конфигурируются в разделе
компьютерной конфигурации
Как показано в таблице 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 описывается каждая установка.
Табл. 13-3. Политики паролей
Параметры установки Описание Значение по умолчанию
конфигурации
Enforce Password History Определяет количество новых 24 пароля запоминается
(Предписанная история уникальных паролей, которые для контроллеров домена
пароля) должны быть введены, прежде и компьютеров-членов
чем пользователь сможет домена; 0 для
повторно использовать старый автономных серверов.
пароль. Возможные значения:
от 0 до 24
Maximum Password Age Определяет количество дней, в 42 дня.
(Максимальное время течение которых может
использования пароля) использоваться пароль, прежде
чем пользователь должен будет
его изменить. Чтобы
сконфигурировать пароль для
бесконечно долгого
использования, установите
число дней на 0. Возможные
значения: от 0 до 999
Maximum Lifetime For Определяет максимальное время в минутах, 600 минут (10 часов).
Service Ticket в течение которого билет службы пригоден
(Максимальный срок для обращения к ресурсу. Возможные
пригодности билета значения: 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 Определяет время в днях, в течение 7 дней.
User Ticket Renewal которого билет TGT пользователя может
(Максимальный срок, в быть возобновлен вместо получения нового
течение которого билета. Значение 0 указывает, что
пользовательский билет возобновление билета заблокировано
может быть
возобновлен)
Local Policies\Security
Используется для конфигурирования опций
Options (Локальные
безопасности для компьютеров, на которые
политики\Опции воздействует эта политика. Можно конфигурировать
безопасности) переименование учетной записи локального
администратора, управление установкой принтера,
установкой драйверов, не имеющих подписи,
возможностью хранения паспорта Microsoft .NET на
рабочих станциях и т.п.
Event Log (Журнал Используется для конфигурирования параметров
регистрации событий) журнала регистрации событий для всех компьютеров,
на которые воздействует данная политика. Можно
конфигурировать максимальный размер журнала,
разрешение на просмотр, сохранение всех журналов.
Шаблоны защиты
Как показано в предыдущих разделах, существуют сотни опций, предназначенных для
конфигурирования безопасности с использованием
групповых политик в сети Windows Server 2003. На первый взгляд можете показаться, что
количество опций непомерно велико. Трудно даже определить, с него начать конфигурирование
опций безопасности. К счастью, компания Microsoft разработала шаблоны защиты, которые
позволяют справиться с этой задачей.
Шаблоны защиты предопределяют наборы конфигураций защиты, которые вы можете применять
к компьютерам вашей сети. Вместо того чтобы просматривать каждый параметр защиты, можно
выбрать шаблон защиты, соответствующий тому, чего вы хотите добиться, а затем применить этот
шаблон, используя групповые политики. Например, если вы развертываете рабочие станции в
среде, где требуются строгие параметры настройки защиты, выберите один из шаблонов сильной
защиты. Если вы развертываете рабочие станции, которые нуждаются в меньшей защите, то для
этих рабочих станций выберите другой шаблон. Шаблоны защиты можно модифицировать. Если
вы не найдете шаблон защиты, который точно отвечает вашим потребностям, можно выбрать один
из предопределенных шаблонов, а затем изменить несколько параметров настройки.
Почти все параметры настройки защиты, сконфигурированные с помощью групповых политик,
могут быть сконфигурированы с использованием шаблон защиты. (Исключения составляют
политики IPSec и политики открытых ключей.) Вы можете создать ваш собственный шаблон
защиты или использовать один из предопределенных шаблонов. Если вы изменяете шаблон,
сохраните его так, чтобы он был доступен другим объектам GPO. При сохранении шаблона он
записывается в виде текстового .inf файла.
Административные шаблоны
Одна из наиболее мощных опций, предназначенных для управления рабочими столами
пользователей с помощью групповых политик, состоит в использовании административных
шаблонов. Административные шаблоны применяются для конфигурирования параметров
настройки системного реестра на компьютерах с системами 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\ функции Remote Assistance (Удаленная
System\Remote Assistance помощь), имеющейся в системе Windows ХР
Professional.
Computer Conf iguration\ Обеспечивает параметры настройки, которые
Administrative Templates\ Windows могут использоваться для конфигурирования
Components\ Terminal Services служб терминала Terminal Services на
сервере и на клиентах.
User Conf iguration\ Administrative Обеспечивает конфигурирование параметров
Templates\ Network\Network настройки, предназначенных для управления
Connections сетевыми связями, и ограничения доступа
пользователей к сетевым подключениям.
Рис. 13-10. В Центре справки и поддержки имеется детальное описание каждой опции
административного шаблона
Табл. 13-8. Заданные по умолчанию шаблоны, загружаемые в систему Windows Server 2003
Административный Параметры настройки конфигурации
шаблон
System.adm Системные параметры настройки.
Inetres.adm Параметры настройки приложения Internet
Explorer.
Wmplayer.adm Параметры настройки приложения Microsoft
Windows Media Player.
Conf.adm Параметры настройки приложения Microsoft
NetMeeting.
Wuau.adm Параметры настройки Windows Update.
Резюме
В 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 — это
критическая служба в вашей сети, и вы должны уметь восстанавливать ее после любых видов
сбоя, которые могут произойти во время работы.
Проектирование предупреждений
Предупреждение определяется как уведомление, которое вызывается автоматически, когда
значение счетчика достигает порогового уровня. Используя инструмент администрирования
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. Откройте Performance (Производительность) в папке Administrative Tools (Средства
администрирования).
2. Дважды щелкните на Performance Logs And Alerts (Журналы работы и предупреждения), а затем
щелкните на Alerts (Предупреждения).
3. Из меню Action (Действия) выберите New Alert Settings (Параметры настройки новых
предупреждений).
4. В поле Name (Имя) напечатайте название предупреждения, а затем щелкните на кнопке
ОК. Это название будет показано в контейнере Performance Logs And Alerts, поэтому
используйте такое имя, которое определяет отслеживаемый счетчик.
5. На вкладке General (Общее) дайте комментарий к вашему предупреждению, а затем
щелкните на кнопке ADD (Добавить), чтобы добавить необходимый объект Performance и
счетчики (см. рис. 14-1).
Вы можете импортировать сохраненный график назад в системный монитор, перемещая файл 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-6. Окно Event Properties (Свойства событий) для записи в журнал событий
Сборка мусора
Один из автоматических процессов, который обычно используется для обслуживания базы данных
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.
Онлайновая дефрагментация
Заключительный шаг в процессе сборки мусора — это онлайновая дефрагментация базы данных
Active Directory. Она освобождает место в пределах базы данных и перестраивает расположение
хранящихся объектов Active Directory в пределах базы данных так, чтобы улучшить ее
эффективность. Во время нормального функционирования база данных Active Directory
оптимизирована так, чтобы можно было делать изменения в ней как можно быстрее. При
удалении объекта из Active Directory страница базы данных, на которой он хранится, загружается
в память компьютера, и объект удаляется с этой страницы. При добавлении объектов к Active
Directory они записываются на страницу базы данных без учета оптимизации последующего
поиска этой информации. После нескольких часов активного внесения изменений в базу данных
способ хранения данных перестает быть оптимизированным. База данных может содержать
пустые страницы, страницы, на которых удалены некоторые элементы. Объекты Active Directory,
которые логически должны храниться вместе, могут храниться на нескольких различных
страницах, расположенных по всей базе данных.
Процесс онлайновой дефрагментации чистит базу данных и возвращает ее в оптимизированное
состояние. Если некоторые записи были удалены с какой-либо страницы, то записи, находящиеся
на других страницах, перемещаются на нее для оптимизации хранения и поиска информации. Те
объекты, которые логически должны храниться вместе, перемещаются на одну и ту же страницу
базы данных или на смежные. Одно из ограничений процесса онлайновой дефрагментации
состоит в том, что он не сокращает размер базы данных Active Directory. Если вы удалили
большое количество объектов из Active Directory, то онлайновая дефрагментация создаст много
пустых страниц, которые она не сможет удалить. Для этого используется процесс автономной
дефрагментации.
Процесс онлайновой дефрагментации выполняется каждые 12 часов как часть процесса сборки
мусора. Когда процесс онлайновой дефрагментации закончен, в журнал службы каталога
записывается событие, указывающее, что процесс завершился успешно. На рисунке 14-8 показан
пример такого сообщения в журнале регистрации событий.
Резюме
В этой главе были представлены некоторые инструменты, которые необходимы для мониторинга
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, регулируя приоритет каждого контроллера домена. Тогда второй контроллер
домена может выполнять другие функции и использоваться только для создания резервной
копии на случай аварии на первом контроллере домена.
Инструмент Ntdsutil
В главе 14 были показаны примеры использования утилиты Ntdsutil для управления базой данных
Active Directory. Ntdsutil - это инструмент командной строки, который применяется для
управления некоторыми компонентами Active Directory и базой данных. Ntdsutil является мощным
инструментом, им надо пользоваться с осторожностью.
Запустите инструмент Ntdsutil, напечатав в командной строке ntdsutil. Инструмент выдает
приглашение к вводу команд Ntdsutil. Вы можете вводить разнообразные команды в зависимости
от того, что вы хотите
сделать. Если вы напечатаете help в любой командной строке, то получите список всех команд,
которые можно использовать в этом положении. На рисунке 15-2 показан список команд,
доступных из окна Ntdsutil.
Рис. 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 в разных режимах. При восстановлении системы после сбоя
придется также управлять ролями хозяев операций и решать специальные задачи
предварительного планирования, связанные с их восстановлением.