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

В службе каталога Windows 2000 существует понятие режима функционирования домена (domain mode). Домен может находиться в одном из двух режимов — основном (native) или смешанном (mixed). Режим функционирования домена определяет возможность использования контроллеров домена Windows NT. В Windows Server 2003 появилось понятие функционального уровня (functional level). Функциональный уровень определяет доступные функциональные возможности.

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

Функциональный уровень определяется как для отдельных доменов, так и для всего леса доменов в целом.

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

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

Таблица 19.1. Функциональные уровни домена

Функциональный уровень		Допустимые контроллеры домена
Windows 2000 mixed		Windows NT, Windows 2000, Windows Server 2003
Windows 2000 native		Windows 2000, Windows Server 2003
Windows Server 2003		Только Windows Server 2003

Уровни Windows 2000 mixed и Windows 2000 native соответствуют смешанному и основному режимам функционирования домена Windows 2000. Охарактеризуем каждый из функциональных уровней.

 Windows 2000 mixed. Этот функциональный уровень допускает сосуществование в домене контроллеров домена, находящихся под управлением различных операционных систем (Windows NT/2000 и Windows Server 2003). Контроллеры домена Windows NT могут существовать в системе только в качестве резервных контроллеров домена (Backup Domain Controller, BDC). Один из контроллеров домена (Windows 2000 или Windows Server 2003) выступает для резервных контроллеров домена Windows NT в качестве основного контроллера домена Windows NT (Primary Domain Controller, PDC). На данном уровне недоступен ряд возможностей Windows 2000 доменов — универсальные (universal) группы безопасности, вложенность групп и т. д. Все создаваемые домены по умолчанию находятся на этом функциональном уровне.

 Windows 2000 native. Данный функциональный уровень ограничивает перечень используемых контроллеров доменов (Windows 2000 и Windows Server 2003). Это объясняется тем, что в домене больше не поддерживается механизм NTLM-репликации, используемый Windows NT. Тем не менее, клиенты могут работать под управлением любых операционных систем. На этом функциональном уровне становятся доступны все возможности Windows 2000 доменов. Однако ряд функциональных возможностей Windows Server 2003 недоступен — возможность переименования контроллеров домена, использование объектов класса InetOrgPerson, номера версий ключей Kerberos.

  Windows Server 2003. Если домен переведен на этот функциональный уровень, в нем допускается использование только контроллеров домена Windows Server 2003. На этом уровне становятся доступны все функциональные возможности службы каталога Windows Server 2003.

Существует одно серьезное ограничение, связанное с использованием функциональных уровней. Архитектура службы каталога допускает только повышение функционального уровня. Другими словами, если домен находится на уровне Windows Server 2003, он не может быть переведен на уровни Windows 2000 mixed или даже Windows 2000 native. Это обусловлено принципиальными изменениями, происходящими в каталоге после повышения функционального уровня.

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

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

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

 Windows 2000. Данный функциональный уровень предполагает наличие в сети контроллеров домена различных версий — Windows NT/2000 и Windows Server 2003. В этом случае некоторая часть новых возможностей Active Directory недоступна. Используется функциональность леса, поддерживаемая системами Windows 2000.

 Windows Server 2003. Чтобы поднять лес доменов на этот функциональный уровень, нужно перевести все контроллеры домена леса под управление Windows Server 2003. На этом функциональном уровне становятся доступными новые возможности, перечисленные в табл. 19.2. Эти функции касаются всего леса доменов и доступны в любом домене.

Таблица 19.2. Новые возможности доменов и леса, доступные на функциональном уровне Windows Server 2003

Функция		Описание
Переименование домена		Любой домен может быть переименован. Процесс переименования может привести к изменению положения домена в рамках иерархии домена (за исключением корневого домена леса)
Доверительные отношения между лесами доменов		Между двумя лесами доменов, находящимися на функциональном уровне Windows Server 2003, могут быть установлены транзитивные доверительные отношения (как односторонние, так и двусторонние)
Репликация связанных (linked) значений		Изменение состава группы пользователей приводит к передаче информации только о новых или удаленных членах группы
Деактивация объектов схемы		Определения классов объектов и атрибутов, содержащиеся в схеме, не могут быть удалены (поскольку это нарушило бы целостность каталога). Вместо этого администратор может выполнить деактивацию требуемого объекта (например, если он содержит ошибку). Впоследствии объект может быть снова активирован
Оптимизация процесса репликации содержимого глобального каталога		Если происходит изменение одного из атрибутов объекта, содержащегося в глобальном каталоге, реплицируется не весь объект, а только измененный атрибут
Динамические объекты и вспомогательные классы		Администратор может создавать в каталоге объекты, которые имеют , ограниченный срок жизни (существуют в каталоге в течение строго определенного периода времени)
Усовершенствованный алгоритм генерации топологии репликации		Оптимизирована работа сервиса Knowledge Consistency Checker (KCC) для лесов доменов, имеющих большое количество сайтов

<
/p> Таким образом, чтобы сделать доступными весь спектр возможностей 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.

Изменение функционального уровня домена и леса доменов

Функциональный уровень, на котором находится домен или лес доменов, определяет перечень возможностей, доступных в рамках домена или леса доменов. Чем выше функциональный уровень, тем шире диапазон возможностей. Необходимо, однако, понимать, что механизм функциональных уровней был введен компанией 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. Группа с глобальной областью действия. Члены группы обладают полномочиями, необходимыми для изменения схемы каталога.

Active Directory Replication Monitor (ReplMon.exe)

Имеющая графический интерфейс утилита Active Directory Replication Monitor (ReplMon.exe) может быть использована для выполнения следующих операций, связанных с репликацией:

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

 синхронизация указанного раздела каталога некоторого контроллера домена со всеми партнерами по репликации;

 синхронизация указанного раздела каталога некоторого контроллера домена с определенным партнером по репликации.

Одним из достоинств утилиты Active Directory Replication Monitor является возможность подробного протоколирования операции репликации.

Администрирование доменов

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

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

Начнем с краткого обзора имеющихся средств администрирования.

Аудит событий доступа к объектам Active Directory

Оценка эффективности существующей политики безопасности системы должна базироваться на некотором аналитическом материале. В состав операционной системы Windows Server 2003 включены действенные механизмы протоколирования событий, связанных с попытками (как удачными, так и неудачными) получения доступа к ресурсам сети. Согласно терминологии Microsoft, процесс протоколирования действий пользователей получил название аудита (audit). Сведения обо всех событиях, связанных с попыткой получения доступа к ресурсам, для которых активизирован режим аудита, фиксируются системой в специальном журнале безопасности (Security log).

Для объектов каталога реализация аудита осуществляется в два этапа:

1. Активизация режима аудита. При этом администратор должен указать категории событий, которые подлежат аудиту.

2. Определение объектов каталога, для которых будет осуществляться аудит событий.

