Неполномочное восстановление AD DS

Неполномочное восстановление AD DSНеполномочное восстановление AD DS выполняется средствами Windows Server Backup и может потребоваться в самых разных случаях. Сценарий восстановления также зависит от используемой версии операционной системы и версии гипервизора (если контроллеры домена работают в виртуальной среде). Большинство из возможных вариантов я рассмотрю в этой статье.


Если вам интересна тематика Windows Server, рекомендую обратиться к тегу  Windows Server  на моем блоге.


Неполномочное восстановление AD DS

Выполнять неполномочное восстановление будем через бэкап System State нашего КД.

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

Немного теории

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

  1. Система возвратится в состояние на момент снятие бэкапа (это очевидно);
  2. Будет сгенерирован новый DSA Invocation ID;
  3. Текущий пул RID будет сброшен и получен новый;
  4. Произойдет неполномочное восстановление SYSVOL.

Теперь о каждом пункте подробнее, начиная со 2.

DSA Invocation ID

Invocation ID — это уникальный guid-идентификатор базы данных ntds.dit. Сбрасывая этот параметр, контроллер домена сообщает своим «соседям» о том, что он был восстановлен из бэкапа. То есть, по сути, восстановленный КД становится другим источником репликации и ему требуются все изменения в AD, начиная с момента создания бэкапа.

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

AD работает таким образом, что между контроллерами домена передаются лишь последние изменения, а не вся база целиком. Каждый КД поддерживает значение USN своих соседей (up-to-dateness vector). Если другой КД вдруг сообщает свой USN и он оказывается выше «запомненного», значит на другом КД произошли изменения и их надо получить посредством репликации данных. Откат к состоянию бэкапа возвращает максимальный последовательный номер изменений восстановленного сервера к меньшему значению. В итоге все другие КД, получая с восстановленного контроллера его USN, будут уверены, что все изменения с него уже реплицированы, ведь их «запомненные» значения USN восстановленного КД будет больше. Все изменения, внесенные в AD на восстановленном КД в промежутке восстановленного USN и «запомненных» USN на других КД, никогда не будут реплицированы на другие контроллеры. Подобная ситуация приведет к рассогласованию баз данных.

RID Pool

Любой принципал безопасности (пользователь, компьютер, группа) в AD имеет уникальный идентификатор, называемый SID. SID, в свою очередь, состоит из нескольких значений, последним из которых является относительный идентификатор — RID.

Примечание: за выдачу пулов относительных идентификаторов отвечает держатель роли FSMO RID Master, о котором я подробно рассказывал в статье RID master — Хозяин относительных идентификаторов.

Если на момент создания резервной копии у КД имеется выданный пул идентификаторов (а на деле в 99% случаев так оно и будет, за исключением ситуации, когда на момент бэкапа пул был израсходован полностью, а связи с хозяином RID для получения нового пула не было), то после восстановления из бэкапа контроллер домена начнет использовать этот пул заново и в лесу появятся принципалы безопасности с одинаковыми SID.

Чтобы такой ситуации не было, во время неполномочного восстановления пул RID сбрасывается и запрашивается новый.

Примечание: может так получиться, что восстанавливать из бэкапа придется хозяина RID. На этот счет Microsoft рекомендует не выполнять восстановление, а захватить все необходимые роли с других КД и вместо утраченного контроллера развернуть другой. Тем не менее, восстановление хозяина RID вполне возможно. Главное, чтобы на момент восстановления хозяина RID остальные КД были реплицированы друг с другом и хотя бы один из их был доступен восстановленному КД для выполнения начальной репликации, иначе роль RID master не стартанет.

Если же вы восстанавливаете весь лес AD, не забудьте повысить границу выдаваемого пула 3 и сбросить текущие пулы на контроллерах домена 4.

Переходим к последнему пункту.

SYSVOL restore

Этот момент самый очевидный из всех рассматриваемых. По умолчанию осуществляется именно неполномочное восстановление SYSVOL, чтобы стянуть последние актуальные данные с других КД. Если же необходимо полномочное восстановление 5, то достаточно поставить соответствующую галочку в мастере WSB или выставить флаг -sysvol, если используете командную консоль.

Когда нужно неполномочное восстановление

Неполномочное восстановление может понадобиться в нескольких ситуациях:

  1. Рабочий КД вышел из строя в связи с аппаратными/программными проблемами и нет желания разворачивать полностью свежий КД (например потому что на старом были какие-то важные приложения и данные);
  2. При откате к снимку виртуальной машины. Если:
    • КД имеет ОС старше Windows Server 2012;
    • Гипервизор не поддерживает VM-Generation ID (все до Windows Server 2012), вне зависимости от гостевой ОС.

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

Подготовка

К моменту восстановления у вас должны быть:

  1. Резервная копия (я подключил к виртуализованному КД отдельный диск, на который ранее был скопирован бэкап состояния системы);
  2. Пароль DSRM. Придется загружаться в режиме восстановления AD, сервисы будут остановлены, а потому зайти под доменной учеткой не получится, только под локальным админом.

Примечание: если пароль DSRM безвозвратно утерян, его можно сбросить 6. Разумеется такой вариант возможен только при локальном входе на КД.

Примечание: если бэкапа системы нет, то все же остается возможность «сообщить» партнерам по репликации о том, что КД был восстановлен. Сделать это можно по инструкции из официальной документации 7. Выполнять эту процедуру нужно аккуратно, убедившись на 100% в корректности завершения всех шагов. Обратите внимание на комментарий в статье:

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

Переходим к кульминации.

Восстановление

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

Есть несколько способов загрузить сервер в режиме восстановления служб каталогов и я воспользуюсь самым простым из них — нажатие F8 во время загрузки.

Примечание: если вам интересно, то второй способ — с помощью утилиты bcdedit, выполнив последовательно команды:

bcdedit /set safeboot dsrepair
shutdown -t 0 -r
После выполнения восстановления выполните команду bcdedit /deletevalue safeboot для загрузки в нормальном режиме.
Третий способ — использовать всем знакомую утилиту Msconfig (Загрузка -> Параметры загрузки -> Безопасный режим -> Восстановление Active Directory). 
После восстановления также не забудьте вернуть сервер в нормальный режим загрузки.

Итак, нажав F8 дожидаемся загрузки сервера и входим под учетной записью локального администратора:

Неполномочное восстановление AD DS 02

Вводим пароль DSRM, дожидаемся пока система загрузится.

Неполномочное восстановление AD DS 03

Не забудьте выбрать Восстановление системы:

Неполномочное восстановление AD DS 04

После этого увидите предупреждение:

Неполномочное восстановление AD DS 05

Подтверждаем, далее нажимаем Восстановить и снова соглашаемся с всплывшим предупреждением. Дожидаемся окончания процесса восстановления и перезагружаемся.

На этом восстановление завершено.

comments powered by HyperComments