Операционная система windows server поддерживает группы трех типов

Замечания по
автоматической установке операционной
системы Windows Server.

Вопросы
автоматической установки системы не
входят в данный учебный курс. Для
получения начальной информации по этой
теме рекомендуем ознакомиться с
материалами, имеющимися на установочном
компакт-диске. На этом CD есть папка
SUPPORTTOOLS,
в которой среди прочих имеется файл
DEPLOY.CAB.
В данном файле содержится ряд утилит,
которые помогают автоматизировать
процедуру установки системы и подготовить
сценарии для тиражирования установки
на большое количество серверов. Это в
первую очередь программа установки
winnt32.exe
(и ее 16-битный собрат winnt.exe),
которая в комбинации с различными
ключами и параметрами может намного
ускорить процесс установки. А также
программы setupmgr.exe
и sysprep.exe.
В файле DEPLOY.CAB
имеется также файл deploy.chm,
в котором содержится подробное описание
использование всех данных утилит.

С
дистрибутивного компакт-диска можно
установить комплект ресурсов Windows Server
2003 Support Tools. Средства поддержки — это
универсальный набор утилит для выполнения
любых сервисных задач от диагностики
системы до сетевого мониторинга.

Есть
много способов администрирования систем
Windows Server 2003. Чаще всего применяются
следующие.

• Панель управления
  — набор средств для управления
  конфигурацией системы Windows Server 2003. В
  классическом меню Пуск (Start) доступ к
  этим средствам открывает подменю
  Настройка (Settings), в упрощенном меню
  Пуск (Start) команда Панель управления
  (Control Panel) доступна сразу.

• Графические
  средства администрирования — ключевые
  средства для управления компьютерами
  в сети и их ресурсами. Доступ к
  необходимому средству можно получить,
  щелкнув его значок в подменю
  Администрирование (Administrative Tools).

• Мастера
  администрирования — средства
  автоматизации ключевых административных
  задач. В отличие от Windows NT мастера не
  сосредоточены в центральном месте —
  доступ к ним происходит посредством
  выбора соответствующих параметров
  меню и других средств администрирования.

• Функции командной
  строки. Большинство административных
  действий можно выполнять из командной
  строки.

В этом
упражнении вы освоите установку
операционных систем семейства Windows 2003
Server

Упражнение
1. Установка операционной системы Windows
2003 Server (редакция Standard или Enterprise)

4. Лекция: Протокол tcp/ip, служба dns:

Работа
сетевых компонент операционных систем
семейства Windows Server базируется на протоколе
TCP/IP, а функционирование службы каталогов
Active Directory полностью зависит от службы
DNS. По этой причине описание протокола
TCP/IP и службы DNS вынесено в отдельный
раздел, предваряющий изучение остальных
служб и компонент. В лекции 1 были кратко
описаны протоколы и приложения, образующие
стек TCP/IP, поэтому в данном разделе
подробно рассматриваются правила
адресации узлов IP-сетей и алгоритмы
взаимодействия узлов, а также работа
службы доменных имен DNS.

4.1 Основы функционирования протокола tcp/ip (ip-адрес, маска подсети, основной шлюз; деление на подсети с помощью маски подсети; введение в ip-маршрутизацию). Адресация узлов в ip-сетях

В
сетях TCP/IP принято различать адреса
сетевых узлов трех уровней

• физический (или
  локальный) адрес узла (МАС-адрес сетевого
  адаптера или порта маршрутизатора);
  эти адреса назначаются производителями
  сетевого оборудования;

• IP-адрес
  узла (например, 192.168.0.1),
  данные адреса назначаются сетевыми
  администраторами или Интернет-провайдерами;

• символьное имя
  (например, www.microsoft.com); эти имена также
  назначаются сетевыми администраторами
  компаний или Интернет-провайдерами.

Рассмотрим
подробнее IP-адресацию.

Компьютеры
или другие сложные сетевые устройства,
подсоединенные к нескольким физическим
сетям, имеют несколько IP-адресов — по
одному на каждый сетевой интерфейс.
Схема адресации позволяет проводить
единичную, широковещательную и групповую
адресацию. Таким образом, выделяют 3
типа IP-адресов.

1. Unicast-адрес (единичная
   адресация конкретному узлу) — используется
   в коммуникациях «один-к-одному».

2. Broadcast-адрес
   (широковещательный адрес, относящийся
   ко всем адресам подсети) — используется
   в коммуникациях «один-ко-всем». В
   этих адресах поле идентификатора
   устройства заполнено единицами.
   IP-адресация допускает широковещательную
   передачу, но не гарантирует ее — эта
   возможность зависит от конкретной
   физической сети. Например, в сетях
   Ethernet широковещательная передача
   выполняется с той же эффективностью,
   что и обычная передача данных, но есть
   сети, которые вообще не поддерживают
   такой тип передачи или поддерживают
   весьма ограничено.

3. Multicast-адрес
   (групповой адрес для многоадресной
   отправки пакетов) — используется в
   коммуникациях «один-ко-многим».
   Поддержка групповой адресации
   используется во многих приложениях,
   например, приложениях интерактивных
   конференций. Для групповой передачи
   рабочие станции и маршрутизаторы
   используют протокол IGMP, который
   предоставляет информацию о принадлежности
   устройств определенным группам.

Unicast-адреса.

Каждый
сетевой интерфейс на каждом узле сети
должен иметь уникальный unicast-адрес.
IP-адрес имеет длину 4 байта (или 32 бита).
Для удобства чтения адресов 32-битные
числа разбивают на октеты по 8 бит, каждый
октет переводят в десятичную систему
счисления и при записи разделяют точками.
Например, IP-адрес 11000000101010000000000000000001
записывается как 192.168.0.1.

I

P-адрес
состоит из двух частей — идентификатор
сети (префикс сети, Network ID) и идентификатор
узла (номер устройства, Host ID). Такая схема
приводит к двухуровневой адресной
иерархии. Структура IP-адреса изображена
на рис.
4.1.

Рис. 4.1

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

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

Таким
образом, в целом IP-адрес будет уникален
для каждого сетевого интерфейса всей
сети TCP/IP.

Соотношение
между идентификатором сети и идентификатором
узла в IP-адресе определяется с помощью
маски подсети (Network mask), которая имеет
длину также 4 байта и также записывается
в десятичной форме по 4 октета, разделенных
точками. Старшие биты маски подсети,
состоящие из 1,
определяют, какие разряды IP-адреса
относятся к идентификатору сети. Младшие
биты маски, состоящие из 0,
определяют, какие разряды IP-адреса
относятся к идентификатору узла.

IP-адрес
и маска подсети — минимальный набор
параметров для конфигурирования
протокола TCP/IP на сетевом узле.

Для
обеспечения гибкости в присваивании
адресов компьютерным сетям разработчики
протокола определили, что адресное
пространство IP должно быть разделено
на три различных класса — А, В и С.

В
дополнение к этим трем классам выделяют
еще два класса. D — этот класс используется
для групповой передачи данных. Е —
класс, зарезервированный для проведения
экспериментов.

IP-адреса
класса А.

С

тарший
бит любого IP-адреса в сети класса А
всегда равен 0. Идентификатор сети
состоит из 8 бит, идентификатор узла —
24 бита. Маска подсети для узлов сетей
класса A — 255.0.0.0.
Структура IP-адресов класса А приведена
на рис.
4.2.

Рис. 4.2

IP-адреса
класса B.

Д

ва
старших бита любого IP-адреса в сети
класса B всегда равны 10. Идентификатор
сети состоит из 16 бит, идентификатор
узла — 16 бит. Маска подсети для узлов
сетей класса B — 255.255.0.0.
Структура IP-адресов класса B приведена
на рис.
4.3.

Рис. 4.3

IP-адреса
класса C.

Т

ри
старших разряда любого IP-адреса в сети
класса C всегда равны 110.
Идентификатор сети состоит из 24 разрядов,
идентификатор узла — из 8 разрядов.
Маска подсети для узлов сетей класса C
— 255.255.255.0.
Структура IP-адресов класса C приведена
на рис.
4.4.

Рис. 4.4

Класс
D

IP-адреса
класса D используются для групповых
адресов (multicast-адреса). Четыре старших
разряда любого IP-адреса в сети класса
D всегда равны 1110.
Оставшиеся 28 бит используются для
назначения группового адреса.

Класс
E

Пять
старших разрядов любого IP-адреса в сети
класса E равны 11110.
Адреса данного класса зарезервированы
для будущего использования (и не
поддерживаются системой Windows Server).

Правила
назначения идентификаторов сети (Network
ID)

• первый
  октет идентификатора сети не может
  быть равен 127
  (адреса вида 127.x.y.z
  предназначены для отправки узлом
  пакетов самому себе и используются как
  правило для отладки сетевых приложений,
  такие адреса называются loopback-адресами,
  или адресами обратной связи);

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

• все
  разряды идентификатора сети не могут
  состоять из одних 0
  (в IP-адресах все биты, установленные в
  ноль, соответствуют либо данному
  устройству, либо данной сети);

• идентификатор
  каждой конкретной сети должен быть
  уникальным среди подсетей, объединенных
  в одну сеть с помощью маршрутизаторов.

Диапазоны
возможных идентификаторов сети приведены
в табл.
4.1.

Правила
назначения идентификаторов узла (Host
ID)

• все
  разряды идентификатора узла не могут
  состоять из одних 1
  (идентификатор узла, состоящий из одних
  1,
  используется для широковещательных
  адресов, или broadcast-адресов);