Подсистема безопасности Windows Server 2003 оперирует девятью категориями событий, подлежащих аудиту. Применительно к аудиту событий, связанных с функционированием службы каталога, интерес представляют три категории событий:

 Audit object access (Аудит событий, связанных с доступом к объектам);

 Audit directory service access (Аудит событий, связанных с доступом к службе каталога);

 Audit account management (Аудит событий, связанных с управлением учетными записями).

Аудит доступа к службе каталога выполняется по отношению к операциям, выполняемым на контроллерах домена. Для активизации аудита можно использовать оснастку Domain Controllers Security Policy. Эта оснастка работает с объектом групповой политики Default Domain Controllers Policy, привязанного к подразделению Domain Controller. Откройте узел Computer Configuration | Windows Settings | Security Settings | Local Policies | Audit Policy (Конфигурация компьютера | Конфигурация Windows | Параметры безопасности | Локальные политики | Политика аудита) содержащий категории аудита.

По умолчанию для политик аудита задано одно значение — No auditing (Нет аудита). В окне оснастки выберите категорию событий, откройте его окно свойств, установите флажок Define these policy settings (Определить следующие параметры политики) и определите, какие именно попытки — успешные (Success) или неуспешные (Failure) — должны регистрироваться в системном журнале безопасности. Если флажок Define these policy settings (Определить следующие параметры политики) снят, считается, что для данной категории событий аудит не определен (Not Defined).

Следует заметить, что установки No auditing (Нет аудита) и Not defined (He определено) имеют разное значение. Если политика не определена, вы можете установить ее на другом уровне. Значение No auditing переопределяет все установки, которые могли быть заданы ранее. Групповые политики для контейнера Domain Controllers применяются последними и, следовательно, имеют самый высокий приоритет. Поэтому установки аудита, определяемые этими политиками по умолчанию, переопределяют любые параметры, заданные на предыдущих уровнях.

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

 на первом уровне отслеживаются все события, связанные с доступом непосредственно к самому объекту (создание, удаление, чтение объекта и т. п.);

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

Режим аудита позволяет отслеживать действия над объектами каталога и их атрибутами на любом уровне иерархии. При этом допускается наследование дочерними объектами параметров аудита от родительских объектов.

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

По умолчанию для группы Everyone (Все) выполняется аудит специальных обращений (успешных и неудачных) ко всем объектам в домене. Все объекты домена наследуют эти установки от корневого доменного контейнера. У некоторых контейнеров имеются дополнительные параметры аудита. Эти установки разрешают аудит критических операций, таких как запись, удаление, изменение и т. д. Все установки аудита можно просматривать в окне свойств объекта: откройте вкладку Security (Безопасность), нажмите кнопку Advanced (Дополнительно) и перейдите на вкладку Auditing (Аудит).



Нажмите кнопку Edit (Редактирование), и в открывшемся окне вы можете просматривать и изменять параметры. Если вы откроете вкладку Auditing для некоторого дочернего объекта каталога, то заметите, что все установленные флажки затенены. Их нельзя изменить непосредственно, для этого нужно открыть родительский или корневой объект. Если установить еще не отмеченный флажок, система создаст новый набор параметров аудита и добавит его в список.

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

Содержимое журнала безопасности может быть просмотрено при помощи оснастки Event Viewer. Для каждого события утилита отображает следующую информация:

 успешность попытки (была ли попытка доступа успешной или нет);

 дата и время попытки;

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

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

Авторитетное восстановление

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

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

Авторитетное восстановление всегда производится после неавторизованного восстановления каталога. Для выполнения этой операции используется утилита командной строки NtdsUtil.exe. Рассмотрим процедуру выполнения авторизованного восстановления более подробно.

На предварительном этапе контроллер домена должен быть загружен в режиме восстановления службы каталога. Используя имеющуюся резервную копию, администратор должен произвести неавторитетное восстановление службы кататога. При этом на вкладке Restore утилиты Backup из раскрывающегося списка Restore flies to (Восстанавливать файлы в) надо выбрать значение Alternate location (Альтернативное расположение). Необходимо будет указать папку на локальном диске, в которую будет произведено восстановление содержимого резервной копии. В выбранном месте после восстановления появятся следующие папки:

 Active Directory. Файлы, используемые механизмом ESE для организации хранилища каталога (файлы ntds.dit, edb.log и т. п.);

 СОМ+ Class Registration Database. Файлы, определяющие содержимое базы данных регистрации классов СОМ+ (файл ComReg.Db.bak);

 Boot Files. Эта папка содержит загрузочные файлы (файлы ntdetect.com, ntldr);

 Registry. В этой папке находятся файлы, содержимое которых определяет значение основных ключей системного реестра (файлы default, SAM, SECURITY, software, system, userdiff);

  Sys Vol. Эта папка определяет содержимое системного тома SYSVOL.

По окончании процедуры неавторизованного восстановления система предложит выполнить перезагрузку. Для выполнения авторизованного восстановления необходимо отказаться от перезагрузки, поскольку при этом произойдет обновление всех системных файлов. Запустите редактор реестра и убедитесь в существовании параметра RestoreinProgress в ключе реестра HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\NTDS.

Вместо перезагрузки необходимо перейти в режим командной строки и запустить утилиту NtdsUtil. Ниже приведен пример диалога для операции authoritative restore (команды администратора выделены полужирным):

C:\>ntdsutil

ntdsutil: authoritative restore

authoritative restore: restore subtree OU=ND,DC=khsu,DC=ru

Opening DIT database... Done.

The current time is 09-20-02 21:45.14.

Most recent database update occurred at 09-19-02 11:03.01.

Increasing attribute version numbers by 300000.

Counting records that need updating...

Records found: 0000000004

Done.

Found 4 records to update.

Updating records...

Records remaining: 0000000000

Done.

Successfully updated 4 records.

Authoritative Restore completed successfully,

authoritative restore: quit

ntdsutil: quit

После этого необходимо выполнить перезагрузку компьютера. Обратите внимание на то, что номера версий объектов увеличиваются на 100 000 для каждого дня, прошедшего с момента создания резервной копии. Для просмотра изменений метаданных можно применять утилиту RepAdmin.exe. Например, для восстановленного подразделения можно воспользоваться следующей командой: c:\repadmin /showmeta OU=ND, DC=khsu, DC=ru store.khsu.ru

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

Если в вашей конфигурации объекты Active Directory меняются редко, можно изменить стандартное значение, на которое увеличивается номер версии. При этом в процессе работы утилиты NtdsUtil используется команда, подобная следующей:  restore subtree OU=ND, DC=khsu, DC=ru verinc 1000



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

Делегирование административных полномочий

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

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

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

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

Операция делегирования административных полномочий осуществляется при помощи мастера Delegation of Control Wizard (Мастер делегирования полномочий). Этот мастер может быть вызван из оснасток Active Directory Users and Computers и Active Directory Sites and Services. Посредством этого мастера администратор может осуществлять делегирование полномочий на уровне отдельных контейнеров каталога.

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

