Методологический подход к проектированию и внедрению единой службы каталогов Microsoft Active Directory. Чижиков Дмитрий :: статьи

Введение

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

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

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

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

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

Определение

Active Directory (AD) – служба каталогов, поставляемая с Microsoft Windows, начиная с Windows 2000 Server. Active Directory содержит каталог, в котором хранится информация о сетевых ресурсах, и службы, предоставляющие доступ к этой информации.

Active Directory обеспечивает:

• упрощенное администрирование;
• масштабируемость;
• поддержку открытых стандартов;
• поддержку стандартных форматов имен.

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

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

Назначение

Функции Active Directory:

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

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

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

Преимущества

Служба каталогов Active Directory является службой, интегрированной с MS Windows, начиная с Windows 2000 Server. Active Directory обеспечивает иерархическую структуру построения организации, наращиваемость и расширяемость, а также функции распределенной безопасности. Эта служба позволяет использовать простые и интуитивно понятные имена объектов, которые в ней содержатся, при этом доступ к ней может быть осуществлен с помощью таких инструментов, как программа просмотра ресурсов Интернет.

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

К преимуществам интеграции управления учетными записями со службой каталогов Active Directory относятся:

• Учетные записи пользователей, групп и машин могут быть организованы в виде контейнеров каталога, называемых организационными подразделениями или просто подразделениями. В домене может быть произвольное число подразделений, организованных в виде древовидного пространства имен. Это пространство имен может быть организовано в соответствии с подразделениями и отделами в организации. Также как и организационные подразделения, учетные записи пользователей являются объектами каталога и могут быть легко переименованы внутри дерева доменов при перемещении пользователей из одного отдела в другой.
• В каталоге Active Directory поддерживается большое число объектов: размер одного домена не ограничивается производительностью сервера, хранящего учетные записи. Дерево связанных между собой доменов может поддерживать большие и сложные организационные структуры.
• Администрирование учетной информации расширено за счет использования графических средств управления Active Directory, а также за счет поддержки OLE в языках сценариев. Общие задачи могут быть реализованы в виде сценариев, позволяющих автоматизировать администрирование.
• Служба тиражирования каталогов позволяет иметь несколько копий учетной информации, причем обновления этой информации могут выполняться в любой копии, а не только на выделенных первичных контроллерах домена. Протокол LDAP и синхронизация каталогов позволяют обеспечивать механизмы связи каталога Windows с другими каталогами на предприятии.
• Хранение учетной информации в Active Directory означает, что пользователи и группы представлены в виде объектов каталога. Права на чтение и запись могут быть предоставлены как по отношению ко всему объекту целиком, так и по отношению к отдельным его свойствам. Администраторы могут точно определять, кто именно может модифицировать информацию о пользователях, и какую именно. Например, оператору телефонной службы может быть разрешено изменять информацию о телефонных номерах пользователей, но при этом он не будет обладать привилегиями системного оператора или администратора.

Проектирование и планирование Active Directory

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

Сбор и анализ информации

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

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

Проектирование структуры Active Directory

Проектирование структуры Active Directory:

• Планирование лесов:

·        Определение типовых лесов для основных типов региональных представительств.

·        Определение основных типов доверительных отношений между разными лесами.

·        Разработка политики контроля изменений леса.

·        Политика изменения схемы.

·        Политика изменения конфигурации.

·        Разработка структуры DNS для типовых лесов.

• Планирование доменов для каждого леса:

·        Реструктуризация существующих доменов на домены в зависимости от административных потребностей.

·        Разбиение на домены в зависимости от физического месторасположения для оптимизации трафика репликации и запросов.

·        Выбор корневого домена для каждого леса.

·        Оптимизация аутентификации укороченными доверительными отношениями.

• Планирование использования сайтов для каждого леса:

·        Определение сайтов на основании физической топологии сети.

·        Создание связей между сайтами.

·        План размещение серверов глобального каталога в сайтах.

·        План размещение серверов DNS в сайтах.

• Планирование структуры организационных единиц для каждого домена:

·        Планирование реорганизации существующих доменов в организационных единицах.

·        Планирование организационных единиц для делегирования административных полномочий.

