Архитектура виртуализованных контроллеров доменов

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

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

• Архитектура клонирования виртуализированного контроллера домена

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

Архитектура клонирования виртуализированного контроллера домена

Обзор

Клонирование виртуализированного контроллера домена основано на предоставлении идентификатора ИД создания виртуальной машины (VM-Generation ID) платформой низкоуровневой оболочки для обнаружения создания виртуальной машины. Доменные службы Active Directory изначально сохраняют значение этого идентификатора в своей базе данных (NTDS.DIT) во время повышения уровня контроллера домена. При загрузке виртуальной машины текущее значение ИД создания виртуальной машины, заданное в виртуальной машине, сравнивается со значением в базе данных. Если два значения отличаются, контроллер домена сбрасывает идентификатор вызова и отключает карта пул RID, тем самым предотвращая повторное использование USN или потенциальное создание повторяющихся субъектов безопасности. После этого контроллер домена выполняет поиск файла DCCloneConfig.xml в расположениях, указанных в шаге 3 процедуры Cloning Detailed Processing. Если он находит файл DCCloneConfig.xml, он завершает развертывание в качестве клона, поэтому он инициирует клонирование для подготовки себя в качестве дополнительного контроллера домена путем повторного воспроизведения с помощью существующего NTDS. Содержимое DIT и SYSVOL, скопированное из исходного носителя.

В смешанной среде, где некоторые гипервизоры поддерживают VM-GenerationID и другие не поддерживают, возможно, что клонированный носитель будет случайно развернут на гипервизоре, который не поддерживает VM-GenerationID. Наличие файла DCCloneConfig.xml указывает на намерение администратора клонировать контроллер домена. Таким образом, если во время загрузки найден файл DCCloneConfig.xml, но vm-GenerationID не предоставляется из узла, клон контроллер домена загружается в режим восстановления служб каталогов (DSRM), чтобы предотвратить любое влияние на остальную часть среды. Носитель клона затем можно переместить в низкоуровневую оболочку, которая поддерживает ИД создания виртуальной машины, после чего попытку клонирования можно повторить.

Если клонированный носитель развертывается на гипервизоре, поддерживающем VM-GenerationID, но не предоставляется файл DCCloneConfig.xml, так как контроллер домена обнаруживает изменение идентификатора виртуальной машины между его DIT и одним из новой виртуальной машины, он активирует средства защиты, чтобы предотвратить повторное использование USN и избежать повторяющихся идентификаторов SID. Однако клонирование не будет инициировано, поэтому вторичный контроллер домена будет продолжать выполняться под тем же удостоверением, что и исходный контроллер домена. Этот дополнительный контроллер домена следует как можно раньше удалить из сети, чтобы предотвратить возникновение несогласованностей в среде.

Подробный процесс клонирования

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

Начальная операция клонирования

Клонирование операции повтора

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

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

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

   2. Даже если значение NULL, следующее создание компьютера будет означать, что он все еще клонирует, так как новый идентификатор поколения виртуальной машины не будет соответствовать.

   3. Идентификатор создания виртуальной машины задается после следующей перезагрузки контроллера домена и не реплика te.

2. После этого виртуальная машина считывает ИД создания виртуальной машины, предоставленный драйвером VMGenerationCounter. Она сравнивает эти два ИД создания виртуальной машины.

   1. Если идентификаторы соответствуют, это не новая виртуальная машина и клонирование не будет продолжаться. Если существует файл DCCloneConfig.xml, контроллер домена переименует его с отметкой времени и даты, чтобы предотвратить клонирование. Сервер продолжает загружаться в обычном режиме. Именно так проходит каждая перезагрузка любого виртуального контроллера домена в Windows Server 2012.

   2. Если два идентификатора не соответствуют, это новая виртуальная машина, содержащая NTDS. DIT из предыдущего контроллера домена (или это восстановленный моментальный снимок). Если файл DCCloneConfig.xml существует, контроллер домена приступает к выполнению операций клонирования. В противном случае он продолжает выполнение операций восстановления моментального снимка. См. раздел Virtualized domain controller safe restore architecture.

   3. Если гипервизор не предоставляет идентификатор создания виртуальной машины для сравнения, но есть файл DCCloneConfig.xml, гость переименовывает файл, а затем загружается в DSRM для защиты сети от повторяющегося контроллера домена. Если файл dccloneconfig.xml отсутствует, гостевая загрузка обычно загружается (с потенциалом для дубликата контроллера домена в сети).

