Функция
|
Описание
|
Переименование домена
|
Любой домен может быть переименован. Процесс переименования может привести к изменению положения домена в рамках иерархии домена (за исключением корневого домена леса)
|
Доверительные отношения между лесами доменов
|
Между двумя лесами доменов, находящимися на функциональном уровне Windows Server 2003, могут быть установлены транзитивные доверительные отношения (как односторонние, так и двусторонние)
|
Репликация связанных (linked) значений
|
Изменение состава группы пользователей приводит к передаче информации только о новых или удаленных членах группы
|
Деактивация объектов схемы
|
Определения классов объектов и атрибутов, содержащиеся в схеме, не могут быть удалены (поскольку это нарушило бы целостность каталога). Вместо этого администратор может выполнить деактивацию требуемого объекта (например, если он содержит ошибку). Впоследствии объект может быть снова активирован
|
Оптимизация процесса репликации содержимого глобального каталога
|
Если происходит изменение одного из атрибутов объекта, содержащегося в глобальном каталоге, реплицируется не весь объект, а только измененный атрибут
|
Динамические объекты и вспомогательные классы
|
Администратор может создавать в каталоге объекты, которые имеют , ограниченный срок жизни (существуют в каталоге в течение строго определенного периода времени)
|
Усовершенствованный алгоритм генерации топологии репликации
|
Оптимизирована работа сервиса Knowledge Consistency Checker (KCC) для лесов доменов, имеющих большое количество сайтов
|
Таким образом, чтобы сделать доступными весь спектр возможностей Windows Server 2003, администратор должен поднять лес доменов на функциональный уровень Windows Server 2003.
Существует еще один функциональный уровень, который используется в ситуации, когда происходит обновление сети на основе Windows NT до Windows Sewer 2003. В этом случае первый же контроллер домена Windows NT, обновленный до Windows Server 2003, переводится на функциональный уровень Windows Server 2003 interim. Этот функциональный уровень допускает существование в сети только контроллеров домена Windows NT и Windows Server 2003. Контроллеры домена под управлением Windows 2000 не допускаются.
Функциональный уровень Windows Sewer 2003 interim включает в себя все возможности, доступные на уровне Windows 2000, плюс две функции уровня Windows Server 2003:
усовершенствованный алгоритм генерации топологии репликации;
репликация связанных значений.
Очевидно, что для переведения леса доменов на функциональный уровень Windows Server 2003 необходимо, чтобы все домены находились на функциональном уровне Windows Server 2003.
Проектирование доменов и развертывание Active Directory
Проектирование доменов и развертывание Active Directory
Сценарии формирования пространства имен
Изолированное корпоративное пространство имен
Корпоративное пространство имен, интегрированное с внешним пространством имен
Корпоративное пространство имен, являющееся частью внешнего пространства имен
Функциональные уровни
Функциональный уровень доменов
Функциональный уровень леса доменов
Изменение имен доменов
Установка контроллеров домена
Подготовка к установке контроллера домена
Требования и ограничения
Проверка службы DNS
Обновление существующего леса доменов Windows 2000
Установка контроллера домена Windows Server 2003
Выполнение установки
Установка контроллера домена из резервной копии
Установка контроллера домена Windows NT/2000 в среде Windows Server 2003
Проверка состояния контроллера домена
Изменение имени контроллера домена
Удаление контроллера домена
Управление доверительными отношениями
Создание доверительных отношений
Удаление доверительных отношений
Управление доверительными отношениями между лесами доменов
Изменение функционального уровня домена и леса доменов
Конфигурирование клиентов
Изменение функционального уровня домена и леса доменов
Функциональный уровень, на котором находится домен или лес доменов, определяет перечень возможностей, доступных в рамках домена или леса доменов. Чем выше функциональный уровень, тем шире диапазон возможностей. Необходимо, однако, понимать, что механизм функциональных уровней был введен компанией Microsoft с целью сохранения совместимости с предыдущими версиями серверных операционных систем (Windows NT/ 2000), которые широко распространены в корпоративных сетях. Организация перехода на Windows Server 2003 требует от компаний значительных финансовых и временных затрат, поэтому для многих из них предпочтительным вариантом является постепенный переход на новую платформу. Этот подход характеризуется одновременным сосуществованием в сети нескольких поколений операционных систем.
Поэтому перевод домена на новый функциональный уровень возможен только в ситуации, когда администратор отказывается от использования одного из поколений операционных систем в качестве контроллеров домена. Отказ от контроллеров домена под управлением Windows NT позволяет перевести домен на функциональный уровень Windows 2000 native. Соответственно, отказ от использования контроллеров домена Windows 2000 позволяет перевести домен на функциональный уровень Windows Server 2003. Только после того как все домены переведены на функциональный уровень Windows Server 2003, администратор может перевести лес доменов на функциональный уровень Windows Server 2003. На этом этапе становится доступен весь спектр возможностей Windows Server 2003.
Для изменения функционального уровня могут использоваться две оснастки: Active Directory Users and Computers и Active Directory Domain and Trusts. Для изменения функционального уровня домена в контекстном меню объекта, ассоциированного с нужным доменом, выберите пункт Raise Domain Functional Level. В открывшемся окне (рис. 19.10) под строкой Current domain functional level отображается текущий функциональный уровень домена. Для его изменения выберите из раскрывающегося списка необходимый функциональный уровень и нажмите кнопку Raise. После изменения функционального уровня домена необходимо некоторое время, чтобы сведения об изменении реплицировались на все контроллеры в домене.
Изменение функционального уровня является необратимой операцией. Это означает, что возвращение домена на прежний функциональный уровень невозможно.
Рис. 19.10. Изменение функционального уровня домена
Изменение функционального уровня леса доменов выполняется аналогичным образом. Вызвав контекстное меню объекта, находящегося в корне пространства имен оснастки Active Directory Domain and Trusts, необходимо выбрать в нем пункт Raise Forest Functional Level. Если возможность переведения леса доменов на новый функциональный уровень отсутствует, в открывшемся окне будет выведено соответствующее предупреждение, говорящее о том, что один из доменов, входящих в лес, еще не был переведен на функциональный уровень Windows Server 2003.
Если все требования для изменения функционального уровня леса доменов соблюдены, необходимо нажать кнопку Raise. После того как сведения о произведенном изменении будут реплицированы на все контроллеры домена леса, администратор может использовать новые функциональные возможности.
Изменение имен доменов
В службе каталога Active Directory, реализованной в составе Windows 2000. лес доменов представлял собой статичную структуру. Администратор мог либо добавить новые домены или даже целые деревья, либо удалить их. Он не мог изменить пространство имен каталога, переименовав один или несколько доменов.
В службе каталога Windows Server 2003 реализована возможность изменения имени домена Active Directory.
Изменение DNS- или NetBIOS-имени домена. Этот процесс предполагает изменение имени, не приводящее к изменению структуры леса доменов. Изменение имени корневого домена приводит к автоматическому изменению имен всех дочерних доменов. Изменение имени корневого домена может потребоваться, например, вследствие изменения названия компании.
Перемещение домена в рамках дерева доменов, либо перемещение в другое дерево доменов. В этом сценарии процесс переименования сводится к изменению родительского домена. Частным случаем является ситуация, когда перемещаемый домен образует новое дерево доменов.
Любой домен может быть перемещен, за исключением корневого домена леса. Функции корневого домена леса не могут быть возложены на другой домен. Тем не менее, администратор может изменить имя корневого домена леса.
В зависимости от задач, стоящих перед администратором, процесс переименования может занять множество шагов и является далеко не тривиальным; поэтому предварительное планирование леса по-прежнему остается важным этапом при развертывании Active Directory. Непосредственно переименование выполняется утилитой командной строки Rendom.exe, которая располагается в папке VALUEADD\MSFT\MGMT\DOMREN дистрибутивного диска. Эта утилита используется исключительно для изменения имени домена. Она не может использоваться для добавления нового домена или удаления существующего.
Процесс переименования доменов возможен только в случае, когда лес доменов был переведен на функциональный уровень Windows Server 2003. В противном случае переименование невозможно. Очевидно, что невозможно изменение имени для доменов Windows 2000.
Изменение имени контроллера домена
Архитектура Windows Server 2003 допускает возможность изменения имени контроллеров домена (в Windows 2000 такая возможность отсутствует). Сам процесс изменения имени не сопряжен с какими-либо сложностями, однако от администратора требуется четкое выполнение определенной последовательности действий. Целью этих действий является последующее изменение всех записей об имени контроллера домена в базе данных службы DNS и в копиях каталога других контроллеров домена (фактически являющихся партнерами по репликации).
Изменение имени контроллера домена возможно только в домене, находящемся на функциональном уровне Windows Server 2003.
Процесс переименования контроллера домена не предполагает его перемещение между различными доменами. Чтобы выполнить перемещение контроллера между доменами, необходимо выполнить его понижение (demotion) до обычного сервера, а затем заново установить его в уже новом домене.
Перед изменением имени контроллера домена необходимо проинформировать других носителей каталога о его новом имени. Для этого в режиме командной строки необходимо выполнить операцию: netdom computername <текущее_имя> /add:<новое_имя>
В результате новое имя контроллера домена будет зарегистрировано в базе данных службы DNS в качестве альтернативного имени. Необходимо подождать пока информация о новом имени не будет реплицирована на все носители зоны. После этого альтернативное имя надо сделать основным. Для этого используется команда: netdom computer-name <текущее_имя> /MakePrimary: <новое_имя>
Данная команда обновляет сведения об имени контроллера домена в каталоге Active Directory. На этом этапе необходимо перезагрузить контроллер домена. После того как изменения будут реплицированы на все носители каталога, следует выполнить команду, удаляющую старое имя из базы данных DNS и каталога Active Directory: netdom computername <новое_имя> /Remove:<текущее_имя>
После этого можно изменять собственно имя компьютера. Для этого откройте окно свойств объекта My Computer (Мой компьютер) и перейдите на вкладку Computer Name (Имя компьютера). Щелкните по кнопке Change (Изменить) и в открывшемся окне замените существующее имя компьютера новым.
Изолированное корпоративное пространство имен
Данный сценарий является наиболее простым. Корпоративное пространство имен DNS полностью изолировано от других пространств имен, являющихся внешними по отношению к компании. Для решения задач, стоящих перед работниками компании, не требуется доступ к внешним ресурсам. Пример подобного пространства имен приведен на рис. 19.1.
Для реализации подобного пространства имен необходимо, чтобы DNS-сервер, стоящий на вершине корпоративного пространства имен DNS, являлся корневым сервером. Для этого необходимо, чтобы все корпоративные DNS-серверы указывали на этот сервер как на корневой сервер пространства имен. Кроме того, корневой сервер не должен быть сконфигурирован для переадресации запросов на другой DNS-сервер. Другими словами, вкладка Forwarders окна свойств этого сервера должна быть пустой.
Для адресации хостов в корпоративной сети администратор может также избрать любую схему. Администратор не обязан принимать во внимание схемы распределения IP-адресов и подсетей, принятые в Интернете. Определяющими в данном случае являются исключительно правила формирования IP-адресов, описанные в спецификации протокола IP.
Рис. 19.1. Изолированное пространство имен DNS
На следующем этапе администратор должен выбрать способ именования доменов. Формируя пространство имен DNS, не являющегося частью пространства DNS-имен Интернета, администратор может не придерживаться схемы именования доменов, принятой в этой глобальной сети. Нет нужды использовать для имен доменов первого уровня стандартные имена Интернета — ru, com, edu и т. п. Администратор может разработать свою собственную схему именования доменов. Определяющим здесь является понятность и простота.
Конфигурирование клиентов
После того как домен создан и установлены все необходимые контроллеры домена, администратор должен соответствующим образом сконфигурировать клиентские компьютеры. Этот процесс может отличаться в зависимости от версии клиентской операционной системы. Полное взаимодействие со службой каталога для решения различных задач допускает только архитектура операционных систем Windows 2000/XP и Windows Server 2003. Операционные системы Windows 9.X/NT разрабатывались в расчете на использование совсем других механизмов обнаружения контроллера домена, разрешения имен и поиска объектов в сети. Чтобы обеспечить возможность нормальной работы в сети для этих клиентов, необходимо установить специальный компонент — службу клиента Active Directory. Независимо от версии операционной системы следует определить для клиента адрес предпочитаемого DNS-сервера и DNS-суффикс (DNS-имя домена). Для того чтобы DNS-суффикс мог изменяться в процессе перемещения клиента между доменами, необходимо убедиться, что флажок Change primary DNS suffix when domain membership changes установлен.
Следует помнить, что в большинстве случаев проблемы в процессе взаимодействия клиента и контроллера домена обусловлены ошибками в конфигурировании стека протоколов TCP/IP. Наиболее важным является адрес предпочитаемого DNS-сервера. Клиент использует DNS-сервер для получения списка доступных контроллеров домена. Если клиент не может получить адреса контроллеров домена, он не сможет участвовать в процессе аутентификации. Как следствие — сетевые ресурсы окажутся недоступными для него. Учитывая ту роль, которую играет служба DNS в процессе функционирования сети, необходимо уделить особое внимание вопросу проверки настроек DNS-клиента на компьютере (адреса предпочитаемого DNS-сервера и DNS-суффикса). Кроме того, всегда в случае возникновения каких-либо проблем в процессе функционирования цепочки "клиент — контроллер домена", необходимо в первую очередь обращаться к настройке DNS-клиента.
Прежде чем компьютер под управлением Windows NT/2000/XP и Windows Server 2003 будет включен в состав домена, необходимо создать в соответствующем доменном разделе каталога объект, ассоциированный с учетной записью для данного компьютера. В противном случае процедура добавления клиента в домен окончится неудачно. Эту операцию можно выполнять заранее или непосредственно при добавлении компьютера к домену.
В случае клиентов под управлением Windows 2000/XP и Windows Server 2003 администратор может использовать различные диагностические инструменты, позволяющие выявить причины возникающих проблем.
Утилита Netdiag позволяет протестировать настройки DNS-клиента и проверить доступность контроллеров для того домена (например, khsu.ru), к которому планируется подключить клиентский компьютер: C:\>netdiag /test:DsGetDc /d:khsu.ru /v
Если предпочитаемый DNS-сервер не содержит информации о домене, к которому подключается клиент, следует проверить настройки клиента и при необходимости использовать другой DNS-сервер в качестве предпочитаемого.
Другой тест позволяет получить список доступных клиенту контроллеров для указанного домена. Этот тест полезно выполнить уже после того, как клиент добавлен в состав домена: C:\>netdiag /testtDcList /d:khsu.ru /v
Если один из контроллеров домена окажется недоступным, утилита выдаст ошибку. В этом случае возможны проблемы с аутентификацией клиента в домене, поиском в каталоге, применением групповых политик и т. д.
Корпоративное пространство имен, интегрированное с внешним пространством имен
Данный сценарий предполагает существование внутреннего корпоративного пространства имен. Фактически оба пространства (корпоративное и внешнее) представляют собой отдельные непересекающиеся пространства имен. Корпоративное пространство имен по своей сути идентично изолированному пространству имен, рассмотренных в предыдущем сценарии. Администратор может выбрать любую схему именования доменов, а также может выбрать любую схему адресации хостов.
Все запросы пользователей на разрешение доменных имен можно условно разделить на две категории:
запросы на разрешение доменных имен, принадлежащих к корпоративному пространству имен. Эти запросы разрешаются корпоративными DNS-серверами;
запросы на разрешение доменных имен, принадлежащих ко внешнему пространству имен. Эти запросы разрешаются внешними DNS-серверами, обслуживающими внешнее пространство имен.
Можно рассматривать описанную ситуацию следующим образом. Существует корпоративная вычислительная сеть, ресурсы которой формирует корпоративное пространство имен. Помимо этого, для выполнения ряда задач согрудникам компании необходим доступ к ресурсам другой сети (в самом простом случае — к ресурсам Интернета) (рис. 19.2).
Рис. 19.2. Корпоративное пространство имен и пространство имен Интернета
Данный сценарий реализуется следующим образом. Корпоративное пространство формируется так же, как и в предыдущем случае. Однако корневой DNS-сервер конфигурируется таким образом, чтобы все запросы, адресованные к внешним доменам, переадресовывались на один из внешних DNS-серверов. Для этого используется режим выборочного перенаправления, который конфигурируется на вкладке Forwarders (Перенаправление) окна свойств корневого сервера.
Для доменов корпоративного пространства имен режим перенаправления на корневом сервере должен быть отключен (т. е. сервер не должен переадресовывать запросы на другой сервер). Для остальных доменов запросы должны переадресовываться на внешний DNS-сервер.
Следует отметить, что рассмотренный сценарий предполагает только разрешение внешних доменных имен. Поскольку в корпоративной вычислительной сети используются внутренние адреса, необходимо предусмотреть механизм маршрутизации запросов ко внешним IP-адресам. Эти запросы последуют после того, как доменное имя будет разрешено в IP-адрес. Для решения этой задачи администратору необходимо соответствующим образом сконфигурировать маршрутизаторы и межсетевые экраны.
Корпоративное пространство имен, являющееся частью внешнего пространства имен
В последнем рассматриваемом сценарии корпоративное пространство имен является фрагментом другого более крупного пространства имен. Например, корпоративная вычислительная сеть интегрируется с глобальной сетью Интернет. В этом случае все корпоративные доменные имена, а также адреса хостов являются реальными адресами и именами Интернета. Такая интеграция имеет массу преимуществ. Одно из них — ресурсы корпоративной сети могут быть доступны из любой точки мира. При этом доступность не предполагает незащищенность. Администратор может отделить внутреннюю сеть от внешней сети межсетевым экраном и использовать системы сертификации и аутентификации.
Реализация данного сценария имеет определенные сложности, связанные с получением "реальных" IP-адресов, являющихся частью внешнего пространства имен, и регистрацией в этом пространстве имен домена. В случае Интернета для регистрации имен и получения пула адресов корпорация должна обратиться в соответствующие инстанции.
Для интеграции необходимо сконфигурировать корпоративный корневой DNS-сервер для перенаправления всех запросов на внешний DNS-сервер.
Рассмотрим ситуацию, когда администратор выполняет
Рассмотрим ситуацию, когда администратор выполняет установку контроллера домена Windows Server 2003 в среде Windows 2000. Это может быть первым шагом к переходу с Windows 2000 на Windows Server 2003. Архитектура службы каталога Windows Server 2003 претерпела ряд принципиальных изменений, из которых, в первую очередь, следует отметить изменения, коснувшиеся схемы каталога (появление новых классов объектов, в том числе динамических).
Как следствие, наличие различий в архитектуре потребовало выполнения специальной процедуры "подготовки" службы каталога Windows 2000 к установке контроллеров домена Windows Server 2003. Фактически эта процедура сводится к выполнению расширения схемы. Для выполнения процедуры используется специальная утилита командной строки Adprep.exe. Эта утилита поставляется в составе дистрибутивного диска Windows Server 2003 и располагается в каталоге \I386.
Перед выполнением "подготовки" леса доменов Windows 2000 на всех контроллерах домена должен быть установлен пакет обновления Windows 2000 Service Pack 2 (или выше). В противном случае работа утилиты Adprep может привести к нарушению работоспособности отдельных контроллеров домена.
Подготовка службы каталога Windows 2000 должна быть выполнена на двух уровнях.
На уровне леса. Следует подготовить лес в целом к развертыванию Windows Server 2003. Для этого необходимо запустить утилиту Adprep с ключом /forestprep. Утилита должна быть запущена на контроллере домена, являющимся хозяином схемы (schema master).
На уровне отдельного домена. После того как выполнено расширение схемы (на уровне всего леса доменов), необходимо выполнить подготовку каждого домена, в котором планируется установка контроллеров домена Windows Server 2003. Для этого следует запустить утилиту Adprep с ключом /domainprep на контроллере домена, являющимся хозяином инфраструктуры домена (infrastructure master).
Подготовка службы каталога на уровне отдельного домена может быть выполнена только после того, как изменения в схеме каталога, выполненные на уровне леса доменов, будут реплицированы на контроллер домена, являющийся хозяином инфраструктуры домена. Любые попытки запустить команду adprep /domainprep до того, как эти изменения будут реплицированы, приведут к выводу сообщения об ошибке.
Если администратор планирует выполнить обновление некоторого контроллера домена Windows 2000 до Windows Server 2003, ему необходимо дождаться того момента, пока изменения, произведенные на хозяине инфраструктуры, не будут реплицированы на обновляемый контроллер домена.
Подготовка к установке контроллера домена
Прежде чем приступить к установке контроллера домена, администратор должен проделать несколько подготовительных операций. В первую очередь администратор должен убедиться в том, что компьютер, выбранный на роль контроллера домена (а, следовательно, носителя копии каталога), отвечает предъявляемым к нему требованиям. Прежде всего, речь идет о минимальных аппаратных и программных требованиях, соблюдение которых является одним из условий успешного выполнения операции установки.
Кроме того, перед выполнением установки контроллера домена необходимо убедиться в работоспособности службы DNS. Ранее уже неоднократно говорилось о роли этой службы в процессе функционирования Active Directory. Тестирование службы DNS на подготовительном этапе позволит предотвратить возникновение проблем в процессе установки контроллера домена.
Проектирование доменов и развертывание Active Directory
Служба каталога Active Directory может использоваться для размещения информации о более чем миллионе объектов. Очевидно, что вся эта информация должна быть каким-то образом организована, чтобы облегчить управление этими объектами и доступ к ним. В предыдущей главе было замечено, что организация объектов каталога представляет собой древовидную структуру, которую также принято называть иерархией объектов каталога. Формирование этой иерархии входит в обязанности администратора, осуществляющего развертывание в сети Active Directory. Именно от администратора, осуществляющего проектирование структуры каталога, зависит то, насколько эффективно будет функционировать корпоративная сеть. Правильное проектирование позволяет избежать появления проблем в будущем.
Архитектура службы каталога позволяет администратору осуществлять формирование структуры каталога на трех уровнях:
доменная структура каталога (создание структуры доменов);
логическая структура каталога (создание подразделений);
физическая структура каталога (создание подсетей и сайтов).
Каждый из этих уровней индивидуален для каждой отдельной компании. Однако прежде чем приступить к их реализации, необходимо оценить существующее окружение, собрать информацию об организационной структуре и состоянии сетевых коммуникаций предприятия. Весь собранный на этом этапе материал явится основной для дальнейшего планирования. Оцените общее количество пользователей вашей сети. Если компания состоит из нескольких филиалов, оцените количество пользователей в каждом из них. Дополнительно оцените возможность увеличения числа пользователей. В процессе проектирования структуры каталога рекомендуется исходить из расчета, что произойдет увеличение количества пользователей в полтора раза. Такой подход позволит вам создать возможности роста вашей сети без необходимости ее реорганизации. Оцените состояние корпоративной вычислительной сети на физическом уровне. Соберите информацию о сушествующих коммуникационных линиях. Важными являются сведения о пропускной способности, степени ее использования, количестве компьютеров в каждой из подсетей.
В данной главе мы рассмотрим некоторые важные вопросы планирования структуры Active Directory, которые нужно решить до начала процесса развертывания доменов на базе Active Directory. Игнорирование этих вопросов (например, выбор правильного имени DNS для корневого домена) может привести к тому, что вся структура доменов окажется несоответствующей требованиям организации. Затем мы подробно рассмотрим операции по установке контроллеров и созданию дерева доменов.
Проверка службы DNS
Прежде чем запустить на сервере мастер установки Active Directory, администратор должен проверить настройки стека протоколов TCP/IP для данного компьютера, обратив, в первую очередь, внимание на параметры службы DNS-клиента. Одним из важнейших параметров в этой ситуации является адрес предпочитаемого DNS-сервера (preferred DNS server). Именно указанный в этом параметре сервер будет использоваться мастером установки для диагностики пространства имен DNS, предшествующего созданию нового домена Active Directory, и поиска существующих носителей копий каталога. Этот же DNS-сервер впоследствии будет использоваться для регистрации доменного имени сервера. Ошибки, допущенные на этом этапе, могут привести к тому, что по окончании процедуры установки контроллер домена окажется неработоспособным. Типичны следующие ошибки:
настройки сервера, выбранного на роль контроллера домена, не содержат сведений о предпочитаемом DNS-сервере;
DNS-сервер, указанный в настройках будущего контроллера домена в качестве предпочтительного, не является носителем требуемой зоны. Кроме того, возможна и другая ситуация, когда указан сервер, являющийся дополнительным носителем зоны. Как следствие, этот DNS-сервер не может быть использован для динамической регистрации доменных имен.
Если вы осуществляете установку первого контроллера домена в лесу доменов (фактически это означает первый этап развертывания в сети службы каталога), то вы должны предоставить возможность мастеру установки Active Directory установить на сервере службу DNS и произвести ее последующее конфигурирование. При этом в настройках стека протоколов TCP/IP данного сервера параметр Preferred DNS Server (Предпочитаемый DNS-сервер) должен указывать непосредственно на сам сервер. То есть поcле установки контроллера домена все ассоциированные с ним ресурсные записи будут зарегистрированы службой DNS, функционирующей на этом же сервере. Все последующие контроллеры домена должны указывать уже на существующие DNS-серверы (например, на первый установленный DNS-сервер).
Кроме того, необходимо проверить доступность DNS-сервера с компьютера, который выбран на роль контроллера домена. Различные проблемы с сетевыми компонентами могут привести к тому, что хотя DNS-сервер функционирует и успешно используется другими хостами, вновь устанавливаемый контроллер домена не имеет с ним сетевого соединения.
Если планируется использование реализации службы DNS от стороннего производителя (не Windows 2000 или Windows Server 2003), необходимо убедиться в том, что этот DNS-сервер поддерживает требования, предъявляемые к нему службой- каталога Active Directory. Сервер имен должен поддерживать ресурсные записи SRV-типа и допускать возможность динамической регистрации имен.
Указанные подготовительные работы могут быть проделаны администратором при помощи специальной утилиты командной строки DCdiag.exe, поставляемой в составе вспомогательного комплекта утилит Windows Server 2003 Support Tools. Эта утилита является основным диагностическим инструментом администратора в ситуации, когда работа мастера установки Active Directory прерывается по причине возникновения каких-либо проблем со службой DNS.
Следующий тест позволяет проверить конфигурацию службы DNS с точки зрения возможности повышения некоторого сервера до роли контроллера домена в уже существующем домене khsu.ru: с:\dcdiag.exe /test:dcpromo /dnsdomain:khsu.ru /replicadc
В случае ошибки проверьте настройку DNS-сервера или укажите в настройках стека протокола TCP/IP другой DNS-сервер.
Другой тест позволяет проверить способность будущего контроллера домена выполнить динамическую регистрацию доменного имени в базе данных DNS-сервера. Хотелось бы отметить, что так же как и в предыдущем случае, тест запускается на сервере, который планируется повысить до роли контроллера домена.
c:\dcdiag.exe /test:RegisterlnDNS /dnsdomain:khsu.ru
Мастер установки Active Directory (утилита Dcpromo) в Windows Server 2003 имеет новые встроенные средства диагностики конфигурации DNS, что позволяет застраховаться от ошибок разрешения имен при создании контроллера домена.
Проверка состояния контроллера домена
Довольно часто возникает необходимость убедиться в том, процесс перехода сервера в новое качество успешно завершен. Если, например, служба репликации файлов (FRS) не может успешно стартовать, она не инициализирует системный том, в результате чего служба Netlogon не может сделать общей (shared) системную папку SYSVOL. Как следствие папка NETLOGON также становится недоступной для общего доступа. Это приводит к возникновению проблем с выполнением групповых политик, а также многих других проблем, в частности, с репликацией и аутентификацией. При возникновении неисправностей в Active Directory, перед тем, как выявлять проблемы, касающиеся соединений между контроллерами домена, аутентификации и т. д., вы в обоих случаях должны убедиться в том, что серверы Windows Server 2003 действительно являются контроллерами домена.
Существует несколько способов, посредством которых администратор может убедиться в том, что некоторый сервер на базе Windows Server 2003 по окончании операции повышения роли сервера (promotion) выполняет функции контроллера домена.
Раздел реестра HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services должен содержать подраздел NTDS.
Введите в командной строке net accounts. Поле Computer role (Роль компьютера) должна содержать значение PRIMARY или BACKUP для контроллера домена. Для обычных серверов это поле имеет значение SERVERS.
Введите в командной строке net start. В списке запущенных сервисов должна присутствовать служба Kerberos Key Distribution Center (Центр распределения ключей Kerberos). Если эта служба не запущена на контроллере домена, механизм аутентификации может не работать.
. Введите в командной строке nbtstat -n. Имя домена, имеющее тип <ic>, должно быть зарегистрировано (в поле Status указано значение REGISTERED).
Введите в командной строке net share. На сервере должны присутствовать общие папки SYSVOL (%SystemRoot%\SYSVOL\sysvol) и NETLOGON (%SystemRoot%\SYSVOL\sysvol\<DomainDNSName>\SCRIPTS).
С помощью утилиты Ldp.exe проверьте значение атрибута isSynchronized объекта RootosE. По окончании процесса повышения роли сервера система должна полностью синхронизировать все разделы каталога. Когда синхронизация закончена, атрибут isSynchronized принимает значение TRUE.
Используйте утилиту командной строки NLtest.exe. Эта утилита поставляется в составе пакета вспомогательных утилит Windows Server 2003 Support Tools.
С помощью утилиты Ntdsutil.exe можно подключиться к только что установленному контроллеру домена и проверить его способность отвечать на запросы LDAP. Утилита позволяет также проверить, знает ли контроллер о расположении ролей FSMO в своем домене.
Сценарии формирования пространства имен
Рассмотрим некоторые сценарии создания корпоративного пространства имен DNS. Фактически существует три сценария:
изолированное пространство имен DNS;
пространство имен DNS, интегрированное с внешним пространством имен;
пространство имен DNS, являющееся фрагментом другого более глобального пространства имен.
Создание доверительных отношений
Для создания доверительных отношений запустите оснастку Active Directory Domain and Trusts и откройте окно свойств объекта, ассоциированного с нужным доменом. Перейдите на вкладку Trusts (рис. 19.8). В поле Domains trusted by this domain отображаются домены1, которым доверяет конфигурируемый домен (исходящие доверительные отношения), а в поле Domains that trust this domain — домены, доверяющие конфигурируемому домену (входящие доверительные отношения). Для каждого значения отображается информация о типе доверительных отношений и транзитивности. Применительно к типу доверительных отношений возможны следующие значения:
Forest — доверительные отношения, установленные между лесами доменов;
Tree Root — доверительные отношения, установленные между деревьями доменов в рамках одного леса доменов;
Child — доверительные отношения, установленные в рамках дерева доменов между дочерним и родительским доменами;
External — доверительные отношения, установленные с внешним доменом любого типа;
Shortcut — перекрестные доверительные отношения, установленные между отдельными доменами леса;
Realm — доверительные отношения, установленные между областями Kerberos.
Доверительные отношения между лесами доменов могут быть установлены только в том случае, если оба леса находятся на функциональном уровне Windows Server 2003.
Рис. 19.8. Вкладка Trusts окна свойств домена
Процесс создания доверительных отношений зависит от того, какой именно тип отношений администратор хочет создать. Например, если администратор хочет создать отношения полного доверия с внешним доменом, он должен создать пару встречных односторонних доверительных отношений.
Для установки доверительных отношений необходимо щелкнуть по кнопке New Trust (Новые доверительные отношения), что приведет к запуску мастера New Trust Wizard. В ходе работы мастера администратор должен будет предоставить мастеру информацию об имени домена, с которым устанавливаются доверительные отношения. Если домен с указанным именем не обнаружен, мастер предполагает, что подразумевается имя области Kerberos.
В пределах леса отношения доверия между родительским и дочерним доменами, а также между деревьями леса доменов не могут быть созданы администраторами вручную. Эти отношения создаются мастером установки Active Directory в ходе создания нового домена.
Требования и ограничения
Процесс повышения выделенного сервера до контроллера домена требует выполнения определенных условий. Рассмотрим эти требования.
Перед установкой на сервере должен быть установлен стек протоколов TCP/IP и для каждого из интерфейсов сервера выделен статический IP-адрес. Впоследствии администратор может изменить этот адрес и заново зарегистрировать в базе данных DNS доменное имя с уже новым адресом.
Для сервера должен быть установлен DNS-суффикс, соответствующий имени домена, для которого будет устанавливаться контроллер домена. Последнее требование является необязательным, если установлен флажок Change primary DNS suffix when domain membership changes. В этом случае система автоматически определит DNS-суффикс при включении сервера в состав некоторого домена.
Служба каталога может быть установлена на раздел диска с файловой системой NTFS. Это требование обусловлено соблюдением должного уровня безопасности, требующего разграничения доступа к файлам, непосредственно на уровне файловой системы (скажем, файловая система FAT не предоставляет такой возможности). Кроме того, раздел, предназначенный для установки службы каталога, должен иметь как минимум 250 Мбайт свободного дискового пространства. С целью повышения производительности службы каталога администратор может разместить файлы хранилища каталога и журнала транзакций на отдельные физические диски. Это позволит избежать конкуренции операции ввода/вывода.
Разумеется, в этом случае каждый из задействованных разделов должен быть отформатирован под NTFS.
Операция установки контроллера домена требует наличия у выполняющего ее пользователя определенных полномочий. Установка первого контроллера домена в лесе осуществляется на одиночном сервере, не являющимся частью какого-либо домена. В этой ситуации пользователь должен обладать полномочиями локального администратора на том сервере, на котором происходит установка. Если происходит установка первого контроллера в домене (в рамках уже существующего леса доменов), пользователь должен являться членом группы Enterprise Admins (Администраторы корпорации). В случае установки дополнительного контроллера в домене пользователь должен быть либо членом уже упомянутой группы, либо членом группы Domain Admins (Администраторы домена).
Удаление доверительных отношений
Для удаления доверительных отношений необходимо выбрать в списке требуемую запись и нажать кнопку Remove (Удалить). Если отношения двусторонние, администратор может при желании удалить отношения доверия направленные как в одну сторону, так ив другую. Может быть удалено только одно из направлений двусторонних отношений доверия.
Необходимо помнить, что не могут быть удалены отношения доверия между корневыми деревьями домена, а также отношения между родительским и дочерним доменами.
Для получения информации о состоянии доверительных отношений администратор может использовать утилиту командной строки NLtest.exe. Ниже приводится результат проверки состояния доверительных отношений между текущим доменом и доменом khsu. khakasnet. ru:
С:\>nltest /sc_query:khsu.khakasnet.ru
Flags: 30 HAS_IP HAS_TIMESERV
Trusted DC Name\\main.khsu.khakasnet.ru
Trusted DC Connection Status Status = 0 0x0 NERR_Success
The command completed successfully
Удаление контроллера домена
Под удалением контроллера домена фактически понимается понижение его до роли обычного сервера. Порой бывает необходимо удалить один или несколько контроллеров из домена или переместить их в другой домен. Нельзя просто вывести контроллер из состава домена, поскольку информация о нем останется в каталоге. Соответственно, этот контроллер домена будет приниматься во внимание при формировании топологии репликации, выполнении аутентификации пользователей и т. п.
Перед выполнением операции понижения контроллера домена необходимо убедиться в том, что контроллер не является сервером глобального каталога или исполнителем специализированных ролей. В последнем случае перед понижением контроллера домена администратор должен передать эти роли другим контроллерам. Необходимо, чтобы после понижения контроллера в домене оставался хотя бы один сервер глобального каталога.
Понижение контроллера, являющегося последним в домене, приводит к удалению домена. Операция удаления домена не может быть осуществлена (соответственно, будет прервана операция понижения последнего контроллера домена), если домен имеет дочерние домены. Запрещается также понижать контроллеры домена, являющиеся последними носителями реплик разделов приложений. Перед выполнением операции понижения администратор должен вручную удалить разделы приложений с помощью утилиты Ntdsutil.exe.
Для выполнения операции понижения необходимо, чтобы контроллер домена был работоспособным. Также должны быть доступны другие контроллеры домена. Это позволит выполнить изменения в каталоге, информирующие об удалении контроллера домена. Операция понижения контроллера домена выполняется мастером установки Active Directory (утилита Dcpromo).
В процессе понижения роли комьпьютера мастер установки проверит копию каталога понижаемого контроллера домена на предмет наличия реплик разделов приложений. Если будут обнаружены реплики, являющиеся последними, мастер выдаст соответствующее предупреждение (рис. 19.7). В этом случае мастер в следующем окне потребует подтвердить готовность администратора удалить эту реплику.
Рис. 19.7. На понижаемом контроллере домена обнаружены последние реплики разделов приложений
Удаление последней реплики раздела приложения приводит к потере всех хранящихся в ней данных. Как следствие это может привести к отказу или неверной работе приложений.
На заключительном этапе администратор должен будет предоставить информацию о пароле, который будет сопоставлен учетной записи локального администратора. Эта учетная запись будет создана мастером по окончании процедуры удаления компонентов службы каталога.
Управление доверительными отношениями
Как говорилось в предыдущей главе, доверительные отношения выступают в качестве связующего звена между доменами, посредством которого домены организуются в иерархию. Для управления доверительными отношениями используется оснастка Active Directory Domain and Trusts (Active Directory — домены и доверия).
Также администратор может использовать для управления доверительными отношениями утилиту командной строки Netdom.exe..
Управление доверительными отношениями между лесами доменов
Если два леса доменов находятся на функциональном уровне Windows Server 2003, они могут быть соединены друг с другом посредством транзитивных доверительных отношений. Если хотя бы один из лесов доменов находится на функциональном уровне Windows 2000, леса доменов могут быть соединены только посредством внешних доверительных отношений (external trusts), которые не обладают свойством транзитивности.
Перед выполнением процедуры создания доверительных отношений между лесами доменов необходимо убедиться, что DNS-сервер способен разрешить доменные имена корневых доменов обоих лесов.
Запустите мастер создания доверительных отношений для корневого домена леса. В ответ на просьбу указать имя домена на противоположном конце доверительных отношений укажите имя корневого домена другого леса. Мастер предложит выбрать способ соединения двух лесов: либо посредством транзитивных доверительных отношений между лесами (forest trust), либо посредством нетранзитивных внешних доверительных отношений (external trust).
На двух последующих страницах мастер попросит предоставить информацию о направлении доверительных отношений (односторонние или двусторонние), а также сведения об учетной записи, в контексте которой создается отношение доверия. Далее администратор должен определить, какая часть ресурсов леса доменов будет доступна аутентифицированным пользователям из другого леса доменов. Имеются два варианта (переключателя на странице мастера):
Allow authentication for all resources in the local forest. В этом случае пользователи одного леса могут получить доступ к любым ресурсам в рамках другого леса доменов. Данный режим можно использовать в ситуации, когда оба леса доменов принадлежат одной организации;
Allow authentication only for selected resources in the local forest. Администратор вручную указывает ресурсы в рамках леса доменов, которые будут доступны пользователям из другого леса. Этот способ разграничения доступа подходит для сценариев, когда леса доменов принадлежат различным организациям, не желающим предоставлять доступ ко всем ресурсам.
Область доступности ресурсов может быть изменена администратором уже после того, как доверительные отношения созданы. Для этого необходимо открыть окно свойств доверительных отношений и перейти на вкладку Authentication.
На заключительном этапе администратор должен сконфигурировать механизм маршрутизации суффиксов (name suffix routing). По умолчанию, если не обнаружены конфликты в доменных именах, мастер предлагает активизировать механизм маршрутизации суффиксов для всех доменов, входящих в оба леса (рис. 19.9). Администратор может снять флажки напротив имени определенного леса, чтобы предотвратить возможность доступа пользователей в указанный домен.
Впоследствии администратор может произвести дополнительное конфигурирование механизма маршрутизации суффиксов. В окне свойств объекта, ассоциированного с доверительными отношениями между лесами доменов, имеется вкладка Name Suffix Routing, на которой перечислены все параметры. Администратор может отключить (disable) или, наоборот, включить маршрутизацию некоторого суффикса, а также исключить (exclude) некоторый домен из маршрутизации.
Рис. 19.9. Конфигурирование механизма маршрутизации суффиксов
Установка контроллера домена из резервной копии
Архитектура Windows Server 2003 позволяет установить в домене дополнительный контроллер, используя резервную копию о состоянии системы (System state) уже существующего контроллера домена. Хотелось бы обратить особое внимание на то, что данная возможность распространяется только на установку дополнительных доменов. Создание нового домена или дерева доменов может быть выполнено только стандартным способом.
Установка контроллера домена из резервной копии позволяет избежать копирования всего содержимого каталога через сеть с уже существующих носителей. Вместо этого, наполнение вновь устанавливаемого каталога будет производиться с резервной копии. Администратор может использовать эту возможность для установки контроллера домена в удаленных филиалах, соединенных с основной корпоративной сетью посредством коммуникационных линий с низкой пропускной способностью. Преимущества указанного метода особенно ощутимы в случае большого размера копии каталога. В этом сценарии на одном из контроллеров домена корпоративный администратор создает резервную копию и передает ее администратору удаленного филиала. Администратор филиала, используя полученную резервную копию, выполняет установку дополнительного контроллера домена. После процедуры синхронизации только что установленный контроллер готов обслуживать пользователей филиала.
Однако необходимо заметить, что даже в случае установки с резервной копии полностью исключить взаимодействие через сеть с уже существующими контроллерами домена нельзя. Поэтому в процессе выполнения установки создаваемый контроллер домена должен иметь сетевое соединение с другими контроллерами в домене.
Если резервная копия была создана на контроллере домена, выполняющем функцию сервера глобального каталога, устанавливаемый из этой копии контроллер домена может быть также сконфигурирован в качестве сервера глобального каталога непосредственно в процессе установки. С другой стороны, существующие разделы приложений не будут автоматически воссозданы на устанавливаемом контроллере домена, даже если оригинальный контроллер был их носителем. Для создания этих разделов администратор должен использовать утилиту Ntdsutil.exe.
Процесс создания резервной копии, отражающей состояние системы (в том числе и файлы службы каталога), будет подробно описан в главе 23 "Восстановление системы". Здесь же заметим, что в процессе создания резервной копии, предназначенной для установки дополнительных контроллеров домена, необходимо снять флажок Automatically backup System Protected Files with the System State (Автоматически резервировать защищенные системные файлы). В этом случае в создаваемую резервную копию не будут включаться защищенные системные файлы.
На сервере Windows Server 2003, выбранном на роль контроллера домена, используя утилиту Backup, восстановите резервную копию в некоторую папку. Для этого из рскрывающегося списка Restore files to (Восстановить файлы в) выберите значение Alternate location (Альтернативное место расположения) и в одноименном поле укажите папку, в которую должна быть восстановлена резервная копия.
После того как процесс восстановления из резервной копии закончится, необходимо запустить утилиту Dcpromo с ключом /adv. Это приведет к запуску мастера установки Active Directory в расширенном режиме. После того как будет выбран режим установки дополнительного контроллера домена, мастер предложит указать способ наполнения каталога на создаваемом контроллере (рис. 19.6):
наполнение через сеть путем копирования с уже существующего контроллера домена. Этому способу соответствует пункт Over the network from a domain controller. В данном случае процесс установки продолжится по стандартному сценарию;
наполнение из резервной копии. Этому способу соответствует пункт From these restored backup files. При этом администратору потребуется указать папку, в которой располагается восстановленная на предыдущем этапе резервная копия.
Если будет выбран режим создания нового домена, процедура установки контроллера домена продолжится по стандартному сценарию.
Рис. 19.6. Выберите способ наполнения каталога для устанавливаемого контроллера домена
к установке контроллера домена, находящегося
Прежде чем приступить к установке контроллера домена, находящегося под управлением предыдущих версий Windows (Windows NT/2000), необходимо убедиться, что функциональный уровень, на котором находится интересующий домен, позволяет это сделать. Контроллер домена Windows NT может быть установлен только в случае, если домен находится на функциональном уровне Windows 2000 mixed. Установка контроллера домена Windows 2000, соответственно, возможна в домене, находящемся на функциональных уровнях Windows 2000 mixed или Windows 2000 native.
В случае установки контроллера домена Windows NT имеется одно ограничение: контроллер домена должен устанавливаться исключительно как резервный контроллер домена (Backup Domain Controller, BDC). Резервные контроллеры домена Windows NT располагают копией базы данных учетных записей, доступной исключительно для чтения. Один из контроллеров в домене, находящийся под управлением Windows Server 2003, выступает исполнителем роли эмулятора РОС. Этот контроллер домена отвечает за репликацию изменений каталога на контроллеры домена Windows NT. При этом реплицируемые данные преобразовываются в специальный формат подсистемы репликации Windows NT.
Прежде чем приступить к установке BDC Windows NT, необходимо создать для него учетную запись в каталоге Active Directory. Для создания объекта, ассоциированного с учетной записью компьютера, используется утилита Active Directory Users and Computers, расположенная в группе программ Administrative Tools. В меню Action (Действие) выберите пункт New | Computer (Создать | Компьютер). В открывшемся окне необходимо ввести информацию об имени компьютера и установить флажки Assign this computer account as a pre-Windows 2000 computer (Рассматривать этот компьютер как пред-Windows 2000 компьютер) и Assign this computer account as a backup domain controller (Рассматривать этот компьютер как резервный контроллер домена).
Если на момент выполнения установки контроллера домена Windows NT в каталоге Active Directory не будет обнаружена соответствующая учетная запись, процедура установки будет на определенном этапе прервана и администратор получит сообщение: "The Machine Account for This Computer either does not exist or is inaccessible". Чтобы продолжить установку, администратору потребуется создать учетную запись в каталоге.
также называемая повышением роли сервера
Процедура установки контроллера домена ( также называемая повышением роли сервера до контроллера домена) выполняется при помощи мастера Active Directory Installation Wizard (Мастер установки Active Directory). Этот мастер запускается утилитой командной строки Dcpromo.exe.
В процессе установки контроллера домена происходит наполнение каталога. В случае установки первого контроллера домена в лесе все содержимое каталога создается непосредственно мастером установки. Если в лесе создается новый домен, то мастер установки создает исключительно доменный раздел. Раздел схемы и каталога копируется с уже существующих контроллеров домена. В ситуации, когда администратор создает дополнительный контроллер в уже существующем домене, имеется два варианта наполнения каталога:
все содержимое каталога копируется с уже существующего контроллера домена;
содержимое каталога воссоздается из резервной копии каталога.
Каждый из предложенных вариантов имеет свои плюсы и минусы. Мы рассмотрим оба варианта.
Мастер установки Active Directory может быть вызван из утилиты Configure Your Server, которая располагается в меню Administrative Tools.
Установка контроллеров домена
Как уже говорилось, контроллер домена выступает в качестве носителя копии каталога. Поэтому развертывание службы каталога начинается непосредственно с установки контроллеров домена. Вся реализация доменной инфраструктуры каталога происходит как раз в процессе установки контроллеров домена. Именно поэтому процессу установки контроллеров домена необходимо уделять особое внимание. Ошибки, допущенные при установке контроллера домена, могут привести к нарушению работоспособности всей службы Active Directory.
Выполнение установки
В ходе использования мастера установки Active Directory возможны четыре сценария (рис. 19.3):
создание нового леса доменов;
создание нового дерева доменов в рамках существующего леса доменов;
создание нового домена в рамках существующего дерева доменов;
установка дополнительного контроллера домена в уже существующем домене.
Рис. 19.3. Сценарии создания контроллера домена
Администратор осуществляет выбор одного из этих сценариев на первых страницах мастера. Если сценарий предполагает создание нового домена, мастер предложит ввести доменное и NetBIOS-имя будущего домена. В сценарии, предполагающем установку дополнительного контроллера, администратору будет необходимо ввести имя существующего домена.
Независимо от избранного сценария мастер предложит выбрать место расположения файлов хранилища и журналов. Вы можете разместить их в одной папке (по умолчанию предлагается %SystemRoot%\NTDS), либо разнести в разные (например, на разные физические диски). Напомним, что эти файлы могут размещаться только в NTFS-разделах. Кроме того, потребуется выбрать место расположения системного тома SYSVOL, используемого службой репликации файлов. Эта папка также может быть размещена только в NTFS-разделе.
На следующем этапе мастер, учитывая информацию о выбранном администратором доменном имени, обратится с запросом к службе DNS. Для взаимодействия со службой DNS используется информация о предпочитаемом DNS-сервере. Версия мастера установки Active Directory, реализованная в рамках Windows Server 2003, позволяет выполнить диагностику имеющейся конфигурации службы DNS в случае возникновения проблем. На рис. 19.4 изображено окно мастера в ситуации, когда предпочитаемый DNS-сервер не содержит зоны для создаваемого домена Active Directory. При этом администратору будет предложено несколько вариантов дальнейших действий.
I have corrected the problem. Perform the DNS diagnostic test again. Выбор этого переключателя предписывает мастеру произвести повторную диагностику службы DNS. Предполагается, что администратор вмешался и устранил возникшую проблему. Применительно к рассматриваемой ситуации, администратор может выполнить создание необходимой зоны.
Рис. 19.4. Мастер установки обнаружил проблемы с разрешением имени будущего домена
Install and configure the DNS server on this computer, and set this computer to use this DNS server as its preferred DNS server. Выбор этого переключателя перекладывает все обязанности по конфигурированию DNS-сервера на мастера установки Active Directory. В случае установки первого контроллера домена в лесу доменов этот режим конфигурирования службы DNS является предпочтительным. Мастер сам выполнит установку службы DNS и создаст все необходимые зоны (за исключением зон обратного разрешения, которые администратор должен создать самостоятельно после окончания процедуры установки).
I will correct the problem later by configuring DNS manually (Advanced). Эта опция означает, что мастер должен продолжить свою работу, несмотря на обнаруженные ошибки. Администратор в этом случае берет на себя все обязанности по конфигурированию службы DNS после окончания процедуры установки. Фактически администратору нужно будет создать две зоны для создаваемого домена и зарегистрировать в них все необходимые ресурсные записи.
Мастер также выдаст сообщение об ошибке, если предпочтительный DNS-сервер не содержит информацию о домене, для которого предполагается установить дополнительный контроллер домена.
Если процесс тестирования структуры DNS закончился успешно, мастер выдаст соответствующую информацию (рис. 19.5).
Рис. 19.5. Процедура тестирования службы DNS окончилась успешно
На заключительном этапе работы мастера администратору необходимо будет определить уровень совместимости разрешений с подсистемой безопасности Windows NT. Если в среде Windows Server 2003 планируется существование серверов под управлением Windows NT (не обязательно контроллеров домена) с установленными на них серверными приложениями, необходимо выбрать уровень совместимости разрешений с платформой Windows NT (переключатель Permissions compatible with pre-Windows 2000 operating system). Этот же уровень совместимости разрешений следует избрать в ситуации, когда контроллер домена Windows Server 2003 устанавливается в среде Windows NT. На этом уровне совместимости разрешается анонимный доступ к информации в доменном разделе каталога. Если изначально администратор уверен, что в сети будут использоваться только серверы Windows 2000 и Windows Server 2003, вопросами совместимости разрешений с архитектурой Windows NT можно пренебречь.
Необходимо понимать, что уровень совместимости разрешений влияет только на серверные приложения, установленные на Windows NT-серверах. На работу обычных клиентов (в том числе находящихся под управлением операционных систем Windows 9x/ME/NT) выбранный уровень совместимости не влияет.
Если в процессе создания домена не был выбран необходимый уровень совместимости разрешений, администратор может впоследствии исправить ситуацию посредством команды net localgroup "Pre-Windows 2000 Compatible Access" everyone /add.
По окончании установки контроллера домена потребуется перезагрузить систему. В процессе загрузки будет зарегистрировано доменное имя в базе данных предпочитаемого DNS-сервера. Если установленный контроллер домена является первым в лесу, то учетная запись локального администратора, в контексте которого производилась установка, преобразуется в учетную запись Administrator (Администратор созданного домена). Эта учетная запись автоматически включается в состав следующих групп:
Administrators. Встроенная локальная группа;
Domain Admins. Группа с глобальной областью действия. Члены этой группы обладают необходимыми полномочиями для управления доменом. По умолчанию включается в состав группы Administrators;
Domain Users. Группа с глобальной областью действия. В состав этой группы включаются все создаваемые в контексте домена пользователи. По умолчанию группа включается в состав встроенной локальной группы Users;
Enterprise Admins. Группа с глобальной областью действия. Члены этой группы обладают полномочиями на управление инфраструктурой службы каталога. По умолчанию группа включается в состав группы Administrators;
Group Policy Creator Owners. Группа с глобальной областью действия. Члены этой группы могут редактировать параметры объектов групповой политики в рамках данного домена;
Schema Admins. Группа с глобальной областью действия. Члены группы обладают полномочиями, необходимыми для изменения схемы каталога.