Таблица 20.3. Уровни делегирования полномочий

Объект каталога	Описание
Контейнер Sites	Делегированные на этом уровне полномочия распространяются на все сайты леса доменов
Контейнер Inter-Site Transport	На этом уровне могут быть делегированы полномочия для управления соединениями сайтов (создание, конфигурирование или удаление), а также транспортами репликации
Контейнер Subnets	На этом уровне администратор может делегировать полномочия для управления подсетями, образующими сайты (создание, изменение и удаление)
Конкретный сайт	Используя этот уровень делегирования, администратор может предоставить полномочия на управление сайтом (в том числе и управление процессом репликации)
Конкретный домен	На этом уровне администратор может делегировать полномочия на включение клиентов в состав домена, что означает создание объекта, ассоциированного с учетной записью компьютера, а также полномочия на управление ссылками групповой политики на уровне домена
Конкретное подразделение (OU)	На этом уровне администратор может делегировать некоторым пользователям полномочия, действие которых ограничивается выбранным подразделением. Конкретные полномочия, которые будут делегированы, определяются целями, с которыми создавалось это подразделение
Контейнер Computers	Делегируя полномочия на этом уровне, администратор предоставляет пользователям полномочия на управление объектами, ассоциированными с учетными записями компьютеров
Контейнер Domain Controllers	На этом уровне администратор предоставляет пользователям полномочия на управление учетными записями контроллеров домена
Контейнер System	Делегируя полномочия на этом уровне, администратор предоставляет полномочия на управление объектами, значение атрибутов которых определяют параметры различных служб Active Directory
Контейнер Users	На этом уровне администратор предоставляет пользователям полномочие на управление учетными записями пользователей

<


/p> В табл. 20. 4 перечислены задачи, выполнение которых администратор может делегировать на уровне отдельной организационной единицы, а также контейнеров Computers, Domain Controllers, ForeignSecurityPrincipals, System и Users.

Таблица 20.4. Задачи, которые могут быть делегированы на уровне организационных единиц

Задача	Описание
Create, delete, and manage user account	Полномочия на создание, удаление и управление учетными записями пользователей
Reset user passwords and force password change at next logon	Полномочия на изменение паролей учетных записей пользователей, а также установка требования на изменение пароля самим пользователем при следующей регистрации в системе
Read all user information	Полномочия на просмотр любой информации о пользователях
Create, delete, and manage groups	Полномочия на создание, удаление и управление группами пользователей
Modify the membership of a group	Полномочия на изменение членства в группе
Manage Group Policy links	Полномочия на управление ссылками групповой политики
Generate Resultant Set of Policy (Planning)	Полномочия, необходимые для генерации результирующих политик в режиме планирования
Generate Resultant Set of Policy (Logging)	Полномочия, необходимые для генерации результирующих политик в режиме ведения журнала
Create, delete and manage inetOrgPerson accounts	Полномочия на создание, удаление и управление объектами класса inetOrgPerson
Reset inetOrgPerson passwords and force password change at next logon	Полномочия на изменение паролей, сопоставленных объектам класса inetOrgPerson, а также установка требования на изменение пароля самим субъектом подсистемы безопасности при следующей регистрации в системе
Read all inetOrgPerson information	Полномочия на просмотр любой информации об объекте класса inetOrgPerson

Процесс делегирования полномочий выполняется следующим образом. Запустите оснастку Active Directory Users and Computers. Выберите контейнер, для которого вы хотите делегировать полномочия и вызовите его контекстное меню. Выберите в меню пункт Delegate Control (Делегировать управление), чтобы запустить мастер Delegation of Control Wizard (Мастер делегирования полномочий). На странице Users or Groups необходимо определить пользователей, которым будут делегированы полномочия (рис. 20.7).





Рис. 20.7. Выбор пользователей, которым будут делегированы полномочия

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

 выбрать задачи, выполнение которых будет разрешено пользователям. Данный режим является наиболее предпочтительным для большинства случаев. Этому режиму соответствует переключатель Delegate the following common tasks (Делегировать следующие общие задачи);

 выбрать вручную объекты каталога, управление которыми будет разрешено пользователям. Этот режим рассчитан на опытных администраторов и ему соответствует переключатель Create a custom task to delegate (Создать задачу для делегирования вручную).



Рис. 20.8. Выбор режима делегирования

Выбрав первый режим делегирования, администратор должен установить флажки напротив задач, которые должны быть делегированы. Если же был выбран расширенный режим делегирования, администратор должен определить классы объектов, управление которыми будет делегировано пользователям в рамках рассматриваемого контейнера (рис. 20.9). Если администратор хочет предоставить пользователям возможность создания или удаления экземпляров выбранных классов объектов, он должен установить флажки Create selected objects in this folder (Создание выбранных объектов в данном контейнере) или Delete selected objects in this folder (Удаление выбранных объектов в данном контейнере).



Рис. 20.9. Выбор классов объектов, управление которыми делегируется

Процесс делегирования только предоставляет пользователям необходимые полномочия для управления объектами. Чтобы предоставить пользователям действительную возможность применить эти полномочия, администратор должен создать для них необходимые инструменты. Используя механизм создания заказных управляющих консолей (ММС), описанный в главе 6 "Средства управления системой", администратор может создавать любой необходимый инструментарий, который и будет применяться пользователями для осуществления операций управления.



Помимо задачи делегирования полномочий, существует также задача отзыва уже предоставленных полномочий. Отзыв полномочий фактически означает отзыв у пользователей определенных разрешений на доступ к контейнерам, на уровне которых осуществлялось делегирование. Для отзыва указанных разрешений необходимо в окне свойств соответствующего контейнера перейти на вкладку Security (Безопасность). Для пользователей, которым были делегированы полномочия, необходимо снять флажки Allow (Разрешено) напротив соответствующих полномочий. Таким образом, администратор редактирует элементы списка управления доступом (ACL) выбранного контейнера. Флажки устанавливаются напротив соответствующих разрешений в ходе работы мастера делегирования. Понимая этот механизм, администратор может легко и гибко управлять объектами каталога и, как следствие, точнее настраивать Active Directory под стоящие перед ним задачи.

Кроме того, администратор всегда может восстановить для контейнера установки по умолчанию. Для этого необходимо в окне Advanced Security Settings (Дополнительные параметры безопасности) щелкнуть по кнопке Default (По умолчанию) (рис. 20.10). Однако следует помнить о том, что в результате будут отозваны все полномочия, предоставленные кому-либо на уровне данного контейнера. Кроме того, будут восстановлены полномочия, наследуемые контейнером от родительских объектов.



Рис. 20.10. Для отзыва всех делегированных полномочий необходимо нажать кнопку Default

Однако существует другой более гибкий способ управления предоставлением полномочий. Мастер позволяет делегировать полномочия как отдельным пользователям, так и группам. Наиболее удобным и оптимальным вариантом делегирования является применение групп безопасности. Это дает возможность управлять процессом делегирования управления через членство пользователей в выбранной группе. В этом случае для отзыва полномочий достаточно отозвать членство пользователя в группе.