3. Служба NTDS проверяет имя значения реестра DWORD VDCisCloning (в разделе HKEY_Local_Machine\System\CurrentControlSet\Services\Ntds\Parameters).

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

   2. Если для него уже задано значение 0x1, это попытка клонирования повтора, в которой произошел сбой предыдущей операции клонирования. Меры безопасности дублирования объектов VDC не принимаются, так как они уже должны были выполняться один раз раньше и не нужно было изменять гостевой несколько раз.

4. Выполняется запись имени значения реестра DWORD IsClone (в разделе Hkey_Local_Machine\System\CurrentControlSet\Services\NTDS\Parameters)

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

6. Служба NTDS пытается считать файл DcCloneConfig.xml в одном из трех допустимых расположениях (рабочий каталог DSA, %windir%\NTDS или съемный носитель с возможностью чтения и записи, поиск выполняется по буквам диска в корневом каталоге).

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

   2. Если файл находится в допустимом расположении, служба NTDS проверяет его параметры. Если файл пуст (или пусты отдельные параметры), то NTDS автоматически настраивает значения для этих параметров.

   3. Если файл DcCloneConfig.xml существует, но содержит какие-либо недопустимые записи или не может быть прочитан, клонирование завершается со сбоем, а гость загружается в режиме восстановления служб каталогов (DSRM).

7. Гость отключает все функции автоматической регистрации DNS, чтобы предотвратить случайный перехват имени и IP-адресов исходного компьютера.

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

9. NTDS проверяет отсутствие служб или программ, которые не являются частью DefaultDCCloneAllowList.xml или CustomDCCloneAllowList.xml

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

   2. При отсутствии несовместимостей клонирование продолжается.

10. Если из-за пустых параметров сети в DCCloneConfig.xml будет использоваться автоматическая IP-адресация, гость включает DHCP на сетевых адаптерах, чтобы получить сведения об аренде IP-адресов, сетевой маршрутизации и разрешении имен.

11. Гость находит контроллер домена, на котором выполняется роль FSMO эмулятора PDC. При этом используется служба DNS и протокол DCLocator. Устанавливается подключение RPC и вызывается метод IDL_DRSAddCloneDC для клонирования объекта-компьютера контроллера домена.

    1. Если исходный объект-компьютер гостя содержит расширенное разрешение заголовка домена "'Разрешить контроллеру домена клонировать себя", клонирование продолжается.

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

12. Имя объекта-компьютера доменных служб Active Directory устанавливается аналогичным имени, указанному в файле DCCloneConfig.xml, если оно там есть, или создается автоматически в PDCE. NTDS создает правильный объект параметров NTDS для подходящего логического сайта Active Directory.

    1. Если это клонирование PDC, то гость переименовывает локальный компьютер и перезагружается. После перезагрузки он проходит через шаг 1 – 10 снова, а затем переходит к шагу 13.

    2. Если это реплика клонирование контроллера домена, на этом этапе нет перезагрузки.

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

14. Служба сервера с ролью DS останавливает все службы, связанные с доменными службами Active Directory (NTDS, NTFRS/DFSR, KDC, DNS).

15. Гость принудительно выполняет синхронизацию времени NT5DS (Windows NTP) с другим контроллером домена (в стандартной иерархии службы времени Windows это означает использование PDCE). Гость обращается к PDCE. Все имеющиеся билеты Kerberos записываются на диск.

16. Гость настраивает службы DFSR или NTFRS на автоматический запуск. Гость удаляет все существующие файлы базы данных DFSR и NTFRS (по умолчанию: c:\windows\ntfrs и c:\system volume information\dfsr\<database_GUID>), чтобы принудительно приступить к неавторитативной синхронизации SYSVOL при следующем запуске службы. Гость не удаляет содержимое файла SYSVOL, чтобы предустановить SYSVOL при запуске синхронизации позже.

17. Гость переименовывается. Служба сервера с ролью DS в госте начинает настройку доменных служб Active Directory (повышение уровня), используя имеющийся файл базы данных NTDS.DIT в качестве источника вместо шаблона базы данных, включенного в c:\windows\system32, который используется при обычном повышении.