• все
  разряды идентификатора сети не могут
  состоять из одних 0
  (если разряды идентификатора узла равны
  0,
  то такой адрес обозначает всю подсеть,
  например, адрес 192.168.1.0
  с маской подсети 255.255.255.0
  обозначает всю подсеть с идентификатором
  сети 192.168.1;

• идентификатор
  узла должен быть уникальным среди узлов
  одной подсети.

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

Другим
способом обозначения сети, более удобным
и более кратким, является обозначение
сети с сетевым префиксом. Такое обозначение
имеет вид «/число бит маски подсети».
Например, подсеть 192.168.1.0
с маской подсети 255.255.255.0
можно более кратко записать в виде
192.168.1.0/24,
где число 24
длина маски подсети в битах.

Публичные и приватные (частные) ip-адреса

Все
пространство IP-адресов разделено на 2
части: публичные адреса, которые
распределяются между Интернет-провайдерами
и компаниями международной организацией
Internet Assigned Numbers Authority (сокращенно IANA), и
приватные адреса, которые не контролируются
IANA и могут назначаться внутрикорпоративным
узлам по усмотрению сетевых администраторов.
Если какая-либо компания приобрела
IP-адреса в публичной сети, то ее сетевые
узлы могут напрямую маршрутизировать
сетевой трафик в сеть Интернет и могут
быть прозрачно доступны из Интернета.
Если внутрикорпоративные узлы имеют
адреса из приватной сети, то они могут
получать доступ в Интернет с помощью
протокола трансляции сетевых адресов
(NAT, Network Address Translation) или с помощью
прокси-сервера. В простейшем случае с
помощью NAT возможно организовать работу
всей компании с использованием
единственного зарегистрированного
IP-адреса.

Механизм
трансляции адресов NAT преобразует
IP-адреса из частного адресного пространства
IP (эти адреса еще называют «внутренние»,
или «серые IP») в зарегистрированное
открытое адресное пространство IP. Обычно
эти функции (NAT) выполняет либо
маршрутизатор, либо межсетевой экран
(firewall) — эти устройства подменяют адреса
в заголовках проходящих через них
IP-пакетов.

На
практике обычно компании получают через
Интернет-провайдеров небольшие сети в
пространстве публичных адресов для
размещения своих внешних ресурсов —
web-сайтов или почтовых серверов. А для
внутрикорпоративных узлов используют
приватные IP-сети.

Пространство
приватных IP-адресов состоит из трех
блоков:

• 10.0.0.0/8
  (одна сеть класса A);

• 172.16.0.0/12
  (диапазон адресов, состоящий из 16 сетей
  класса B — от 172.16.0.0/16
  до 172.31.0.0/16);

• 192.168.0.0/16(диапазон
  адресов, состоящий из 256 сетей класса
  C — от 192.168.0.0/24
  до
  192.168.255.0/16).

Кроме
данных трех блоков имеется еще блок
адресов, используемых для автоматической
IP-адресации (APIPA, Automatic Private IP Addressing).
Автоматическая IP-адресация применяется
в том случае, когда сетевой интерфейс
настраивается для автоматической
настройки IP-конфигурации, но при этом
в сети отсутствует сервер DHCP. Диапазон
адресов для APIPA — сеть класса B
169.254.0.0/16.

Отображение ip-адресов на физические адреса

Каждый
сетевой адаптер имеет свой уникальный
физический адрес (или MAC-адрес). За
отображение IP-адресов адаптеров на их
физические адреса отвечает протокол
ARP (Address Resolution Protocol). Необходимость
протокола ARP продиктована тем
обстоятельством, что IP-адреса устройств
в сети назначаются независимо от их
физических адресов. Поэтому для доставки
сообщений по сети необходимо определить
соответствие между физическим адресом
устройства и его IP-адресом — это
называется разрешением адресов. В
большинстве случаев прикладные программы
используют именно IP-адреса. А так как
схемы физической адресации устройств
весьма разнообразны, то необходим
специальный, универсальный протокол.
Протокол разрешения адресов ARP был
разработан таким образом, чтобы его
можно было использовать для разрешения
адресов в различных сетях. Фактически
ARP можно использовать с произвольными
физическими адресами и сетевыми
протоколами. Протокол ARP предполагает,
что каждое устройство знает как свой
IP-адрес, так и свой физический адрес.
ARP динамически связывает их и заносит
в специальную таблицу, где хранятся
пары «IP-адрес — физический адрес»
(обычно каждая запись в ARP-таблице имеет
время жизни 10 мин.). Эта таблица хранится
в памяти компьютера и называется кэш
протокола ARP (ARP-cache).

Работа
протокола ARP заключается в отправке
сообщений между сетевыми узлами:

• ARP Request (запрос
  ARP) — широковещательный запрос,
  отправляемый на физическом уровне
  модели TCP/IP, для определения MAC-адреса
  узла, имеющего конкретный IP-адрес;

• ARP Reply (ответ ARP) —
  узел, IP-адрес которого содержится в
  ARP-запросе, отправляет узлу, пославшему
  ARP-запрос, информацию о своем MAC-адресе;

• RARP Request, или Reverse
  ARP Request (обратный ARP-запрос) — запрос на
  определение IP-адреса по известному
  MAC-адресу;

• RARP Reply, или Reverse
  ARP Reply (обратный ARP-ответ) — ответ узла
  на обратный ARP-запрос.

Разбиение сетей на подсети с помощью маски подсети

Для
более эффективного использования
пространства адресов IP-сети с помощью
маски подсети могут быть разбиты на
более мелкие подсети (subnetting) или объединены
в более крупные сети (supernetting).

Рассмотрим
на примере разбиение сети 192.168.1.0/24
(сеть класса C) на более мелкие подсети.
В исходной сети в IP-адресе 24 бита относятся
к идентификатору сети и 8 бит — к
идентификатору узла. Используем маску
подсети из 27 бит, или, в десятичном
обозначении, — 255.255.255.224,
в двоичном обозначении — 11111111
11111111 11111111 11100000. Получим
следующее разбиение на подсети:

Таким
образом, мы получили 8 подсетей, в каждой
из которых может быть до 30 узлов. Напомним,
что идентификатор узла, состоящий из
нулей, обозначает всю подсеть, а
идентификатор узла, состоящий из одних
единиц, означает широковещательный
адрес (пакет, отправленный на такой
адрес, будет доставлен всем узлам
подсети).

IP-адреса
в данных подсетях будут иметь структуру:

Отметим
очень важный момент. С использованием
такой маски узлы с такими, например,
IP-адресами, как 192.168.1.48
и 192.168.1.72,
находятся в различных подсетях, и для
взаимодействия данных узлов необходимы
маршрутизаторы, пересылающие пакеты
между подсетями192.168.1.32/27
и 192.168.1.64/27.

Примечание.
Согласно стандартам протокола TCP/IP для
данного примера не должно существовать
подсетей 192.168.1.0/27
и 192.168.1.224/27
(т.е. первая и последняя подсети). На
практике большинство операционных
систем (в т.ч. системы семейства Microsoft
Windows) и маршрутизаторов поддерживают
работу с такими сетями.

А

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

Например,
IP-адреса сети 192.168.0.0/21
будут иметь следующую структуру:

Диапазон
IP-адресов данной сети: 192.168.0.1–192.168.7.254
(всего — 2046 узлов), широковещательный
адрес подсети — 192.168.7.255.

Преимущества
подсетей внутри частной сети:

• разбиение больших
  IP-сетей на подсети (subnetting) позволяет
  снизить объем широковещательного
  трафика (маршрутизаторы не пропускают
  широковещательные пакеты);

• объединение
  небольших сетей в более крупные сети
  (supernetting) позволяет увеличить адресное
  пространство с помощью сетей более
  низкого класса;

• изменение топологии
  частной сети не влияет на таблицы
  маршрутизации в сети Интернет (хранят
  только маршрут с общим номером сети);

• размер глобальных
  таблиц маршрутизации в сети Интернет
  не растет;

• администратор
  может создавать новые подсети без
  необходимости получения новых номеров
  сетей.

Старшие
биты IP-адреса используются рабочими
станциями и маршрутизаторами для
определения класса адреса. После того
как класс определен, устройство может
однозначно вычислить границу между
битами, использующимися для идентификации
номера сети, и битами номера устройства
в этой сети. Однако при разбиении сетей
на подсети или при объединении сетей
для определения границ битов,
идентифицирующих номер подсети, такая
схема не подходит. Для этого как раз и
используется 32-битная маска подсети,
которая помогает однозначно определить
требуемую границу. Напомним, что для
стандартных классов сетей маски имеют
следующие значения:

• 255.0.0.0
  – маска для сети класса А;

• 255.255.0.0
  — маска для сети класса В;

• 255.255.255.0
  — маска для сети класса С.

Для
администратора сети чрезвычайно важно
знать четкие ответы на следующие вопросы:

• Сколько подсетей
  требуется организации сегодня?

• Сколько подсетей
  может потребоваться организации в
  будущем?

• Сколько устройств
  в наибольшей подсети организации
  сегодня?

• Сколько устройств
  будет в самой большой подсети организации
  в будущем?

Отказ
от использования только стандартных
классов IP-сетей (A, B, и C) называется
бесклассовой междоменной маршрутизацией
(Classless Inter-Domain Routing, CIDR).

Введение в ip-маршрутизацию

Для
начала уточним некоторые понятия:

• сетевой узел
  (node) — любое сетевое устройство с
  протоколом TCP/IP;

• хост (host) — сетевой
  узел, не обладающий возможностями
  маршрутизации пакетов;

• маршрутизатор
  (router) — сетевой узел, обладающий
  возможностями маршрутизации пакетов

IP-маршрутизация
— это процесс пересылки unicast-трафика
от узла-отправителя к узлу–получателю
в IP-сети с произвольной топологией.

Когда
один узел IP-сети отправляет пакет другому
узлу, в заголовке IP-пакета указываются
IP-адрес узла отправителя и IP-адрес
узла-получателя. Отправка пакета
происходит следующим образом:

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

2. Если оба сетевых
   узла расположены в одной IP-сети, то
   узел-отправитель сначала проверяет
   ARP-кэш на наличие в ARP-таблице MAC-адреса
   узла-получателя. Если нужная запись в
   таблице имеется, то дальше отправка
   пакетов производится напрямую
   узлу-получателю на канальном уровне.
   Если же в ARP-таблице нужной записи нет,
   то узел-отправитель посылает ARP-запрос
   для IP-адреса узла-получателя, ответ
   помещает в ARP-таблицу и после этого
   передача пакета также производится на
   канальном уровне (между сетевыми
   адаптерами компьютеров).

3. Если узел-отправитель
   и узел-получатель расположены в разных
   IP-сетях, то узел-отправитель посылает
   данный пакет сетевому узлу, который в
   конфигурации отправителя указан как
   «Основной шлюз» (default gateway). Основной
   шлюз всегда находится в той же IP-сети,
   что и узел-отправитель, поэтому
   взаимодействие происходит на канальном
   уровне (после выполнения ARP-запроса).
   Основной шлюз — это маршрутизатор,
   который отвечает за отправку пакетов
   в другие подсети (либо напрямую, либо
   через другие маршрутизаторы).

Р

ассмотрим
пример, изображенный на рис.
4.5.

Рис. 4.5

В
данном примере 2 подсети: 192.168.0.0/24
и 192.168.1.0/24.
Подсети объединены в одну сеть
маршрутизатором. Интерфейс маршрутизатора
в первой подсети имеет IP-адрес 192.168.0.1,
во второй подсети — 192.168.1.1.
В первой подсети имеются 2 узла: узел A
(192.168.0.5)
и узел B (192.168.0.7).
Во второй подсети имеется узел C с
IP-адресом 192.168.1.10.

Если
узел A будет отправлять пакет узлу B, то
сначала он вычислит, что узел B находится
в той же подсети, что и узел A (т.е. в
локальной подсети), затем узел A выполнит
ARP-запрос для IP-адреса 192.168.0.7.
После этого содержимое IP-пакета будет
передано на канальный уровень, и
информация будет передана сетевым
адаптером узла A сетевому адаптеру узла
B. Это пример прямой доставки данных
(или прямой маршрутизации, direct delivery).

Если
узел A будет отправлять пакет узлу C, то
сначала он вычислит, что узел C находится
в другой подсети (т.е. в удаленной
подсети). После этого узел A отправит
пакет узлу, который в его конфигурации
указан в качестве основного шлюза (в
данном случае это интерфейс маршрутизатора
с IP-адресом 192.168.0.1).
Затем маршрутизатор с интерфейса
192.168.1.1
выполнит прямую доставку узлу C. Это
пример непрямой доставки (или косвенной
маршрутизации, indirect delivery) пакета от узла
A узлу C. В данном случае процесс косвенной
маршрутизации состоит из двух операций
прямой маршрутизации.

В
целом процесс IP-маршрутизации представляет
собой серии отдельных операций прямой
или косвенной маршрутизации пакетов.

Каждый
сетевой узел принимает решение о
маршрутизации пакета на основе таблицы
маршрутизации, которая хранится в
оперативной памяти данного узла. Таблицы
маршрутизации существуют не только у
маршрутизаторов с несколькими
интерфейсами, но и у рабочих станций,
подключаемых к сети через сетевой
адаптер. Таблицу маршрутизации в системе
Windows можно посмотреть по команде route
print.
Каждая таблица маршрутизации содержит
набор записей. Записи могут формироваться
различными способами:

• записи, созданные
  автоматически системой на основе
  конфигурации протокола TCP/IP на каждом
  из сетевых адаптеров;

• статические
  записи, созданные командой route
  add
  или в консоли службы Routing
  and Remote Access Service;

• динамические
  записи, созданные различными протоколами
  маршрутизации (RIP или OSPF).

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

Рабочая
станция.

В
данном примере имеется рабочая станция
с системой Windows XP, с одним сетевым
адаптером и такими настройками протокола
TCP/IP: IP-адрес — 192.168.1.10,
маска подсети — 255.255.255.0,
основной шлюз — 192.168.1.1.

Введем
в командной строке системы Windows команду
route
print,
результатом работы команды будет
следующий экран (рис.
4.6; в
скобках приведен текст для английской
версии системы):

Р

ис.
4.6

Список
интерфейсов
— список сетевых адаптеров, установленных
в компьютере. Интерфейс MS
TCP Loopback interface
присутствует всегда и предназначен для
обращения узла к самому себе. Интерфейс
Realtek
RTL8139 Family PCI Fast Ethernet NIC
— сетевая
карта.

Далее
идет сама таблица маршрутов. Каждая
строка таблицы — это маршрут для
какой-либо IP-сети. Ее столбцы:

Сетевой
адрес —
диапазон IP-адресов, которые достижимы
с помощью данного маршрута.

Маска
сети — маска
подсети, в которую отправляется пакет
с помощью данного маршрута.

Адрес
шлюза —
IP-адрес узла, на который пересылаются
пакеты, соответствующие данному маршруту.

Интерфейс
— обозначение сетевого интерфейса
данного компьютера, на который пересылаются
пакеты, соответствующие маршруту.

Метрика
— условная стоимость маршрута. Если
для одной и той же сети есть несколько
маршрутов, то выбирается маршрут с
минимальной стоимостью. Как правило,
метрика — это количество маршрутизаторов,
которые должен пройти пакет, чтобы
попасть в нужную сеть.

Проанализируем
некоторые строки таблицы.

Первая
строка таблицы соответствует значению
основного шлюза в конфигурации TCP/IP
данной станции. Сеть с адресом «0.0.0.0»
обозначает «все остальные сети, не
соответствующие другим строкам данной
таблицы маршрутизации».

Вторая
строка — маршрут для отправки пакетов
от узла самому себе.

Третья
строка (сеть 192.168.1.0
с маской 255.255.255.0)
— маршрут для отправки пакетов в
локальной IP-сети (т.е. той сети, в которой
расположена данная рабочая станция).

Последняя
строка — широковещательный адрес для
всех узлов локальной IP-сети.

Последняя
строка на рис.
4.6 —
список постоянных маршрутов рабочей
станции. Это статические маршруты,
которые созданы командой route
print.
В данном примере нет ни одного такого
статического маршрута.

Сервер.

Теперь
рассмотрим сервер с системой Windows 2003
Server, с тремя сетевыми адаптерами:

• Адаптер
  1 — расположен во внутренней сети
  компании (IP-адрес — 192.168.1.10,
  маска подсети — 255.255.255.0);

• Адаптер
  2 — расположен во внешней сети
  Интернет-провайдера ISP-1 (IP-адрес —
  213.10.11.2,
  маска подсети — 255.255.255.248,
  ближайший интерфейс в сети провайдера
  — 213.10.11.1);

• Адаптер
  3 — расположен во внешней сети
  Интернет-провайдера ISP-2 (IP-адрес —
  217.1.1.34,
  маска подсети — 255.255.255.248,
  ближайший интерфейс в сети провайдера
  — 217.1.1.33).

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

Кроме
того, на сервере установлена Служба
маршрутизации и удаленного доступа для
управления маршрутизацией пакетов
между IP-сетями и доступа в сеть компании
через модемный пул.

В
данном случае команда route
print
выдаст таблицу маршрутизации, изображенную
на рис.
4.7.

Р

ис.
4.7

В
таблице в списке интерфейсов отображены
три сетевых адаптера разных моделей,
адаптер обратной связи (MS TCP Loopback
interface) и WAN
(PPP/SLIP) Interface —
интерфейс для доступа в сеть через
модемный пул.

Отметим
особенности таблицы маршрутов сервера
с несколькими сетевыми интерфейсами.

Первая
строка похожа на первую строку в таблице
рабочей станции. Она также соответствует
значению основного шлюза в конфигурации
TCP/IP данной станции. Заметим, что только
на одном интерфейсе можно задавать
параметр «Основной шлюз». В данном
случае этот параметр был задан на одном
из внешних интерфейсов (это же значение
отражено и в конце таблицы в строке
«Основной шлюз»).

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

Во
второй строке содержится статический
маршрут, сконфигурированный в консоли
Службы
маршрутизации и удаленного доступа,
для пересылки пакетов в сеть 196.15.20.16/24.

Поддержка
таблиц маршрутизации.

Есть
два способа поддержки актуального
состояния таблиц маршрутизации: ручной
и автоматический.

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

В
больших сетях ручной способ становится
слишком трудоемким и чреват ошибками.
Автоматическое построение и модификация
таблиц маршрутизации производится так
называемыми «динамическими
маршрутизаторами».
Динамические маршрутизаторы отслеживают
изменения в топологии сети, вносят
необходимые изменения в таблицы маршрутов
и обмениваются данной информацией с
другими маршрутизаторами, работающими
по тем же протоколам маршрутизации. В
Windows Server реализована динамическая
маршрутизация в Службе
маршрутизации и удаленного доступа.
В данной службе реализованы наиболее
распространенные протоколы маршрутизации
— протокол RIP версий 1 и 2 и протокол
OSPF.

4.2 Служба dns (домены, зоны; зоны прямого и обратного просмотра; основные и дополнительные зоны; рекурсивный и итеративный запросы на разрешение имен).

Историческая
справка:
Систему доменных имен разработал в 1983
году Пол Мокапетрис. Тогда же было
проведено первое успешное тестирование
DNS, ставшей позже одним из базовых
компонентов сети Internet. С помощью DNS стало
возможным реализовать масштабируемый
распределенный механизм, устанавливающий
соответствие между иерархическими
именами сайтов и числовыми IP-адресами.

В
1983 году Пол Мокапетрис работал научным
сотрудником института информатики
(Information Sciences Institute, ISI), входящего в состав
инженерной школы университета Южной
Калифорнии (USC). Его руководитель, Джон
Постел, предложил Полу придумать новый
механизм, устанавливающий связи между
именами компьютеров и адресами Internet, —
взамен использовавшемуся тогда
централизованному каталогу имен и
адресов хостов, который поддерживала
калифорнийская компания SRI International.

«Все
понимали, что старая схема не сможет
работать вечно, — вспоминает Мокапетрис.
— Рост Internet становился лавинообразным.
К сети, возникшей на основе проекта
ARPANET, инициированного Пентагоном,
присоединялись все новые и новые компании
и исследовательские институты».

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

«Как
только организация подключалась к сети,
она могла использовать сколь угодно
много компьютеров и сама назначать им
имена», — подчеркнул Мокапетрис.
Названия доменов компаний получили
суффикс .com,
университетов — .edu
и так далее.

Первоначально
DNS была рассчитана на поддержку 50 млн.
записей и допускала безопасное расширение
до нескольких сотен миллионов записей.
По оценкам Мокапетриса, сейчас
насчитывается около 1 млрд. имен DNS, в
том числе почти 20 млн. общедоступных
имен. Остальные принадлежат системам,
расположенным за межсетевыми экранами.
Их имена неизвестны обычным
Internet-пользователям.

Новая
система внедрялась постепенно, в течение
нескольких лет. В это время ряд
исследователей экспериментировали с
ее возможностями, а Мокапетрис занимался
в ISI обслуживанием и поддержанием
стабильной работы «корневого сервера»,
построенного на мэйнфреймах компании
Digital Equipment. Копии таблиц хостов хранились
на каждом компьютере, подключенном к
Internet, еще примерно до 1986 года. Затем
начался массовый переход на использование
DNS.

Необходимость отображения имен сетевых узлов в ip-адреса

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

Есть
два таких механизма — локальный для
каждого компьютера файл hosts и
централизованная иерархическая служба
имен DNS.

Использование локального файла hosts и системы доменных имен dns для разрешения имен сетевых узлов

На
начальном этапе развития сетей, когда
количество узлов в каждой сети было
небольшое, достаточно было на каждом
компьютере хранить и поддерживать
актуальное состояние простого текстового
файла, в котором содержался список
сетевых узлов данной сети. Список устроен
очень просто — в каждой строке текстового
файла содержится пара «IP-адрес — имя
сетевого узла». В системах семейства
Windows данный файл расположен в папке
%system
root%system32driversetc
(где %system
root%
обозначает папку, в которой установлена
операционная система). Сразу после
установки системы Windows создается файл
hosts
с одной записью 127.0.0.1
localhost.

С
ростом сетей поддерживать актуальность
и точность информации в файле hosts
становится все труднее. Для этого надо
постоянно обновлять содержимое этого
файла на всех узлах сети. Кроме того,
такая простая технология не позволяет
организовать пространство имен в
какую-либо структуру. Поэтому появилась
необходимость в централизованной базе
данных имен, позволяющей производить
преобразование имен в IP-адреса без
хранения списка соответствия на каждом
компьютере. Такой базой стала DNS (Domain
Name System) — система именования доменов,
которая начала массовую работу в 1987
году.

Заметим,
что с появлением службы DNS актуальность
использования файла host совсем не исчезла,
в ряде случаев использование этого
файла оказывается очень эффективным.

Служба dns: пространство имен, домены

DNS
— это иерархическая база данных,
сопоставляющая имена сетевых узлов и
их сетевых служб IP-адресам узлов.
Содержимое этой базы, с одной стороны,
распределено по большому количеству
серверов службы DNS, а с другой стороны,
является централизованно управляемым.
В основе иерархической структуры базы
данных DNS лежит доменное пространство
имен (domain namespace), основной структурной
единицей которого является домен,
объединяющий сетевые узлы (хосты), а
также поддомены. Процесс поиска в БД
службы DNS имени некоего сетевого узла
и сопоставления этому имени IP-адреса
называется «разрешением имени узла
в пространстве имен DNS».

Служба
DNS состоит из трех основных компонент:

• Пространство
  имен DNS и соответствующие ресурсные
  записи (RR, resource record)
  — это сама распределенная база данных
  DNS;

• Серверы
  имен DNS
  — компьютеры, хранящие базу данных DNS и
  отвечающие на запросы DNS-клиентов;

• DNS-клиенты
  (DNS-clients, DNS-resolvers)
  -компьютеры, посылающие запросы серверам
  DNS для получения ресурсных записей.

Пространство
имен.

П

ространство
имен DNS — иерархическая древовидная
структура, начинающаяся с корня, не
имеющего имени и обозначаемого точкой
«.». Схему построения пространства
имен DNS лучше всего проиллюстрировать
на примере сети Интернет (рис.
4.8).

Рис. 4.8

Для
доменов 1-го уровня различают 3 категории
имен:

• ARPA
  — специальное имя, используемое для
  обратного разрешения DNS (из IP-адреса в
  полное имя узла);

• Общие
  (generic) имена 1-го уровня
  — 16 (на данный момент) имен, назначение
  которых приведено в табл.
  4.4;

• Двухбуквенные
  имена для стран
  — имена для доменов, зарегистрированных
  в соответствующих странах (например,
  ru
  — для России, ua
  — для Украины, uk
  — для Великобритании и т.д.).

Для
непосредственного отображения
пространства имен в пространство
IP-адресов служат т.н. ресурсные записи
(RR, resource record). Каждый сервер DNS содержит
ресурсные записи для той части пространства
имен, за которую он несет ответственность
(authoritative). табл.
4.5
содержит описание наиболее часто
используемых типов ресурсных записей.

Полное
имя узла (FQDN, fully qualified domain name) состоит из
нескольких имен, называемых метками
(label) и разделенных точкой. Самая левая
метка относится непосредственно к узлу,
остальные метки — список доменов от
домена первого уровня до того домена,
в котором находится узел (данный список
просматривается справа налево).

Серверы
имен DNS.

Серверы
имен DNS (или DNS-серверы) — это компьютеры,
на которых хранятся те части БД
пространства имен DNS, за которые данные
серверы отвечают, и функционирует
программное обеспечение, которое
обрабатывает запросы DNS-клиентов на
разрешение имен и выдает ответы на
полученные запросы.

DNS-клиенты.

DNS-клиент
— это любой сетевой узел, который обратился
к DNS-серверу для разрешения имени узла
в IP-адрес или, обратно, IP-адреса в имя
узла.

Служба dns: домены и зоны

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

Системы
семейства Windows Server поддерживают следующие
типы зон:

• Стандартная
  основная (standard primary)
  — главная копия стандартной зоны; только
  в данном экземпляре зоны допускается
  производить какие-либо изменения,
  которые затем реплицируются на серверы,
  хранящие дополнительные зоны;

• Стандартная
  дополнительная (standard secondary)
  — копия основной зоны, доступная в режиме
  «только-чтение», предназначена
  для повышения отказоустойчивости и
  распределения нагрузки между серверами,
  отвечающими за определенную зону;
  процесс репликации изменений в записях
  зон называется «передачей зоны»
  (zone
  transfer)
  (информация в стандартных зонах хранится
  в текстовых файлах, файлы создаются в
  папке «%system root%system32dns», имя файла,
  как правило, образуется из имени зоны
  с добавлением расширения файла «.dns»;
  термин «стандартная» используется
  только в системах семейства Windows);

• Интегрированная
  в Active Directory (Active Directory–integrated)
  — вся информация о зоне хранится в виде
  одной записи в базе данных Active Directory
  (такие типы зон могут существовать
  только на серверах Windows, являющихся
  контроллерами доменов Active Directory; в
  интегрированных зонах можно более
  жестко управлять правами доступа к
  записям зоны; изменения в записях зоны
  между разными экземплярами интегрированной
  зоны производятся не по технологии
  передачи зоны службой DNS, а механизмами
  репликации службы Active Directory);

• Зона-заглушка
  (stub;
  только в Windows 2003) — особый тип зоны,
  которая для данной части пространства
  имен DNS содержит самый минимальный
  набор ресурсных записей (начальная
  запись зоны SOA, список серверов имен,
  отвечающих за данную зону, и несколько
  записей типа A для ссылок на серверы
  имен для данной зоны).

Р

ассмотрим
на примере соотношение между понятиями
домена и зоны. Проанализируем информацию,
представленную на рис.
4.9.

Рис. 4.9

В
данном примере пространство имен DNS
начинается с домена microsoft.com,
который содержит 3 поддомена:
sales.microsoft.com,
it.microsoft.com
и edu.microsoft.com
(домены на рисунке обозначены маленькими
горизонтальными овалами). Домен — понятие
чисто логическое, относящееся только
к распределению имен. Понятие домена
никак не связано с технологией хранения
информации о домене. Зона — это способ
представления информации о домене и
его поддоменах в хранилище тех серверов
DNS, которые отвечают за данный домен и
поддомены. В данной ситуации, если для
хранения выбрана технология стандартных
зон, то размещение информации о доменах
может быть реализовано следующим
образом:

• записи,
  относящиеся к доменам microsoft.com
  и edu.microsoft.com,
  хранятся в одной зоне в файле
  «microsoft.com.dns»
  (на рисунке зона обозначена большим
  наклонным овалом);

• управление
  доменами sales.microsoft.com
  и it.microsoft.com
  делегировано другим серверам DNS, для
  этих доменов на других серверах созданы
  соответствующие файлы «sales.microsoft.com.dns»
  и «it.microsoft.com.dns»
  (данные зоны обозначены большими
  вертикальными овалами).

Делегирование
управления — передача ответственности
за часть пространства имен другим
серверам DNS.

Зоны прямого и обратного просмотра

Зоны,
рассмотренные в предыдущем примере,
являются зонами
прямого просмотра (forward lookup zones).
Данные зоны служат для разрешения имен
узлов в IP-адреса. Наиболее часто
используемые для этого типы записей:
A,
CNAME,
SRV.

Для
определения имени узла по его IP-адресу
служат зоны обратного просмотра (reverse
lookup zones), основной тип записи в «обратных»
зонах — PTR. Для решения данной задачи
создан специальный домен с именем
in-addr.arpa.
Для каждой IP-сети в таком домене создаются
соответствующие поддомены, образованные
из идентификатора сети, записанного в
обратном порядке. Записи в такой зоне
будут сопоставлять идентификатору узла
полное FQDN-имя данного узла. Например,
для IP-сети 192.168.0.0/24
необходимо создать зону с именем
«0.168.192.in-addr.arpa».
Для узла с IP-адресом 192.168.0.10
и именем host.company.ru
в данной зоне должна быть создана запись
«10
PTR host.company.ru».

Алгоритмы работы итеративных и рекурсивных запросов dns

Все
запросы, отправляемые DNS-клиентом
DNS-серверу для разрешения имен, делятся
на два типа:

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

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

Обычные
DNS-клиенты (например, рабочие станции
пользователей), как правило, посылают
рекурсивные запросы.

Рассмотрим
на примерах, как происходит взаимодействие
DNS-клиента и DNS-сервера при обработке
итеративных и рекурсивных запросов.

Допустим,
что пользователь запустил программу
Обозреватель Интернета и ввел в адресной
строке адрес http://www.microsoft.com.
Прежде чем Обозреватель установит сеанс
связи с веб-сайтом по протоколу HTTP,
клиентский компьютер должен определить
IP-адрес веб-сервера. Для этого клиентская
часть протокола TCP/IP рабочей станции
пользователя (так называемый resolver)
сначала просматривает свой локальный
кэш разрешенных ранее имен в попытке
найти там имя www.microsoft.com.
Если имя не найдено, то клиент посылает
запрос DNS-серверу, указанному в конфигурации
TCP/IP данного компьютера (назовем данный
DNS-сервер «локальным
DNS-сервером»),
на разрешение имени www.microsoft.com
в IP-адрес данного узла. Далее DNS-сервер
обрабатывает запрос в зависимости от
типа запроса.

Вариант
1 (итеративный запрос).

Если
клиент отправил серверу итеративный
запрос (напомним, что обычно клиенты
посылают рекурсивные запросы), то
обработка запроса происходит по следующей
схеме:

• сначала
  локальный DNS-сервер ищет среди зон, за
  которые он отвечает, зону microsoft.com;

если
такая зона найдена, то в ней ищется
запись для узла www;
если запись найдена, то результат поиска
сразу же возвращается клиенту;

в
противном случае локальный DNS-сервер
ищет запрошенное имя www.microsoft.com
в своем кэше разрешенных ранее
DNS-запросов;

если
искомое имя есть в кэше, то результат
поиска возвращается клиенту; если
локальный DNS-сервер не нашел в своей
базе данных искомую запись, то клиенту
посылается IP-адрес одного из корневых
серверов DNS;

• клиент
  получает IP-адрес корневого сервера и
  повторяет ему запрос на разрешение
  имени www.microsoft.com;

корневой
сервер не содержит в своей БД зоны
«microsoft.com», но ему известны DNS-серверы,
отвечающие за зону «com», и корневой
сервер посылает клиенту IP-адрес одного
из серверов, отвечающих за эту зону;

• клиент
  получает IP-адрес сервера, отвечающего
  за зону «com», и посылает ему запрос
  на разрешение имени www.microsoft.com;

сервер,
отвечающий за зону com,
не содержит в своей БД зоны microsoft.com,
но ему известны DNS-серверы, отвечающие
за зону microsoft.com,
и данный DNS-сервер посылает клиенту
IP-адрес одного из серверов, отвечающих
уже за зону microsoft.com;

• клиент
  получает IP-адрес сервера, отвечающего
  за зону microsoft.com,
  и посылает ему запрос на разрешение
  имени www.microsoft.com;

сервер,
отвечающий за зону microsoft.com,
получает данный запрос, находит в своей
базе данных IP-адрес узла www,
расположенного в зоне microsoft.com,
и посылает результат клиенту;

клиент
получает искомый IP-адрес, сохраняет
разрешенный запрос в своем локальном
кэше и передает IP-адрес веб-сайта
программе Обозреватель Интернета (после
чего Обзреватель устанавливает связь
с веб-сайтом по протоколу HTTP).

Вариант
2 (рекурсивный запрос).

Если
клиент отправил серверу рекурсивный
запрос, то обработка запроса происходит
по такой схеме:

• сначала
  локальный DNS-сервер ищет среди зон, за
  которые он отвечает, зону microsoft.com;
  если такая зона найдена, то в ней ищется
  запись для узла www;
  если запись найдена, то результат поиска
  сразу же возвращается клиенту;

в
противном случае локальный DNS-сервер
ищет запрошенное имя www.microsoft.com
в своем кэше разрешенных ранее
DNS-запросов; если искомое имя есть в
кэше, то результат поиска возвращается
клиенту;

• если
  локальный DNS-сервер не нашел в своей
  базе данных искомую запись, то сам
  локальный DNS-сервер выполняет серию
  итеративных запросов на разрешение
  имени www.microsoft.com,
  и клиенту посылается либо найденный
  IP-адрес, либо сообщение об ошибке.

Реализация службы dns в системах семейства Windows Server

Главная
особенность службы DNS в системах семейства
Windows Server заключается в том, что служба
DNS разрабатывалась для поддержки службы
каталогов Active Directory. Для выполнения этой
функции требуются обеспечение двух
условий:

• поддержка службой
  DNS динамической регистрации (dynamic
  updates);

• поддержка
  службой DNS записей типа SRV.

Служба
DNS систем Windows Server удовлетворяет обоим
условиям, и реализация служб каталогов
Active Directory может быть обеспечена только
серверами на базе систем Windows Server.

Рассмотрим
несколько простых примеров управления
службой DNS:

• установка службы
  DNS;

• создание основной
  и дополнительной зоны прямого просмотра;

• создание зоны
  обратного просмотра;

• выполнение
  динамической регистрации узлов в зоне.

Все
рассматриваемые далее в пособии примеры
были выполнены в следующей конфигурации:

• сеть состоит из
  двух серверов Windows 2003 Server;

• операционная
  система — ограниченная по времени
  120-дневная русская версия Windows 2003 Server
  Enterprise Edition;

• первый
  сервер установлен на ПК с процессором
  Intel Pentium-4 3Ггц и оперативной памятью 512
  МБ, имя сервера — DC1, IP-адрес — 192.168.0.1/24;

• второй
  сервер работает в качестве виртуальной
  системы с помощью Microsoft VirtualPC 2004, имя
  сервера -DC2, IP-адрес — 192.168.0.2/24;

• имя домена в
  пространстве DNS и соответствующее имя
  в службе каталогов Active Directory — world.ru (сеть
  полностью изолирована от других сетей,
  поэтому в данном примере авторы были
  свободны в выборе имени домена; в
  реальной обстановке конкретного
  учебного заведения преподавателю нужно
  скорректировать данную информацию).

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

Установка
службы DNS

Установка
службы DNS (как и других компонент системы)
производится достаточно просто с помощью
мастера установки компонент Windows:

1. Откройте
   Панель
   управления.

2. Выберите
   пункт «Установка
   и удаление программ».

3. Нажмите
   кнопку «Установка
   компонентов Windows».

4. Выберите
   «Сетевые
   службы»
   — кнопка «Дополнительно»
   (ни в коем случае не снимайте галочку
   у названия «Сетевые
   службы»).

5. О

   тметьте
   службу DNS.

Рис. 4.10

1. Кнопка
   «ОК»,
   кнопка «Далее»,
   кнопка «Готово».

Если
система попросит указать путь к
дистрибутиву системы, введите путь к
папке с дистрибутивом.

Выполним
данное действие на обоих серверах.

Создание
основной зоны прямого просмотра.

На
сервере DC1 создадим стандартную основную
зону с именем world.ru.

1. Откроем консоль
   DNS.

2. Выберем
   раздел «Зоны
   прямого просмотра».

3. Запустим
   мастер создания зоны (тип зоны —
   «Основная»,
   динамические обновления — разрешить,
   остальные параметры — по умолчанию).

4. Введем
   имя зоны — world.ru.

5. Разрешим
   передачу данной зоны на любой сервер
   DNS (Консоль
   DNS
   — зона world.ru
   — Свойства
   — Закладка «Передачи
   зон»
   — Отметьте «Разрешить
   передачи»
   и «На
   любой сервер»).

Создание
дополнительной зоны прямого просмотра.

На
сервере DC2 создадим стандартную
дополнительную зону с именем world.ru.

1. Откроем консоль
   DNS.

2. Выберем
   раздел «Зоны
   прямого просмотра»

3. Запустим
   мастер создания зоны (выбрать: тип зоны
   — «Дополнительная»,
   IP-адрес master-сервера (с которого будет
   копироваться зона) — адрес сервера DC1,
   остальные параметры — по умолчанию)

4. Введем
   имя зоны — world.ru.

5. Проверим в консоли
   DNS появление зоны.

Настройка
узлов для выполнения динамической
регистрации на сервер DNS.

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

Сервер
DNS.

1. Создать
   соответствующую зону.

2. Разрешить
   динамические обновления.

Это
нами уже выполнено.

Клиент
DNS.

1. Указать в настройках
   протокола TCP/IP адрес предпочитаемого
   DNS-сервера — тот сервер, на котором
   разрешены динамические обновления (в
   нашем примере — сервер DC1).

2. В

   полном имени компьютера указать
   соответствующий DNS-суффикс (в нашем
   примере — world.ru).
   Для этого — «Мой
   компьютер»
   — «Свойства»
   — Закладка «Имя
   компьютера»
   — Кнопка «Изменить»
   — Кнопка «Дополнительно»
   — в пустом текстовом поле впишем название
   домена world.ru
   — кнопка «ОК»
   (3 раза)).