Кэширование информации о составе групп с универсальной областью действия

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

Режим кэширования доступен только для контроллеров домена под управлением Windows Server 2003, не являющихся серверами глобального каталога.

Рис. 20.5. Активизация режима кэширования информации о составе универсальных групп

Чтобы активизировать процесс кэширования информации о составе универсальных групп, нужно открыть окно свойств объекта NTDS Site Settings (Настройки NTDS сайта), расположенного непосредственно внутри контейнера, ассоциированного с требуемым сайтом. В открывшемся окне (рис. 20.5) на вкладке Site Settings (Настройки сайта) необходимо установить флажок Enable Universal Group Membership Caching (Включить кэширование информации о составе универсальных групп). При этом в раскрывающемся списке Refresh cache from (Обновлять кэш из) следует выбрать сайт, к которому будут осуществляться обращения для обновления содержимого кэша.

Настройка команды поиска на клиентском компьютере

Напомним, что механизмы доступа к службе каталога реализованы только в составе операционных систем Windows 2000/XP и Windows Server 2003. Операционные системы Windows 9x/ME/NT также могут взаимодействовать со службой каталога, однако для этого необходимо установить на компьютере службу клиента Active Directory (DSClient). Служба клиента поставляется в составе дистрибутивного диска Windows Server 2003.

Ярлык для операций поиска может быть добавлен на рабочий стол или в любую папку файловой системы. Для этого необходимо вызвать контекстное меню родительского объекта и в нем выбрать команду New | Shortcut (Создать | Ярлык). В поле Type the location of the item (Укажите местоположение объекта) необходимо ввести строку: rundll32.exe dsquery,OpenQueryWindow

В следующем окне дайте ярлыку имя и нажмите кнопку Finish (Готово). При необходимости созданный ярлык можно переместить в некоторую папку или меню. Теперь этот ярлык может использоваться для вызова окна поиска объектов в каталоге. Из этого окна можно выполнять поиск пользователей, контактов, групп, принтеров, подразделений и т. д. Область поиска ресурсов может варьироваться от конкретного контейнера (подразделения) до целого домена или всего леса доменов. Выбор параметра Entire Directory (Вся папка) эквивалентен поиску в Глобальном каталоге.

Определение владельцев ролей FSMO

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

 Оснастка Active Directory Users and Computers отображает информацию о владельцах ролей, к которым предъявляются требования уникальности в пределах домена (владелец инфраструктуры каталога, идентификаторов и эмулятора PDC). Для получения информации о текущем владельце той или иной роли необходимо выбрать в контекстном меню объекта, ассоциированного с интересующим доменом, команду Operations Master (Владелец операций). В соответствующем окне на трех вкладках будет выведена информация о существующих владельцах. Текущий владелец роли отображается в поле Operations master.

 Оснастка Active Directory Domains and Trusts может быть использована для получения информации о владельце доменных имен (Domain Naming master). Для получения информации о текущем владельце необходимо выбрать в контекстном меню объекта, расположенного в корне пространства имен оснастки, команду Operations Master (Владелец операций). Текущий владелец роли доменных имен отображается в поле Domain naming operations master.

 Оснастка Active Directory Schema позволяет получить информацию о владельце схемы. Эта оснастка должна быть загружена администратором в консоль ММС вручную. Для получения информации о текущем владельце схемы необходимо выбрать в контекстном меню объекта, ассоциированного с загруженной оснасткой, команду Operations Master (Владелец операций). Текущий владелец роли отображается в открывшемся окне в поле Current schema master.

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

Оснастка Active Directory Domains and Trusts

Оснастка Active Directory Domains and Trusts позволяет осуществлять управление структурой леса домена и, в первую очередь, ориентирована на администратора уровня предприятия. Эта оснастка позволяет просмотреть лес доменов и выбрать некоторый домен для администрирования, а также управлять доверительными отношениями между доменами и лесами. На рис. 20.6 показан пример оснастки Active Directory Domains and Trusts, в которой отображается структура леса доменов, состоящего из двух деревьев (с корневыми доменами khsu. ru и khsu. khakasnet. ru).

Рис. 20.6. Оснастка Active Directory Domains and Trusts

Чтобы перейти к администрированию домена, необходимо в его контекстном меню выбрать команду Manage (Управление). При этом для выбранного домена будет запущена оснастка Active Directory Users and Computer.

Использование оснастки Active Directory Domains and Trusts для создания доверительных отношений рассматривалось в разд. "Управление доверительными отношениями" предыдущей главы.

Оснастка Active Directory Sites and Services

Оснастка Active Directory Sites and Services представляет собой основной инструмент с графическим интерфейсом, посредством которого администратор может управлять физической структурой Active Directory — подсетями, сайтами и соединениями; другие же административные оснастки представляют Active Directory на логическом уровне как единое целое. Оснастка Active Directory Sites and Services является одним из основных средств администрирования Active Directory в том случае, когда корпоративная сеть реализована в виде нескольких сайтов. В случае, если механизм сайтов не используется при построении службы каталога (т. е. сайт только один — созданный по умолчанию), данная оснастка, скорее всего, останется невостребованной.

Оснастка Active Directory Sites and Services позволяет выполнять следующие операции:

 изменение топологии репликации в лесе доменов (создание/удаление сайтов, подсетей и соединений);

 определение стоимости для соединений (cost);

 изменение расписаний и интервалов для репликации внутри сайта и между сайтами;

 определение мостовых серверов (bridgehead server);

 инициация процесса репликации внутри сайта и между сайтами;

 запуск сервиса Knowledge Consistency Checker (KCC) для регенерации топологии репликации;

 делегирование пользователям или группам прав на управление сайтами, подсетями, серверами и другими контейнерами в разделе конфигурации;

 настройка параметров безопасности и аудита для различных объектов, определяющих топологию репликации;

 выбор объектов GPO, привязка объектов GPO к сайтам и запуск оснастки Group Policy Object Editor для редактирования объектов GPO;

 назначение контроллерам домена роли сервера глобального каталога;

 назначение политик запросов LDAP.

На рис. 20.4 показан пример окна оснастки Active Directory Sites and Services. В приведенном примере представлены практически все основные элементы сетевой топологии Active Directory: сайты, подсети, межсайтовые соединения, соединения между контроллерами домена в рамках сайта, а также непосредственно сами контроллеры домена.

Рис. 20.4. Пример окна оснастки Active Directory Sites and Services

Стандартным инструментом управления процессом репликации изменений каталога является оснастка Active Directory Sites and Services. При помощи этой оснастки администратор может инициировать процесс репликации изменений для всех разделов каталога от отдельного партнера по репликации. Следует обратить особое внимание на то, что реплицируются все разделы каталога. Нельзя инициировать процедуру репликации только для одного раздела каталога.

