Репликация Active Directory (AD) -- метод, посредством которого изменения в базе службы каталогов на одном контроллере домена (DC) передаются другим контроллерам. AD -- очень надежная и отказоустойчивая служба. Поскольку AD распределена по многим контроллерам домена, потеря части целого не нарушит работу всей службы каталогов. В лесу AD необходимо контролировать не только основные параметры DC, но и репликацию между контроллерами домена. Если не вести мониторинг, то со временем репликация в лесу нарушается, даже если администратор тщательно настроил контроллеры домена. Отслеживать и устранять неполадки репликации по мере возникновения значительно проще, чем восстанавливать лес с накопившимися проблемами. Но потребность в диагностике неизбежно возникает даже при мониторинге репликации AD. В данной статье объясняются основные принципы репликации и приводится простая методика диагностики неисправностей в репликации AD. Порой диагностика репликации AD представляет собой запутанный процесс. Следование описанному в статье порядку действий поможет упростить эту задачу.
Основы
Иногда бывает сложно найти оптимальный подход к диагностике репликации. Конечно, предпочтителен самый быстрый метод, однако пропуск одного этапа может в конечном итоге нарушить весь процесс диагностики. Логичный, исчерпывающий подход -- самый эффективный. Желание немедленно применить мощные инструменты диагностики естественно, но разумнее сначала выполнить элементарные проверки. После того как будет приобретен опыт диагностики проблем репликации, многие операции покажутся очень простыми. Однако сперва требуется приобрести навыки, тщательно выполняя каждое действие, чтобы не сделать поспешных выводов и избежать необходимости повторять ранее совершенные действия. Начните с проверки состояния операционной системы на самом DC, затем проверьте состояние службы каталогов. После этого проверьте основные соединения между DC и другими контроллерами. И, наконец, проверьте протокол, используемый службой каталогов, и убедитесь, что контроллеры домена корректно выполняют взаимную проверку подлинности. Следование этой процедуре поможет обнаружить 90 процентов неисправностей репликации.
Тестирование фундамента
Первый шаг -- проверить операционную систему DC. Ошибки репликации могут быть вызваны разнообразными локальными ошибками DC, поэтому необходимо проверить состояние фундамента - сервера. Если это еще не сделано, установите новейшие инструменты Windows Server Support Tools на всех производственных компьютерах. Все описанные утилиты входят в набор инструментов Windows Server Support Tools. Их можно загрузить из Microsoft Download Center (http://www.microsoft.com/downloads). Выполните поиск с ключевыми словами support tools для конкретной версии операционной системы и пакета обновления. Список полезных инструментов опубликован во врезке "Набор инструментов для диагностики репликации". Вряд ли удастся сразу решить все проблемы крупной компании; однако поисковый механизм Internet и база знаний Microsoft Knowledge Base (http://support.microsoft.com/search/?adv=1) помогут устранить самые заметные неполадки.
После установки пакета Windows Server Support Tools обследуйте журналы событий. Во-первых, следует провести поиск предупреждений и ошибок в системном журнале. Если в системном журнале есть сведения об ошибках, попробуйте запустить NetDiag. Даже без параметров командной строки NetDiag выполняет 23 проверки сетевой конфигурации компьютера. Среди выполняемых утилитой полезных проверок -- членство в домене, DNS, конфигурация клиентов, доверительные отношения, Kerberos и функциональность LDAP. Если обнаружены неполадки, перезапустите NetDiag с ключом /test:testname и параметром /v, чтобы произвести тщательный анализ проблемной области. Важный параметр NetDiag, который будет рассмотрен далее в статье -- ключ /fix, который перерегистрирует DNS-записи сервера.
Если сведения об ошибках содержатся в службе каталогов, запустите DCDiag, исчерпывающую тестовую утилиту для контроллеров домена. Даже без параметров командной строки DCDiag выполняет 25 тестов DC. Как и в случае с NetDiag, при обнаружении неполадок нужно перезапустить DCDiag с ключом /test:testname и параметром /v, чтобы выполнить тест проблемной области. Не следует придавать чрезмерное значение ошибкам в системном журнале; достаточно любого недавнего сбоя, чтобы тест завершился неудачей.
Если с помощью NetDiag и DCDiag не удалось обнаружить ошибок в операционной системе и службах каталогов, значит, пришло время заняться репликацией. Лучшая отправная точка -- анализ результатов тестов DCDiag, так как DCDiag выполняет многочисленные тесты репликации.
Рассмотрим процесс диагностики типичной ошибки на примере домена, изображенного на Рис. 1. В домене, именуемом Deuby.net, имеется три DC. Контроллеры с именами Godan и Kohai находятся в сайте Hub. DC с именем Sandan расположен в сайте Branch, связанном с сайтом Hub через канал репликации, проводимой с интервалом 15 минут. Предположим, что обновления из Kohai в Godan не реплицируются.
Рис. 1. Пример домена с тремя DC
Репликация всегда обращена внутрь. Поэтому необходимо рассматривать обновления как извлекаемые целевым DC из другого контроллера, хотя репликация в сайте инициирована извещениями об изменениях от обновленного DC. Начните диагностику с DC, который должен получить обновления. В данном случае это Godan.
Рис. 2. Результаты работы DCDiag
На Рис. 2 показаны некоторые результаты запуска DCDiag на Godan. Обратите внимание, что тест Replications завершился неудачей из-за ошибки "[KOHAI] DsBindWith-SpnEx() failed with error 1722, The RPC server is unavailable". Несмотря на краткость сообщения, по нему можно составить хорошее представление о проблеме. Очевидно, отказ связан с контроллером домена Kohai. Но что означает "DsBind-WithSpnEx()"? "BindWithSpn" свидетельствует, что ошибка произошла при попытке привязки (подключения или проверки подлинности) Godan к Kohai. Поэтому источник неполадки -- в неудачной организации связи Godan с Kohai.
Необходимо выяснить, может ли Godan обнаружить своего партнера по репликации, Kohai. Одна из первых проверок -- ping-тестирование IP-адреса Kohai, это позволит убедиться в наличии элементарной сетевой связи. Если тест выполнен успешно, можно обратиться к Kohai по имени (по записи DNS типа A). Однако этот метод -- не исчерпывающий тест репликации, так как DC ищет партнеров по репликации не с помощью A-записей (например, dc1.mycompany.com), но путем преобразования общего имени Canonical Name (CNAME) DNS, уникального внутри леса.
Каждый DC в лесу должен зарегистрировать запись CNAME для имени DsaGuid._msdcs.ForestName; по этой записи система репликации идентифицирует компьютер как DC. Запись CNAME ставит эту строку в соответствие записи A контроллера домена, в которой содержится его IP-адрес. Например, DNS CNAME узла dc1.mycompany.com может быть d40c01da-23fa-46e6-8bf3-798503e2590f._msdcs.mycompany.com. Запись CNAME будет иметь вид d40c01da-23fa-46e6-8bf3-798503e2590f._msdcs.mycompany.com CNAME dc1.mycompany.com. Следует отметить, что глобальный уникальный идентификатор (GUID) агента службы каталогов (directory service agent -- DSA), который составляет первую часть записи CNAME контроллера домена -- не GUID (конкретно, атрибут GUID объекта) объекта computer контроллера домена, как можно было бы ожидать. В действительности, это GUID объекта NTDS Settings в разделе DC в контейнере Sites. Например, если бы DC1 был в сайте Hub, то его отличительное имя (DN) было бы CN=NTDS Settings,CN=DC1,CN=Servers,CN=Hub,CN=sites,CN=configuration,DC=mycompany,DC=com.
Рис. 3. Просмотр записи CNAME контроллера домена Kohai
Если проблемный DC не может преобразовать запись CNAME партнера по репликации, то он не получает обновлений. Поэтому сначала необходимо определить DNS CNAME на основе GUID контроллера Kohai; затем нужно проверить, может ли Godan преобразовать CNAME. Вероятно, самый простой способ это сделать -- запустить Active Directory Sites and Services (dssite.msc), перейти к сайту Godan (то есть Hub, контейнер Servers, компьютерный объект KOHAI), а затем щелкнуть правой кнопкой мыши на контейнере NTDS Settings и выбрать пункт Properties. Запись CNAME для Kohai находится в поле DNS Alias (Экран 3). Эту строку следует скопировать и вставить в команду Ping в командной строке в компьютере Godan (Экран 4), чтобы выяснить, может ли механизм репликации распознать Kohai. Поскольку DNS не может распознать Kohai через запись CNAME, репликации не произойдет. Особо отметим, что аналогичный запрос с использованием записи CNAME контроллера Godan обработан корректно.
Рис. 4. Эхо-тестирование CNAME Kohai
Выяснилось, что проблема -- в отсутствии записи CNAME DNS контроллера Kohai. Существует два метода для ее перерегистрации. Простое решение -- остановить и запустить службу Netlogon; однако при этом будет временно нарушена связь между Kohai и его активными пользователями. Из наличия неполадок в репликации не следует, что DC не обслуживает пользователей. Менее разрушительное решение -- запустить NetDiag /fix. Параметр /fix предназначен специально для перерегистрации всех необходимых записей DNS для DC. После того, как будет выполнена эта операция, NetDiag функционирует корректно, но с предупреждением, что потребуется некоторое время для репликации добавленной записи CNAME на DNS-сервер, указанный как вторичный в конфигурации DNS сетевой платы.
Ошибки в настройке DNS
В данном примере показано, почему ошибки в настройке DNS -- самая распространенная причина неполадок AD. Сложный процесс настройки DNS тесно связан с функциональностью AD; ошибки в конфигурации DNS очень разнообразны. При сбоях в преобразовании DNS или других ошибках обнаружения для контроллера домена необходимо проверить следующие параметры.
Убедитесь в корректности IP-адресов в клиентских настройках DC (свойства TCP/IP локального соединения). Если DC также играет роль DNS-сервера, то рекомендуется, чтобы первичная запись DNS указывала на себя. (Longhorn Server автоматически настраивает запись DNS на замыкание на себя -- 127.0.0.1 -- если работает мастер Dcpromo.) Вторичный DNS-сервер должен указывать на другой DC в том же домене. Дополнительные сведения о преимуществах и недостатках различных типов конфигурации DNS-клиента для контроллеров домена приведены в статье Microsoft "Best practices for DNS client settings in Windows 2000 Server and in Windows Server 2003".
Первичный DNS-сервер -- единственное средство, с помощью которого контроллер домена обнаруживает другие сетевые ресурсы. Таким образом, можно управлять сведениями, которые DC получает о других серверах и доменах, управляя первичной записью DNS. Чтобы убедиться в исправности собственного DNS-сервера контроллера домена, следует направить первичную запись DNS на заведомо исправный DNS-сервер.
Убедитесь, что DC уже зарегистрировал необходимые для функционирования записи ресурсов. К репликации относятся три записи. Две из них -- CNAME (о которой шла речь выше) и A-запись (имя узла для преобразования IP-адреса). С помощью команды DCDiag /test:connectivity можно проверить, зарегистрированы ли эти записи в первичном DNS-сервере контроллера домена, и при необходимости использовать команду NetDiag для перерегистрации записей. Если записи все же не регистрируются, следует запустить DCDiag /test:Registerindomain /DnsDomain:dnsdomainname, чтобы проверить корректность настройки DC для регистрации. A-запись также должна соответствовать корректному IP-адресу. Кроме того, эти регистрации должны быть реплицированы на DNS-серверы, используемые партнерами, прежде чем те смогут обнаружить их. (Учтите, что команда IPConfig /RegisterDNS не регистрирует всех DNS-записей, необходимых контроллеру домена.)
Для дочерних контроллеров в древовидной структуре домена необходимо проверить третью, связующую (glue) запись. Связующие записи представляют собой A-записи DNS-серверов (иными словами, контроллеров домена) для дочерних доменов леса и хранятся в зоне прямого просмотра корневого домена. С помощью связующих записей удается решить проблему циклических ссылок: чтобы найти узел в дочернем домене вне этого домена, необходимо связаться с доверенным DNS-сервером данного домена. Но преобразовать имя доверенного сервера невозможно, так как его A-запись находится в том самом домене, о котором требуется получить DNS-информацию. Поместив второй набор A-записей для DNS-серверов дочернего домена в корневой каталог, удается решить проблему ссылок и "привязать" дочерние домены к корневому. Тестирование DNS с помощью команды DCDiag с параметром /DnsDelegation (DCDiag /test:DNS /DnsDelegation) проверяет корректность регистрации записей о связях в DC.
Отказ в доступе
Вторая наиболее распространенная группа ошибок относится к отказу в доступе DC к партнеру по репликации. В обычных условиях проблемы доступа отсутствуют, так как все учетные записи компьютеров DC являются членами встроенной группы Enterprise Domain Controllers. Таким образом, отказ в доступе означает, что результате какого-то события нарушены условия безопасности между партнерами по репликации. Одна из наиболее распространенных коренных причин -- неверное время синхронизации одного из DC. Собственно репликация не зависит от времени, но Kerberos учитывает время. Kerberos требует точной временной синхронизации между контроллерами домена; если их внутренние часы отличаются более чем на пять минут (по умолчанию), то проверка Kerberos заканчивается неудачей и выдается сообщение об отказе в доступе к исходному DC. В системный журнал заносятся ошибки Kerberos и, возможно, W32Time.
С помощью команды Net Time /QuerySNTP можно выяснить, какие серверы времени назначены для данного DC. DC -- член домена по определению; если DC -- не эмулятор главного контроллера (PDC) корневого домена, то его указатель сервера времени должен быть пустым, потому что NTP-сервер (Network Time Protocol -- сетевой протокол службы времени) для DC, отличного от главного контроллера домена -- это PDC домена. Если данный DC расположен в дочернем домене, то PDC ищет DC в корневом домене в качестве источника времени, а эти контроллеры в свою очередь ищут PDC родительского домена (обычно корневого) в качестве доверенного источника времени для всего леса. Удалить ссылки на конкретный сервер времени можно с помощью команды Net Time /SetSNTP:. Затем можно использовать удобную команду W32tm, чтобы управлять NTP-параметрами DC. Чтобы настроить DC на обнаружение и синхронизацию с источником времени, запустите команду W32tm /Resync /Rediscover. Можно также применить команду W32tm /Config /Syncfromflags:DOMHIER для синхронизации с DC в соответствии с иерархией домена. Команда W32tm /Monitor позволяет проверить NTP-параметры всех DC в домене. Изменения времени отображаются на часах на панели задач. Дополнительные сведения о функционировании службы Windows Time приведены в статьях Microsoft "How Windows Time Service Works" и "How to configure an authoritative time server in Windows Server 2003".
Если из-за долгого отсутствия временной синхронизации истекли собственные билеты Kerberos контроллера домена, то необходимо отключить центр рассылки ключей Key Distribution Center (KDC) на DC и перезагрузиться. Чтобы отключить KDC, остановите его с помощью утилиты Control Panel Services и установите режим запуска в Disabled. В результате билеты Kerberos отменяются, и DC должен получить новые билеты с одного из оставшихся функциональных DC.
Другие рекомендации
Во-первых, запаситесь терпением. Для завершения репликации на предприятии требуется время, как и для устранения возникающих неполадок. Например, если DC не отвечает, то служба контроля целостности Knowledge Consistency Checker (KCC) ожидает 90 минут, прежде чем выполнить перерасчет объектов связи вокруг DC.
Особое значение придается безопасности, поэтому необходимо учитывать, что репликация могла быть блокирована в результате изменений в настройках брандмауэра. Обратите внимание на исправные серверы, которые не отвечают на эхо-тестирование по ping, и на серверы, которые отвечают на сигналы, посылаемые по одним протоколам, но не реагируют на другие. Подробные сведения о требованиях к портам DC приведены в статье Microsoft "Active Directory Replication over Firewalls".
Если данные в журнале службы каталогов недостаточно подробны, следует включить протоколирование NTDS в разделе реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNtdsDiagnostics. Выбор параметра зависит от области, которую нужно проанализировать (например, контроль целостности, преобразование имен, события репликации). Значение по умолчанию -- 0, максимальное значение -- 5. Обычно применять значения выше 3 не требуется. Исследуйте эффект изменения параметра на детальность сведений в журнале службы каталогов и отключите протоколирование, когда потребность в нем исчезнет.
Доверяйте KCC. Не поддавайтесь искушению поправить KCC, обнаружив отличия между созданной инструментом и плановой топологией. Если поведение KCC не такое, как ожидалось, то, вероятно, действительные настройки топологии сайта иные, чем предполагал администратор. Например, необходимо убедиться, что IP-адрес контроллера домена соответствует подсетям, связанным с сайтом, к которому относится DC.
И, наконец, если получены ошибки, указывающие, что DC не реплицировался в течение более длительного периода, чем время жизни объектов, помеченных на удаление, то рекомендуется отказаться от попыток диагностики. Необходимо перестроить DC, удалить метаданные из AD и заново назначить DC. Как сказал однажды коллега, обладатель сертификата MVP: "Контроллеры домена -- как оловянные солдатики; всегда можно убрать DC и заменить его другим, точно таким же".
Волшебная палочка не нужна
Репликация -- ключевая функция AD, но к диагностике репликации почему-то часто относятся как к колдовству. Чтобы снять мистический покров, используйте логический подход к основным проверкам; затем убедитесь, что операционная система DC функционирует корректно, проверьте конфигурацию DNS, связи между DC, Kerberos и его взаимозависимости (например, службу Windows Time), а также настройки брандмауэра. Следование рекомендациям данной статьи поможет вернуть диагностику репликации AD из области черной магии в сферу обычных технических процедур.
Шон Дьюби (sdeuby@windowsitpro.com) - редактор Windows IT Pro и член группы службы каталогов в компании Intel. В течение четырех лет получал звание MVP; является автором книги "Windows 2000 Server: Planning and Migration" (издательство Macmillan).
Моментальный снимок решения:
Проблема:
Диагностика репликации Active Directory (AD).
Решение:
Проверить основные характеристики и использовать инструменты Windows Server Support Tools для мониторинга и восстановления процесса репликации AD.
Требуемые ресурсы:
Windows Server 2003 или Windows 2000, Windows Server Support Tools
Уровень сложности: 3 из 5
- Убедитесь, что операционная система и служба каталогов целевого DC функционируют нормально.
- Убедитесь, что DNS работает исправно как на целевом, так и на исходном контроллерах домена.
- Убедитесь, что целевой DC распознает исходный DC.
- Проверьте Kerberos и службы, от которых зависит его функционирование.
- Проверьте настройки брандмауэра.
«Набор инструментов для диагностики репликации»
Шон Дьюби
Нельзя переоценить значение набора для диагностики репликации Active Directory (AD). Я рекомендую обратиться на Web-узел Windows Server 2003 Service Pack 1 32-bit Support Tools и составить базовый набор из следующих вспомогательных инструментов Windows Server. Независимые поставщики, такие как NetPro Computing и Quest Software, также выпускают утилиты, с помощью которых проще выполнить диагностику AD, в том числе и процесса репликации.
* Event Viewer. На первый взгляд, необходимость в этом инструменте очевидна, но мне приходилось встречать администраторов, которые игнорировали журнал, пытаясь разобраться в проблемах репликации. Используйте журнал службы каталогов, системный журнал и журнал DNS, если DNS установлена на контроллере домена (DC). Сообщения о событиях Windows Server 2003 гораздо более информативны, чем в предшествующих операционных системах, хотя встроенные ссылки на справочную систему Microsoft оказываются полезными далеко не всегда.
* DCDiag. Часто этот мощный инструмент можно применять вообще без параметров. Чтобы назначить отдельные тесты, используйте ключ /test:testname. Рекомендуется прочитать обо всех имеющихся тестах и разобраться в них. Ниже приведены некоторые важные параметры и тесты.
/S:server -- указывает удаленный DC для тестирования.
/A -- тестирует все контроллеры домена сайта.
/E -- тестирует все контроллеры домена леса.
/test:DNS -- исчерпывающий набор из семи тестов DNS, новшество Windows 2003 SP1. Дополнительные сведения приведены по адресу.
/CheckSecurityError -- обнаруживает параметры безопасности, которые могут стать причиной отказа репликации.
* Repadmin. Repadmin -- универсальная утилита репликации. Как только появляется новый способ управления или диагностики репликации, компания Microsoft обычно добавляет соответствующую функцию в этот инструмент. Параметр /experthelp выводит на экран две страницы с информацией о синтаксисе. Инструмент можно немедленно применять для устранения неполадок репликации, но чтобы освоить его, требуется время и глубокое понимание процесса репликации. Ниже перечислены важные команды Repadmin, знать которые полезно каждому администратору.
/Showrepl -- показывает входящих партнеров по репликации DC для всех разделов каталога. Параметр /RepsTo показывает исходящих соседей DC.
/ReplSummary -- показывает состояние репликации всего леса.
/KCC -- задает пересчет топологии репликации с использованием инструмента проверки согласованности знаний (KCC). Это полезно, если требуется быстрее, чем обычно, учесть в KCC изменения, внесенные в контроллер домена.
/Queue -- показывает задачи, ожидающие в очереди репликации.
/ShowObjMeta -- показывает, какой DC инициировал обновление атрибутов указанного объекта.
/Replicate -- принудительная репликация контекста именования (раздел каталога).
/OldHelp -- перечисляет устаревшие команды.
/ExpertHelp -- перечисляет дополнительные команды.
* Replmon. Хороший графический инструмент для анализа состояния различных разделов каталога, задействованных в репликации. Несмотря на отсутствие некоторых команд, имеющихся в Repadmin, это отличный выбор для администраторов, которым неудобно работать с Repadmin.