Балтийский государственный технический университет
«ВОЕНМЕХ»
Кафедра вычислительной техники
В.А.Гаврилов
Методические указания к лабораторным работам
по курсу «Локальные и корпоративные сети»
Санкт-Петербург
2007 г.
Лабораторная работа №1
Установка серверной ОС Windows server
Цель работы: Изучение методики и приобретение практических навыков установки сетевых операционных систем для дальнейшего развертывания домена.
Краткие сведения из теории.
В настоящее время существует несколько поколений сетевых операционных систем, разработанных фирмой Microsoft. Последние поколения ОС (Семейство Windows 2000 Server, Windows 2003 Server и выходящая версия Windows 2008 Server) существенно отличаются от ранних разработок (Windows NT 3.5, Windows NT 4.0), поэтому мы будем ориентироваться в основном на последние семейства OC Windows. Несмотря на некоторые различия, основные концепции, принципы их работы и администрирование систем в общих чертах совпадают.
Для организации доменов на базе систем Windows 2000 Server и Windows Server 2003 используется служба каталога Active Directory. Каждый контроллер домена под управлением этих систем является сервером каталога Active Directory, и службу Active Directory невозможно развернуть без создания доменной структуры.
Объединение компьютеров в единую информационную сеть позволяет пользователям совместно использовать общие ресурсы. Современные операционные системы, ориентированные на корпоративный рынок, используют для организации ресурсов специальную сетевую службу, дающую пользователям возможность получения доступа к ресурсам сети без необходимости точного знания местоположения этих ресурсов. Речь идет о службе каталога (Directory Service). Каталог при этом рассматривается как глобальное унифицированное хранилище информации об элементах сетевой инфраструктуры. Вся информация о компонентах сетевой инфраструктуры, в качестве которых могут выступать пользователи, ресурсы, сетевые службы и т. п., размещается в каталоге. Внутри каталога объекты организуются либо в соответствии с физической, либо логической структурой сети. В качестве аналогии можно провести параллель с библиотечным каталогом, содержащим упорядоченные сведения о книгах.
Ниже перечислены задачи, которые служба каталога позволяет решить администратору.
Управление сетевыми ресурсами. Поскольку задача предоставления ресурсов в общее пользование является основной, ради чего компьютеры объединяются в сеть, необходимо, чтобы пользователи получали доступ к требуемым ресурсам наиболее эффективным способом. Служба каталога облегчает пользователям поиск нужных ресурсов, скрывая от них подробности реализации механизма поиска. Пользователь формулирует запрос, а служба каталога локализует требуемый ресурс.
Управление пользователями. Каждому пользователю поставлен в соответствие определенный набор характеристик, позволяющий персонализировать его деятельность в сети. Это дает возможность управлять доступом к сетевым ресурсам на уровне пользователей. При этом служба каталога рассматривает пользователей в качестве обыкновенных объектов каталога, что дает возможность организовывать их в соответствии со структурой сети (логической либо физической).
Управление приложениями. В зависимости от того, на решение каких конкретно задач ориентируются пользователи, на их компьютерах может быть развернуто различное программное обеспечение. В небольшой локальной сети осуществление контроля используемого программного обеспечения не требует от администратора особых усилий. В случае большой корпорации на передний план выходит задача по централизованному управлению программным обеспечением, включая развертывание новых приложений и выполнение обновления существующих.
Управление службами. При построении сети администратору приходится также решать вопросы, связанные с конкретным способом ее организации. Например, при построении сети на основе протокола TCP/IP необходимо решить, каким образом будет осуществляться выделение IP-адресов. Необходимо разработать соглашение о сетевых именах и организовать процесс их разрешения в соответствующие IP-адреса. Большинство сетевых служб может быть интегрировано со службой каталога, что позволит более эффективно организовать функционирование этих служб.
Практически все производители корпоративных операционных систем предлагают потребителям свои реализации службы каталога. Компания Microsoft предлагает свою версию службы каталога, названную Active Directory. Впервые эта служба каталога была реализована в составе операционной системы Windows 2000 Server. Обновленная версия Active Directory включена в Windows Server 2003. Концептуально эти версии практически не отличаются, поэтому чаще всего можно говорить о доменах Active Directory, подразумевая их реализацию на базе систем Windows 2000 Server и/или Windows Server 2003.
Служба каталога Active Directory базируется на открытых стандартах:
протокол LDAP;
система доменных имен (Domain Name System, DNS);
протокол аутентификации Kerberos v5.
Протокол LDAP обеспечивает доступ к каталогу, разработанному в соответствии с рекомендациями стандарта Х.500. Протокол представляет собой стандартное средство реализации доступа и обновления информации в каталоге для приложений. Протокол LDAP является частью стека протоколов TCP/IP, что и послужило одной из причин его популярности. Доступ к содержимому каталога Active Directory no протоколу LDAP может осуществляться с помощью любого LDAP-клиента. При этом использование протокола LDAP не является единственно возможным способом доступа к каталогу Active Directory.
Спецификация протокола LDAP базируется на четырех моделях.
Информационная модель (Information Model) описывает структуру каталога и содержащейся в ней информации.
Модель именования (Naming Model) описывает схему организации информации в каталоге и используемые схемы именования и идентификации объектов каталога.
Функциональная модель (Functional Model) определяет действия, которые могут быть осуществлены над информацией, размещенной в каталоге.
Модель безопасности (Security Model) описывает механизмы защиты информации, размещенной в каталоге.
Можно выделить два сценария развертывания доменной структуры сети:
первоначальная организация домена и установка первичного контроллера домена и леса доменов
установка дополнительного контроллера в существующем домене или установка нового домена в существующем лесу.
Оба сценария разворачиваются в два этапа и имеют незначительные отличия при выполнении второго этапа: установка простого сервера Windows и затем повышение роли сервера до уровня контроллера домена.
На первом этапе осуществляется установка выбранной версии Windows Server. Если же на компьютере уже имеется одна из операционных систем Microsoft и необходима установка сервера, то для запуска программы установки можно воспользоваться этой системой. Загрузите компьютер под управлением имеющейся ОС и запустите утилиту Winnt32.exe из установочного каталога \I386 с дистрибутивом Windows Server. Winnt32.exe — это 32-разрядная версия программы установки, которая может использоваться для инсталляции или обновления версии. Данная утилита может быть запущена под управлением Windows 9x или любой из версий Windows NT/2000/XP. Преимущество этой программы по сравнению с 16-разрядной версией заключается в том, что она работает быстрее, имеет графический интерфейс, и, помимо этого, во время ее работы можно продолжать работу с другими программами.
Если осуществляется установка с дистрибутивного компакт-диска, имеющего графическую оболочку, то в открывающихся последовательно окнах нужно выбрать «Тип установки» - Новая установка, затем принять лицензионное соглашение. В окне выбора способа динамического обновления выбрать «Пропустить этот шаг и продолжить установку Windows. После копирования файлов установки и перезагрузки системы в режиме DOS нужно выбрать каталог установки ОС сервера.
Примечание. Выбор каталога уточните у преподавателя.
Далее следуйте инструкциям программы установки и после выбора каталога нажмите клавишу «Ввод». На следующем шаге выберите пункт «Отформатировать в системе NTFS». После форматирования раздела (при этом выдается несколько предупреждающих сообщений, чтобы случайно не удалить нужный раздел) система перезагрузится и перейдет в графическую стадию установки (во время перезагрузки ничего вводить не нужно). Во время выполнения этого этапа экран пожжет гаснуть не непродолжительное время при установке графического драйвера. На определенном шаге нужно ввести имя пользователя ( например U533-1) и Организацию – BSTU. На следующем шаге нужно выбрать «Вариант лицензирования» - «На сервер» и установить число одновременных подключений – 100. Далее имя компьютера можно выбрать – BSTU-533-1. Поле «пароль администратора» оставить пустым.
Примечание. Пароль администратора не устанавливать!
Для автоматизации процесса установки ( целесообразно в случае установки нескольких ОС) можно воспользоваться утилитой Setup Manager (Setupmgr.exe), которую можно найти на дистрибутивном компакт-диске в файле Deploy.cab. Эта утилита позволяет подготовить инсталляционный сценарий (installation script), содержащий предопределенные ответы на все вопросы, задаваемые в процессе инсталляции таких операционных систем, как Windows 2000, Windows XP и Windows Server 2003.
Основные трудности при установке второй ОС на компьютере связаны с обеспечением двойной загрузки системы. Последовательность установки второй ОС во многом зависит от того, какая первичная ОС установлена на компьютере. Если первичная ОС имеет более раннюю версию, чем устанавливаемая ( как в нашем случае), то можно осуществлять установку из этой системы, запуская мастер установки \I386\Winnt32.exe. В противном случае мастер установки блокируется системой и установку нужно осуществлять из-под MS-DOS, выполнив предварительно определенные шаги по сохранению загрузчика. Дело в том, что загрузчики ОС более ранних версий не способны загружать операционные системы поздних версий.
После установки сервера на следующем этапе осуществляется повышение роли сервера. Процесс повышения выделенного сервера до контроллера домена требует выполнения определенных условий и будет рассмотрен в дальнейшем.
Последовательность выполнения работы:
Задание является общим для трех подгрупп и предполагает установку серверной ОС Windows Server 2003 для дальнейшего развертывания трех дополнительных контроллеров домена. Для выполнения работы необходимо знание основных принципов организации Windows Server и этапов загрузки системы.
Задание выполняется в следующем порядке.
Установка ОС Windows Server 2003 в качестве второй операционной системы на дополнительном винчестере в выделенном разделе. Для этого необходимо:
Загрузить предустановленную Windows систему ( Windows 98);
Войти в каталог \I386 дистрибутива Windows Server 2003 (или установить компакт- диск с дистрибутивом системы) и запустить мастер установки Winnt32.exe ( или выбрать меню установки серверной ОС);
Далее следовать инструкциям мастера установки как описано выше;
Во время установки можно не задавать никаких устанавливаемых компонентов. Любые службы могут быть доустановлены в любое время после установки сервера.
По окончании установки компьютер будет автоматически перезагружен;
Для выполнения дальнейших операций необходимо войти в систему с правами администратора;
Установка драйвера сетевой карты. Если в диспетчере устройств не установлен драйвер сетевого адаптера (большинство из них распознается автоматически в процессе установки ОС), то нужно установить требуемый драйвер (например с помощью замены драйвера в диспетчере устройств, вызвав его из контекстного меню);
Задание параметров стека протокола TCP/IP.( контроллер домена обязательно должен иметь статический IP адрес, первичный DNS сервер, включение в домен):
в свойствах сетевого соединения задайте статический IP-адрес и адрес DNS-сервера, уточнив их у преподавателя
включите вновь установленный сервер в существующий домен, если он еще не является членом домена: Свойства «Мой компьютер»|вкладка«Имя компьютера»-«Изменить» (имя домена, учетные данные администратора домена уточнить у преподавателя)
Проверка работоспособности сервера. Перезагрузите компьютер и проверьте возможность загрузки первоначальной ОС и ОС Windows Server 2003. Проверьте доступность первичного контроллера домена по сети. Загрузив Windows Server 2003, просмотрите список запущенных процессов в менеджере задач. Нужно уметь объяснить назначение каждой из основных служб. Примерный список запущенных процессов приведен ниже.
Лабораторная работа №2
Настройка и администрирование службы DNS
Цель работы: Изучение одной из основных служб контроллера домена – службы DNS (Domain Name Service). Приобретение навыков по установке службы, настройке ее компонентов.
Краткие сведения из теории.
Процесс установки контроллера домена несколько отличается для случая развертывания нового домена и добавления дополнительного контроллера в существующий домен. При организации нового домена прежде чем устанавливать сервер, Active Directory и связанные с ним службы, важно разработать реализацию DNS (Domain Naimed Server), которая бы соответствовала как вашей системе разрешения имен, так и требованиям Active Directory. DNS необходим Active Directory как для разрешения имен, так и для определения пространства имен, так как доменные имена в Windows 2003 базируются на соглашении об именовании DNS. Как следствие, любой сервер, на который вы устанавливаете Active Directory, должен иметь в своих настройках протокола TCP/IP указание на сервер DNS, который необходимо установить и настроить предварительно. Если вы не сделаете это заранее, то инсталляция Active Directory автоматически создаст для вас структуру DNS, которая, возможно, не будет соответствовать вашим пожеланиям. Рассмотрим основные аспекты службы DNS, которые необходимы для успешного внедрения службы как для разрешения имен, так и для поддержки Active Directory.
Первая концепция, которую необходимо запомнить, это использование DNS для разрешения имен узлов (нахождение соответствующего узлу IP-адреса) или разрешения FQDN (Fully Qualified Domain Name – полностью определенное имя домена) в его IP-адрес. FQDN представляет имя узла в виде доменного имени системы. Например:
www.2000trainers.com или более подходящее для локальной сети - user1.ipnet.i5.ru
В этом примере имя узла – левая часть полного имени, а именно www или user1. Имена узлов также могут разрешаться при помощи файла HOSTS, который является статическим текстовым файлом и находится в папке %systemroot%\system32\drivers\etc на локальном компьютере. Не стоит путать DNS c WINS, которая ставит в соответствие Netbios имени соответствующий IP-адрес (также имеется текстовый эквивалент данной службы, файл LMHOSTS).
Служба DNS хранит большое число записей ресурсов различного типа, кроме простой записи хоста, т.н. «А» записи. Наиболее используемые типы записей, которые можно встретить в файле зоны, рассмотрены ниже:
SOA – представляет из себя запись ресурса начальной записи зоны, и предоставляет информацию о зоне, включая сведения о том, какой сервер является основным, кто отвечает за административный контакт, как часто файл базы данных проверяется на наличие изменений, серийный номер базы данных, значение времени жизни, и т.д.
A – представляет уникальный адрес узла в сети, сопоставляя его имя IP-адресу.
NS – обозначает доменное имя и связанное с ним FQDN сервера имен, который является полномочным для домена.
MX – обозначает, что данный узел является почтовой службой (сервером почты или сервером пересылки) для определенного домена.
PTR – предоставляет возможность для обратного просмотра (сопоставляет IP-адресу узла его FQDN). Это позволяет находить имя узла, связанное с IP-адресом. Записи PTR находятся в файле reverse lookup zone (зоны обратного просмотра).
SRV – сопоставляет отдельные службы одному или нескольким узлам и наоборот. Например, записи могут обозначать сервер как сервер Глобального Каталога, контроллер домена и т.д.
Вторая концепция, с которой вы должны быть знакомы – эта концепция Зоны. Зона – это область пространства имен DNS, которая функционирует как административная единица. То есть группа серверов ответственна (имеет полномочие) за записи, относящиеся к некоторому домену или поддомену. Можно говорить о зонах как об областях ответственности. Например, можно создать зону для домена ipnet.i5.ru и создать 2 сервера, которые будут отвечать (будут полномочны) за хранение записей для данной зоны. Можно затем создать другую зону для поддомена market. ipnet.i5.ru и будет 2 других сервера , которые будут отвечать (будут полномочны) за эту другую зону. Однако зона может включать в себя несколько доменов, если они лежат в прилегающих друг к другу пространствах имен. Например, 2000trainers.com и asia.2000trainers.com могут являться частями одной зоны и иметь несколько серверов, отвечающих за хранение записей, относящихся к обоим доменам. Если посылается запрос на этот DNS сервер для поиска записи ресурса, находящегося в 2000 trainers.com или asia.2000trainers.com, этот DNS сервер сможет ответить на запрос, так как он будет полномочен для зоны, в которую включены оба домена.
Главной причиной для того, чтобы иметь несколько зон, является разделение административной ответственности, так же как и задача пересылки зон. Например, если есть один DNS администратор в Москве и один в Санкт-Петербурге. Тогда применение двух зон может быть оправданным. Другими словами, если есть только одна зона, тогда все DNS сервера (возможно, их два в Москве и два в Санкт-Петербурге) будут вынуждены участвовать в передаче зоны для получения обновлений. Это может вызвать недопустимый уровень трафика по линиям WAN.
Существует 5 основных типов серверов DNS. Это основные, вторичные, интегрированные в Active Directory, серверы пересылки и кэширующие серверы. Каждый из типов описан ниже:
Основной сервер DNS – основным сервером DNS является сервер, который полномочен для зоны. По существу это означает, что в зоне есть сервер, на котором можно производить изменения в базе данных зоны.
Вторичный сервер DNS – вторичный сервер DNS содержит копии «только для чтения» информации, хранящейся на основном сервере DNS, и получают обновления в ходе передачи зоны. Один вторичный сервер является минимально необходимым, но и другие могут создаваться с целью выравнивания нагрузки и обеспечению отказоустойчивости.
Интегрированный в Active Directory сервер DNS – возможен только для серверов DNS на базе OS Windows 2000 и выше, в данной реализации DNS файл зоны хранится как объект в Active Directory, а не как несколько файлов на жестком диске. В данном сценарии каждый контроллер домена, на котором установлена служба DNS по существу действует как основной сервер DNS, допускает изменения в зоне и осуществляет синхронизацию файла зоны через репликацию Каталога. Как следствие, если какой-либо сервер DNS выйдет из строя, любой другой сервер, интегрированный в Active Directory может продолжать осуществлять изменения.
Кэширующий только – кэширующий сервер DNS не является полномочным для зоны. Как следствие, он только получает клиентские запросы, получает запросы других серверов DNS, кэширует результаты и посылает ответы клиентам. По умолчанию кэширующий сервер DNS пересылает все запросы, ответы на которые не найдены в его кэше, корневому серверу DNS.
Сервер пересылки DNS – серверы DNS могут быть настроены так, что будут пересылать запросы, которые не могут разрешить, к какому-либо определенному серверу. Такие серверы называются forwarder (сервер пересылки). Серверы пересылки могут впоследствии обрабатывать запросы, вместо других серверов DNS. Это позволяет уменьшить время обработки некоторых запросов по поиску узлов (в Интернете, например), т.к. сервер пересылки обрабатывает запросы и кэширует результат, который потом возвращается к компьютеру, сделавшему запрос. Это может улучшить и скорость и производительность.
В реализации DNS в Windows 2003 по сравнению с предыдущими версиями есть ряд изменений. Наиболее важные из них это – поддержка записей служб, динамическая DNS, безопасное динамическое обновление, добавочная передача зоны и интегрирование с Active Directory. Все эти возможности описаны ниже:
Записи для служб – в реализации DNS в Windows 2003 поддерживаются записи для такого важного типа ресурсов, как записи служб (часто упоминаемые как SRV записи). Записи служб позволяют клиентам запрашивать DNS-поиск для систем, на которых запущены определенные службы, такие как Глобальный Каталог (который обозначается как GC-запись).
Динамическая DNS – в традиционных реализациях DNS все записи было необходимо создавать и изменять вручную на DNS сервере, что могло отнимать огромное количество времени. Реализация DNS в Windows 2003 называется Dynamic DNS или DDNS. В данной реализации клиенты имеют возможность автоматически обновлять свои записи, которые главным образом используются в среде, где клиенты подключаются к серверу DHCP для получения IP-адресов. Windows server 2003 является не единственной OС фирмы Microsoft, которая поддерживает динамическое обновление. Можно настроить сервер DHCP в Windows 2003 так, что он сможет обновлять DNS на стороне клиентов, что позволяет клиентам, работающим под другими (не-Windows 2003) OС, обновлять информацию о себе в DNS. Динамическая DNS также очень удобна для контроллеров домена, которые также могут автоматически регистрировать записи своих сервисов, в противном случае, все это было бы необходимо делать вручную.
Безопасное динамическое обновление – если DNS зона является интегрированной в Active Directory, то Windows 2003 позволяет вам использовать нечто, что называется безопасным динамическим обновлением. Заметьте, что простые динамические обновления могут быть потенциально опасными, потому что любой клиент может быть зарегистрирован в DNS, так как динамический DNS только отвечает на запросы, но не аутентифицирует их. Если установлено безопасное динамическое обновление, только пользователь или система, которые имеют соответствующие разрешения на связанных ACL (access control list – списках управления доступом) для зоны, могут добавлять записи в DNS. По умолчанию группа аутентифицированных пользователей имеет необходимые разрешения. Клиентские системы сначала предпринимают попытку использовать обычный запрос по умолчанию и, если он будет отвергнут, безопасное обновление.
Добавочная передача зоны – реализация NT 4 DNS поддерживала только AXFR, или полную передачу зоны. При этой конфигурации каждый раз, когда основной сервер имен осуществлял передачу зоны вторичному серверу, файл базы данных зоны передавался целиком, даже если в нем произошло единичное изменение. Windows 2003 поддерживает IXFR или добавочную (инкрементную) передачу зоны. В данной реализации, только изменения передаются в ходе передачи зоны, вместо передачи всего файла базы данных зоны.
Интеграция с Active Directory – Windows 2003 продолжает поддерживать традиционную реализацию по схеме основной/вторичный сервера DNS, использовавшуюся в предыдущих версиях Windows server. В данном сценарии, изменения в файле зоны могут быть сделаны только на основном сервере, так как только он содержит редактируемую копию файла зоны. В Windows 2003 вводится новая концепция – DNS, интегрированная в Active Directory. В этой реализации файл зоны DNS и связанная с ним информация хранится как объект в Active Directory вместо того, чтобы находиться в папке DNS на жестком диске. Эта интеграция позволяет любому контроллеру домена, на котором запущена служба DNS, делать изменения в базе данных DNS, при этом изменения в зоне реплицируются как часть процесса репликации Active Directory. Это также позволяет сделать службу DNS более отказоустойчивой. В традиционной среде DNS, если основной сервер имен выходит из строя, все динамические изменения в DNS становятся невозможными, так как редактируемая копия зоны недоступна. В службе DNS, интегрированной в Active Directory, все DNS сервера могут осуществлять обновления. Заметьте, что традиционные сервера DNS могут продолжать существовать в такой среде – они могут быть вторичными и использовать сервер DNS, интегрированный в Active Directory, как основной сервер для получения файла зоны.
Для Active Directory в Windows 2003 требуется, чтобы служба DNS функционировала нормально. Безусловным требованием является поддержка службой DNS записей служб – SRV.
Нужно понимать, что означают различные записи служб SRV и связанные с ними поддомены, которые вы можете найти (или которые потребуется создать) в реализации службы DNS для поддержки Active Directory. Windows 2003 использует записи служб в DNS для того, чтобы определять местоположение контроллеров домена в конкретном домене, контроллеров домена расположенных на том же сайте, серверов Глобального Каталога, центров распределения ключей и т.д. Записи служб используют стандартный формат для записей, пример которого приведен ниже:
_service._protocol.name ttl class SRV priority weight port target
_service – представляет имя службы, которая запущена на контроллере домена, такая как ldap (для контроллера домена), gc (для сервера Глобального Каталога), kerberos (для центра распределения ключей) и т.д.
_protocol – определяет, какой транспортный протокол используется, например TCP или UDP.
Name – определяет имя домена, связанное с записью, например ipnet.i5.com.
Ttl – определяет время жизни записи в секундах.
Class – определяет значение класса записи DNS, практически всегда это IN для Интернета.
Priority – определяет уровень приоритета для сервера. Клиент пытается контактировать с сервером, у которого минимальный уровень приоритета.
Weight (вес) – является функцией выравнивания нагрузки. Если несколько серверов имеют одинаковый приоритет, клиент выбирает запись SRV с наибольшим весом.
Port – определяет номер порта, на котором установлена данная служба.
Target (цель) – определяет FQDN узла, на котором запущена служба.
Таким образом, контроллер домена с FQDN dc1.ipnet.i5.ru, который является сервером Глобального Каталога, будет иметь следующую запись этого сервиса:
_gc._tcp.ipnet.i5.ru 600 IN SRV 0 100 3268 dc1.ipnet.i5.ru
Контроллеры домена регистрируют записи своих служб, когда запускается их служба Netlogon. Следовательно, останавливая и вновь запуская службу Netlogon на контроллере домена, можно тем самым добиться перерегистрации всех SRV записей. Рассмотрим различные поддомены, которые создаются в домене в ходе реализации службы Windows 2003 DNS. В домене создаются четыре главные поддомена:
_msdcs – этот поддомен используется для того, чтобы дать возможность пользователям находить контроллеры домена, которые предоставляют специфические службы, запущенные под Windows 2003.
_sites – этот поддомен используется для того, чтобы дать возможность пользователям находить контроллеры домена, которые предоставляют специфические службы в конкретном сайте.
_tcp – этот поддомен содержит список служб, которые используют протокол ТСР для взаимодействия.
_udp - этот поддомен содержит список служб, которые используют протокол UDP для взаимодействия.
Записи служб и их содержание могут контролироваться при помощи как оснастки DNS MMC (Microsoft Menegment Console), так и запросов DNS, которые выполняются утилитой nslookup.exe. Синтаксис запроса сервера DNS для получения перечня всех записей служб для данного домена показан ниже:
C:\Nslookup
>ls –t SRV ipnet.i5.ru
Кроме тех деталей, которые были упомянуты выше, важно также понять, как создавать начальную зону DNS для поддержки Active Directory.
Для начала работы по созданию новой зоны потребуется уже существующий домен (пусть это будет домен ipnet.i5.ru) и компьютер, с установленной на нем OС Windows server 2003. Конфигурирование зоны потребует установки на сервер службы DNS при помощи мастера.
Щелкните на ссылке «Добавить или удалить роль» и следуйте инструкциям мастера установки. В окне «Установка и удаление программ» выберите сетевые службы
В составе служб выберите DNS
После того, как вы сделаете это, откройте оснастку DNS и вы увидите следующее окно:
По умолчанию сервер будет действовать как кэширующий сервер, просто пересылая запросы корневому серверу, когда ответ на запрос не может быть найден в его кэше. Однако для поддержки Active Directory должна быть создана зона, которая будет правомочной для создаваемого домена Active Directory. Щелкнем правой кнопкой мыши на forward lookup zone (Зоны прямого просмотра) и выберем New Zone (Создать новую зону). При этом запустится мастер создания новой зоны. Существует три вида зон, которые могут быть созданы:
Заметьте, что опция для интегрированной в Active Directory зоны недоступна до тех пор, пока Active Directory не будет установлена. Если вы добавляете контроллер в существующий домен, то есть возможность выбора - standard secondary (дополнительная зона) или standart primary - создание основной зоны. Основная зона может быть впоследствии преобразована в интегрированную в Active Directory, как мы увидим чуть позднее. Наилучшим выбором будет создание основной зоны, что впоследствии даст возможность организовать полноценный резервный DNS сервер. Зона должна обязательно иметь название, поэтому выберете например имя ipnet.i5.ru, что вызовет создание файла зоны, который будет называться ipnet.i5.ru.dns.
Перед созданием зоны выдается предупреждающее сообщение
Новая зона создается в поддиректории Зоны прямого просмотра:
После создания зоны удостоверьтесь, что на вкладке TCP/IP свойств сервера, который вы хотите повысить до контроллера домена, имеется запись для этого, вновь созданного, сервера DNS (это может быть одна и та же система). Также заметьте, что свойства зоны доступны для изменения настроек, таких как тип зоны (который может быть изменен, после установки Active Directory), поддержка динамических обновлений (отключенная по умолчанию), SOA (Запись ресурса начальной записи зоны), Серверы имен, WINS и передачи зоны, как показано на рисунке, расположенном ниже:
Заметьте, что динамические обновления не установлены по умолчанию. Вам потребуется изменить эту настройку для того, чтобы контроллеры домена автоматически регистрировали записи своих служб в DNS.
Настройки для зоны могут отличаться от настроек сервера DNS, который может поддерживать несколько зон одновременно. Свойства, настраиваемые на сервере DNS, показаны на рисунке ниже, и включают в себя настройку сетевых карт, серверов пересылки, дополнительных свойств, корневых ссылок, ведения журнала и мониторинга.
Также нужно иметь ввиду, что зона может включать в себя несколько доменов только в том случае, когда они имеют связанные пространства имен. Если вы захотите, чтобы один сервер DNS поддерживал домены, называемые kaf.operzone.ru и ipnet.i5.ru, то вы вынуждены будете создать две отдельные зоны. Однако, для доменов ipnet.i5.ru и market.ipnet.i5.ru вам будет достаточно одной зоны.
Хоть это и не является обязательным для поддержки Active Directory, все же будет правильным всегда создавать reverse lookup zones (зон обратного поиска) для всех зон прямого поиска, так как они помогают осуществлять обратное разрешение IP-адресов в имена узлов. Имена зон обратного поиска записываются в формате, в котором часть IP-адреса, соответствующая подсети узла, представляется в обратном порядке и на конце добавляется имя домена обратного поиска. Например, доменное имя для зоны обратного поиска, которая поддерживает сеть 192.168.0.0. будет представлена в виде 168.192. in-addr.arpa. Вы также можете задать динамические обновления для этой зоны для того, чтобы обратные записи добавлялись автоматически. Создайте зону обратного просмотра точно так же, как и прямого просмотра и введите адрес сети в появившемся окне
В окне динамического обновления задайте возможность такого обновления
В итоге будут получены две зоны прямого и обратного просмотра:
После установки DNS сервера и организации зон следует проверить правильность настроек и работоспособность DNS сервера. Есть три основных средства для выявления неисправностей серверов DNS, о которых необходимо знать. Первое из них – это вкладка «наблюдение» свойств сервера DNS, показанная на рисунке, расположенном ниже:
Этот инструмент позволяет посылать запросы серверу DNS для того, чтобы убедиться, что он функционирует нормально. Простой запрос посылается только к данному серверу и его выполнение оценивается как «Пройден» или «Отказ». Рекурсивный запрос, при котором сервер DNS будет опрашивать другие сервера DNS для получения ответа, тоже будет оценен в виде «Пройден» или «Отказ». Для выполнения запроса нужно нажать кнопку «Тест». Этот инструмент может применяться для тестирования DNS на регулярной основе, если вы определите интервал выполнения теста.
Ведение журнала DNS (logging) может быть также использовано для целей выявления неисправностей, так как он записывает все главные события DNS. Настройка ведения журнала выполняется на вкладке Logging свойств сервера DNS, а все накопленные данные сохраняются в текстовом файле, который называется dns.log и хранится в папке %systenroot%\system32\dns на сервере. Заметьте, что чрезмерное увлечение регистрацией событий может негативно повлиять на производительность сервера и поэтому должна использоваться только в целях выявления неисправностей.
Утилита командной строки nslookup является наиболее универсальным средством, которое можно использовать в различных ситуациях, в том числе при поиске неполадок. Она может запускаться в двух режимах: неинтерактивном и интерактивном. Однако используя nslookup в интерактивном режиме, можно извлечь гораздо больше пользы. В этом режиме с ее помощью можно получить наиболее подробную информацию об удаленных компьютерах и доменах, так как с помощью опций можно указать, какая информация должна быть получена из базы DNS. Основной формат команды nslookup:
nslookup [-option...] [host-to-find | -[server]]
Если в командной строке задать параметр host-to-find, то nslookup будет работать в неинтерактивном режиме. Если аргументы не заданы или первый аргумент — дефис (-), то nslookup будет работать в интерактивном режиме. При необходимости с помощью аргумента -server можно указать другой DNS-сервер, где server — IP-адрес запрашиваемого DNS-сервера. В противном случае nslookup будет по умолчанию обращаться к DNS-серверу, который задается в файле /etc/resolv.conf.
Параметры nslookup можно изменить тремя способами. Во-первых, можно задать параметры в командной строке вместе с командой nslookup. Во-вторых, можно указать их в интерактивной командной строке nslookup с помощью команды set. И в-третьих, можно создать в своем рабочем каталоге $HOME файл .nslookuprc и указать в нем желаемые параметры, по одному на строку. Список параметров, которые можно использовать с командой nslookup, приведен в таблице.
Параметры nslookup |
|
Параметр |
Описание |
all |
Выводит текущие значения параметров |
class |
Устанавливает класс DNS (по умолчанию = IN ) |
[no]debug |
Включает/выключает режим отладки (по умолчанию =nodebug ) |
[no]d2 |
Включает/выключает режим полной отладки (по умолчанию =nod2 ) |
domain=name |
Устанавливает доменное имя по умолчанию name |
srchlist=name1/ name2... |
Изменяет домен по умолчанию на name1 и производит поиск по списку name1/name2... |
[no]defname |
Добавляет доменное имя по умолчанию к компоненту запроса |
[no]search |
Добавляет доменные имена в списке к имени хоста (по умолчанию =search ) |
port=value |
Изменяет номер порта TCP/UDP (по умолчанию = 53 ) |
querytype=value |
Изменяет тип запрашиваемой записи (по умолчанию = А ) |
type=value |
То же, что и querytype. |
[no]recurse |
Указывает серверу имен запросить другие серверы для получения ответа (по умолчанию = recurse ) |
retry=number |
Устанавливает число повторов запроса при неудачном ответе (по умолчанию = 4) |
root=host |
Изменяет имя корневого сервера на хост с именем host (по умолчанию = ns.internic.net ) |
timeout=number |
Изменяет интервал времени ожидания ответа на значение, равное number (по умолчанию = 5 сек) |
[no]vc |
Всегда использовать виртуальную цепочку (по умолчанию = novc ) |
[no]ignoretc |
Игнорировать ошибки при урезании пакета (по умолчанию = noignoretc ) |
В следующем листинге показан пример сеанса nslookup, во время которого запрашивается информация о хосте www.linux.org. На запрос с установленными по умолчанию параметрами для указанного имени просто возвращается соответствующий ему IP-адрес. В нашем примере демонстрируется изменение параметров с целью поиска почтовых серверов для данного домена.
1 [katie@shadrach katie]$ nslookup
2 Default Server: ns1.isp.net
3 Address: 10.0.0.1
4
5 > www.linux.org
6 Server: ns1.isp.net
7 Address: 10.0.0.1
8
9 Non-authoritative answer:
10 Name: www.linux.org
11 Address: 198.182.196.56
12
13 > set type=MX
14 > www.linux.org
15 Server: ns1.isp.net
16 Address: 10.0.0.1
17
18 Non-authoritative answer:
19 www.linux.org preference =20, mail exchanger = router.invlogic.com
20 www.linux.org preference =30, mail exchanger = border-ai.invlogic.com
21 www.linux.org preference =10, mail exchanger = mail.linux.org
22
23 Authoritative answers can be found from:
24 linux.org nameserver = NS0.AITCOM.NET
25 linux.org nameserver = NS. invlogic. com
26 router.invlogic.com internet address = 198.182.196.1
27 border-ai.invlogic.com internet address = 205.134.175.254
28 mail.linux.org internet address = 198.182.196.60
29 NS0.AITCOM.NET internet address = 208.234.1.34
30 NS.invlogic.com internet address = 205.134.175.254
31 > exit
32 [katie@shadrach katie]$
В строке 5 формируется запрос для хоста с именем www.linux.org. В строках 6 и 7 показан DNS-сервер, который обрабатывает данный запрос, а в строках 9–11 отображается, что сервер выдает неавторитетный ответ об IP-адресе. Очевидно, что кто-то уже обращался к этому же хосту и его IP-адрес хранился в кэше локального DNS-сервера. В строке 13 устанавливается параметр, с помощью которого запрашивается информация о почтовых серверах для данного домена. В строках 18–30 отображается информация, полученная от DNS-сервера. Строки 18–21 являются по сути разделом ответа пакета DNS, который сигнализирует о том, что ответ не является авторитетным, и далее показывает три почтовых сервера, ответственных за доставку электронной почты на хост www.linux.org. В строках 23–30 показан авторитетный ответ и дополнительная информация из пакета DNS. Так, строки 23–25 показывают два авторитетных DNS-сервера для домена linux.org, в которых содержаться исходные записи о www.linux.org. В строках 26–30 отображается дополнительная информация об IP-адресах хостов, содержащихся в ответах.
Последовательность выполнения работы:
Установка DNS сервера.
Запустите мастер установки DNS сервера и следуйте инструкциям мастера как описано выше.
После установки сервера DNS в меню программ|администрирование появится команда запуска оснастки «DNS».
Создайте зону прямого просмотра и настройте параметры зоны, как описано выше. После задания параметров нужно уметь объяснить параметры настройки.
Создайте зону обратного просмотра и настройте параметры зоны. Нужно уметь объяснить параметры настройки.
Проверьте работоспособность DNS сервера на простых и рекурсивных запросах как описано выше.
С помощью утилиты nslookup определить:
IP адрес www.mail.ru
Имена и адреса почтовых серверов для www.mail.ru
Местонахождение службы DHCP в собственном домене.