Лабораторные работы

Для закрепления материала раздела 3 необходимо выполнить упражнения лабораторных работ.

Всего предусмотрено выполнение пяти упражнений.

Упражнение 1. Настройка протокола TCP/IP на сетевом узле. Проверка коммуникаций между узлами при отсутствии серверов DNS.

Упражнение 2. Установка на сервере службы DNS. Создание основной и дополнительной зон прямого просмотра. Динамическая регистрация узлов на сервере DNS.

Упражнение 3. Создание зон обратного просмотра.

Упражнение 4. Примеры применения диагностических утилит.

Упражнение 5. Подготовка компьютеров к выполнению упражнений следующего раздела.

Раздел № 4 «Служба каталогов Active Directory»

4.1 Основные термины и понятия (лес, дерево, домен, организационное подразделение). Планирование пространства имен AD. Установка контроллеров доменов.

4.2 Логическая и физическая структуры, управление репликацией AD. Серверы Глобального каталога и Хозяева операций.

4.3 Управление пользователями и группами. Управление организационными подразделениями, делегирование полномочий. Групповые политики.

4.4 Система безопасности (протокол Kerberos, настройка параметров системы безопасности).

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

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

В настоящее время большинство служб каталогов различных фирм базируются на стандарте X.500. Для доступа к информации, хранящейся в службах каталогов, обычно используется протокол Lightweight Directory Access Protocol (LDAP). В связи со стремительным развитием сетей TCP/IP, протокол LDAP становится стандартом для служб каталогов и приложений, ориентированных на использование службы каталога.

Служба каталогов Active Directory является основой логической структуры корпоративных сетей, базирующихся на системе Windows. Термин «Каталог» в самом широком смысле означает «Справочник», а служба каталогов корпоративной сети — это централизованный корпоративный справочник. Корпоративный каталог может содержать информацию об объектах различных типов. Служба каталогов Active Directory содержит в первую очередь объекты, на которых базируется система безопасности сетей Windows, — учетные записи пользователей, групп и компьютеров. Учетные записи организованы в логические структуры: домен, дерево, лес, организационные подразделения.

С точки зрения изучения материала курса «Сетевое администрирование» вполне возможен следующий вариант прохождения учебного материала: сначала изучить первую часть данного раздела (от основных понятий до установки контроллеров домена), затем перейти к Разделу 5 «Служба файлов и печати», а после изучения 5-го раздела вернуться к разделу 4 для изучения более сложных понятий служб каталогов.

Основные термины и понятия (лес, дерево, домен, организационное подразделение). Планирование пространства имен AD. Установка контроллеров доменов.

Модели управления безопасностью: модель «Рабочая группа» и централизованная доменная модель

Как уже говорилось выше, основное назначение служб каталогов — управление сетевой безопасностью. Основа сетевой безопасности — база данных учетных записей (accounts) пользователей, групп пользователей и компьютеров, с помощью котярой осуществляется управление доступом к сетевым ресурсам. Прежде чем говорить о службе каталогов Active Directory, сравним две модели построения базы данных служб каталогов и управления доступом к ресурсам.

Модель «Рабочая группа».

Данная модель управления безопасностью корпоративной сети — самая примитивная. Она предназначена для использования в небольших одноранговых сетях (3–10 компьютеров) и основана на том, что каждый компьютер в сети с операционными системами Windows NT/2000/XP/2003 имеет свою собственную локальную базу данных учетных записей и с помощью этой локальной БД осуществляется управление доступом к ресурсам данного компьютера. Локальная БД учетных записей называется база данных SAM (Security Account Manager) и хранится в реестре операционной системы. Базы данных отдельных компьютеров полностью изолированы друг от друга и никак не связаны между собой.

Пример управления доступом при использовании такой модели изображен на рис. 4.1.

Рис. 4.1