Рис. 4.11

П

осле
этого система предложит перезагрузить
компьютер. После выполнения перезагрузки
на сервер DNS в зоне world.ru
автоматически создадутся записи типа
A
для наших серверов (рис.
4.12).

Рис. 4.12

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

1. Откроем консоль
   DNS.

2. Выберем
   раздел «Зоны
   обратного просмотра».

3. Запустим
   мастер создания зоны (выбрать: тип зоны
   — «Основная»,
   динамические обновления — разрешить,
   остальные параметры — по умолчанию)

4. В поле
   «Код
   сети (ID)»
   введем параметры идентификатора сети
   — 192.168.0.

5. Выполним
   команду принудительной регистрации
   клиента на сервере DNS — ipconfig
   /registerdns.

Наши
серверы зарегистрируются в обратной
зоне DNS (рис.
4.13):

Р

ис.
4.13

4.3 Диагностические утилиты tcp/ip и dns.

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

Перечислим
утилиты командной строки, являющиеся
инструментами первой необходимости
для проверки настроек протокола TCP/IP и
работы сетей и коммуникаций. Подробное
описание данных утилит содержится в
системе интерактивной помощи Windows. В
Таблице 4.6 укажем основные и наиболее
часто используемые параметры этих
команд и дадим их краткое описание.

