Рекомендации по защите Active Directory: Часть 2. Восстановление контроллера домена

Все публикации серии:

Это вторая статья в серии, посвященной защите Active Directory (AD) с помощью Veeam. В предыдущей статье рассказывалось о процедуре бэкапе физических и виртуальных контроллеров домена (DC). Сегодня поговорим об их восстановлении.

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

Доскональное знание своей инфраструктуры очень помогает при планировании восстановления AD. Сколько контроллеров домена в вашей среде — один или несколько? Это контроллеры домена, доступные для чтения и записи (RWDC) или только для чтения (RODC)? Вышел из строя только один контроллер, или повреждена вся инфраструктура AD? Если у вас несколько контроллеров, используете ли вы для синхронизации изменений между разными контроллерами домена службу репликации файлов (FRS) или перешли на распределенную DFSR для синхронизации изменений между разными контроллерами домена? Вот лишь часть вопросов, ответы на которые вам необходимо знать, чтобы успешно восстанавливать данные.

Примечание: FRS — служба ОС Windows Server 2000 и Windows Server 2003, предназначенная для распределения общих файлов и объектов групповых политик (GPO). В более поздних версиях ОС Windows Server она была заменена службой репликации DFSR.Начиная с Windows Server 2008, репликация DFSR стала вариантом настройкой по умолчанию для репликации каталога SYSVOL. Если на первом контроллере домена функциональный режим работы был установлен на Windows Server 2008 или выше, вы используете репликацию DFSR. Чтобы понять, используется ли в вашем домене служба FRSR или репликация DFSR, прочитайте эту статью. А здесь рассказывается о преимуществах репликации DFS перед FRS.

Восстановление контроллера домена в режиме «non-authoritative»

Собираясь восстанавливать контроллер домена, необходимо сначала определить, будет ли достаточен режим «non-authoritative» или потребуется воспользоваться режимом «authoritative». Разница между этими двумя режимами заключается в том, что при режиме восстановлении «non-authoritative» контроллер домена понимает, что он был в течение некоторого времени отключен. Поэтому он позволяет другим контроллерам домена обновить его базу данных, внеся в нее последние изменения, произошедшие во время его отсутствия. При «authoritative» восстановлении контроллер считает, что только на нем имеется истинно верная база данных, поэтому именно он получает полномочия на обновление баз данных других контроллеров домена на основе своих данных.

В большинстве сценариев восстановления вам потребуется режим «non-authoritative», поскольку в среде имеется несколько контроллеров домена. Кроме того, «authoritative» восстановление контроллера домена может привести к новым проблемам. Именно на этом основана логика Veeam Backup & Replication: по умолчанию выполняется «non-authoritative» восстановление DC, поскольку считается, что инфраструктура выстроена с избыточностью и включает в себя несколько контроллеров домена. Чтобы выполнить «authoritative» восстановление с помощью Veeam, необходимо осуществить некоторые дополнительные действия, которые описаны ниже.

ПРИМЕЧАНИЕ. Еще один распространенный вариант действий при отказе контроллера домена — распределить его роли между другими контроллерами и очистить метаданные, если восстановление маловероятно. В этом случае вы поручаете другим DC выполнять функции отказавшего, и вам не нужно его восстанавливать.

Давайте вернемся к файлам резервных копий, которые были описаны в предыдущей статье. Восстановить контроллер домена из резервной копии Veeam Backup & Replication очень легко. Для этого нужно:

• Выбрать мастер восстановления в пользовательском интерфейсе
• Найти нужный контроллер домена
• Выбрать в меню восстановления вариант восстановления ВМ целиком (Restore Entire VM)
• Затем указать точку восстановления
• Выбрать исходное или новое место восстановления
• Завершить процедуру

Самое замечательное здесь, что благодаря обработке данных с учетом состояния приложений при создании резервной копии, вам больше ничего не потребуется делать. Veeam распознает контроллер домена в указанной ВМ и аккуратно восстановит его, используя особый алгоритм:

• Восстановление файлов и жестких дисков ВМ
• Загрузка ОС в специальном режиме восстановления доменных сервисов (DSRM mode)
• Применение настроек
• Перезапуск в обычном режиме

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

Рис. 1. Veeam Backup & Replication: Восстановление ВМ целиком