Для инициации процесса репликации изменений выберите целевой контроллер в контейнере Servers (Серверы) соответствующего сайта и откройте объект NTDS Settings (Параметры NT Directory Service). Можно запросить репликацию у любого контроллера домена, соединение с которым присутствует в правом окне в виде объекта класса Connection. Для этого вызовите контекстное меню нужного соединения и выберите команду Replicate Now (Реплицировать немедленно). В зависимости от пропускной способности коммуникационных линий, соединяющих контроллеры домена, и объема имеющихся изменений может потребоваться некоторое время для выполнения процедуры репликации. В случае успешной репликации всех изменений будет выведено сообщение "Active Directory has replicated the connections" (Active Directory произвела репликацию подключений).

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

Оснастка Active Directory Users and Computers

Оснастка Active Directory Users and Computers является основным инструментом, посредством которого администратор осуществляет управление содержимым доменных разделов каталога. Вот перечень лишь основных операций: создание, модификация и удаление объектов различного типа, привязка объектов групповых политик к контейнерам Active Directory, настройка прав доступа к объектам каталога, аудит. Знание возможностей этой оснастки позволяет повысить эффективность выполнения рутинных операций, особенно в случае, когда доменные разделы содержат большое количество объектов, что затрудняет их поиск и работу с ними.

В системах Windows Server 2003 оснастка Active Directory Users and Computers имеет насколько новых возможностей:

 одновременная работа с несколькими объектами каталога;

 операции, выполняемые с помощью мыши (например, перемещение объектов между контейнерами);

 хранимые запросы (saved queries).

Для выполнения операций с каталогом оснастка Active Directory Users and Computers должна быть подключена к некоторому контроллеру домена (которые выступают в качестве носителя копии разделов каталога). Оснастка может быть подключена только к одному контроллеру домена и, соответственно, к одному доменному разделу. По умолчанию оснастка подключается к контроллеру домена, в котором зарегистрировался текущий пользователь. Администратор может подключить оснастку к любому другому контроллеру домена, а также к другому домену при условии наличия у него соответствующих прав.

Основное и неавторитетное восстановление

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

 жесткий диск не должен быть меньшего объема, чем вышедший из строя;

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

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

Объекты, выбранные пользователем для удаления, не удаляются из каталога сразу. Они помечаются службой каталога для удаления, и информация об этом реплицируется на все остальные контроллеры домена. Только через некоторый промежуток времени, называемый временем жизни объекта, помеченного для удаления, объект будет реально удален из каталога. По умолчанию время жизни объектов, помеченных для удаления, составляет 60 дней (минимальное значение — 2 дня). Эта величина хранится в атрибуте tombstoneLifetime объекта c именем CN=Directory Service, CN=Windows NT, CN=Service, CN=Configuration, DC=<ForestRootDomain>. Для восстановления каталога запрещается использовать резервные копии старше, чем значение времени жизни объектов, помеченных для удаления.

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

Запустите утилиту Backup и перейдите на вкладку Restore. Выберите из списка необходимую резервную копию и установите в ней флажок System State. Выберите из списка Restore files to (Восстанавливать файлы в) значение Original location (Исходное расположение). Нажмите кнопку Start Restore и выберите опцию Advanced в окне Confirm Restore (Подтверждение восстановления). Для выполнения основного восстановления необходимо установить флажки, как показано на рис. 20.11. Если выполняется неавторитетное восстановление, необходимо снять флажок When restoring replicated data sets, mark the restored data as the primary data for all replicas. Закройте окно и начните процесс восстановления.

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

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

После того как резервная копия состояния системы загружена, необходимо выполнить перезагрузку системы. Однако до того как будет выполнена перезагрузка, администратор может проверить успешность выполнения операции восстановления каталога. Показателем успешности служит наличие в реестре параметра RestoreinProgress в ключе реестра HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlset\Services\NTDS. Этот параметр используется системой для обнаружения факта восстановления каталога и используется для инициации процесса обновления соответствующих системных файлов.



Рис. 20.11. Выполнение основного восстановления

Основные оснастки для администрирования Active Directory

После того как на базе некоторого сервера под управлением Windows Server 2003 создан контроллер домена, в группе Administrative Tools (Администрирование) на панели управления появляются новые инструменты (табл. 20.1).

Перечисленные в табл. 20.1 оснастки входят в состав пакета Windows Server 2003 Administrative Tools. Они могут быть установлены на любом компьютере под управлением Windows XP или Windows Server 2003, входящем в состав леса доменов. В этом случае оснастки Security Policy (Политики безопасности) не появляются в меню Start (Пуск).

Таблица 20.1. Стандартные средства администрирования Active Directory

Оснастки		Назначение
Active Directory Domains and Trusts (Active Directory — домены и доверия)		Выбор администрируемого домена в больших лесах. Просмотр режима работы домена. Создание, проверка и удаление доверительных отношений между доменами
Active Directory Sites and Services (Active Directory — сайты и службы)		Создание и изменение сайтов, транспортов и подсетей. Настройка расписаний репликации и связей (links). Запуск репликации между контроллерами домена. Установка разрешений на объекты. Привязка объектов групповой политики (GPO) к сайтам. Запуск серверов глобального каталога на контроллерах домена
Active Directory Users and Computers (Active Directory — пользователи и компьютеры)		Создание и изменение объектов каталога (пользователей, групп, подразделений и т. д.). Установка разрешений на объекты. Привязка объектов групповой политики (GPO) к доменам и подразделениям (OU). Управление специализированными ролями (FSMO)
Domain Controller Security Policy (Политика безопасности контроллера домена)		Модификация узла Security Settings (Параметры безопасности) объекта групповой политики, привязанного к подразделению Domain Controllers. Для редактирования всего GPO используйте оснастку Group Policy Object Editor
Domain Security Policy (Политика безопасности домена)		Модификация узла Security Settings объекта групповой политики, привязанного к контейнеру домена. Для редактирования всего GPO используйте оснастку Group Policy Object Editor
Group Policy Object Editor (Редактор объекта групповой политики)		Модификация объекта групповой политики, привязанного к некоторому контейнеру Active Directory (сайту, домену, подразделению) или хранящегося локально на компьютере. Эта оснастка не отображается в меню Start (Пуск), однако она доступна из других административных оснасток или может быть добавлена к пользовательской консоли ММС

<
/p> Некоторые дополнительные инструменты (табл. 20.2) для администрирования Active Directory поставляются в составе пакета Windows Server 2003 Support Tools. Эти инструменты незаменимы в некоторых случаях для тонкой настройки и мониторинга Active Directory.

Таблица 20.2. Дополнительные средства администрирования Active Directory (из пакета Windows Server 2003 Support Tools)

