Ошибка репликации active directory 5. доступ запрещен

Описание проблемы вызывающей ошибку ID 2042

И так у меня есть установленные Active Directory на базе Windows Server 2019, который работает в виде виртуальных машин на гипервизоре ESXI 6.5. Была проблема с репликацией между двумя сайтами AD, где было установлено, что один из контроллеров домена не получал репликацию более 50 дней, там об этом сигнализировала ошибка «SyncAll exited with fatal Win32 error: 8440 (0x20f8)», которую мы успешно устранили. Как только пробежали все реплики, мы успокоились, но на следующий день у нас массово в логах Windows стали появляться события с кодом ID 2042:

It has been too long since this machine last replicated with the named source machine. The time between replications with this source has exceeded the tombstone lifetime. Replication has been stopped with this source.

The reason that replication is not allowed to continue is that the two DCs may contain lingering objects. Objects that have been deleted and garbage collected from an Active Directory Domain Services partition but still exist in the writable partitions of other DCs in the same domain, or read-only partitions of global catalog servers in other domains in the forest are known as «lingering objects». If the local destination DC was allowed to replicate with the source DC, these potential lingering object would be recreated in the local Active Directory Domain Services database.

Time of last successful replication: 2020-09-08 14:47:05 Invocation ID of source directory server: f96c8e1b-f760-4e75-b2b2-ec464646d663 Name of source directory server: d06896a3-be4b-4b8a-b75f-e524564526a0f._msdcs.root.pyatilistnik.orgTombstone lifetime (days): 60

The replication operation has failed.

User Action: The action plan to recover from this error can be found at http://support.microsoft.com/?id=314282.

If both the source and destination DCs are Windows Server 2003 DCs, then install the support tools included on the installation CD. To see which objects would be deleted without actually performing the deletion run «repadmin /removelingeringobjects <Source DC> <Destination DC DSA GUID> <NC> /ADVISORY_MODE». The event logs on the source DC will enumerate all lingering objects. To remove lingering objects from a source domain controller run «repadmin /removelingeringobjects <Source DC> <Destination DC DSA GUID> <NC>».

If either source or destination DC is a Windows 2000 Server DC, then more information on how to remove lingering objects on the source DC can be found at http://support.microsoft.com/?id=314282 or from your Microsoft support personnel.

If you need Active Directory Domain Services replication to function immediately at all costs and don’t have time to remove lingering objects, enable replication by setting the following registry key to a non-zero value:

Registry Key: HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Allow Replication With Divergent and Corrupt Partner

Replication errors between DCs sharing a common partition can prevent user and computer accounts, trust relationships, their passwords, security groups, security group memberships and other Active Directory Domain Services configuration data to vary between DCs, affecting the ability to log on, find objects of interest and perform other critical operations. These inconsistencies are resolved once replication errors are resolved. DCs that fail to inbound replicate deleted objects within tombstone lifetime number of days will remain inconsistent until lingering objects are manually removed by an administrator from each local DC. Additionally, replication may continue to be blocked after this registry key is set, depending on whether lingering objects are located immediately.

Alternate User Action:

Force demote or reinstall the DC(s) that were disconnected.

Я выделил тут участок Tombstone lifetime (days): 60, именно это является ключевым вопросом. Так как у вас сбойный контроллер не принимал реплики более 60 дней, то ваш Active Directory просто перестраховывается, чтобы ничего не наломать, есть там такой защитный механизм, называется принудительный запрет репликации.

Событие 2042 — событие указывает на то, что включена строгая репликация, исходный контроллер домена не реплицировался в в период tombstone и пытается реплицировать, поэтому репликация отключена из источника. Событие предоставляет GUID источника в формате записи DNS CName:982a942e-40e4-4e3c-8609-bae0cfd2affb._msdcs.pyatilistnik.org. Понятное имя контроллера домена можно легко найти, просмотрев записи псевдонимов в зоне _msdcs в оснастке DNS.

Перемещение файлов журналов

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

Чтобы переместить файлы журналов, выполните следующие действия.

1. Нажмите кнопку «Пуск», выберите «Выполнить», введите ntdsutil в поле «Открыть» и нажмите клавишу ВВОД.
2. В командной строке Ntdsutil введите файлы и нажмите клавишу ВВОД.
3. В командной строке обслуживания файлов введите журналы перемещения в новое расположение (где новое расположение — это существующая папка, созданная для этой цели), а затем нажмите клавишу ВВОД.
4. Введите «Выйти» и нажмите клавишу ВВОД.
5. Перезагрузите компьютер.