В данном примере изображены два сервера (SRV-1 и SRV-2) и две рабочие станции (WS-1 и WS-2). Их базы данных SAM обозначены соответственно SAM-1, SAM-2, SAM-3 и SAM-4 (на рисунке базы SAM изображены в виде овала). В каждой БД есть учетные записи пользователей User1 и User2. Полное имя пользователя User1 на сервере SRV-1 будет выглядеть как «SRV-1\User1», а полное имя пользователя User1 на рабочей станции WS-1 будет выглядеть как «WS-1\User1». Представим, что на сервере SRV-1 создана папка Folder, к которой предоставлен доступ по сети пользователям User1 — на чтение (R), User2 — чтение и запись (RW). Главный момент в этой модели заключается в том, что компьютер SRV-1 ничего «не знает» об учетных записях компьютеров SRV-2, WS-1, WS-2, а также всех остальных компьютеров сети. Если пользователь с именем User1локально зарегистрируется в системе на компьютере, например, WS-2 (или, как еще говорят, «войдет в систему с локальным именем User1 на компьютере WS-2»), то при попытке получить доступ с этого компьютера по сети к папке Folder на сервере SRV-1 сервер запросит пользователя ввести имя и пароль (исключение составляет тот случай, если у пользователей с одинаковыми именами одинаковые пароли).

Модель «Рабочая группа» более проста для изучения, здесь нет необходимости изучать сложные понятия Active Directory. Но при использовании в сети с большим количеством компьютеров и сетевых ресурсов становится очень сложным управлять именами пользователей и их паролями — приходится на каждом компьютере (который предоставляет свои ресурсы для совместного использования в сети) вручную создавать одни и те же учетные записи с одинаковыми паролями, что очень трудоемко, либо делать одну учетную запись на всех пользователей с одним на всех паролем (или вообще без пароля), что сильно снижает уровень защиты информации. Поэтому модель «Рабочая группа» рекомендуется только для сетей с числом компьютеров от 3 до 10 (а еще лучше — не более 5), при условии что среди всех компьютеров нет ни одного с системой Windows Server.

Доменная модель.

В доменной модели существует единая база данных служб каталогов, доступная всем компьютерам сети. Для этого в сети устанавливаются специализированные серверы, называемые контроллерами домена, которые хранят на своих жестких дисках эту базу. На рис. 4.2. изображена схема доменной модели. Серверы DC-1 и DC-2 — контроллеры домена, они хранят доменную базу данных учетных записей (каждый контроллер хранит у себя свою собственную копию БД, но все изменения, производимые в БД на одном из серверов, реплицируются на остальные контроллеры).

Рис. 4.2

В такой модели, если, например, на сервере SRV-1, являющемся членом домена, предоставлен общий доступ к папке Folder, то права доступа к данному ресурсу можно назначать не только для учетных записей локальной базы SAM данного сервера, но, самое главное, учетным записям, хранящимся в доменной БД. На рисунке для доступа к папке Folder даны права доступа одной локальной учетной записи компьютера SRV-1 и нескольким учетным записям домена (пользователя и группам пользователей). В доменной модели управления безопасностью пользователь регистрируется на компьютере («входит в систему») со своей доменной учетной записью и, независимо от компьютера, на котором была выполнена регистрация, получает доступ к необходимым сетевым ресурсам. И нет необходимости на каждом компьютере создавать большое количество локальных учетных записей, все записи созданы однократно в доменной БД. И с помощью доменной базы данных осуществляется централизованное управление доступом к сетевым ресурсам независимо от количества компьютеров в сети.

Назначение службы каталогов Active Directory

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

Active Directory отвечает не только за создание и организацию этих небольших объектов, но также и за большие объекты, такие как домены, OU (организационные подразделения) и сайты.

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

Служба каталогов Active Directory (сокращенно — AD) обеспечивает эффективную работу сложной корпоративной среды, предоставляя следующие возможности:

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

- Безопасность информации. Средства аутентификации и управления доступом к ресурсам, встроенные в службу Active Directory, обеспечивают централизованную защиту сети;

- Централизованное управление. Администраторы могут централизованно управлять всеми корпоративными ресурсами;

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

- Интеграция с DNS. Функционирование служб каталогов полностью зависит от работы службы DNS. В свою очередь серверы DNS могут хранить информацию о зонах в базе данных Active Directory;

- Расширяемость каталога. Администраторы могут добавлять в схему каталога новые классы объектов или добавлять новые атрибуты к существующим классам;