·        Планирование организационных единиц для скрытия объектов.

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

• Планирование реорганизации существующих доменов и их перевод на новую платформу Active Directory:

·        Планирование перемещения пользователей, компьютеров и групп.

·        Планирование модификации или удаления из структуры реструктуризируемых доменов.

·        Планирование изменения существующих доверительных отношений.

·        Планирование клонирования объектов безопасности.

• Тестирование внедряемых решений и установка стенда:

·        Определение возможностей и целей тестирования.

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

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

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

Архитектура Active Directory

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

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

Компонентами физической структуры Active Directory являются сайты, тогда как компонентами логической структуры являются домены:

• Сайт – комбинация одной или более IP-подсетей, которые должны быть соединены высокоскоростным каналом связи.
• Домен – объединение серверов и других сетевых ресурсов, собранных под одним именем.

Схема объектов

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

Объект – это отдельный именованный набор атрибутов, которыми представлен сетевой ресурс. Атрибуты объекта являются его характеристиками в каталоге.

Рисунок 1. Схема объектов Active Directory и их атрибуты

Функциональная структура

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

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

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

Рисунок 2. Многоуровневая архитектура Active Directory

Основные компоненты служб:

• Системный агент каталога (Directory System Agent, DSA). Выстраивает иерархию родительско-дочерних отношений, хранящихся в каталоге. Предоставляет API-интерфейсы для вызовов доступа к каталогу. Клиенты получают доступ к Active Directory, используя механизмы, поддерживаемые DSA.
• Уровень БД. Предоставляет уровень абстрагирования между приложениями и БД. Вызовы из приложений никогда не выполняются напрямую к БД, а только через уровень БД.
• Расширяемое ядро хранения. Напрямую взаимодействует с конкретными записями в хранилище каталога на основе атрибута относительного составного имени объекта.
• Хранилище данных (файл БД NTDS.dit). Управляется при помощи расширяемого механизма хранения БД, расположенного на контроллере домена.
• LDAP/ADSI. Клиенты, поддерживающие LDAP, используют его для связи с DSA. Active Directory поддерживает LDAP версии 2. Клиенты Windows с установленными клиентскими компонентами Active Directory для связи с DSA используют LDAP версии 3. Хотя ADSI является средством абстрагирования API LDAP, Active Directory использует только LDAP.
• API-интерфейс обмена сообщениями (Messaging API, MAPI). Традиционные клиенты MAPI, например Microsoft Outlook, подключаются к DSA, используя интерфейс поставщика адресной книги MAPI RPC.
• Диспетчер учетных записей безопасности (Security Accounts Manager, SAM). Репликация с резервных контроллеров в домене смешанного режима также выполняется через интерфейс SAM.
• Репликация (REPL). При репликации каталога, агенты DSA взаимодействуют друг с другом, используя патентованный интерфейс RPC.

Логическая структура

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

На рисунке показаны взаимоотношения компонентов Active Directory.

Рисунок 3. Ресурсы, организованные в логическую иерархическую структуру

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

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

Примеры предоставления доступа к сетевым ресурсам:

• Пример «Единственный домен в центральном офисе». Предположим, что в компании имеется единственный домен в центральном офисе. Менеджерам компании для выполнения своих задач требуется доступ к инвентаризационной БД. Для предоставления доступа необходимо объединить всех менеджеров в глобальную группу, создать локальную доменную группу, обладающую полномочиями доступа к инвентарной базе, и добавить глобальную группу менеджеров в эту локальную доменную группу.
• Пример «Среда с несколькими доменами в регионах». Предположим, что в компании используется среда с тремя доменами. Корневой домен находится в центральном офисе, а другие домены – в регионах. Менеджерам из всех трех доменов для выполнения задач требуется доступ к расположенной в центральном офисе инвентаризационной БД. Для предоставления доступа необходимо:

·        в каждом домене создать глобальную группу и добавить учетные записи менеджеров в этом домене в эту глобальную группу,

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

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

·        добавить глобальные группы менеджеров из каждого домена в локальную доменную группу базы данных,

·        предоставить права доступа к инвентарной БД локальной доменной группе.

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

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

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

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

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