П

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

Пример
1. Команда ipconfig
(без параметров и с параметром /all).

Рис. 4.14

Пример
2. Команда arp.

П

оскольку
в нашей сети только два узла, то в кэше
сервера DC1 будет только одна запись —
отображение IP-адреса сервера DC2 на
MAC-адрес сетевого адаптера.

Рис. 4.15

Пример
3. Команда ping.

Варианты
использования:

• ping
  <IP-адрес>;

• ping
  <NetBIOS-имя узла>,
  когда в зоне сервера DNS нет записи для
  сервера DC2 (поиск IP-адреса производится
  широковещательным запросом );

• ping
  <NetBIOS-имя узла>,
  когда в зоне сервера DNS есть запись для
  сервера DC2 (надо обратить внимание на
  подстановку клиентом DNS суффикса домена
  в запросе на имя узла, т.е в команде
  используется краткое NetBIOS-имя сервера,
  а в статистике команды выводится полное
  имя);

• ping
  <FQDN-имя узла>,
  когда в зоне сервера DNS нет записи для
  сервера DC2 (узел DC2 не будет найдет в
  сети);

• p

  ing
  <FQDN-имя узла>,
  когда в зоне сервера DNS есть запись для
  сервера DC2 (узел успешно найден);

• ping
  –a <IP-адрес>
  (обратное разрешение IP-адреса в имя
  узла)

