Контроллер домена Windows Server регистрирует событие 2095 служб каталогов при обнаружении отката USN

  • Статья

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

Применимо к: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер базы знаний: 875495

Примечание.

Эта статья предназначена только для агентов технической поддержки и ИТ-специалистов. Если вы ищете помощь по проблеме, обратитесь в сообщество Майкрософт.

Сводка

В этой статье описывается сбой автоматической репликации Active Directory, вызванный откатом последовательного номера обновления (USN). Откат USN происходит при неправильном восстановлении или вставке более старой версии базы данных Active Directory.

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

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

Пример записи журнала события 2095

Log Name:      <Service name> Service  
Source:        Microsoft-Windows-ActiveDirectory_DomainService  
Date:          <DateTime>
Event ID:      2095  
Task Category: Replication  
Level:         Error  
Keywords:      Classic  
User:          <USER NAME>  
Computer:      SERVER.contoso.com  
Description:

During an Active Directory Domain Services replication request, the local domain controller (DC) identified a remote DC which has received replication data from the local DC using already-acknowledged USN tracking numbers.

Because the remote DC believes it is has a more up-to-date Active Directory Domain Services database than the local DC, the remote DC will not apply future changes to its copy of the Active Directory Domain Services database or replicate them to its direct and transitive replication partners that originate from this local DC.

If not resolved immediately, this scenario will result in inconsistencies in the Active Directory Domain Services databases of this source DC and one or more direct and transitive replication partners. Specifically the consistency of users, computers and trust relationships, their passwords, security groups, security group memberships and other Active Directory Domain Services configuration data may vary, affecting the ability to log on, find objects of interest and perform other critical operations.

To determine if this misconfiguration exists, query this event ID using http://support.microsoft.com or contact your Microsoft product support.

The most probable cause of this situation is the improper restore of Active Directory Domain Services on the local domain controller.

User Actions:

If this situation occurred because of an improper or unintended restore, forcibly demote the DC.

В следующих разделах описывается обнаружение и восстановление после отката USN в контроллере домена под управлением Windows Server.

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

Windows Server 2012 добавлена поддержка идентификатора поколения Hyper-Visor (GenID). Это позволяет виртуальному гостю обнаруживать тома диска с новым идентификатором и реагировать на новый GenID. В Active Directory службы каталогов реагируют так, как если бы контроллер домена был восстановлен из резервной копии. Затем создается новый идентификатор вызова. Используя новый идентификатор вызова, экземпляр базы данных может безопасно повторно ввести репликацию в лесу.

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

Поддерживаемые методы резервного копирования 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. Теневые копии с одним моментом времени также называются моментальными снимками. Дополнительные сведения см. в разделе "Служба теневого копирования томов" в служба поддержки Майкрософт.

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

Типичное поведение, возникающее при восстановлении резервной копии состояния системы с поддержкой Active Directory

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

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

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

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

Программное обеспечение и методологии, вызывающие откат USN

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

  • Запуск контроллера домена Active Directory, файл базы данных которого был восстановлен (скопирован) на место с помощью программы создания образов, например Norton Ghost.

  • Запуск ранее сохраненного образа виртуального жесткого диска контроллера домена. Следующий сценарий может вызвать откат USN:

    1. Повышение уровня контроллера домена в виртуальной среде размещения.
    2. Создайте snapshot или альтернативную версию виртуальной среды размещения.
    3. Позвольте контроллеру домена продолжить реплицировать входящий и исходящий репликацию.
    4. Запустите файл образа контроллера домена, созданный на шаге 2.

  • Примерами виртуализированных сред размещения, которые вызывают этот сценарий, являются Microsoft Virtual PC 2004, Microsoft Virtual Server 2005 и EMC VMWARE. Другие виртуализированные среды размещения также могут вызвать этот сценарий.

  • Дополнительные сведения об условиях поддержки для контроллеров домена в виртуальных средах размещения см. в статье Что следует учитывать при размещении контроллеров домена Active Directory в виртуальных средах размещения.

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

    • Сценарий A. Запуск нескольких копий Active Directory, расположенных в подсистеме диска, в котором хранится несколько версий тома

      1. Повышение уровня контроллера домена. Найдите файл Ntds.dit в подсистеме диска, которая может хранить несколько версий тома, на котором размещен файл Ntds.dit.
      2. Используйте подсистему диска, чтобы создать snapshot тома, на котором размещается файл Ntds.dit для контроллера домена.
      3. Продолжайте разрешать контроллеру домена загружать Active Directory из тома, созданного на шаге 1.
      4. Запустите контроллер домена, сохраненный базой данных Active Directory на шаге 2.

    • Сценарий Б. Запуск Active Directory с других дисков в неработающем зеркало

      1. Повышение уровня контроллера домена. Найдите файл Ntds.dit на зеркальном диске.
      2. Разорвать зеркало.
      3. Продолжайте входящую репликацию и исходящую репликацию с помощью файла Ntds.dit на первом диске в зеркало.
      4. Запустите контроллер домена с помощью файла Ntds.dit на втором диске в зеркало.

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