18. Гость обращается к владельцу роли FSMO хозяина RID для получения нового распределения пула относительных идентификаторов.

19. Процесс повышения уровня создает новый идентификатор вызова и воссоздает объект параметров NTDS для клонированного контроллера домена (при использовании имеющейся базы данных NTDS.DIT это входит в состав повышения домена независимо от клонирования).

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

21. Служба DFSR или FRS запускается, так как нет базы данных, SYSVOL неавторитетно синхронизирует входящий трафик от партнера реплика tion. Этот процесс повторно использует существующие данные в папке SYSVOL, чтобы свести к минимуму сетевой реплика трафик.

22. Гость повторно активирует регистрацию DNS-клиента на компьютере, который получил уникальное имя и параметры сети.

23. Гость запускает модули SYSPREP, указанные элементом DefaultDCCloneAllowList.xml <SysprepInformation> , чтобы свернуть ссылки на предыдущее имя компьютера и идентификатор безопасности.

24. Повышение уровня клонирования выполнено.

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

    2. Гость переименовывает DCCloneConfig.xml с добавленной меткой даты и времени, чтобы она снова не считывалась при следующей загрузке.

    3. Гость удаляет имя значения реестра DWORD VdcIsCloning из раздела HKEY_Local_Machine\System\CurrentControlSet\Services\NTDS\Parameters.

    4. Гость задает для имени значения реестра DWORD "VdcCloningDone" в разделе HKEY_Local_Machine\System\CurrentControlSet\Services\NTDS\Parameters значение 0x1. Windows не использует это значение, а предоставляет его в качестве маркера для третьих сторон.

25. Гость обновляет атрибут msDS-GenerationID в своем клонированном объекте контроллера домена, чтобы он соответствовал текущему ИД создания виртуальной машины гостя.

26. Выполняется перезапуск гостя. Теперь это обычный, рекламный контроллер домена.

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

Обзор

Работа доменных служб Active Directory основана на предоставлении идентификатора ИД создания виртуальной машины (VM-Generation ID) платформой низкоуровневой оболочки для обнаружения восстановления моментального снимка виртуальной машины. Доменные службы Active Directory изначально сохраняют значение этого идентификатора в своей базе данных (NTDS.DIT) во время повышения уровня контроллера домена. Когда администратор восстанавливает машину из предыдущего снимка, текущее значение ИД создания виртуальной машины из виртуальной машины сравнивается со значением в базе данных. Если два значения отличаются, контроллер домена сбрасывает идентификатор вызова и отключает карта пул RID, тем самым предотвращая повторное использование USN или потенциальное создание повторяющихся субъектов безопасности. Существует два сценария, в которых возможно выполнение безопасного восстановления:

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

• Когда моментальный снимок восстанавливается на работающем контроллере домена

  Если виртуализированный контроллер домена в моментальном снимке находится в приостановленном, а не в выключенном состоянии, вам требуется перезапустить доменные службы Active Directory, чтобы активировать новый запрос пула относительных идентификаторов. Вы можете перезапустить доменные службы Active Directory с помощью оснастки "Службы" или Windows PowerShell (Restart-Service NTDS -force).

Следующие разделы содержат подробное описание безопасного восстановления для каждого из сценариев.

Подробный процесс безопасного восстановления

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

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

2. Новый ИД создания виртуальной машины из виртуальной машины сравнивается с ИД создания виртуальной машины из базы данных. Так как два идентификатора не соответствуют, он использует средства защиты виртуализации (см. шаг 3 в предыдущем разделе). После завершения обновления ИД создания виртуальной машины, заданный для объекта-компьютера доменных служб Active Directory, обновляется, чтобы соответствовать новому идентификатору предоставленному узлом низкоуровневой оболочки.

3. Гость применяет следующие меры безопасности виртуализации:

   1. Прекращение действия локального пула относительных идентификаторов.

   2. Установка нового идентификатора вызова для базы данных контроллера домена.

Примечание.

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

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

Примечание.

Предыдущая иллюстрация специально упрощена, чтобы продемонстрировать наиболее основные принципы.