- Масштабируемость. Служба Active Directory может охватывать как один домен, так и множество доменов, объединенных в дерево доменов, а из нескольких деревьев доменов может быть построен лес;

- Репликация информации. В службе Active Directory используется репликация служебной информации в схеме со многими ведущими (multi-master), что позволяет модифицировать БД Active Directory на любом контроллере домена. Наличие в домене нескольких контроллеров обеспечивает отказоустойчивость и возможность распределения сетевой нагрузки;

- Гибкость запросов к каталогу. БД Active Directory может использоваться для быстрого поиска любого объекта AD, используя его свойства (например, имя пользователя или адрес его электронной почты, тип принтера или его местоположение и т. п.);

- Стандартные интерфейсы программирования. Для разработчиков программного обеспечения служба каталогов предоставляет доступ ко всем возможностям (средствам) каталога и поддерживает принятые стандарты и интерфейсы программирования (API).

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

Терминология

Служба каталогов системы Windows Server построена на общепринятых технологических стандартах. Изначально для служб каталогов был разработан стандарт X.500, который предназначался для построения иерархических древовидных масштабируемых справочников с возможностью расширения как классов объектов, так и наборов атрибутов (свойств) каждого отдельного класса. Однако практическая реализация этого стандарта оказалась неэффективной с точки зрения производительности. Тогда на базе стандарта X.500 была разработана упрощенная (облегченная) версия стандарта построения каталогов, получившая название LDAP (Lightweight Directory Access Protocol). Протокол LDAP сохраняет все основные свойства X.500 (иерархическая система построения справочника, масштабируемость, расширяемость), но при этом позволяет достаточно эффективно реализовать данный стандарт на практике. Термин «lightweight» («облегченный») в названии LDAP отражает основную цель разработки протокола: создать инструментарий для построения службы каталогов, которая обладает достаточной функциональной мощью для решения базовых задач, но не перегружена сложными технологиями, делающими реализацию служб каталогов неэффективной. В настоящее время LDAP является стандартным методом доступа к информации сетевых каталогов и играет роль фундамента во множестве продуктов, таких как системы аутентификации, почтовые программы и приложения электронной коммерции. Сегодня на рынке присутствует более 60 коммерческих серверов LDAP, причем около 90% из них представляют собой самостоятельные серверы каталогов LDAP, а остальные предлагаются в качестве компонентов других приложений.

Протокол LDAP четко определяет круг операций над каталогами, которые может выполнять клиентское приложение. Эти операции распадаются на пять групп:

- установление связи с каталогом;

- поиск в нем информации;

- модификация его содержимого;

- добавление объекта;

- удаление объекта.

Кроме протокола LDAP служба каталогов Active Directory использует также протокол аутентификации Kerberos и службу DNS для поиска в сети компонент служб каталогов (контроллеры доменов, серверы глобального каталога, службу Kerberos и др.).

Домен.

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

Имена доменов Active Directory формируются по той же схеме, что и имена в пространстве имен DNS. И это не случайно. Служба DNS является средством поиска компонент домена — в первую очередь контроллеров домена.

Контроллеры домена — специальные серверы, которые хранят соответствующую данному домену часть базы данных Active Directory. Основные функции контроллеров домена:

- хранение БД Active Directory (организация доступа к информации, содержащейся в каталоге, включая управление этой информацией и ее модификацию);

- синхронизация изменений в AD (изменения в базу данных AD могут быть внесены на любом из контроллеров домена, любые изменения, осуществляемые на одном из контроллеров, будут синхронизированы c копиями, хранящимися на других контроллерах);

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

Настоятельно рекомендуется в каждом домене устанавливать не менее двух контроллеров домена — во-первых, для защиты от потери БД Active Directory в случае выхода из строя какого-либо контроллера, во-вторых, для распределения нагрузки между контроллерами.

Дерево.

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

Пример дерева Active Directory изображен на рисунке 4.3. В данном примере домен company.ru является доменом Active Directory верхнего уровня. От корневого домена отходят дочерние домены it.company.ru и fin.company.ru. Эти домены могут относиться соответственно к ИТ-службе компании и финансовой службе. У домена it.company.ru есть поддомен dev.it.company.ru, созданный для отдела разработчиков ПО ИТ-службы.