Симптомы

Рассмотрим следующий сценарий. В среде Windows Server 2003 режим работы леса в лесу устанавливается на Windows Server 2003 или более поздней версии Windows. Это необходимо для применения изменений репликации значений ссылок (LVR) к членству в группах атрибутов с поддержкой LVR. В этом сценарии могут возникать следующие симптомы:

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

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

  Примечание.

  Ошибка Win32 8451 соответствует ошибке ERROR_DS_DRA_DB_ERROR и следующему описанию:
  При выполнении операции репликации произошла ошибка базы данных.

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

• Конечные контроллеры домена под управлением Windows Server 2008 и Windows Server 2003 регистрирует события в журнале службы каталогов.

  Примечание.

  • Общее событие NTDS 1173 указывает на сбой универсальной репликации.
  • Дополнительное значение ошибки данных -1603 сопоставляется с валютой, не включенной в ошибку струи записи, и с символическим именем errNoCurrentRecord. Орфографические ошибки в валюте, не в тексте ошибки записи .
  • Исключение e0010004 соответствует ошибке DSA_DB_EXCEPTION.
  • Внутренний идентификатор 2050344 соответствует функции в коде уровня базы данных NTDS. Это число зависит от операционной системы, пакета обновления и исправлений.

• Конечные контроллеры домена под управлением Windows Server 2008 и Windows Server 2003 регистрирует событие службы каталогов 1692.

  Примечание.

  Это событие регистрируется при включении ведения журнала диагностики и при установке значения для записи реестра «5 событий репликации» значение 1 или более.

  Дополнительные сведения о ВЕДЕНИИ журнала диагностики NTDS см. в разделе «Настройка ведения журнала событий диагностики Active Directory и LDS».

  

  

  

  

  

  

  

  

  

  

Эти симптомы могут возникать при внесении изменений в любой реплицируемый LVR класс объектов с перенаправленными ссылками. (Эти изменения в реплицируемом LVR классе объектов также внесены в изменения, внесенные в группы безопасности и распространения.)

Причина

Эта проблема возникает по одной из следующих причин:

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

О проблеме с сетевым подключением

Эта проблема возникает, когда партнеру репликации контроллера домена не удается завершить подключение RPC к службе RPC репликации AD (UUID DRSR E3514235-4B06-11D1-AB04-00C04FC2DCD2). В частности, партнер репликации может выполнить привязку к сопоставитель конечных точек RPC, но не может выполнить привязку DRSR RPC.

Возможные первопричины:

• Брандмауэры
• Маршрутизаторы
• Оптимизаторы глобальной сети
• другие промежуточные сетевые устройства
• драйверы сетевого фильтра

О проблеме с производительностью

Эта проблема возникает, если выполняется одно из следующих условий:

• Сервер находится в невыполненной работе и не отвечает на подтверждение TCP или ответное сообщение. Таким образом, отправитель прерывает сеанс TCP.
• Сеть слишком медленная или ненадежная. Он не может доставить подтверждение TCP или ответное сообщение.

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

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

• Число дисков на целевом сервере должно быть равно числу в резервной копии, и они должны иметь одинаковый размер или больше.
• Целевой сервер необходимо запустить с DVD-диска операционной системы, чтобы получить доступ к параметру «Восстановить компьютер «.
• Если целевой контроллер домена работает на виртуальной машине в Hyper-V, а резервная копия хранится в сетевом расположении, необходимо установить устаревший сетевой адаптер.
• После полного восстановления сервера необходимо отдельно выполнить заслуживающее доверия восстановление SYSVOL, как описано в разделе AD Forest Recovery — выполнение заслуживающей доверия синхронизации DFSR-реплицированного SYSVOL.

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

Поддерживаемые методы резервного копирования Active Directory на контроллерах домена под управлением Windows Server 2003 или более поздних версий Windows Server

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

Ниже приведены поддерживаемые методы, которые можно использовать для отката содержимого Active Directory:

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

• Используйте служебную программу резервного копирования и восстановления с поддержкой Active Directory, которая использует API-интерфейсы службы теневого копирования томов Майкрософт. Эти API резервного копирования и восстановления состояния системы контроллера домена. Служба теневого копирования томов поддерживает создание теневых копий на один или несколько томов на компьютерах под управлением Windows Server 2003, Windows Server 2008 или Windows Server 2008 R2. Теневые копии на определенный момент времени также называются моментальными снимками. Дополнительные сведения см. в разделе «Служба теневого копирования томов» служба поддержки Майкрософт.

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

Дополнительные сведения

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

Только ошибка