Деление на сайты не зависит от доменной (логической) структуры, то есть:

• В сайте может быть один домен (либо только его часть) или несколько доменов.
• В домене (или даже в организационном подразделении) может быть несколько сайтов.

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

• Структура с одним сайтом (единый сайт, включающий все ip-подсети).
• Структура с несколькими сайтами (отдельный сайт для каждой площадки).

Особенностями сайта являются:

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

Понятие сайта неразрывно связано с топологией тиражирования. Тиражирование внутри сайта и между сайтами использует различные топологии:

• Внутри сайта это двунаправленное кольцо. Тиражирование выполняется методом вызова удаленных процедур (remote procedure calls, RPC). Внутри сайта контроллер домена задерживает оповещение о сделанных изменениях на некоторый устанавливаемый промежуток времени.
• Для тиражирования между сайтами используется RPC или сообщения. Стандартно используется механизм SMTP, однако, если в сети есть Microsoft Exchange, то он также может быть задействован для тиражирования Active Directory.

Служба каталогов отслеживает целостность топологии: ни один контроллер домена не может быть исключен из процесса тиражирования, что обеспечивается отдельным контрольным процессом (Knowledge Consistency Checker, KCC), исполняемым на всех контроллерах домена – в случае нарушения топологии тиражирования она восстанавливается KCC.

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

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

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

Планирование развертывания Active Directory

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

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

Указанные действия позволяют учесть разветвленную структуру компании при развертывании единой инфраструктуры Active Directory.

План-график развертывания

Основные вехи в плане-графике развертывания Active Directory:

• Формирование проектной группы.
• Инициация проекта, согласования плана работ, ролей и ответственности.
• Обследование существующей ИТ-инфраструктуры:

·        Обследование существующей структуры Active Directory.

·        Обследование инфраструктуры (приложения, использующие Active Directory).

·        Формализация результатов обследования.

• Планирование структуры Active Directory:

·        Анализ требований заказчика к построению инфраструктуры Active Directory.

·        Планирование дерева и доменов.

·        Планирование топологии сайтов.

·        Разработка архитектуры PKI.

·        Планирование политики резервного копирования.

·        Планирование системы мониторинга на период опытной эксплуатации.

·        Формализация и разработка технического задания.

• Развертывание тестовой среды, тестирование миграции

·        Определение перечня приложений, подлежащих тестированию.

·        Определение аппаратной конфигурации тестового стенда.

·        Определение набора ресурсов Active Directory для миграции (для каждого приложения).

·        Развертывание репрезентативной копии боевой среды.

·        Верификация идентичности тестовой среды промышленной.

·        Развертывание спроектированной структуры Active Directory.

·        Проведение миграции.

·        Деинсталляция копии боевой среды.

·        Верификация корректности проведенной миграции.

·        Формирование проектной документации (типовая процедура миграции).

• Развертывание структуры Active Directory корневого домена и центрального офиса:

·        Информирование пользователей.

·        Развертывание спроектированной структуры Active Directory.

·        Проведение миграции.

·        Наблюдение в период адаптации.

·        Доработка типовой процедуры миграции по результатам развертывания.

·        Обучение администраторов.

• Тиражирование решения на филиалы организации.
• Доработка и сдача документации.

Модели построения лесов

Сравнительный анализ различных моделей построения лесов Active Directory:

• Вариант 1 «Единый лес, каждый регион – отдельное дерево». Существует отдельное дерево с корневым доменом, хранящим группы Enterprise Admins, Schema Admins, что позволит гибко контролировать членство в этих группах и исключить присутствие в них по умолчанию всех администраторов центрального офиса (группа Admins корневого домена входит в группы Enterprise Admins, Schema Admins). Разные деревья могут иметь различные пространства имен DNS. Корневые домены деревьев связаны транзитивными доверительными отношениями. Плюсы: пользователи могут просматривать ресурсы центрального офиса и регионов при соответствующих правах доступа к объектам Active Directory; возможность регистрации мобильных пользователей в любой точке организации; единый обмен в организации; повышенная защищенность (наличие аутентификации Kerberos между лесами, группы Enterprise Admins, Schema Admins находятся в отдельном корневом домене, Schema master находится в отдельном домене); самый короткий путь доверия. Минусы: видимость списка доменов всей организации; для наличия права создания новых деревьев/доменов администратор должен присутствовать в группе Enterprise Admins; тиражирование конфигурации и схемы Active Directory для всех регионов; если в новой организации уже развернута структура Active Directory, то контроллеры домена в этой организации надо переустановить.
• Вариант 2 «Единый лес, административный корневой домен, каждый регион – домен». Общее дерево Active Directory для регионов, общая система именования, основанная на географическом принципе. Каждое региональное подразделение представлено доменом. Региональные домены добавляются как дочерние к корневому домену. Административные группы Enterprise Admins, Schema Admins, дающие их членам административные полномочия в лесу, вынесены в отдельный корневой домен. Существует единое пространство доменных имен, дочерние домены наследуют DNS имя родительского домена. Существует единая служба Active Directory, позволяющая находить объекты в любом домене Active Directory. Плюсы: пользователи могут просматривать ресурсы центрального офиса и регионов при соответствующих правах доступа к объектам Active Directory; возможность регистрации мобильных пользователей в любой точке организации; единый обмен в организации; повышенная защищенность (наличие аутентификации Kerberos между лесами, группы Enterprise Admins, Schema Admins находятся в отдельном корневом домене, Schema master находится в отдельном домене). Минусы: видимость списка доменов всей организации; для наличия права создания новых деревьев/доменов администратор должен присутствовать в группе Enterprise Admins; тиражирование конфигурации и схемы Active Directory для всех регионов; путь доверия длиннее.
• Вариант 3 «Организация с единым лесом Active Directory, в котором каждый регион является дочерним доменом центрального домена». В корневом домене наряду с группами Enterprise Admins, Schema Admins существуют остальные пользовательские учетные записи центрального офиса. Любой пользователь, попадающий в группу Admins, становится Enterprise Admins, так как группа Admins входит в группы Enterprise Admins и Schema Admins. Региональные домены становятся дочерними для корневого домена. Существует единое пространство доменных имен, дочерние домены наследуют DNS имя родительского домена. Существует единая служба Active Directory, позволяющая находить объекты в любом домене Active Directory. Плюсы: пользователи могут просматривать ресурсы центрального офиса и регионов при соответствующих правах доступа к объектам Active Directory; возможность регистрации мобильных пользователей в любой точке организации; единый обмен в организации; наличие аутентификации Kerberos между лесами (повышенная защищенность); сокращение количества компьютеров-контроллеров домена из-за отсутствия корневого «пустого» домена. Минусы: видимость списка доменов всей организации; для наличия права создания новых деревьев/доменов, администратор должен присутствовать в группе Enterprise Admins; тиражирование конфигурации и схемы Active Directory для всех регионов; необходимы дополнительные усилия по контролю членства в группах Enterprise Admins, Schema Admins (не допускать в них группу Admins); структурное подчинение регионов; путь доверия длиннее.

Сравнительная характеристика вариантов построения леса Active Directory

Детализация доменной структуры

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

Варианты детализации доменной структуры:

• Вариант 1 «Повторение существующей доменной структуры». Домен для миграции существует в отдельном лесу. Необходимо создание двух учетных записей для каждого пользователя центрального офиса и регионального пользователя - одну в создаваемом домене, другую – в существующем домене. Все ресурсы DMZ (а также front-end почтовые сервера) располагаются в домене дочернем домене (DMZ Internal VLAN). При этом доступ учетных записей пользователей из существующего домена к ресурсам нового домена автоматически запрещен на уровне доверительных отношений между доменами. Учетным записям пользователей в мигрируемом домене дано право доступа к почтовому ящику соответствующего пользователя в создаваемом домене. Почтовые ящики пользователей находятся на сервере нового домена (LAN центрального офиса). Для упрощения создания двойной учетной записи можно использовать продукт «Microsoft Metadirectory Service». Необходимо отметить, что при создании DMZ в регионах по схеме, аналогичной центральному офису, неизбежно внедрение еще одного леса Active Directory для каждого региона и синхронизация этого леса с остальными лесами. Плюсы: структура Active Directory приближена к существующей доменной структуре, не потребует переконфигурации сетевого оборудования; пользователи, находясь внутри корпоративной сети, смогут получить доступ к ресурсам всей сети (регионы и центральный офис) согласно правам доступа. Минусы: ведение двойной базы данных учетных записей пользователей; использование продукта MMS для синхронизации каталогов.
• Вариант 2 «Несколько лесов. Минимальное количество доменов». Данная схема предлагает консолидировать создаваемый домен и его дочерний домен в единый домен. Домен для миграции существует в отдельном лесу. Необходимо создание двух учетных записей для каждого пользователя центрального офиса и регионального пользователя: одну в новом домене, другую – в существующем домене. Все ресурсы DMZ (а также front-end почтовые сервера) располагаются в создаваемом домене (DMZ Internal VLAN). Контроллеры нового домена находятся в зонах LAN и DMZ. При этом доступ учетных записей пользователей из существующего домена к ресурсам создаваемого домена, находящимся в зоне LAN, должен быть запрещен выставлением прав доступа к объектам нового домена и/или правилами на брандмауэре. Учетным записям пользователей в мигрируемом домене дано право доступа к почтовому ящику соответствующего пользователя в создаваемом домене. Почтовые ящики пользователей находятся на сервере нового домена (LAN центрального офиса). Для упрощения создания двойной учетной записи можно использовать продукт «Microsoft Metadirectory Service» , позволяющий синхронизовать объекты различных каталогов. Необходимо отметить, что при создании DMZ в регионах по схеме, аналогичной центральному офису, неизбежно внедрение еще одного леса Active Directory для каждого региона и синхронизация этого леса с остальными лесами. Плюсы: структура Active Directory приближена к существующей доменной структуре, не потребует переконфигурации сетевого оборудования; пользователи, находясь внутри корпоративной сети, смогут получить доступ к ресурсам всей сети (регионы и центральный офис) согласно правам доступа; по сравнению с вариантом №1 уменьшено количество доменов, в том числе, сокращено количество используемых компьютеров и административная нагрузка. Минусы: ведение двойной базы данных учетных записей пользователей; использование продукта MMS для синхронизации каталогов.
• Вариант 3 «Единый лес». Негативным моментом предыдущих вариантов является существование двух лесов Active Directory, что заставляет внедрять дополнительную систему синхронизации двух лесов или вести дублирующие записи в двух лесах (фактически ручная синхронизация). Возникает желание уйти от существования двух лесов. В данном варианте построения Active Directory все домены находятся в общем лесу. Бывший домен, подготовленный для миграции, отсутствует. Домен COMM может быть дочерним по отношению к создаваемому домену или корневому домену. Данный вариант построения Active Directory позволяет избежать ведения двух учетных записей для каждого пользователя. Все ресурсы DMZ (а также front-end почтовые сервера) располагаются в дочернем домене (DMZ Internal VLAN). Почтовые ящики пользователей находятся на сервере нового домена (LAN центрального офиса). Учетные записи пользователей центрального офиса заведены в создаваемом домене. Учетные записи мобильных пользователей, требующих доступ к ресурсам зоны DMZ Internal, заведены в дочернем домене. Для таких пользователей доступ к ресурсам будет ограничен с использованием прав доступа пользователей и групповой политики дочернего домена. В частности, используя группу Domain Users дочернего домена, возможно настроить автоматический первоначальный запрет доступа к ресурсам Active Directory для новых пользователей для повышения безопасности системы. Плюсы: уникальность учетных записей в пределах Active Directory для любого пользователя; пользователи, находясь как внутри корпоративной сети, так и в Интернет, смогут получить доступ к ресурсам всей сети (регионы и центральный офис) согласно правам доступа. Минусы: модернизация сетевой инфраструктуры.

Внедрение Active Directory

После выбора стратегии развертывания Active Directory осуществляется поэтапное внедрение единой службы каталогов в соответствии с планом-графиком развертывания.

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

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

Развертывание Active Directory

При установке Active Directory выполняются следующие функции:

• Добавление контроллера домена к существующему домену. Создается равноправный контроллер домена, обеспечивающий отказоустойчивость и уменьшение нагрузки на имеющиеся контроллеры доменов.
• Создание первого контроллер домена в новом домене. Создается новый домен, необходимый для распределения информации, что позволит настроить Active Directory в соответствии с потребностями организации. При создании нового домена разрешается создать новый дочерний домен или новое дерево.
• Создание нового дочернего домена.
• Создание нового дерева домена.
• Установка DNS-сервера.
• Создание БД и журналов БД.
• Создание общего системного тома.

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

При установке службы каталогов Active Directory на первом контроллере домена сайта в контейнере Sites создается объект с именем Default-First-Site-Name. В этом сайте необходимо установить первый контроллер домена. Дополнительные контроллеры устанавливаются в сайте первого контроллера домена (предполагается, что IP-адрес жестко связан с сайтом) или в другом существующем сайте. После установки первого контроллера домена имя Default-First-Site-Name можно изменить на любое другое.

Если производится установка Active Directory на дополнительные серверы, а в хранилище определены дополнительные сайты, при этом IР-адрес устанавливаемого компьютера соответствует имеющейся в существующем сайте подсети, то контроллер добавляется в этот сайт. Иначе контроллер добавляется в сайт исходного контроллера домена.

Основные этапы настройки сайта:

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

Основные этапы настройки репликации между сайтами:

• Создание связи сайта.
• Настройка атрибутов связей сайта – такие, как стоимость связи сайта, частота репликации и возможность репликации.
• Создание мостов связей сайта.

Тестирование

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

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

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

На следующем этапе создания стенда необходимо протестировать:

• Распределение ролей между серверами.
• Работу сервиса DNS, установленного на серверах.
• Прохождение репликации между контроллерами доменов.
• Настройку соединения между контроллерами доменов.
• Добавление контроллера домена в Internet VLAN.
• Перенос баз WINS, DHCP.
• Аутентификацию пользователей на контроллере.

После этого необходимо выполнить следующую последовательность действий:

• Установить в Internet VLAN standalone-сервер (сервер не должен быть установлен как контроллер домена или member-сервер), принадлежащий рабочей группе.
• Настроить на standalone-сервере обмен данными по протоколу IPSec в туннельном режиме с остальными контроллерами доменов.
• Добавить standalone-сервер в домен в качестве member-сервера, указать в свойствах TCP/IP адрес DNS сервера.
• Установить на сервер сервисы DHCP, WINS и перенести на него копированием базы, затем преобразовать их в формат Windows.
• Обновить member-сервер Windows до статуса контроллера домена.
• Авторизовать сервер DHCP в Active Directory.
• Провести синхронизацию между standalone-сервером и контроллерами домена.
• На контроллере домена установить DNS сервис. В свойствах TCP/IP этого сервера указать адрес DNS сервера, равный собственному адресу сервера.
• Назначить функцию глобального каталога для standalone-сервера.
• Проверить прохождение репликации между контроллерами домена.
• Запустить тест проверки функционирования контроллеров домена
• Проверить вход пользователей в сеть и выполнение сценариев входа
• Создать имидж первого раздела контроллера домена и сохранить его на втором разделе.

Тестирование реструктуризации домена – протестировать перенос учетных записей пользователей и компьютеров из существующего домена в новый домен с помощью утилиты ADMT:

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

Тестирование переноса баз DHCP, WINS – протестировать корректность переноса баз в процессе миграции:

• Установить на сервере сервисы DHCP, WINS и перенести на него копированием базы с существующих серверов, затем преобразовать их в формат Windows.
• Авторизовать сервер DHCP в Active Directory.

Тестирование многосайтовой конфигурации физической топологии Active Directory – создать дополнительный сайт для удаленной площадки, установить контроллер домена в этот сайт и проверить следующие характеристики:

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

Миграция данных

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

• Определение домена, который должен быть модернизирован первым.
• Определение последовательности модернизации доменов учетных записей.
• Определение последовательности модернизации ресурсных доменов.
• Определение момента переключения для каждого домена из Mixed mode в Native mode Windows.
• Тестирование имеющихся критичных приложений в окружении Active Directory в смешанном режиме работы контроллеров доменов.

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