Утилита	Описание
ADSI Edit (AdsiEdit.msc)	"Низкоуровневое" редактирование объектов Active Directory, расположенных в любом разделе каталога (раздел доменных имен, разделы конфигурации и схемы). Посредством утилиты можно также получить информацию об объекте RootDSE. Администратор может использовать утилиту для установки разрешений на доступ к объектам
Active Directory Administration Tool (Ldp.exe)	Утилита может использоваться для поиска и модификации объектов Active Directory при помощи запросов LDAP
Active Directory Replication Monitor (ReplNon.exe)	Утилита может использоваться для мониторинга состояния репликации и существующей топологии репликации. Утилита позволяет инициировать процесс репликации. Кроме того, утилита может быть использована для получения информации об исполнителях специализированных ролей и статусе контроллеров домена

Передача и захват ролей FSMO

Если в рамках леса доменов имеется несколько контроллеров домена, обязанности исполнения специализированной роли могут быть перенесены с одного контроллера домена на другой. Процедура передачи роли требует, чтобы в оперативном режиме находились контроллеры домена, выступающие в качестве текущего и будущего исполнителя. В этом случае передача роли может быть осуществлена при помощи стандартных оснасток (таких, например, как Active Directory Users and Computers).

В случае, если необходимо передать роль другому контроллеру домена при недоступном текущем исполнителе, следует прибегнуть к захвату роли. Захват роли осуществляется при помощи утилиты NtdsUtil.exe.

Передача роли владельца доменных имен

Передача роли владельца доменных имен осуществляется при помощи оснастки Active Directory Domains and Trusts. Подключите оснастку к контроллеру домена, который выбран в качестве нового исполнителя роли. В контекстном меню корневого объекта пространства имен утилиты выберите команду Operations Masters (Владелец операций). Чтобы изменить исполнителя роли в открывшемся окне, щелкните по кнопке Change (Изменить). Помните о том, что только один контроллер в лесу доменов может исполнять роль владельца доменных имен. При этом данный контроллер домена должен также выполнять функции сервера глобального каталога.

Передача роли владельца операций RID, PDC и Infrastructure

Процедура передачи ролей, требующих уникальности исполнителя в пределах домена, происходит следующим образом. Подключите оснастку Active Directory Users and Computers к контроллеру домена, который выбран в качестве нового исполнителя роли. В контекстном меню корневого объекта пространства имен утилиты выберите команду Operations Masters (Владелец операций). В открывшемся окне необходимо перейти на требуемую вкладку: RID, PDC или Infrastructure. Чтобы изменить исполнителя роли, щелкните по кнопке Change (Изменить).

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

Передача роли владельца схемы

Передача роли владельца схемы осуществляется при помощи оснастки Active Directory Schema. Подключите оснастку к контроллеру домена, который выбран в качестве нового исполнителя роли. В контекстном меню корневого объекта пространства имен утилиты выберите команду Operations Masters (Владелец операций). Чтобы изменить владельца роли в открывшемся окне, щелкните по кнопке Change (Изменить). Помните о том, что только один контроллер в лесу доменов может быть владельцем схемы.

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

Поиск объектов в каталоге

Служба каталога используется клиентами для обнаружения сетевых ресурсов, точное местоположение которых зачастую неизвестно. Для поиска объектов в каталоге Active Directory клиенты могут использовать перечисленные ниже инструменты (некоторые из которых доступны клиентам любого типа,. включая клиентов нижнего уровня, а некоторые могут работать только в системах Windows 2000/XP и Windows Server 2003).

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

 Утилиты командной строки DsQuery.exe и DsGet.exe, входящие в состав Windows Server 2003, представляют собой стандартный инструмент, посредством которого администратор может обращаться с запросами к каталогу.

 Оснастка ADSI Edit. С помощью этого инструмента, входящего в состав пакета Windows Server 2003 Support Tools, администратор может формировать запросы с целью поиска в каталоге необходимых объектов. Данная утилита позволяет также модифицировать найденные объекты независимо от того, к какому разделу каталога они принадлежат.

 Сценарий Search.vbs' — самое простое средство для выполнения запросов, использующее протокол LDAP. Сценарий входит в состав пакета Windows Server 2003 Support Tools.

 Утилита Active Directory Administration Tool (Ldp.exe), входящая в состав пакета Windows Server 2003 Support Tools, представляет собой сложный административный инструмент, позволяющий просматривать дерево каталога и модифицировать объекты. Утилита использует протокол LDAP для доступа к каталогу и является единственным средством, позволяющим получить доступ к удаленным объектам.

При работе с большинством из перечисленных инструментов требуется хорошее знание синтаксиса фильтров LDAP. Только в этом случае вы сможете быстро и точно выбирать нужные объекты.

Публикация папок и принтеров

Служба Active Directory значительно упрощает работу с общими сетевыми ресурсами по сравнению с традиционными методами просмотра доменов. Информация о любом ресурсе может быть опубликована (published) в каталоге Active Directory. Публикация папки или принтера в Active Directory подразумевает под собой создание в каталоге нового объекта — Shared Folder (Общая папка) или Printer (Принтер) соответственно.

В этом случае пользователи могут использовать службу каталога для поиска ресурсов (например, с помощью команды Search | For Printers в меню Start). Место публикации ресурсов определяется существующей структурой каталога. Если в домене существуют организационные единицы, созданные для объединения ресурсов, то каждый тип ресурса будет располагаться в отдельной организационной единице. Если же организационные единицы создавались для реализации административной иерархии, ресурсы будут размещаться в контейнерах в зависимости от их принадлежности к некоторому структурному подразделению корпорации.

В процессе создания в каталоге объекта, ассоциированного с общей папкой, администратор может указать ключевые слова, которые характеризуют содержимое папки. Эти ключевые слова могут быть использованы для поиска в каталоге необходимой общей папки на основании ее характеристик. Если пользователь выполняет в каталоге поиск общих папок, он может указать некоторые ключевые слова и найти ресурсы по их содержимому, а не по их именам. Чтобы задать ключевые слова в пространстве имен утилиты Active Directory Users and Computers, выберите объект, ассоциированный с общей папкой, и вызовите окно свойств объекта. В открывшемся окне щелкните на кнопке Keywords (Ключевые слова). Надо будет добавить в список слова, логически связанные с содержимым папки.

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

Принтеры, подключенные к компьютерам, под управлением Windows 2000/ХР или Windows Server 2003, могут быть опубликованы только из окна свойств принтера. Для этого на вкладке Sharing (Доступ) необходимо установить флажок List in the Directory (Отображать в каталоге).

Процессом публикации и удаления (pruning) принтеров в домене администратор может управлять при помощи механизма групповых политик. Соответствующий объект находится в узле Computer Configuration | Administrative Templates | Printers пространства имен оснастки Group Policy Object Editor.

Работа с множеством объектов

В системах Windows Server 2003 оснастка Active Directory Users and Computers предоставляет пользователю возможность манипуляции множеством объектов. Другими словами, пользователь может задействовать в некоторой операции сразу несколько объектов. Для большинства классов объектов (группы, компьютеры, подразделения и т. п.) единственной доступной групповой операцией является изменение описания. В случае объектов, ассоциированных с учетными записями пользователей, имеется порядка 30 атрибутов, которые допускается изменять сразу для множества объектов.

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