1. В момент времени T1 администратор низкоуровневой оболочки получает моментальный снимок виртуального контроллера домена DC1. При этом DC1 имеет номер последовательного обновления (USN) (на практике это highestCommittedUsn) со значением 100 и InvocationId (на предыдущей схеме это ID) со значением A (на практике это GUID). Значение savedVMGID — это ИД создания виртуальной машины в файле DIT контроллера домена (хранится для объекта-компьютера контроллера домена в атрибуте с именем msDS-GenerationId). VMGID — это текущее значение ИД создания виртуальной машины из драйвера виртуальной машины. Данное значение предоставляется низкоуровневой оболочкой.

2. В более поздний момент времени T2 для этого контроллера домена добавляется 100 пользователей (рассматривайте пользователей в качестве примера обновлений, которые могли иметь место для данного контроллера домена между моментами T1 и T2; реальные обновления могут включать в себя создание пользователей и групп, обновления паролей и атрибутов и т. п.). В данном примере каждое обновление использует один уникальный номер последовательного обновления (USN) (хотя на практике создание пользователя может использовать более одного номера). Перед фиксацией этих обновлений DC1 проверяет, совпадает ли значение ИД создания виртуальной машины в его базе данных (savedVMGID) с текущим значением в драйвере (VMGID). Они одинаковы, так как откат еще не произошел, поэтому обновления фиксируются и USN перемещается до 200, указывая, что следующее обновление может использовать USN 201. Изменения в InvocationId, savedVMGID или VMGID не изменяются. Эти обновления реплицируются на DC2 в рамках следующего цикла репликации. DC2 обновляет его высокий водяной знак (и UptoDatenessVector), представленный здесь просто как DC1(A) @USN = 200. Теперь DC2 оповещен обо всех обновлениях из DC1 в контексте идентификатора InvocationId A до номера последовательного обновления 200.

3. В момент времени T3 моментальный снимок, полученный в момент времени T1, применяется к DC1. Для DC1 был выполнен откат, поэтому его номер последовательного обновления вернулся к 100, указывая, что он может использовать номера с 101 для сопоставления с последующими обновлениями. Однако на данном этапе значение VMGID было бы другим в низкоуровневых оболочках, которые поддерживают ИД создания виртуальной машины.

4. Впоследствии, когда DC1 выполняет любое обновление, он проверяет, совпадает ли значение ИД создания виртуальной машины в его базе данных (savedVMGID) со значением в драйвере виртуальной машины (VMGID). В этом случае это не так же, поэтому DC1 выводит это как свидетельство отката, и он активирует защиту виртуализации; другими словами, он сбрасывает идентификатор вызова (ID = B) и от карта служивает пул RID (не показан на предыдущей схеме). Затем он сохраняет новое значение VMGID в базе данных и фиксирует эти обновления (USN 101 – 250) в контексте нового вызоваId B. В следующем цикле реплика tion DC2 ничего не знает от DC1 в контексте InvocationId B, поэтому он запрашивает все из DC1, связанного с InvocationID B. В результате обновления, выполненные в DC1 после применения моментального снимка, будут безопасно конвергентироваться. Кроме того, набор обновлений, выполненных на DC1 в момент времени T2 (которые были потеряны на DC1 после восстановления снимка), будут реплицированы обратно на DC1 при следующей запланированной репликации, так как они были реплицированы на DC2 (что показано пунктирной линией, возвращающейся к DC1).

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

• При использовании FRS гость останавливает службу NTFRS и задает значение реестра D2 BURFLAGS. Затем она запускает службу NTFRS, которая неавторитативно реплика tes входящий трафик, повторно используя существующие без изменений данные SYSVOL, когда это возможно.

• При использовании DFSR гость останавливает службу DFSR и удаляет файлы базы данных DFSR (расположение по умолчанию: %systemroot%\system volume information\dfsr\database GUID>).< Затем он запускает службу DFSR, которая неавторитетно реплика tes входящий трафик, повторно используя существующие без изменений данные SYSVOL, когда это возможно.

Примечание.

• Если низкоуровневая оболочка не предоставляет ИД создания виртуальной машины для сравнения, она не поддерживает меры безопасности виртуализации, и гость будет работать в качестве виртуализированного контроллера домена под управлением Windows Server 2008 R2 или более ранней версии. Гость реализует карантинную защиту отката номера последовательного обновления при наличии попытки запустить репликацию с номерами последовательного обновления, не превышающими последний наибольший номер, который был зарегистрирован партнерским контроллером домена. Дополнительные сведения о карантинной защите отката номера последовательного обновления см. в разделе USN и откат USN