Корпорация Microsoft рекомендует строить Active Directory в виде одного домена. Построение дерева, состоящего из многих доменов необходимо в следующих случаях:

- для децентрализации администрирования служб каталогов (например, в случае, когда компания имеет филиалы, географически удаленные друг от друга, и централизованное управление затруднено по техническим причинам);

- для повышения производительности (для компаний с большим количеством пользователей и серверов актуален вопрос повышения производительности работы контроллеров домена);

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

- для применения различных политик безопасности для различных подразделений компании;

- при большом количестве объектов в БД Active Directory.

Рис. 4.3

Лес.

Наиболее крупная структура в Active Directory. Лес объединяет деревья, которые поддерживают единую схему (схема Active Directory — набор определений типов, или классов, объектов в БД Active Directory). В лесе между всеми доменами установлены двухсторонние транзитивными доверительными отношения, что позволяет пользователям любого домена получать доступ к ресурсам всех остальных доменов, если они имеют соответствующие разрешения на доступ. По умолчанию, первый домен, создаваемый в лесе, считается его корневым доменом, в корневом домене хранится схема AD.

Новые деревья в лесе создаются в том случае, когда необходимо построить иерархию доменов с пространством имен, отличным от других пространств леса. В примере на рис. 4.3 российская компания могла открыть офис за рубежом и для своего зарубежного отделения создать дерево с доменом верхнего уровня company.com. При этом оба дерева являются частями одного леса с общим «виртуальным» корнем.

При управлении деревьями и лесами нужно помнить два очень важных момента:

- первое созданное в лесу доменов дерево является корневым деревом, первый созданный в дереве домен называется корневым доменом дерева (tree root domain);

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

Организационные подразделения (ОП).

Организационные подразделения (Organizational Units, OU) — контейнеры внутри AD, которые создаются для объединения объектов в целях делегирования административных прав и применения групповых политик в домене. ОП существуют только внутри доменов и могут объединять только объекты из своего домена. ОП могут быть вложенными друг в друга, что позволяет строить внутри домена сложную древовидную иерархию из контейнеров и осуществлять более гибкий административный контроль. Кроме того, ОП могут создаваться для отражения административной иерархии и организационной структуры компании.

Глобальный каталог

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

Именование объектов.

В службе каталогов должен быть механизм именования объектов, позволяющий однозначно идентифицировать любой объект каталога. В каталогах на базе протокола LDAP для идентификации объекта в масштабе всего леса используется механизм отличительных имен (Distinguished Name, DN). В Active Directory учетная запись пользователя с именем User домена company.ru, размещенная в стандартном контейнере Users, будет иметь следующее отличительное имя: «DC=ru, DC=company, CN=Users, CN=User».

Обозначения:

- DC (Domain Component) — указатель на составную часть доменного имени;

- OU (Organizational Unit) — указатель на организационное подразделение (ОП);

- CN (Common Name) — указатель на общее имя.

Если отличительное имя однозначно определяет объект в масштабе всего леса, то для идентификации объекта относительно контейнера, в котором данный объект хранится, существует относительное отличительное имя (Relative Distinguished Name, RDN). Для пользователя User из предыдущего примера RDN-имя будет иметь вид «CN=User».

Кроме имен DN и RDN, используется основное имя объекта (User Principal Name, UPN). Оно имеет формат <имя субъекта>@<суффикс домена>. Для того же пользователя из примера основное имя будет выглядеть как User@company.ru.

Имена DN, RDN могут меняться, если объект перемещается из одного контейнера AD в другой. Для того чтобы не терять ссылки на объекты при их перемещении в лесе, всем объектам назначается глобально уникальный идентификатор (Globally Unique Identifier, GUID), представляющий собой 128-битное число.

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

Планирование пространства имен и структуры AD — очень ответственный момент, от которого зависит эффективность функционирования будущей корпоративной системы безопасности. При этом надо иметь в виду, что созданную вначале структуру в процессе эксплуатации будет очень трудно изменить (например, в Windows 2000 изменить имя домена верхнего уровня вообще невозможно, а в Windows 2003 решение этой задачи требует выполнения жестких условий и тщательной подготовки данной операции). При планировании AD необходимо учитывать следующие моменты:

- тщательный выбор имен доменов верхнего уровня;

- качество коммуникаций в компании (связь между отдельными подразделениями и филиалами);

- организационная структура компании;

- количество пользователей и компьютеров в момент планирования;

- прогноз темпов роста количества пользователей и компьютеров.

Рассмотрим вопрос пространства имен AD.

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

Рассмотрим основные варианты.

1) Один домен, одна зона DNS (рис. 4.4).

На рисунке в левой части — внутренняя сеть компании, справа — сеть Интернет, две сети разделены маршрутизатором «R» (кроме маршрутизатора, на границе могут быть также прокси-сервер или межсетевой экран).

Рис. 4.4

В данном примере используется одна и та же зона DNS (company.ru) как для поддержки внутреннего домена AD с тем же именем (записи DC, SRV-1, SRV-2, WS-1), так и хранения ссылок на внешние ресурсы компании — веб-сайт, почтовый сервер (записи www, mail).

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

2) Одно имя домена, две зоны DNS (рис. 4.5).

Рис. 4.5

В данном случае на различных серверах DNS создаются различные зоны с одним и тем же именем company.ru. На внутреннем DNS-сервере функционирует зона company.ru.для Active Directory, на внешнем DNS-сервере — зона с таким же именем, но для ссылок не внешние ресурсы. Важный момент — данные зоны никак между собой не связаны — ни механизмами репликации, ни ручной синхронизацией.

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

3) «Расщепление» пространства имен DNS (рис. 4.6).

Рис. 4.6

В данном примере корневой домен компании company.ru служит для хранения ссылок на внешние ресурсы. В домене company.ru настраивается делегирование управление поддоменом corp.company.ru на внутренний DNS-сервер, и именно на базе домене corp.company.ru создается домен Active Directory. В этом случае во внешней зоне хранятся ссылки на внешние ресурсы, а также ссылка на делегирование управления поддоменом на внутренний DNS-сервер. Таким образом, пользователям Интернета доступен минимум информации о внутренней сети. Такой вариант организации пространства имен довольно часто используется компаниями.

4) Два различных домена DNS для внешних ресурсов и для Active Directory (рис. 4.7.).

Рис. 4.7

В этом сценарии компания регистрирует в Интернет-органах два доменных имени: одно для публикации внешних ресурсов, другое — для развертывания Active Directory.

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

5) Домен с именем типа company.local.

Во многих учебных пособиях и статьях используются примеры с доменными иенами вида company.local. Такая схема вполне работоспособна и также часто применяется на практике. Однако в материалах разработчика системы Windows, корпорации Microsoft, нет прямых рекомендаций об использовании данного варианта.

Установка контроллеров доменов

Теперь перейдем к описанию процедур установки контроллеров доменов Active Directory.

Разберем установку самого первого контроллера самого первого домена самого первого леса в структуре AD.

Установка начинается с запуска из командной строки мастера установки Active Directory — dcpromo (рис. 4.8).

Рис. 4.8

Нажимаем кнопку «ОК» и видим стартовую страницу мастера (рис. 4.9):

Рис. 4.9

Далее идет предупреждение, что операционные системы Windows 95, Windows NT 4.0 SP3 и более ранние не смогут функционировать в доменах Windows 2003 (рис. 4.10). Заметим, что в доменах на базе Windows 2000 такой проблемы нет (да и в доменах на базе windows 2003 эта проблема решаема).

Рис. 4.10

Затем выбираем варианты установки контроллера домена в новом домене (рис. 4.11) и создания нового домена в новом лесу (рис. 4.12):

Рис. 4.11

Рис. 4.12

Следующий шаг — выбор имени домена (для Active Directory это будет корневой домен). В нашем примере выберем имя world.ru (рис. 4.13):

Рис. 4.13

Зададим NetBIOS-имя домена (по умолчанию, будет предложена левая часть полного имени домена, выбранного на предыдущем шаге). В нашем примере — WORLD (рис. 4.14.):

Рис. 4.14

Далее мастер предложит выбрать место на жестких дисках для размещения базы данных Active Directory, журнала транзакций это БД (рис. 4.15) и папки системного тома SYSVOL (рис. 4.16). Системный том обязательно должен быть размещен на разделе с файловой системой NTFS.