Выделение множества объектов осуществляется стандартным для интерфейса Windows способом — при помощи клавиш <Ctrl> и <Shift>. Выделив объекты, щелкните правой кнопкой мыши, чтобы вызвать контекстное меню. Для изменения атрибутов выбранных объектов в контекстном меню выберите пункт Properties (Свойства). Это приведет к открытию модифицированного окна свойств для выбранного класса объектов. Применительно к объектам, ассоциированным с учетными записями пользователей, окно свойств показано на рис. 20.3.

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

Replication Diagnostics Tool (RepAdmin.exe)

При помощи утилиты командной строки Replication Diagnostics Tool (RepAdmin.exe) администратор может осуществлять репликацию изменений на уровне отдельных разделов каталога. При этом администратор может включать в процесс репликации как один сервер-источник, так и все источники. Применительно к процессу управления репликацией, утилита может быть запущена в одном из двух режимов:

 запрос репликации изменений определенного раздела каталога со всех серверов-источников, выступающих в качестве партнеров по репликации;

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

В первом случае необходимо использовать следующий формат утилиты:  repadmin /syncall <целевой_сервер> [<раздел_каталога>] [<флаги>]

В этом случае выполняется репликация только одного раздела, однако от всех источников-партнеров по репликации. Флаги позволяют задать параметры репликации. Например, чтобы инициировать репликацию изменений доменного раздела khsu.ru на контроллер домена store со всех источников-партнеров, необходимо воспользоваться следующей командой: repadmin /syncall store.khsu.ru DC=khsv., DC=ru

Следует помнить о том, что команда repadmin /syncall позволяет выполнить репликацию только одного раздела каталога. Однако достаточно часто возникает необходимость синхронизировать все разделы каталога. Для этого используется специальный флаг /А. Ниже приводится пример синхронизации всех разделов каталога для контроллера домена store. repadmin /syncall store.khsu.ru /А

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

Для выполнения репликации некоторого раздела каталога от одного конкретного партнера используется другой формат утилиты:  repadmin /sync <раздел_каталога> <целевой_сервер> <сервер_источник> [<флаги>]

Сервер-источник задается посредством глобально уникального идентификатора (GUID). Например, для репликации изменений доменного раздела khsu.ru на контроллер домена store с контроллера домена root (имеющего GUID 337e47bb-3902-4a8f-9666-fe736ddc0b7c) необходимо воспользоваться следующей командой:  repadmin /sync DC=khsu, DC=ru store.khsu.ru 337e47bb-3902-4a8f-9666-fe736ddc0b7c

Резервирование и восстановление Active Directory

Для выполнения операций резервного копирования в составе операционной системы Windows Server 2003 Server поставляется утилита Backup. С ее помощью можно резервировать и восстанавливать многие системные данные, в том числе файлы базы данных Active Directory. Использование этой утилиты подробно рассматривается в главе 23 "Восстановление системы", здесь мы коснемся лишь специфики работы с Active Directory.

Важно понимать, что резервная копия состояния системы (System State) содержит параметры, характеризующие конкретный контроллер домена. Как следствие, вы не можете использовать резервную копию состояния системы одного контроллера домена для восстановления другого контроллера домена. В этом случае вы получите два абсолютно идентичных контроллера домена, что приведет к возникновению конфликтов (начиная с идентичных настроек стека протоколов TCP/IP и заканчивая GUID DSA).

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

Режим Saved Queries (Сохраненные запросы)

Благодаря этому режиму администратор имеет возможность сохранять предварительно созданные LDAP-запросы. Впоследствии администратор может использовать сохраненные запросы для быстрого поиска требуемых объектов. Сохраненные запросы избавляют администратора от необходимости многократного определения однотипных фильтров при формировании LDAP-запросов.

Оснастка позволяет организовать сохраненные запросы в некую иерархическую структуру в соответствии с предпочтениями администратора. Данная структура формируется внутри контейнера Saved Query оснастки. В рамках этого контейнера могут размещаться как непосредственно сохраненные запросы, так и контейнеры, используемые для их логической организации.

Чтобы создать сохраненный запрос, в контекстном меню контейнера выберите команду New | Query (Создать | Запрос). В открывшемся окне (рис. 20.1) необходимо дать имя создаваемому запросу и краткое описание. Параметр Query root (Корень запроса) задает область поиска. По умолчанию запрос охватывает домен целиком. При необходимости администратор может ограничить область поиска некоторым подразделением. Если требуется, чтобы поиск осуществлялся и во вложенных контейнерах, администратор должен установить флажок Include subcontainers (Включая вложенные контейнеры). Чтобы сформировать LDAP-запрос, нужно щелкнуть по кнопке Define Query (Определить запрос) и выбрать объекты и критерии поиска.

В конечном итоге, администратор может сформировать некоторую произвольную иерархию запросов (рис. 20.2). Для логической организации запросов можно использовать контейнеры. Чтобы создать контейнер, в контекстном меню корневого контейнера выбрать New | Container (Создать | Контейнер).

Сохраненные запросы хранятся не в виде объектов каталога, а в виде атрибутов оснастки. Таким образом, запросы сохраняются вместе с другими настройками оснастки. По умолчанию настройки административных оснасток размещаются в XML-файле в папке Documents and settings \ <имя_пользователя>\Аррliсаtion Data\Microsoft\MMC. Если администратор будет запускать оснастки с различных контроллеров домена, запросы будут сохранены только для одного из экземпляров оснастки. В этой ситуации оптимальным решением будет размещение всех административных оснасток в перемещаемом профиле пользователя. При этом одни и те же настройки оснастки будут использоваться администратором независимо от того, на каком контроллере домена он их запускает.

Рис. 20.1. Создание сохраненного запроса

Рис. 20.2. Структура сохраненных запросов

Существующие сохраненные запросы могут быть экспортированы в XML-файлы. Эти файлы могут быть переданы другим пользователям или администраторам для последующего использования (при этом они должны импортировать запросы в свои экземпляры оснасток). Для экспорта запроса необходимо в его контекстном меню выбрать пункт Export Query Definition (Экспортировать определение запроса).

Создание резервной копии Active Directory

Подсистема резервного копирования Windows Server 2003 позволяет создавать резервные копии различных типов (нормальную, дублирующую, добавочную, разностную и ежедневную). Однако применительно к резервной копии, отражающей состояние системы, речь может идти только о нормальном резервном копировании (normal backup).

Для создания резервной копии состояния системы запустите утилиту Backup, выполнив команду Start | Programs | Accessories | System Tools | Backup.

Утилита Backup предлагает администратору два способа создания резервной копии.

 Использование мастера Backup Wizard. Этот способ является наиболее удобным, поскольку упрощает процедуру резервного копирования.

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