Корпорация Майкрософт не поддерживает какой-либо другой процесс, который принимает snapshot элементов системного состояния контроллера домена Active Directory и копирует элементы этого состояния системы в образ операционной системы. Если администратор не вмешается, такие процессы вызывают откат USN. Такой откат USN приводит к тому, что партнеры прямой и транзитивной репликации неправильно восстановленного контроллера домена имеют несогласованные объекты в базах данных Active Directory.

Последствия отката USN

При откате USN изменения объектов и атрибутов не реплицируются контроллерами домена назначения, которые ранее видели USN.

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

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

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

  1. Администратор продвигает три контроллера домена в домене. (В этом примере контроллерами домена являются DC1, DC2 и DC2, а домен — Contoso.com.) DC1 и DC2 являются партнерами по прямой репликации. DC2 и DC3 также являются прямыми партнерами по репликации. DC1 и DC3 не являются партнерами прямой репликации, но получают исходные обновления транзитивно через DC2.

  2. Администратор создает 10 учетных записей пользователей, соответствующих usn от 1 до 10 в DC1. Все эти учетные записи реплицируются в DC2 и DC3.

  3. Образ диска операционной системы записывается в DC1. Это изображение содержит запись объектов, соответствующих локальным usN от 1 до 10 в DC1.

  4. В Active Directory внесены следующие изменения:

    • Пароли для всех 10 учетных записей пользователей, созданных на шаге 2, сбрасываются в DC1. Эти пароли соответствуют usn от 11 до 20. Все 10 обновленных паролей реплицируются в DC2 и DC3.
    • В DC1 создается 10 новых учетных записей пользователей, соответствующих USN 21–30. Эти 10 учетных записей пользователей реплицируются в DC2 и DC3.
    • В DC1 создается 10 новых учетных записей компьютеров, соответствующих USN 31–40. Эти 10 учетных записей компьютеров реплицируются в DC2 и DC3.
    • В DC1 создается 10 новых групп безопасности, соответствующих USN 41–50. Эти 10 групп безопасности реплицируются в DC2 и DC3.

  5. DC1 испытывает сбой оборудования или программного обеспечения. Администратор использует программу создания образа диска для копирования образа операционной системы, созданного на шаге 3, на место. DC1 теперь начинается с базы данных Active Directory, которая знает об usn от 1 до 10.

    Так как образ операционной системы был скопирован на место, а поддерживаемый метод восстановления состояния системы не использовался, DC1 продолжает использовать тот же идентификатор вызова, который создал начальную копию базы данных, и все изменения до USN 50. DC2 и DC3 также поддерживают один и тот же идентификатор вызова для DC1, а также актуальный вектор USN 50 для DC1. (Актуальный вектор — это текущее состояние последних исходных обновлений, возникающих на всех контроллерах домена для определенной секции каталога.)

    Если администратор не вмешается, DC2 и DC3 не реплицируют входящий трафик изменения, соответствующие локальным usN 11–50, исходящим из DC1. Кроме того, в соответствии с идентификатором вызова, который использует DC2, DC1 уже знает об изменениях, которые соответствуют USN от 11 до 50. Поэтому DC2 не отправляет эти изменения. Так как изменения, внесенные в шаге 4, не существуют в DC1, запросы на вход завершаются ошибкой "доступ запрещен". Эта ошибка возникает из-за того, что пароли не совпадают или учетная запись не существует, когда более новые учетные записи случайным образом проходят проверку подлинности с помощью DC1.

  6. Администраторы, отслеживающие работоспособность репликации в лесу, отмечают следующие ситуации:

    • Программа Repadmin /showreps командной строки сообщает, что двусторонняя репликация Active Directory между DC1 и DC2, а также между DC2 и DC3 выполняется без ошибок. В этой ситуации трудно обнаружить любое несоответствие репликации.

    • События репликации в журналах событий службы каталогов контроллеров домена под управлением Windows Server не указывают на сбои репликации в журналах событий службы каталогов. В этой ситуации трудно обнаружить любое несоответствие репликации.

    • Пользователи и компьютеры Active Directory или средство администрирования Active Directory (Ldp.exe) отображает разное количество объектов и метаданные объектов, если секции доменных каталогов в DC2 и DC3 сравниваются с разделом в DC1. Разница заключается в наборе изменений, сопоставленных с изменениями USN с 11 по 50 на шаге 4.

      Примечание.

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

    • Запросы проверки подлинности пользователей для 10 учетных записей пользователей, созданных на шаге 2, иногда создают ошибку "доступ запрещен" или "неправильный пароль". Эта ошибка может возникать из-за несоответствия паролей между этими учетными записями пользователей в DC1 и учетными записями в DC2 и DC3. Учетные записи пользователей, которые сталкиваются с этой проблемой, соответствуют учетным записям пользователей, созданным на шаге 4. Учетные записи пользователей и сбросы паролей на шаге 4 не реплицировались на другие контроллеры домена в домене.

  7. DC2 и DC3 начинают реплицировать входящие обновления, которые соответствуют номерам USN, превышающим 50 из DC1. Репликация выполняется обычно без вмешательства администратора, так как превышено ранее записанное пороговое значение вектора актуальности USN 50. (USN 50 — это векторный USN актуальности, записанный для DC1 в DC2 и DC3 до того, как DC1 был отключен и восстановлен.) Однако новые изменения, соответствующие USN 11–50 в исходном DC1 после неподдерживаемого восстановления, никогда не будут реплицироваться в DC2, DC3 или их транзитивных партнеров по репликации.

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

  • Топология и расписание репликации Active Directory

  • Наличие контроллеров домена в лесу и роли, которые эти контроллеры домена удерживают

    Примечание.

    К этим ролям относятся глобальный каталог, выделение относительных идентификаторов (RID) и операции, master роли. (Роли master операций также называются гибкими операциями master или FSMO.)

  • Существование доменных секций и секций приложений в лесу

  • Существование групп безопасности и их текущее членство в группах

  • Регистрация записей DNS в зонах DNS, интегрированных с Active Directory

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