Здесь можно прочитать о восстановлении «на голое железо» резервной копии с помощью Veeam Endpoint Backup. Вам потребуется заранее подготовленный аварийный загрузочный диск Veeam и доступ к самой резервной копии (на USB-носителе или сетевом диске). Помните, что в данном случае особая логика Veeam Backup & Replication использоваться не будет. После восстановления с помощью Veeam Endpoint Backup ваш контроллер домена загрузится в режиме восстановления. Вам нужно будет решить, хотите ли вы менять ключи реестра или сразу перезапустите ВМ в обычном режиме. Возможно, эта статья базы знаний будет полезна.

Рис. 2. Veeam Endpoint Backup: восстановление «на голое железо»

Восстановление контроллера домена в режиме «authoritative»

С большой долей вероятности вам не потребуется этот режим восстановления. Однако давайте познакомимся с ним поближе, чтобы вы поняли, почему это так. Этот режим может быть использован, когда вы пытаетесь восстановить верную копию контроллера домена в среде с несколькими контроллерами домена, при том, что вся структура AD по какой-то причине повреждена (напр., вредоносное ПО, вирус и т. п.). В этой ситуации вы предпочтете, чтобы поврежденные котроллеры домена принимали изменения от вновь восстановленного контроллера.

ПРИМЕЧАНИЕ. Выполняемые действия сходны с тем, что происходит при использовании Veeam SureBackup для восстановления контроллера домена в изолированной среде.

Чтобы выполнить восстановление удаленного объекта или контейнера в режиме «authoritative» и принудить контроллер домена скопировать восстановленные данные с этого DC на другие контроллеры:

1. Выберите в Veeam операцию восстановления ВМ полностью: программа автоматически выполнит стандартное восстановление DC в режиме «non-authoritative» (см. выше).
2. При втором перезапуске DC откройте мастер загрузки (нажмите F8), выберите пункт DSRM и войдите в систему с данными учетной записи DSRM (те данныеучетная запись, которыеую вы настроиливвели, когда назначали сделав данный компьютер контроллером домена).
3. Откройте командную строку и запустите утилиту ntdsutil
4. Используйте следующие команды: activate instance ntds; затем authoritative restore; затем restore object “distinguishedName” или restore subtree “distinguishedName”
   Пример: restore subtree “OU=Branch,DC=dc,DC=lab, DC=local.
5. Подтвердите «authoritative» восстановление и перезапустите сервер после завершения операции.

Процедура «authoritative» восстановления SYSVOL (при использовании службы DFSR) осуществляется следующим образом:

1. Выполните «non-authoritative» восстановление контроллера домена (например, восстановление ВМ целиком в Veeam Backup & Replication).
2. При второй загрузке перейдите в ветку реестра HKLM\System\CurrentControlSet\Services\DFSR, создайте ключ Restore, а затем создайте строку SYSVOL со значением authoritative.
   Это значение будет считано службой DFSR. Если значение не установлено, по умолчанию производится восстановление SYSVOL в режиме «non-authoritative»
3. Перейдите к HKLM\System\CurrentControlSet\Control\BackupRestore, создайте ключ SystemStateRestore, затем создайте строку LastRestoreId с любым значением GUID. Например: 10000000-0000-0000-0000-000000000000.
4. Перезапустите службу DFSR.

Рис. 3. Восстановление SYSVOL в режиме «authoritative» (служба DFSR)

Процедура «authoritative» восстановления SYSVOL (при использовании службы FRS):

1. Выполните «non-authoritative» восстановление контроллера домена (например, восстановление ВМ целиком в Veeam Backup & Replication).
2. При второй загрузке перейдите в ветку реестра HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup и измените значение ключа Burflag на 000000D4 (hex) или 212 (dec).
   Это обеспечит принудительное копирование данных на контроллеры домена, использующие старую технологию FRS, в «authoritative» режиме. Подробнее о восстановлении FRS.
3. Перезапустите службу NTFRS.

В этой статье я рассмотрел восстановление отдельного контроллера домена. Однако чаще всего при работе с AD вам требуется восстановить случайно удаленный объект, и в этом случае восстанавливать контроллер целиком — не лучший вариант. В следующей статье я расскажу о восстановлении отдельных объектов каталога AD с помощью собственных инструментов Microsoft и утилиты Veeam Explorer для Active Directory.

Также вас могут заинтересовать:

• Статья Восстановление объектов Active Directory
• Принятые правила при «authoritative» восстановлении (TechNet)
• Восстановление леса Active Directory
• Значение ключей реестра, используемых при резервном копировании и восстановлении
• «Authoritative» и «non-authoritative» восстановление SYSVOL при использовании NTFRS или DFSR
• Подробная информация о Veeam Explorer для Microsoft Active Directory