Рассмотрим процесс создания резервной копии вручную. Процесс сохранения данных Active Directory сводится к резервированию состояния системы на контроллере домена. Перейдите на вкладку Backup и установите флажок System State в окне структуры. При необходимости можно также включить в создаваемую резервную копию ряд дополнительных файлов. В списке Backup Destination выберите тип носителя архива. Если выбран режим создания резервной копии на жестком диске, в поле Backup media or file name необходимо будет указать имя файла. Затем нажмите кнопку Start Backup, и процесс архивации начнется. Напомним, что полученный архив можно использовать для установки контроллера домена из резервной копии (см. главу 19 "Проектирование доменов и развертывание Active Directory").

В системах Windows Server 2003

В системах Windows Server 2003 имеется набор эффективных утилит, позволяющих выполнять многие операции с объектами Active Directory из командной строки или из командных файлов. Все эти утилиты используют протокол LDAP и могут работать с любыми доменами на базе Active Directory (Windows 2000 и Windows Server 2003). При этом запускаться они могут только на компьютерах под управлением Windows XP или Windows Server 2003.

 DsAdd — позволяет создать объект заданного типа: computer, contact, group, OU, user или quota.

 DsQuery и DsGet — служат для поиска объектов каталога любого типа или с указанным типом. Утилита Dsget.exe позволяет отображать атрибуты объектов указанного типа. Например, для поиска всех пользователей домена можно использовать команду dsquery user.

 DsMod — позволяет изменять атрибуты объектов указанного типа: computer, contact, group, OU, server или user.

 DsMove — позволяет переименовать или переместить объект любого типа.

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

Управление объектами каталога

В распоряжении администратора имеется множество инструментов, посредством которых он может создавать или удалять объекты Active Directory, a также изменять их атрибуты. Некоторые из этих инструментов позволяют управлять отдельными объектами, другие позволяют управлять группами объектов (так называемый пакетный режим). Многие задачи могут быть выполнены любым из этих инструментов. Ниже перечислены все основные средства управления каталогом Active Directory, предоставляемые системами Windows Server 2003.

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

 оснастка Active Directory Users and Computers позволяет работать с пользователями, контактами, группами, компьютерами, пользователями из внешних служб каталога, принтерами, общими папками и организационными единицами;

 оснастка Active Directory Sites and Services предназначена для манипулирования сайтами, подсетями, связями и соединениями;

 оснастка Active Directory Domains and Trusts позволяет осуществлять управление доверительными отношениями между доменами.

 Специализированные оснастки — утилиты с графическим интерфейсом, используемые для выполнения специальных операций либо для точной настройки и отладки Active Directory:

 оснастка Active Directory Schema позволяет осуществлять управление содержимым схемы, создавать новые классы атрибутов и объектов. Эта утилита не создается по умолчанию. Администратор должен создать ее самостоятельно, загрузив соответствующую оснастку в пустую консоль ММС;

 оснастка ADSI Edit, утилиты Ldp.exe и AdsVw.exe. Эти утилиты позволяют редактировать отдельные атрибуты существующих объектов. Однако они могут быть использованы также для создания объектов любого типа (включая те, которые невозможно создать при помощи стандартных инструментов).

 Утилиты LDIFDE и CSVDE — утилиты командной строки, предназначенные для выполнения операций импорта/экспорта объектов каталога. Эти утилиты могут быть использованы как средство повышения эффективности администрирования крупномасштабных инсталляций Active Directory. Утилиту LDIFDE можно также применять для изменения атрибутов множества однотипных объектов.

 Специальные сценарии и утилиты, позволяющие выполнять специфические задачи:

 утилиты DsAdd.exe и AddUsers.exe, сценарии CreateUsers.vbs, CreateGroups.vbs и другие специализированные утилиты командной строки (например, утилиту NetDom.exe можно использовать для создания учетных записей компьютеров домена);

 сценарии ADSI (Active Directory Service Interfaces) — самый гибкий и довольно простой способ манипулирования объектами Active Directory. Эти сценарии используют программный интерфейс ADSI для доступа к каталогу.

Управление процессом репликации

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

 оснастка Active Directory Sites and Services;

 утилита командной строки Replication Diagnostics Tool (RepAdmin.exe);

 утилита Active Directory Replication Monitor (ReplMon.exe).

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

 между некоторой парой контроллеров домена;

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

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

Управление ролями FSMO

Выполнение ряда операций в доменах на базе Active Directory требует уникальности их исполнителя. Контроллеры домена, на которых возложена обязанность выполнения указанных операций, называют исполнителями специализированных ролей — Flexible Single-Master Operations (FSMO). В данном разделе разговор пойдет о процессе управления ролями FSMO, a также о методике получения информации об их владельцах (хозяевах).

Восстановление Active Directory

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

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

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

В данном разделе речь пойдет о восстановлении из резервной копии. При этом у администратора имеется три различных сценария восстановления состояния системы:

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

 если в домене остался хотя бы один контроллер домена, можно выполнить неавторитетное восстановление (non-authoritative restore). При этом база данных каталога будет приведена в состояние, в котором каталог находился на момент создания резервной копии. Восстановленный контроллер получит актуальные данные об изменениях, произошедших в каталоге с момента создания данной резервной копии, в процессе репликации Active Directory с других контроллеров домена. К неавторитетному восстановлению целостности каталога прибегают в случае возникновения неисправностей, вызванных нарушениями в работе компьютера. Этот тип восстановления используется чаще всего;

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

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

Восстановление содержимого системного тома SYSVOL

В ряде ситуаций может потребоваться восстановить содержимое системного тома SYSVOL. В качестве примера можно привести ситуацию, когда удаляется группа объектов групповой политики. Информация о групповой политике хранится как в виде объектов каталога, так и в виде файлов в составе системного тома SYSVOL. Поэтому восстановление только объектов каталога не приведет к полному восстановлению объектов групповой политики. Необходимо также восстановить содержимое системного тома SYSVOL.

По окончании процедуры авторитетного восстановления следует перезагрузить контроллер домена в нормальном режиме и дождаться момента публикации тома SYSVOL. Обнаружить момент публикации можно при помощи команды net share.

Скопируйте содержимое тома SYSVOL из альтернативной папки в его рабочую папку (по умолчанию %SystemRoot%\SYSVOL\sysvo\). Изменение состояния тома SYSVOL вызовет репликацию тома на остальные контроллеры домена.

Захват ролей

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

Ниже приводится пример использования утилиты NtdsUtil для захвата всех специализированных ролей контроллером домена store.khsu.ru (полужирным выделены команды, вводимые администратором):

C:\ntdsutil

ntdsutil: roles

fsmo maintenance: connection

server connections: connect to server store.khsu.ru

Binding to store.khsu.ru...

Connected to store.khsu.ru using credentials of locally logged on user

server connection: quit

fsmo maintenance seize schema master

fsmo maintenance seize domain naming master

fsmo maintenance seize PDC

fsmo maintenance seize RID master

fsmo maintenance seize infrastructure master

fsmo maintenance quit

ntdsutil: quit

Disconnecting from store.khsu.ru...

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

---

---