Рис. 4.16

Пример
4. Команда tracert.

Т

рассировка
маршрута до узла www.ru (если в вашем
распоряжении только одна IP-сеть, то
изучить работу данной команды будет
невозможно).

Рис. 4.17

Пример
5. Команда pathping.

А

налогичная
задача (трассировка маршрута до узла
www.ru), выполненная командой pathping.

Рис. 4.18

П

ример
6. Команда netstat
(с
параметрами –an
— отображение в числовой форме списка
активных подключений и слушающих
портов).

Рис. 4.19

П

ример
7. Команда nbtstat
(с
параметром –n
— отображение локальных имен NetBIOS).

Рис. 4.20

5. Лабораторная работа: Протокол tcp/ip, служба dns:

В
лабораторной работе рассмотрены примеры
работы с программой ping.exe, рассмотрены
практические приемы применения
стандартных утилит Windows Server 2003 для
диагностики протокола TCP/IP. Приведен
пошаговый процесс установки службы
DNS, ее настройки

Упражнение 1. Базовые сведения о параметрах протокола tcp/ip. Проверка коммуникаций с помощью команды ping.

Упражнение 2. Установка службы dns. Создание зон прямого просмотра (forward lookup zones). Динамическая регистрация узлов на сервере dns. Команда ipconfig.

Упражнение 3. Создание зон обратного просмотра (reverse lookup zones). Динамическая регистрация узлов на сервере dns. Команда ipconfig.

Упражнение 4. Диагностические утилиты для протокола tcp/ip: ipconfig, arp, ping, netstat, nbtstat, tracert, pathping

Примечания.

• Команды
  netstat,
  nbtstat
  полезно повторить после изучения
  различных сетевых служб (служб каталогов,
  файлов и печати, DNS, DHCP, WINS). После
  прохождения соответствующих тем
  студенты/слушатели будут иметь более
  четкое представление об использовании
  таких понятий как IP-адрес и порт, а также
  понятий сеанс, соединение, слушающий
  порт, интерфейс NetBIOS и др.

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

Упражнение 5. Завершающие действия

6. Лекция: Служба каталогов Active Directory

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

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

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

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

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

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

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

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

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

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

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

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

Р

ис.
6.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-1User1», а полное
имя пользователя User1 на рабочей станции
WS-1 будет выглядеть как «WS-1User1».
Представим, что на сервере 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.

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

В

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

Рис. 6.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 изображен на рис.
6.3. В
данном примере домен company.ru
является доменом Active Directory верхнего
уровня. От корневого домена отходят
дочерние домены it.company.ru
и fin.company.ru.
Эти домены могут относиться соответственно
к ИТ-службе компании и финансовой службе.
У домена it.company.ru
есть
поддомен dev.it.company.ru,
созданный для отдела разработчиков ПО
ИТ-службы.

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

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

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

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

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

• п

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

Рис. 6.3

Лес

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

Новые
деревья в лесу создаются в том случае,
когда необходимо построить иерархию
доменов с пространством имен, отличным
от других пространств леса. В примере
на рис.
6.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 (рис.
   6.4).

Н

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

Рис. 6.4

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

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

1. «Расщепление»
   пространства имен DNS — одно имя домена,
   две различные зоны DNS(рис.
   6.5).

Р

ис.
6.5

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

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

1. Поддомен
   в пространстве имен DNS для поддержки
   Active Directory (рис.
   6.6).

Р

ис.
6.6

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

1. Д

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

Рис. 6.7

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

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

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

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

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

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

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

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