Общие положения модернизации доменной инфраструктуры

При модернизации доменной инфраструктуры осуществляется миграция данных: перенос в единую службу каталога информационных систем и приложений, работа которых тесно связана с Active Directory. При этом возможна миграция с существующей структуры DNS/WINS с интеграцией новой и существующей структуры DNS/WINS на этапе миграции.

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

Существует два основных варианта модернизации доменной инфраструктуры:

• Обновление доменов.
• Реструктуризация доменов.

Обновление доменов

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

Реструктуризация доменов

Данный способ позволяет изменить существующую структуру доменов, объединить домены или преобразовать домены в организационные подразделения. На этапе реструктуризации доменов возможно использование утилиты Active Directory Migration Tools (ADMT), позволяющей переносить пользователей, группы, компьютеры, ресурсы из одного домена в другой. ADMT устанавливается как оснастка консоли Microsoft Management Console (MMC), которая включает несколько мастеров, выполняющих основные задачи в процессе миграции. Эти мастера позволяют осуществить миграцию пользователей, групп и компьютеров.

ADMT позволяет:

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

Резервное копирование

Централизованное хранение данных упрощает их резервное копирование.

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

При использовании съемных носителей необходимо убедиться, что:

• устройство резервного копирования подсоединено к компьютеру сети и включено;
• соответствующее устройство перечислено в списке совместимых с Windows устройств (Hardware Compatibility List, HCL).

Репликация данных

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

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

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

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

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

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

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

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

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

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

Виды реплицируемой информации

Хранимая в каталоге информация делится на три категории, которые называются разделами каталога. Раздел каталога служит объектом репликации. В каждом каталоге содержится следующая информация:

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

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

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

Контроллер домена хранит и реплицирует:

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

Глобальный каталог хранит и реплицирует:

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

Протоколы репликации

Обмен данными из каталога производится с помощью разных сетевых протоколов, таких как IP или SMTP:

• IP-репликация. Использует удаленный вызов процедур (remote procedure call, RPC) для репликации через связи сайтов (межсайтовой) и внутри сайта (внутрисайтовой). По умолчанию межсайтовая IP-репликация выполняется по соответствующему расписанию, однако можно настроить репликацию Active Directory, чтобы игнорировать расписания. Для IP-репликации не требуется центр сертификации.
• SMTP-репликация. Производится только через связи сайтов (межсайтовая), но не в пределах сайта. Так как протокол SMTP асинхронный, обычно все расписания им игнорируются. Необходимо установить и настроить центр сертификации (certification authority, CA) компании для использования SMTP-связей сайтов. Центр сертификации подписывает сообщения SMTP, которыми обмениваются контроллеры домена для подтверждения подлинности обновлений каталога.

Типовые проблемы при миграции

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

• Неэффективная репликация вызывает падение производительности службы Active Directory, например, могут не распознаваться новые пользователи.
• Из-за полной синхронизации всех данных в домене расширение схемы может влиять на большие сети в связи с возникновением больших временных задержек. Чтобы свести к минимуму временные задержки, связанные с репликацией данных, лучше выполнять репликацию в ночное время.
• Проблемы с репликацией данных:

·        Репликация информации каталога прекратилась.

·        Замедление репликации данных.

• В большинстве случаев в результате неэффективной обработки запросов информация каталога устаревает, а контроллеры домена становятся недоступными.
• Сохранение имеющихся почтовых сообщений при миграции почтовых ящиков пользователей из UNIX-системы в Exchange Server.
• Автоматизация прописывания путей к перемещаемым профилям после миграции пользователей – для решения создается специализированный сценарий (VBScript).
• Увеличение база данных каталога по мере расширения организации без ограничений по производительности сервера или по местонахождению в сети – каталог разделяется на распределенные разделы.

Мониторинг Active Directory

Как и любая критичная для бизнеса система, Active Directory должна находиться под постоянным контролем. Для решения этой задачи Microsoft встроило в механизм Active Directory целый ряд возможностей, включающий как расширенную диагностику в eventlog контроллеров домена, отчеты и логи в текстовые файлы, так и встроенные счетчики производительности.

Мониторинг производительности Active Directory