С помощью кнопки » Только ошибки» (в правом верхнем углу изображения ниже) можно отфильтровать работоспособные контроллеры домена, чтобы сосредоточиться на целевых контроллерах домена, которые сообщают об ошибках репликации:

Анализ ошибок репликации

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

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

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

Текущая версия ADREPLSTATUS на этот раз — 2.2.20717.1 (как показано на экране-заставке запуска ADREPLSTATUS).

Возможности

• Автоматическое обнаружение контроллеров доменов и доменов в лесу Active Directory, к которому присоединен компьютер под управлением ADREPLSTATUS.
• Режим «Только ошибки» позволяет администраторам сосредоточиться только на контроллерах домена, которые сообщать о сбоях репликации. Дополнительные сведения см. .
• Когда ADREPLSTATUS обнаруживает ошибки репликации, средство использует интеграцию с содержимым разрешения в Microsoft TechNet, чтобы отобразить шаги по устранению основных ошибок репликации AD. Дополнительные сведения см. .
• Расширенная сортировка и группирование выходных данных результатов путем щелчка любого заголовка отдельного столбца (сортировка) или перетаскивания одного или нескольких заголовков столбцов на панель фильтра. Используйте один или оба варианта для размещения выходных данных по последней ошибке репликации, дате успешного завершения последней репликации, контексту именования исходного контроллера домена, дате успешного выполнения репликации и т. д.
• Экспортируйте данные о состоянии репликации, чтобы их могли импортировать и просматривать администраторы исходного домена, администраторы домена назначения или специалисты службы поддержки в Microsoft Excel или ADREPLSTATUS.
• Выберите столбцы, которые нужно отобразить, и их порядок отображения. Эти параметры сохраняются в качестве предпочтений на компьютере ADREPLSTATUS.

Примечание.

ADREPLSTATUS — это средство только для чтения, которое не вносит изменений в конфигурацию леса Active Directory или объектов в лесу Active Directory.

Удаление контроллера домена

Удаление из домена active directory контроллера, который находиться в офлайне происходит в несколько простых и коротких этапов.

NTDSUTIL

• На исправном контролере домена из под администратора запускаем командную строку и вводим ntdsutil . Мы «вошли» в утилиту и должны увидеть приглашение «ntdsutil:» для ввода команд.
• Вводим команду metadata cleanup
• Нам необходимо уточнить что именно нужно удалить. Вводим connections — мы вошли в меню для подключения к серверу. 
  • Вводим connect to server имя_сервера , где имя_сервера — имя исправного сервера с контроллером домена.
  • Вводим команду quit — для возврата в меню Metadata Cleanup.
• Вводим команду select operation target
  • Вводим команду list domains — появиться список доменов. У меня он один.
  • Вводим команду select domain номер — указываем из какого домена мы хотим удалить сервер, где «номер» — номер домена из предыдущего списка.
  • Вводим команду list sites — отобразится список узлов с номерами.
  • Вводим команду select site номер, где номер — номер узла в котором находиться удаляемый сервер.
  • Вводим команду list servers in site — выводим список серверов с номерами в указанном узле
  • Вводим команду select server номер, где номер — номер сервера который мы хотим удалить.
  • Вводим команду quit — выходим в меню metadata cleanup утилиты ntdsutil
• Вводим команду remove selected server — удаляем контроллер домена. Появиться окно с предупреждением, подтверждаем кнопкой «yes».
• Вводим quit — выходим из меню metadata cleanup утилиты ntdsutil
• Вводим quit — выходим из утилиты  ntdsutil

Эта процедура выглядит приблизительно вот так:

Удаление из оснасток:

• Открываем оснастку «Active Directory Sites and Services», разворачиваем сайт (узел) в котором находиться удаляемый контроллер домена, убеждаемся что он не содержит никаких объектов и удаляем его.
• Открываем оснастку  «Active Directory Users and Computers», разворачиваем контейнер «Domain Controllers» и убеждаемся что там нет удаляемого контроллера домена. Если есть — удаляем.
• Открываем оснастку «DNS Manager».
  • Находим зону DNS в которой удаляемый контроллер домена был DNS-сервером.
  • Кликаем правой кнопки мышки по зоне и выбираем Properties
  • Переходим на вкладку Name Servers и удаляем не нужный контроллер домена.
  • Жмем OК, для того чтобы удалить все оставшиеся DNS записи: HOST (A) или Pointer (PTR) и убеждаемся что в зоне не осталось никаких DNS записей связанных с удаляемым контроллером домена.

Решение

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

Устранение причины 1

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