Рис. 4.15

Рис. 4.16

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

Рис. 4.17

Далее предлагается выбрать уровень разрешений создаваемого домена (рис. 4.18). Заметим, что если мы выберем наиболее высокий уровень, то в таком домене не смогут существовать компьютеры с операционными системами, более ранними, чем Windows 2000.

Рис. 4.18

Затем задаем пароль администратора при запуске системы в режиме восстановления служб каталогов (рис. 4.19). данный режим используется для восстановления БД Active Directory из резервной копии.

Рис. 4.19

Затем следует экран со сводкой информации о создаваемом домене и параметрах контроллера домена (рис. 4.20). На этом шаге в случае обнаруженной ошибки в конфигурации можно вернуться назад и исправить ошибку.

Рис. 4.20

После этого начинается работа по созданию базы данных AD и наполнению ее нужными записями (рис. 4.21).

Рис. 4.21

Последний шаг — нажать кнопку «Готово» и перезагрузить сервер (рис. 4.22).

Рис. 4.22

Важное замечание. Если при создании первого контроллера в домене перед запуском мастера в локальной базе SAM данного сервера были какие-либо учетные записи пользователей и групп, то все они импортируются в созданную БД Active Directory с сохранением своих имен и паролей, в том числе и учетная запись администратора сервера, которая становится учетной записью администратора домена (а если это самый первый домен в лесе, то и администратором предприятия и администратором схемы).

Кратко опишем процесс установки дополнительного контроллера в уже созданном домене.

Если у нас есть второй сервер, который мы хотим сделать дополнительным контроллером домена, то вначале желательно включить его в домен в качестве сервера–члена домена. Кнопка «Пуск» — Панель управления — Система — Закладка «Имя компьютера» — Кнопка «Изменить». Далее в поле «Является членом домена» ввести имя домена, нажать ОК, ввести имя и пароль администратора домена, снова нажать ОК и перезагрузить сервер (рис. 4.23).

Рис. 4.23

После перезагрузки входим в систему с учетной записью администратора домена и запускаем мастер установки Active Directory — команда dcpromo. Выбираем вариант «Добавочный контроллер в существующем домене» (рис. 4.24).

Рис. 4.24

Указываем учетные данные администратора домена (рис. 4.25):

Рис. 4.25

Снова указываем имя домена — world.ru. Начинается процесс импорта БД Active Directory на создаваемый контроллер (рис. 4.26):

Рис. 4.26

По окончании процесса — снова нажать кнопку «Готово» и перезагрузить сервер.

Важное замечание. При добавлении дополнительного контроллера в домене существовавшая на сервере локальная база SAM с сервера удаляется.

Опишем процесс установки дополнительного контроллера домена из резервной копии AD существующего контроллера.

Сначала создадим резервную копию AD. Запустим на существующем контроллере домена утилиту ntbackup, выберем архивацию состояния системы (System State), укажем путь для создания файла с резервной копией и нажмем кнопку «Архивировать» (рис. 4.27):

Рис. 4.27

На следующем шаге — нажать кнопку «Дополнительно» (рис. 4.28):

Рис. 4.28

В открывшейся панели — убрать галочку у поля «Автоматически архивировать защищенные системные файлы вместе с состоянием системы» (рис. 4.29):

Рис. 4.29

После создания резервной копии AD файл с резервной копией желательно скопировать на жесткий диск того сервера, который будет преобразовываться в контроллер домена. Затем надо разархивировать резервную копию утилитой ntbackup. При этом обязательно надо указать, что восстанавливать данные надо в альтернативное размещение и указать папку для размещения восстановленных данных (рис. 4.30):

Рис. 4.30

Теперь на сервере, который преобразуем из простого сервера в контроллер домена, запускаем утилиту dcpromo с параметром «/adv» (рис. 4.31):

Рис. 4.31

На этапе выбора источника БД Active Directory — выбрать вариант «используя файлы из архива» и указать путь к папке, в которую разархивировали резервную копию (рис. 4.32):

Рис. 4.32

По окончании процесса — перезагрузить сервер.