Данные о производительности Active Directory позволяют:

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

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

Автоматизация мониторинга Active Directory

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

Для этого рядом фирм разработано специальное программное обеспечение, позволяющее в реальном времени отслеживать работу Active Directory и предоставляющее администратору расширенный набор инструментов для диагностики и устранения проблем. Microsoft также выпустила на рынок свое решение под названием Operations Manager 2005/2007. Возможности этого продукта позволяют контролировать абсолютное большинство ключевых параметров Active Directory:

• AD DIT/Log Free Space.
• All Performance Data.
• Database and Log Overview.
• Database Size.
• DC OS Metrics Overview.
• DC Response Time.
• DC/GC Response.
• GC Response Time.
• Log File Size.
• LSASS Processor Time.
• Memory metrics.
• Intersite Replication Traffic.
• Replication Alerts last 7 days.
• Replication Inbound Bytes/sec.
• Replication Latency.
• Replication Performance Overview.

В Microsoft Operations Manager 2005/2007 имеется встроенный механизм оповещения администраторов о возникших проблемах, а также возможность строить целевые отчеты для выявления узких мест системы и опасных тенденций, что позволяет предотвратить сбой еще до того, как он возникнет и ситуация станет критической. Рекомендуется внедрять данное ПО уже на ранних стадиях развертывания Active Directory.

Устранение неполадок

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

Типичные проблемы с Active Directory

Некоторые типичные проблемы с Active Directory, с которыми можно столкнуться, и их возможные решения:

• Невозможно добавить или удалить домен. Причина: хозяин именования доменов недоступен, что может быть вызвано проблемами с сетевым соединением или отказом компьютера, играющего роль хозяина именования доменов. Решение: решить проблему с сетевым соединением, или починить/заменить компьютер, играющий роль хозяина именования доменов, или переназначить роль хозяина именования доменов.
• Невозможно создать объекты в Active Directory. Причина: недоступен мастер относительных идентификаторов, что может быть вызвано проблемами с сетевым соединением или отказом компьютера, играющего роль мастера относительных идентификаторов. Решение: решить проблему с сетевым соединением, или починить/заменить компьютер, играющий роль мастера относительных идентификаторов, или переназначить роль мастера относительных идентификаторов.
• Невозможно изменить схему. Причина: хозяин схемы недоступен, что может быть вызвано проблемами с сетевым соединением или отказом компьютера, играющего роль хозяина схемы. Решение: решить проблему с сетевым соединением, или починить/заменить компьютер, играющий роль хозяина схемы, или переназначить роль хозяина схемы.
• Изменения членства в группе не вступают в силу. Причина: недоступен хозяин инфраструктуры, что может быть вызвано проблемами с сетевым соединением или отказом компьютера, играющего роль хозяина инфраструктуры. Решение: решить проблему с сетевым соединением, или починить/заменить компьютер, играющий роль хозяина инфраструктуры, или переназначить роль хозяина инфраструктуры.
• Пользователи без программного обеспечения Active Directory не могут войти в систему. Причина: недоступен эмулятор основного контроллера домена, что может быть вызвано проблемами с сетевым соединением или отказом компьютера, играющего роль эмулятора основного контроллера домена. Решение: решить проблему с сетевым соединением, или починить/заменить компьютер, играющий роль эмулятора основного контроллера домена, или переназначить роль эмулятора основного контроллера домена.

Контроль работы сервера DNS

В Windows предусмотрены два способа контроля работы сервера DNS:

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

При работе Windows сообщения о событиях сервера DNS хранятся в журнале (log-файле) сервера отдельно от файлов событий, связанных с другими приложениями. Этот журнал можно просмотреть из оснастки Event Viewer. В него записывается ограниченный набор событий, выявляемых службой DNS, таких, как запуск и остановка сервера. Event Viewer также позволяет наблюдать за событиями DNS на компьютерах клиентов, занося данные события в файл журнала на каждом компьютере.

Восстановление служб каталога

Для восстановления Active Directory необходимо архивировать данные состояния системы: реестр, базу данных регистрации СОМ+, системные загрузочные файлы и базу данных служб сертификации (если это сервер служб сертификации).

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