Р

ис.
6.8

Н

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

Рис. 6.9

Д

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

Рис. 6.10

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

Р

ис.
6.11

Рис. 6.12

С

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

Рис. 6.13

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

Р

ис.
6.14

Д

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

Р

ис.
6.15

Рис. 6.16

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

Р

ис.
6.17

Д

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

Рис. 6.18

З

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

Рис. 6.19

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

Р

ис.
6.20

П

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

Рис. 6.21

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

Рис. 6.22

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

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

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

рис.
6.23).

Рис. 6.23

П

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

Рис. 6.24

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

Рис. 6.25

С

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

Рис. 6.26

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

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

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

С

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

Рис. 6.27

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

Рис. 6.28

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

Р

ис.
6.29

П

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

Рис. 6.30

Т

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

Рис. 6.31

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

Р

ис.
6.32

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

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

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

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

Д

ерево
является набором доменов, которые
связаны отношениями «дочерний»/»родительский»,
а также используют связанные (смежные,
или прилегающие) пространства имен. При
этом дочерний домен получает имя от
родительского. Например, можно создать
дочерний домен, называемый it,
в домене company.com,
тогда его полное имя будет it.company.com
(рис.
6.33).
Между доменами автоматически
устанавливаются двухсторонние
транзитивные доверительные отношения
(домен it.company.com доверяет своему
«родительскому» домену, который в
свою очередь «доверяет» домену
sales.company.com – таким образом, домен
it.company.com
доверяет домену sales.company.com,
и наоборот). Это означает, что доверительные
отношения могут быть использованы всеми
другими доменами данного леса для
доступа к ресурсам данного домена.
Заметим, что домен it.company.com продолжает
оставаться самостоятельным доменом, в
том смысле, что он остается единицей
для управления системой безопасности
и процессом репликации. Поэтому, например,
администраторы из домена sales.company.com не
могут администрировать домен it.company.com
до тех пор, пока им явно не будет дано
такое право.

Рис. 6.33

Лес
— это одно или несколько деревьев,
которые разделяют общую схему,
серверы Глобального
каталога и
конфигурационную
информацию.
В лесу все домены объединены транзитивными
двухсторонними доверительными
отношениями.

Каждая
конкретная инсталляция Active Directory является
лесом,
даже если состоит всего из одного домена.

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

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

Физическая структура Active Directory

Физическая
структура Active Directory служит для связи
между логической структурой AD и топологией
корпоративной сети.

Основные
элементы физической структуры Active
Directory — контроллеры
домена и сайты.

Контроллеры
домена были подробно описаны в предыдущем
разделе.

Сайт
— группа IP-сетей, соединенных быстрыми
и надежными коммуникациями. Назначение
сайтов — управление процессом репликации
между контроллерами доменов и процессом
аутентификации пользователей. Понятие
«быстрые коммуникации» очень
относительное, оно зависит не только
от качества линий связи, но и от объема
данных, передаваемых по этим линиям.
Считается, что быстрый канал — это не
менее 128 Кбит/с (хотя Microsoft рекомендует
считать быстрыми каналы с пропускной
способностью не менее 512 Кбит/с).

С

труктура
сайтов никак не зависит от структуры
доменов. Один домен может быть размещен
в нескольких сайтах, и в одном сайте
могут находиться несколько доменов
(рис.
6.34).

Рис. 6.34

Поскольку
сайты соединяются друг с другом медленными
линиями связи, механизмы репликации
изменений в AD внутри сайта и между
сайтами различные. Внутри сайта
контроллеры домена соединены линиями
с высокой пропускной способностью.
Поэтому репликация между контроллерами
производится каждые 5 минут, данные при
передаче не сжимаются, для взаимодействия
между серверами используется технология
вызова удаленных процедур (RPC). Для
репликации между сайтами кроме RPC может
использоваться также протокол SMTP, данные
при передаче сжимаются (в результате
сетевой трафик составляет от 10 до 40% от
первоначального значения), передача
изменений происходит по определенному
расписанию. Если имеется несколько
маршрутов передачи данных, то система
выбирает маршрут с наименьшей стоимостью.

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

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

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

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

Рассмотрим
сам процесс репликации изменений в AD
как внутри сайта, так и между сайтами.

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

Репликация
изменений в AD между контроллерами домена
происходит автоматически, каждые 5
минут. Топологию репликации, т.е. порядок,
в котором серверы опрашивают друг друга
для получения изменений в базе данных,
серверы строят автоматически (эту задачу
выполняет компонента служб каталогов,
называемая Knowledge
Consistency Checker,
или KCC,
вариант перевода данного термина —
«наблюдатель
показаний целостности«).
При достаточно большом количестве
контроллеров KCC строит кольцевую
топологию репликации, причем для
надежности образует несколько колец,
по которым контроллеры передают данные
репликации. Наглядно увидеть топологию
репликации можно с помощью административной
консоли «Active
Directory — сайты и службы«.
Если в этой консоли раскрыть последовательно
контейнеры Sites,
Defauit-First-site-Name,
Servers,
далее — конкретный сервер (например,
DC1) и установить на узле NTDS
Settings, то в
правой половине окна видно, что сервер
DC1 запрашивает изменения с сервера DC2
(рис.
6.35):

Р

ис.
6.35

В

озможностей
управления репликацией у администратора
сети в данном случае немного. Можно лишь
вызвать принудительную репликацию в
той же консоли «Active
Directory — сайты и службы«.
Если в правой части того же окна консоли,
изображенного на рис.
6.35,
щелкнуть правой кнопкой мыши на имени
DC2 и выбрать вариант «Реплицировать
сейчас«, то
контроллер DC1 получит изменения в базе
данных AD с контроллера DC2 (рис.
6.36):

Рис. 6.36

Репликация между сайтами

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

Вернемся
к сетевой структуре, изображенной на
рис.
6.34, и
обсудим понятия и термины, играющие
важную роль в управлении репликацией
между сайтами.

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

Для
репликации между сайтами используется
тот или иной межсайтовый
транспорт —
это либо IP
(RPC),
либо SMTP.
Для каждого вида межсайтового транспорта
определяется «соединение
сайтов»
(site link),
с помощью которого строится управление
репликацией между двумя и более сайтами.
Именно для соединения («линка»)
задаются такие параметры как «Расписание
репликации»
и «Стоимость«.
На рис.
6.34.
соединение Link-1
связывает в единую цепочку сайты Сайт-1,
Сайт-3,
Сайт-4
и Сайт-2,
соединение Link-2
связывает два сайта — Сайт-1
и Сайт-2.
В данном примере репликация между
сайтами Сайт-1
и Сайт-2
будет проходить либо по соединению
Link-1,
либо по соединению Link-2
— в зависимости от расписания, стоимости
соединения и его доступности (при
доступности обоих соединений преимущество
будет иметь соединение с более низкой
стоимостью). На рис.
6.37
изображено созданное автоматически
соединение для транспорта IP
(RPC)
— DEFAULTIPSITELINK.
Если открыть Свойства
этого соединения (рис.
6.38), то
можно управлять списком сайтов,
относящихся к этому соединению, назначать
стоимость соединения (значение по
умолчанию — 100), интервал репликации
(по умолчанию — каждые 3 часа), а если
нажать кнопку «Изменить
расписание«,
то можно более тонко определить дни и
часы, в которые будет производиться
репликация.

К

онтейнер
Subnets
консоли «Active
Directory — сайты и службы»
служит для описания подсетей, входящих
в тот или иной сайт.

Рис. 6.37

Рис. 6.38

Функциональные уровни домена и леса

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

Для
Windows 2003 имеются 4 уровня функционирования
(в Windows 2000 — 2 уровня):

Windows
2000 смешанный (Windows 2000 mixed)

В
данном режиме в домене могут существовать
резервные контроллеры домена под
управлением системы Windows NT Server. Этот
режим рассматривается как переходный
в процессе модернизации служб каталогов
с Windows NT на Windows 2000/2003. В этом режиме
отсутствует ряд возможностей Active
Directory — универсальные группы, вложенность
групп. Кроме того, наличие контроллеров
домена под управлением Windows NT накладывает
ограничение на размер БД Active Directory (40
мегабайт).

После
установки системы и создания первого
контроллера домена домен всегда работает
именно в смешанном режиме.

Windows
2000 основной (Windows 2000 native)

В
данном режиме контроллерами домена
могут быть серверы под управлением
Windows 2000 и Windows 2003. В данном режиме появляется
возможность использования универсальных
групп, вложенность групп, и ликвидируется
ограничение на размер БД Active Directory.

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

Данный
уровень возможен только в том случае,
когда контроллеры домена работают под
управлением Windows NT и Windows 2003 (не может
быть контроллеров с системой Windows 2000).
Этот уровень доступен только тогда,
когда производится установка Windows 2003
поверх контроллеров домена с Windows NT.
Ограничения этого режима аналогичны
смешанному режиму.

Windows
2003

Это
наивысший уровень функционирования
домена, в котором есть контроллеры с
Windows 2003, причем все контроллеры обязаны
быть с системой Windows 2003.

И

зменять
уровень функционирования домена можно
только в сторону
его повышения.
Сделать это можно с помощью административных
консолей «Active
Directory – домены и доверие»
или «Active
Directory – пользователи и компьютеры«.
Если в какой-либо из этих консолей
щелкнуть правой кнопкой мыши на имени
домена и выбрать в контекстном меню
пункт «Изменение
режима работы домена«,
то появится панель, изображенная на
рис.
6.39:

Рис. 6.39

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

Для
всего леса в целом также можно определять
функциональные уровни. Это делается с
помощью консоли «Active
Directory – домены и доверие«.
Только правой кнопкой мыши надо щелкнуть
не на имени домена, а на надписи «Active
Directory – домены и доверие«.

Существуют
3 уровня функционирования леса:

• Windows 2000 (с
  контроллерами под управлением Windows NT,
  2000 и 2003);

• Windows 2003 interim (с
  контроллерами под управлением только
  Windows NT и 2003);

• Windows
  2003 (все
  домены всего леса
  — с контроллерами под управлением
  только
  Windows 2003).

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

• переименование
  доменов;

• установление
  доверительных отношений между двумя
  не
  связанными друг с другом
  лесами с использованием Kerberos в качестве
  протокола аутентификации (без такого
  режима доверительные отношения могут
  устанавливаться только между отдельными
  доменами, а не целыми лесами, при этом
  будет использоваться менее защищенный
  протокол аутентификации NTLM).

Серверы Глобального каталога и Хозяева операций

Большинство
операций с записями БД Active Directory
администратор может выполнять,
подключившись с помощью соответствующей
консоли к любому из контроллеров домена.
Однако, во избежание несогласованности,
некоторые действия должны быть
скоординированы и выполнены специально
выделенными для данной цели серверами.
Такие контроллеры домена называются
Хозяевами
операций
(Operations Masters),
или исполнителями
специализированных ролей
(Flexible Single-Master
Operations, сокращенно
— FSMO).

Всего
имеется пять специализированных ролей:

1. Schema
   Master (хозяин схемы):
   контролирует возникающие изменения
   Схемы базы данных Active Directory (добавление
   и удаление классов объектов, модификация
   набора атрибутов). Один
   контроллер домена в
   масштабе всего леса
   выполняет эту роль (по умолчанию —
   самый первый контроллер в лесу).

2. Domain
   Naming Master (хозяин именования доменов):
   контролирует процесс добавления или
   удаления доменов в лесу. Один
   контроллер домена в
   масштабе всего леса
   выполняет эту роль (по умолчанию —
   самый первый контроллер в лесу).

3. PDC
   Emulator (эмулятор PDC):
   действует как PDC (главный контроллер
   домена) для BDC (резервный контроллер
   домена) под управлением Windows NT, когда
   домен находится в смешанном режиме;
   управляет изменениями паролей (изменение
   пароля учетной записи в первую очередь
   реплицируется на эмулятор PDC); является
   предпочтительным сервером (в Windows 2000 —
   единственный сервер) для редактирования
   групповых политик; является сервером
   времени для остальных контроллеров
   данного домена (контроллеры домена
   синхронизируют свои системные часы с
   эмулятором PDC). Один
   контроллер в
   домене
   выполняет эту роль (по умолчанию —
   самый первый контроллер в домене).

4. RID
   Master (хозяин RID, распределитель
   идентификаторов учетных записей):
   выделяет контроллерам домена пулы
   относительных идентификаторов (RID,
   которые являются уникальной частью
   идентификаторов безопасности SID). Один
   контроллер в
   домене
   выполняет эту роль (по умолчанию —
   самый первый контроллер в домене).

5. Infrastructure
   Master (хозяин инфраструктуры):
   отвечает за обновление связей
   «пользователи — группы» между
   доменами. Эта роль не должна храниться
   на контроллере домена, который также
   является сервером Глобального Каталога
   – хозяин инфраструктуры не будет
   работать в данном сценарии (за исключением
   случая, когда в домене всего один
   контроллер). Один
   контроллер в
   домене
   выполняет эту роль (по умолчанию —
   самый первый контроллер в домене).

Просмотреть
текущих владельцев ролей и передать ту
или иную роль на другой контролер можно
с помощью административных консолей:

• роль
  Хозяина
  Схемы
  — с помощью консоли «Active
  Directory Schema»
  (чтобы запустить эту консоль, надо
  сначала зарегистрировать соответствующую
  программную компоненту в командной
  строке: regsvr32
  schmmgmt.dll,
  а затем запустить саму консоль тоже в
  командной строке — schmmgmt.msc);

• роль
  Хозяина
  именования доменов
  — с помощью консоли «Active
  Directory – домены и доверие«;

• р

  оли
  эмулятора
  PDC,
  хозяина
  RID
  и хозяина
  инфраструктуры
  — с помощью консоли «Active
  Directory – пользователи и компьютеры»
  (пример можно увидеть на рис.
  6.40).

Рис. 6.40

Необходимо
знать, кто из пользователей имеет право
менять роли хозяев операций:

• эмулятор
  PDC — члены группы «Администраторы
  домена«;

• хозяин
  RID — члены группы «Администраторы
  домена«;

• хозяин
  инфраструктуры — члены группы
  «Администраторы
  домена«;

• хозяин
  именования доменов — члены группы
  «Администраторы
  предприятия«;

• хозяин
  схемы — члены группы «Администраторы
  Схемы»
  или группы «Администратор
  предприятия«.

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

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

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

Сервер
глобального каталога выполняет две
очень важные функции:

• поиск объектов в
  масштабах всего леса (клиенты могут
  обращаться к глобальному каталогу с
  запросами на поиск объектов по
  определенным значениям атрибутов;
  использование сервера глобального
  каталога — единственный способ
  осуществлять поиск объектов по всему
  лесу);

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

П

о
умолчанию самый первый контроллер
домена в лесу является сервером
глобального каталога. Однако администратор
сети может назначить любой контроллер
домена сервером глобального каталога.
Это делается с помощью административной
консоли «Active
Directory – сайты и службы«,
в свойствах узла «NTDS
Settings»
выбранного контроллера (рис.
6.41):

Рис. 6.41

Д

ля
эффективной работы службы каталогов
Active Directory необходимо, чтобы в каждом
сайте AD был либо сервер глобального
каталога, либо контроллер домена,
кэширующий у себя списки членов
универсальных групп. Кэширование
универсальных групп также настраивается
в консоли «Active
Directory – сайты и службы»
в свойствах узла «NTDS
Settings» для
каждого сайта Active Directory. Для включения
кэширования нужно поставить галочку у
поля «Разрешить
кэширование членства в универсальных
группах» и
указать, из какого сайта данный сайт
будет получать списки универсальных
групп в поле «Обновлять
кэш из:»
(рис.
6.42):

Рис. 6.42

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

Учетные
записи
(accounts)
пользователей, компьютеров и групп —
один из главных элементов управления
доступом к сетевым ресурсам, а значит,
и всей системы безопасности сети в
целом.

В
среде Windows 2003 Active Directory существует 3
главных типа пользовательских учетных
записей:

• Локальные
  учетные записи пользователей.
  Эти учетные записи существуют в локальной
  базе данных SAM
  (Security
  Accounts Manager)
  на каждой системе, работающей под
  управлением Windows 2003. Эти учетные записи
  создаются с использованием инструмента
  Local
  Users and Groups
  (Локальные
  пользователи и группы)
  консоли Computer
  Management
  (Управление
  компьютером).
  Заметим, что для входа в систему по
  локальной учетной записи, эта учетная
  запись обязательно должна присутствовать
  в базе данных SAM на системе, в которую
  вы пытаетесь войти. Это делает локальные
  учетные записи непрактичными для
  больших сетей, вследствие больших
  накладных расходов по их администрированию.

• Учетные
  записи пользователей домена.
  Эти учетные записи хранятся в Active
  Directory и могут использоваться для входа
  в систему и доступа к ресурсам по всему
  лесу AD. Учетные записи этого типа
  создаются централизованно при помощи
  консоли «Active
  Directory Users and Computers»
  («Active
  Directory – пользователи и компьютеры«).

• Встроенные
  учетные записи.
  Эти учетные записи создаются самой
  системой и не могут быть удалены. По
  умолчанию любая система, будь то
  изолированная (отдельно стоящая) или
  входящая в домен, создает две учетные
  записи – Administrator
  (Администратор)
  и Guest
  (Гость).
  По умолчанию учетная запись Гость
  отключена.

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

Существуют
различные форматы, в которых могут быть
представлены имена для входа пользователей
в систему, потому что они могут отличаться
для целей совместимости с клиентами,
работающими под управлением более
ранних версий Windows (такими как 95, 98, NT).
Два основных вида имен входа — это с
использованием суффикса User
Principal Name
(основного
имени пользователя)
и имя входа пользователя в системах
пред-Windows 2000.

Основное
имя пользователя (UPN,
User Principle Name)
имеет такой же формат, как и электронный
адрес. Он включает в себя имя входа
пользователя, затем значок «@»
и имя домена. По умолчанию доменное имя
корневого домена выделено в выпадающем
окне меню, независимо от того, в каком
домене учетная запись была создана
(выпадающий список будет также содержать
имя домена, в котором вы создали эту
учетную запись).