Обнаружение отката USN на контроллере домена Windows Server

Так как откат USN трудно обнаружить, контроллер домена Windows Server 2003 с пакетом обновления 1 (SP1) или более поздней версии регистрирует событие 2095, когда исходный контроллер домена отправляет ранее признанный номер USN на контроллер домена назначения без соответствующего изменения идентификатора вызова.

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

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

  • Исходный контроллер домена отправляет ранее признанный номер USN на контроллер домена назначения.
  • Соответствующее изменение в идентификаторе вызова отсутствует.

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

Вы можете подозревать, что произошел откат USN. Однако коррелирующие события не отображаются в журнале событий службы каталогов. В этом сценарии проверка для записи в реестре Dsa Not Writable. Эта запись предоставляет судебно-медицинские доказательства того, что произошел откат USN.

  • Подраздел реестра: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
  • Запись реестра: Dsa Not Writable
  • Значение: 0x4

Удаление или изменение значения записи реестра Dsa Not Writable вручную переводит контроллер домена отката в состояние постоянно неподдерживаемого. Поэтому такие изменения не поддерживаются. В частности, изменение значения удаляет поведение карантина, добавленное кодом обнаружения отката USN. Разделы Active Directory на контроллере домена отката будут постоянно несовместимы с партнерами прямой и транзитивной репликации в том же лесу Active Directory.

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

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

Ссылки