Убедитесь, что в редакторе ACL есть запись управления доступом (ACE) для учетной записи доверенного лица SELF и что у нее есть доступ «Разрешить» для следующих расширенных прав:

• Проверенная запись в DNS-имя узла
• Проверенная запись в имя субъекта-службы

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

• Все пользователи
• Пользователи, прошедшие проверку
• SELF

API, которые применяются к этим доверенным субъектам, также могут запретить доступ для записи в атрибуты или запретить расширенные права «Проверенная запись в DNS-имя узла» или «Проверенная запись в имя субъекта-службы».

Метод 1. Исправление непреднамеренного несвязанного пространства имен

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

Дополнительные сведения о восстановлении непрерывного пространства имен в Windows Server 2003 см. в следующей статье Microsoft TechNet:Переход от несвязанного пространства имен к непрерывному пространству имен
Для Windows Server 2008, Windows Vista и более поздних версий см. следующую статью Microsoft TechNet:Отмена случайно созданного несвязанного пространства имен

Метод 2. Убедитесь, что конфигурация несвязанного пространства имен работает правильно

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

Дополнительные сведения о том, как проверить правильность работы несвязанного пространства имен в Windows Server 2003 R2, Windows Server 2003, Windows Server 2003 с пакетом обновления 1 (SP1) и Windows Server 2003 с пакетом обновления 2 (SP2), см. в следующей статье Microsoft TechNet: Создание несвязанного пространства имен
Дополнительные сведения о том, как проверить правильность работы несвязанного пространства имен в Windows Server 2008 R2 и Windows Server 2008, см. в следующей статье Microsoft TechNet: Создание несвязанного пространства имен

Расширив пример, упомянутый в последней основной маркированной точке в разделе «Причина», вы добавите в атрибут разрешенный суффикс.

Восстановление после отката USN

Существует три подхода к восстановлению после отката USN.

• Удалите контроллер домена из домена. Для этого выполните следующие действия:

  1. Удалите Active Directory из контроллера домена, чтобы принудительно сделать его автономным сервером. Дополнительные сведения см. в статье «Контроллеры домена не понижаются корректно при использовании мастера установки Active Directory для принудительного понижения уровня».

  2. Завершите работу пониженного сервера.

  3. На работоспособном контроллере домена очистите метаданные пониженного контроллера домена. Дополнительные сведения см. в разделе «Очистка домен Active Directory метаданных сервера контроллера».

  4. Если неправильно восстановленный контроллер домена размещает главные роли операций, переведите эти роли на работоспособный контроллер домена. Дополнительные сведения см. в разделе «Передача или захват ролей FSMO в доменные службы Active Directory».

  5. Перезапустите пониженный сервер.

  6. При необходимости установите Active Directory на автономном сервере еще раз.

  7. Если контроллер домена ранее был глобальным каталогом, настройте контроллер домена как глобальный каталог. Дополнительные сведения см. в статье о создании или перемещении глобального каталога.

  8. Если контроллер домена ранее размещал главные роли операций, переведите главные роли операций обратно на контроллер домена. Дополнительные сведения см. в разделе «Передача или захват ролей FSMO в доменные службы Active Directory».

• Восстановите состояние системы для хорошей резервной копии.

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

• Восстановление состояния системы без резервного копирования состояния системы.

  Моментальный снимок можно использовать в качестве источника резервной копии. Вы также можете задать для базы данных новый идентификатор вызова, выполнив процедуру в разделе «Восстановление предыдущей версии виртуального жесткого диска виртуального контроллера домена без резервного копирования данных о состоянии системы» в разделе «Запуск контроллеров домена в Hyper-V».

Как задать пути

Чтобы задать путь для следующих элементов, можно использовать команду set path:

• Резервное копирование. Используйте этот параметр с командой set path, чтобы задать целевой объект резервного копирования между дисками для папки, указанной переменной расположения. Вы можете настроить службу каталогов для резервного копирования подключенного диска на диск с интервалами по расписанию.
• База данных: используйте этот параметр с командой set path для обновления части реестра, которая определяет расположение и имя файла данных. Используйте эту команду только для перестроения контроллера домена, который теряет файл данных и не восстанавливается с помощью типичных процедур восстановления.
• Журналы. Используйте этот параметр с командой set path для обновления части реестра, которая определяет расположение файлов журнала. Используйте эту команду, только если вы перестраиваете контроллер домена, который теряет файлы журналов и не восстанавливается с помощью стандартных процедур восстановления.
• Рабочий каталог. Используйте этот параметр с командой set path, чтобы задать часть реестра, которая определяет рабочую папку службы каталогов, в папку, указанную переменной расположения. Чтобы выполнить команду set path, выполните следующие действия:

Перемещение базы данных

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

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

1. Нажмите кнопку «Пуск», выберите «Выполнить», введите ntdsutil в поле «Открыть» и нажмите клавишу ВВОД.
2. В командной строке Ntdsutil введите файлы и нажмите клавишу ВВОД.
3. В командной строке обслуживания файлов введите move DB to new location (where new location is an existing folder that you’ve created for this purpose), and then press ВВОД.
4. Чтобы выйти из Ntdsutil, введите «Выйти» и нажмите клавишу ВВОД.
5. Перезагрузите компьютер.

Причина

Код ошибки\ -21468930220×80090322\SEC_E_WRONG_PRINCIPAL не является ошибкой Active Directory. Он может быть возвращен следующими компонентами нижнего слоя для различных первопричин:

• RPC
• Kerberos;
• SSL
• Lsa
• NTLM;

Ошибки Kerberos, сопоставленные кодом Windows с -2146893022\0x80090322\SEC_E_WRONG_PRINCIPAL :

• KRB_AP_ERR_MODIFIED (0x29/41 десятичное/KRB_APP_ERR_MODIFIED)
• KRB_AP_ERR_BADMATCH (0x24h/36 decimal/»Ticket and authenticator don’t match»)
• KRB_AP_ERR_NOT_US (0x23h/35 decimal/»The ticket isn’t for us»)

Ниже перечислены некоторые конкретные основные причины для -2146893022\0x80090322\SEC_E_WRONG_PRINCIPAL .

• Неправильное сопоставление имени с IP-адресом в файле DNS, WINS, HOST или LMHOST. Это привело к подключению конечного контроллера домена к неправильному исходному контроллеру домена в другой области Kerberos.

  

  

  

  

  

  

  

  

  

• KDC и исходный контроллер домена имеют разные версии пароля учетной записи компьютера исходного контроллера домена. Поэтому целевому компьютеру Kerberos (исходному контроллеру домена) не удалось расшифровать данные проверки подлинности Kerberos, отправленные клиентом Kerberos (конечным контроллером домена).

• KDC не удалось найти домен для поиска имени субъекта-службы исходного контроллера домена.

• Данные проверки подлинности в зашифрованных кадрах Kerberos были изменены оборудованием (включая сетевые устройства), программным обеспечением или злоумышленником.

Подробные инструкции по устранению неполадок

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

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

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

1. Проверьте, прослушивает ли исходный контроллер домена TCP-порт 135. Для этого выполните команду .

   Если состояние порта — FILTERED, сбой репликации AD, скорее всего, завершится сбоем и вернет ошибку 1722. Попробуйте разрешить ошибку 1722, а затем проверьте, успешно ли выполняется репликация AD. Если проблема не исчезнет, перезапустите подробные инструкции по устранению неполадок.

   Если состояние не фильтруется, команды возвращают базу данных модуля сопоставления конечных точек RPC. Найдите интерфейс MS NT Directory DRS , чтобы найти порт верхнего диапазона в базе данных сопоставляемого модуля сопоставления конечных точек, прослушиваемой исходным контроллером домена для репликации AD. Вы можете получить одну или несколько записей. Запишите порты для ncacn_ip_tcp.

   Например, вы получите примерно такой пример, который представляет два порта верхнего диапазона 49159 и 49160:

   UUID: e3514235-4b06-11d1-ab04-00c04fc2dcd2 MS NT Directory DRS Interface ncacn_ip_tcp:2012dc UUID: e3514235-4b06-11d1-ab04-00c04fc2dcd2 MS NT Directory DRS Interface ncacn_ip_tcp:2012dc

   Примечание.

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

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
   Значение реестра: TCP/IP-порт
   Тип значения: REG_DWORD
   Данные значения: (доступный порт)

2. Проверьте подключение TCP-портов к портам верхнего диапазона, которые вы записали. Для этого выполните следующую команду:

   Например, выполните следующие команды:

   Если состояние порта — FILTERED, проверьте трассировку сети, чтобы определить, где заблокирован пакет.

3. Тестирование DNS. Убедитесь, что конечный контроллер домена может разрешать записи CNAME и HOST исходного контроллера домена. И убедитесь, что разрешенный IP-адрес является фактическим IP-адресом исходного контроллера домена. Если DNS указывает на старый или недопустимый IP-адрес, выполняется попытка подключения RPC к неправильному исходному контроллеру домена.