Также
можно создавать дополнительные доменные
суффиксы (та часть имени, которая стоит
после знака @),
которые будут появляться в выпадающем
списке и могут быть использованы при
образовании UPN, если вы их выберете (это
делается при помощи консоли «Active
Directory – домены и доверие»
(«Active Directory
Domain and Trusts«).

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

Локальные учетные записи

Каждый
компьютер с операционными системами
Windows NT/2000/XP/2003 (если это не сервер,
являющийся контроллером домена) имеет
локальную базу данных учетных записей,
называемую базой данных SAM. Эти БД
обсуждались при описании модели
безопасности «Рабочая группа».
Локальные пользователи и особенно
группы используются при назначении
прав доступа к ресурсам конкретного
компьютера даже в доменной модели
безопасности. Общие правила использования
локальных и доменных групп для управления
доступом будут описаны ниже.

Управление доменными учетными записями пользователей

Доменные
учетные записи пользователей (а также
компьютеров и групп) хранятся в специальных
контейнерах AD. Это могут быть либо
стандартные контейнеры Users
для пользователей и Computers
для компьютеров, либо созданное
администратором Организационное
подразделение (ОП). Исключение составляют
учетные записи контроллеров домена,
они всегда хранятся в ОП с названием
Domain Controllers.

Рассмотрим
на примерах процесс создания учетных
записей пользователей в БД Active Directory и
разберем основные свойства доменных
учетных записей. Учетные записи для
компьютеров создаются в процессе
включения компьютера в домен.

Создание доменной учетной записи

1. Откроем
   административную консоль «Active
   Directory – пользователи и компьютеры«.

2. Щелкнем
   правой кнопкой мыши на контейнере, в
   котором будем создавать учетную запись,
   выберем в меню команду «Создать»
   и далее — «Пользователь«.

3. Заполним
   поля «Имя«,
   «Фамилия«,
   например, «Иван»
   и «Иванов»
   (в английской версии — First
   Name,
   Last
   Name),
   поле «Полное
   имя»
   (Full
   Name)
   заполнится само.

4. Введем
   «Имя
   входа пользователя»
   (User
   logon name),
   например, User1.
   К этому имени автоматически приписывается
   часть вида «@<имя
   домена>»,
   в нашем примере — «@world.ru»
   (полученное имя должно быть уникальным
   в масштабах леса).

5. В

   процессе формирования имени входа
   автоматически заполняется «Имя
   входа пользователя (пред-Windows 2000)»
   (User
   logon name (pre- Windows 2000)),
   создаваемое для совместимости с прежними
   версиями Windows (данное имя должно быть
   уникально в масштабе домена). В каждой
   организации должны быть разработаны
   схемы именования пользователей (по
   имени, фамилии, инициалам, должности,
   подразделению и т.д.) В нашем примере
   получится имя «WORLDUser1«.
   Нажмем кнопку «Далее»
   (рис.
   6.43):

Рис. 6.43

1. Вводим пароль
   пользователя (два раза, для подтверждения).

2. Укажем начальные
   требования к паролю:

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

   • Запретить смену
     пароля пользователем (полезно и даже
     необходимо для учетных записей различных
     системных служб);

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

   • Отключить учетную
     запись.

Н

ажмем
кнопку «Далее»
(рис.
6.44):

Рис. 6.44

1. Получаем
   итоговую сводку для создаваемого
   объекта и нажимаем кнопку «Готово«.

Внимание!
В упражнениях лабораторных работ дается
задание настроить политики, которые
сильно понижают уровень требований к
паролям и полномочиям пользователей:

• отключается
  требование сложности паролей,

• устанавливается
  минимальная длина пароля, равная 0 (т.е.
  пароль может быть пустым),

• устанавливается
  минимальный срок действия паролей 0
  дней (т.е. пользователь может в любой
  момент сменить пароль),

• устанавливается
  история хранения паролей, равная 0 (т.е.
  при смене пароля система не проверяет
  историю ранее используемых паролей),

• группе «Пользователи»
  дается право локального входа на
  контроллеры домена.

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

Правила
выбора символов для создания пароля:

• длина пароля —
  не менее 7 символов;

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

• пароль не должен
  состоять из какого-либо слова (чтобы
  исключить возможность подбора пароля
  по словарю);

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

• пароль
  должен быть комбинацией букв в верхнем
  и нижнем регистрах, цифр и спецсимволов
  (типа @#$%^*&()_+
  и т.д.).

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

Обзор свойств учетных записей пользователей

Свойства
учетной записи пользователя содержат
большой набор различных параметров,
размещенных на нескольких закладках
при просмотре в консоли «Active
Directory – пользователи и компьютеры«,
причем при установке различных программных
продуктов набор свойств может расширяться.

Рассмотрим
наиболее важные с точки зрения
администрирования свойства.

Откроем
консоль «Active
Directory – пользователи и компьютеры»
и посмотрим свойства только что созданного
нами пользователя.

Закладка
«Общие«.
На данной закладке содержатся в основном
справочные данные, которые могут быть
очень полезны при поиске пользователей
в лесу AD. Наиболее интересные из них:

• «Имя«

• «Фамилия«

• «Выводимое
  имя«

• «Описание«

• «Номер
  телефона«

• «Электронная
  почта«

Закладка
«Адрес»
— справочная информация для поиска в
AD.

Закладка
«Учетная
запись» —
очень важный набор параметров (параметры
«Имя входа
пользователя»
и «Имя входа
пользователя (пред-Windows 2000)»
обсуждались выше при создании
пользователя):

• кнопка
  «Время
  входа»
  — дни и часы, когда пользователь может
  войти в домен;

• кнопка
  «Вход
  на…»
  — список компьютеров, с которых
  пользователь может входить в систему
  (регистрироваться в домене);

• Поле
  типа чек-бокс «Заблокировать
  учетную запись»
  — этот параметр недоступен, пока учетная
  запись не заблокируется после
  определенного политиками некоторого
  количества неудачных попыток входа в
  систему (попытки с неверным паролем),
  служит для защиты от взлома пароля
  чужой учетной записи методом перебора
  вариантов; если будет сделано определенное
  количество неудачных попыток, то учетная
  запись пользователя автоматически
  заблокируется, поле станет доступным
  и в нем будет установлена галочка, снять
  которую администратор может вручную,
  либо она снимется автоматически после
  интервала, заданного политиками паролей;

• «Параметры
  учетной записи»
  (первые три параметра обсуждались
  выше):

  • «Требовать
    смену пароля при следующем входе в
    систему«

  • «Запретить
    смену пароля пользователем«

  • «Срок
    действия пароля не ограничен«

  • «Отключить
    учетную запись»
    — принудительное отключение учетной
    записи (пользователь не сможет войти
    в домен);

  • «Для
    интерактивного входа в сеть нужна
    смарт-карта»
    — вход в домен будет осуществляться
    не при помощи пароля, а при помощи
    смарт-карты (для этого на компьютере
    пользователя должно быть устройство
    для считывания смарт-карт, смарт-карты
    должны содержать сертификаты, созданные
    Центром выдачи сертификатов);

• «Срок
  действия учетной записи»
  — устанавливает дату, с которой данная
  учетная запись не будет действовать
  при регистрации в домене (этот параметр
  целесообразно задавать для сотрудников,
  принятых на временную работу, людей,
  приехавших в компанию в командировку,
  студентов, проходящих практику в
  организации и т.д.)

Закладки
«Телефоны«,
«Организация»
— справочная информация о пользователе
для поиска в AD.

Закладка
«Профиль«

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

• локальные
  — хранятся в папке «Documents
  and Settings»
  на том разделе диска, где установлена
  операционная система;

• перемещаемые
  (сетевые, или roaming)
  — хранятся на сервере в папке общего
  доступа, загружаются в сеанс пользователя
  на любом компьютере, с которого
  пользователь вошел (зарегистрировался)
  в домен, давая возможность пользователю
  иметь одинаковую рабочую среду на любом
  компьютере (путь к папке с профилем
  указывается на данной закладке в виде
  адреса \servershare%username%,
  где server
  — имя сервера, share
  — имя папки общего доступа, %username%
  —
  имя папки с профилем; использование
  переменной среды системы Windows с названием
  %username%
  позволяет задавать имя папки с профилем,
  совпадающее с именем пользователя);

• обязательные
  (mandatory)
  — настройки данного типа профиля
  пользователь может изменить только в
  текущем сеансе работы в Windows, при выходе
  из системы изменения не сохраняются.

Параметр
«Сценарий входа» определяет
исполняемый файл, который при входе
пользователя в систему загружается на
компьютер и исполняется. Исполняемым
файлом может быть пакетный файл (.bat,
.cmd),
исполняемая программа (.exe, .com), файл
сценария (.vbs, js).

Закладка
«Член групп»
— позволяет управлять списком групп,
в которые входит данный пользователь.

Закладка
«Входящие
звонки«.

Управление
доступом пользователя в корпоративную
систему через средства удаленного
доступа системы Windows Server (например, через
модем или VPN-соединение). В смешанном
режиме домена
Windows доступны только варианты «Разрешить
доступ» и
«Запретить
доступ«, а
также параметры обратного дозвона
(«Ответный
вызов сервера«).
В режимах «Windows
2000 основной»
и «Windows 2003»
доступом можно управлять с помощью
политик сервера удаленного доступа (не
надо путать с групповыми политиками).
Подробнее данный вопрос обсуждается в
разделе, посвященном средствам удаленного
доступа.

Закладки
«Профиль
служб терминалов«,
«Среда«,
«Сеансы«,
«Удаленное
управление»
— данные закладки управляют параметрами
работы пользователя на сервере терминалов:

• управление
  разрешением пользователя работать на
  сервере терминалов;

• размещение профиля
  при работе в терминальной сессии,

• настройка среды
  пользователя в терминальной сессии
  (запуск определенной программы или
  режим рабочего стола, подключение
  локальных дисков и принтеров пользователя
  в терминальную сессию);

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

• разрешение
  администратору подключаться к
  терминальной сессии пользователя.

Управление группами

Учетные
записи групп, как и учетные записи
пользователей, могут быть созданы либо
в локальной базе SAM компьютера (сервера
или рабочей станции), либо в доменной
базе данных Active Directory.

Локальные
группы простого сервера-члена домена
или рабочей станции могут включать в
себя и локальные учетные записи данного
компьютера, и глобальные учетные записи
любого пользователя или компьютера
всего леса, а также доменные локальные
группы «своего» домена и глобальные
и универсальные группы всего леса.

Рассмотрим
подробнее, какие группы могут создаваться
в Active Directory.

В
Active Directory группы различаются по типу
(группы безопасности и группы
распространения) и по области действия
(локальные в домене, глобальные и
универсальные).

Типы
групп

• Группы
  безопасности — каждая группа данного
  типа, так же как и каждая учетная запись
  пользователя, имеет идентификатор
  безопасности
  (Security
  Identifier,
  или SID),
  поэтому группы безопасности используются
  для назначения разрешений при определении
  прав доступа к различным сетевым
  ресурсам.

• Группы распространения
  — группы этого типа не имеют идентификатора
  безопасности, поэтому не могут
  использоваться для назначения прав
  доступа, их главное назначение —
  организация списков рассылки для
  почтовых программ (например, для
  Microsoft Exchange Server).

Область
действия групп

• Локальные
  в домене
  могут содержать — глобальные группы
  из любого домена, универсальные группы,
  глобальные учетные записи пользователей
  из любого домена леса, используются —
  при назначении прав доступа только к
  ресурсам «своего» домена;

• Глобальные
  могут содержать — только глобальные
  учетные записи пользователей «своего»
  домена, используются — при назначении
  прав доступа к ресурсам любого домена
  в лесу;

• Универсальные
  могут содержать — другие универсальные
  группы всего леса, глобальные группы
  всего леса, глобальные учетные записи
  пользователей из любого домена леса,
  используются — при назначении прав
  доступа к ресурсам любого домена в
  лесу.

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

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

Маркер
доступа.

При
регистрации в домене пользователю
передается в его сессию на компьютере
т.н. маркер
доступа (Access
Token), называемый
иногда маркером безопасности. Маркер
доступа состоит из набора идентификаторов
безопасности — идентификатора
безопасности (SID) самого пользователя
и идентификаторов безопасности тех
групп, членом которых он является.
Впоследствии этот маркер доступа
используется при проверке разрешений
пользователя на доступ к различным
ресурсам домена.

Стратегия
создания и использования групп.

При
создании и использовании групп следует
придерживаться следующих правил:

1. Включать
   глобальные учетные записи пользователей
   (Accounts)
   в глобальные группы (Global
   groups). Глобальные группы формируются
   обычно по
   функциональным обязанностям сотрудников.

2. Включать
   глобальные группы в доменные локальные
   или локальные на простом сервере или
   рабочей станции (Local
   groups). Локальные группы формируются на
   основе разрешений для доступа к
   конкретным ресурсам.

3. Давать
   разрешения (Permissions)
   на доступ к ресурсам локальным группам.

По
первым буквам английских слов эту
стратегию часто обозначают сокращенно
AGLP.
В основном режиме и режиме Windows 2003 с
использованием универсальных (Universal)
групп эта стратегия может быть в более
общем виде представлена как аббревиатура
AGG…GULL…LP.
Такой подход облегчает управление
доступом к ресурсам по сравнению с
назначением разрешений напрямую учетным
записям пользователей. Например, при
переходе сотрудника с одной должности
на другую или из одного подразделения
в другое достаточно соответствующим
образом поменять его членство в различных
группах, и разрешения на доступ к сетевым
ресурсам автоматически будут назначены
уже исходя из его новой должности.

Встроенные
и динамически формируемые группы.

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

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

Управление Организационными подразделениями, делегирование полномочий

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

На
практике использование ОП (кроме
иерархической организации объектов)
сводится к двум задачам:

• делегирование
  административных полномочий на
  управление объектами ОП какому-либо
  пользователю или группе пользователей;

• применение
  групповых политик к объектам, входящим
  в ОП.

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

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

1. Откроем
   консоль «Active
   Directory – пользователи и компьютеры«.

2. Создадим в домене
   подразделение, скажем, с именем OU-1,
   переместим в это ОП несколько имеющихся
   в домене учетных записей (или создадим
   новые).

3. Щелкнем
   правой кнопкой мыши на подразделении
   OU-1 и выберем пункт меню «Делегирование
   управления…«.
   Запустится «Мастер
   делегирования управления«

4. В

   ыберем
   пользователя (или группу), которому
   будем делегировать управление данным
   ОП. Пусть это будет пользователь User1
   (рис.
   6.45).
   Нажмем «Далее«.

Рис. 6.45

1. Выберем
   набор административных задач, которые
   делегируются данному пользователю
   (рис.
   6.46):