Active directory восстановление: Восстановление леса AD. Определение способа восстановления леса

Восстановление леса AD. Определение способа восстановления леса

• Статья
• 12/21/2022

применимо к: Windows server 2022, Windows server 2019, Windows Server 2016, Windows Server 2012 и 2012 r2, Windows Server 2008 и 2008 r2

Восстановление всего Active Directory леса предполагает восстановление из резервной копии или переустановку домен Active Directory служб (AD DS) на каждом контроллере домена в лесу. При восстановлении леса каждый домен в лесу восстанавливает состояние во время последнего надежного резервного копирования. Следовательно, операция восстановления приведет к утрате по крайней мере следующих Active Directory данных:

• Все объекты (например, пользователи и компьютеры), добавленные после последней доверенной резервной копии
• Все обновления, внесенные в существующие объекты с момента последнего доверенного резервного копирования
• Все изменения, внесенные в раздел конфигурации или в секцию схемы в AD DS (например, изменения схемы) с момента последней доверенной резервной копии

Для каждого домена в лесу должен быть известен пароль учетной записи администратора домена. Желательно, чтобы это пароль встроенной учетной записи администратора. Чтобы выполнить восстановление состояния системы контроллера домена, необходимо также иметь пароль DSRM. Как правило, рекомендуется архивировать учетную запись администратора и журнал паролей DSRM в надежном месте до тех пор, пока резервные копии действительны, то есть в течение времени существования захоронения или в течение времени существования удаленного объекта, если включена Active Directory корзина. Можно также синхронизировать пароль DSRM с учетной записью пользователя домена, чтобы упростить его запоминание. Дополнительные сведения см. в статье базы знаний 961320. Синхронизация учетной записи DSRM должна выполняться заранее с восстановлением леса в рамках подготовки.

Примечание

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

Определение резервных копий для использования

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

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

«Указанная резервная копия отличается от сервера текущей. Не рекомендуется выполнять восстановление состояния системы с резервной копией на альтернативном сервере, так как сервер может стать непригодным для использования. Вы действительно хотите использовать эту резервную копию для восстановления текущего сервера? «

Если необходимо восстановить Active Directory на другое оборудование, создайте полные резервные копии сервера и запланируйте выполнение полного восстановления сервера.

Важно!

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

1. Выполните полное восстановление сервера, чтобы восстановить операционную систему и все файлы и приложения.
2. Выполните восстановление состояния системы с помощью wbadmin.exe, чтобы пометить SYSVOL как полномочный.

Дополнительные сведения см. в статье базы знаний Майкрософт 249694.

Если время возникновения сбоя неизвестно, проверьте дополнительные сведения о том, как определить резервные копии, в которых хранится Последнее состояние леса. Этот подход является менее предпочтительным. Поэтому настоятельно рекомендуется хранить подробные журналы состояния работоспособности AD DS на ежедневной основе, чтобы при сбое в масштабе леса можно было определить примерное время сбоя. Чтобы обеспечить более быстрое восстановление, следует также создать локальную копию резервных копий.

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

В качестве альтернативы можно также использовать средство Active Directory Database Mount Tool (Dsamain.

exe) и средство протокола LDAP, например Ldp.exe или Active Directory пользователи и компьютеры, чтобы указать, какая резервная копия имеет Последнее состояние в этом лесу. Active Directory средство монтирования баз данных, которое входит в состав Windows server 2008 и более поздних Windows серверных операционных систем, предоставляет Active Directory данные, хранящиеся в резервных копиях или моментальных снимках в качестве сервера LDAP. Затем для просмотра данных можно использовать средство LDAP. Этот подход имеет преимущество не требует перезапуска контроллера домена в режиме восстановления служб каталогов (DSRM) для проверки содержимого резервной копии AD DS.

Дополнительные сведения об использовании средства монтирования баз данных Active Directory см. в разделе пошаговое описание инструмента для подключения к базе данных Active Directory.

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

ntdsutil snapshot . Планируя задачу для периодического создания моментальных снимков, можно получить дополнительные копии Active Directory базы данных с течением времени. Эти копии можно использовать, чтобы лучше определить время сбоя в масштабе леса, а затем выбрать наиболее подходящую резервную копию для восстановления. чтобы создать моментальные снимки, используйте версию ntdsutil , входящую в состав Windows Server 2008 или средства удаленного администрирования сервера (RSAT) для Windows Vista или более поздней версии. целевой контроллер домена может работать под управлением любой версии Windows Server. Дополнительные сведения об использовании команды ntdsutil snapshot см. в разделе snapshot.

Определение контроллеров домена для восстановления

Простота процесса восстановления является важным фактором при принятии решения о том, какой контроллер домена поддается восстановлению. Рекомендуется использовать выделенный контроллер домена для каждого домена, который является предпочитаемым КОНТРОЛЛЕРом домена для восстановления. Выделенный контроллер домена для восстановления упрощает планирование и выполнение восстановления леса, так как используется та же конфигурация источника, которая использовалась для выполнения тестов восстановления.

Вы можете создать скрипт восстановления и не конкурировать с различными конфигурациями, например, если контроллер домена содержит роли хозяина операций или нет, а также является ли он ГЛОБАЛЬным или DNS-сервером.

Примечание

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

Выберите контроллер домена, который наилучшим образом соответствует следующим критериям:

• Доступный для записи контроллер домена. Это обязательный аргумент.

• контроллер домена, выполняющий Windows Server 2012 в качестве виртуальной машины в низкоуровневой оболочке, поддерживающей VM-GenerationID. Этот контроллер домена можно использовать в качестве источника для клонирования.

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

• Контроллер домена с хорошей полной резервной копией сервера. Хорошая резервная копия — это резервная копия, которая может быть успешно восстановлена, заняла несколько дней до сбоя и содержит как можно больше полезных данных.

• КОНТРОЛЛЕР домена, который был сервером системы доменных имен (DNS) до сбоя. Это экономит время, необходимое для переустановки DNS.

• если вы также используете службы Windows Deployment Services, выберите контроллер домена, который не настроен для использования сетевой разблокировки BitLocker. В этом случае сетевая разблокировка BitLocker не поддерживается для первого контроллера домена, который восстанавливается из резервной копии во время восстановления леса.

  сетевая разблокировка BitLocker в качестве единственного предохранителя ключа не может использоваться на контроллерах домена, где развернута Windows служб развертывания (WDS), так как это приводит к ситуации, когда первый контроллер домена требует Active Directory и WDS для разблокировки. Но перед восстановлением первого контроллера домена Active Directory еще не доступен для WDS, поэтому он не может разблокировать.

  Чтобы определить, настроен ли контроллер домена для использования сетевой разблокировки BitLocker, убедитесь, что сертификат сетевой разблокировки указан в следующем разделе реестра:

  HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftSystemCertificatesFVE_NKP

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

Указание текущей структуры леса и функций контроллера домена

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

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

Имя контроллера домена	Операционная система	FSMO	Сборка мусора	Контроллер домена только для чтения	Backup	DNS	Основные серверные компоненты	ВМ	VM-GenID
DC_1	Windows Server 2012	Хозяин схемы, хозяин именования доменов	Да	Нет	Да	Нет	Нет	Да	Да
DC_2	Windows Server 2012	Нет	Да	Нет	Да	Да	Нет	Да	Да
DC_3	Windows Server 2012	Хозяин инфраструктуры	Нет	Нет	Нет	Да	Да	Да	Да
DC_4	Windows Server 2012	Эмулятор основного контроллера домена, хозяин RID	Да	Нет	Нет	Нет	Нет	Да	Нет
DC_5	Windows Server 2012	Нет	Нет	Нет	Да	Да	Нет	Да	Да
RODC_1	Windows Server 2008 R2	Нет	Да	Да	Да	Да	Да	Да	Нет
RODC_2	Windows Server 2008	Нет	Да	Да	Нет	Да	Да	Да	Нет

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

В этом примере есть четыре кандидата для резервного копирования: DC_1, DC_2, DC_4 и DC_5. Из этих кандидатов резервного копирования вы восстанавливаете только одно. Рекомендуемый контроллер домена DC_5 по следующим причинам.

• он удовлетворяет требованиям к использованию в качестве источника для виртуализованного клонирования контроллеров домена, то есть он запускается Windows Server 2012 как виртуальный контроллер домена в гипервизоре, поддерживающем VM-GenerationID, запускает программное обеспечение, которое разрешено клонировать (или может быть удалено, если его невозможно клонировать). После восстановления роль эмулятора основного контроллера домена будет захвачена на этом сервере и может быть добавлена в группу клонированных контроллеров доменов для домена.
• Он выполняет полную установку Windows Server 2012. Контроллер домена, на котором установлена установка Server Core, может быть менее удобен для восстановления.
• Это DNS-сервер. Поэтому переустановка DNS не требуется.

Примечание

Поскольку DC_5 не является сервером глобального каталога, он также имеет преимущество в том, что глобальный каталог не нужно удалять после восстановления. но независимо от того, является ли контроллер домена сервером глобального каталога, не является деЦисиве фактором, так как начинается с Windows Server 2012, все контроллеры домена по умолчанию являются серверами глобального каталога, а после восстановления в рамках процесса восстановления леса рекомендуется удалять и добавлять глобальный каталог.

Восстановление леса в режиме изоляции

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

Примечание

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

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

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

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

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

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

Контроллеры RODC могут продолжать работу, пока доступные для записи контроллеры домена находятся в автономном режиме. Ни один другой контроллер домена не будет напрямую реплицировать изменения с любого контроллера домена только для чтения (особенно без изменений контейнера схемы или конфигурации), так что они не будут иметь тот же риск, что и записываемые контроллеры домена во время восстановления. После восстановления и подключения всех доступных для записи контроллеров домена следует перестроить все контроллеры RODC.

Контроллеры RODC будут по-прежнему разрешать доступ к локальным ресурсам, кэшированным на соответствующих сайтах, в то время как операции восстановления будут выполняться параллельно. Локальные ресурсы, которые не кэшируются на RODC, будут иметь запросы на проверку подлинности, перенаправляемые на доступный для записи контроллер домена. Эти запросы завершатся ошибкой, так как доступные для записи контроллеры домена находятся в автономном режиме. Некоторые операции, такие как изменение пароля, также не будут работать до тех пор, пока не будет восстановлен доступный для записи контроллер домена.

Если вы используете архитектуру сети типа «звезда», вы можете сначала сосредоточиться на восстановлении доступных для записи контроллеров домена на центральных сайтах. Позже можно перестроить Контроллеры RODC на удаленных сайтах.

Next Steps

• Восстановление леса AD — необходимые условия
• Восстановление леса AD — Девисинг план восстановления пользовательского леса
• Восстановление леса AD. обнаружение проблемы
• Восстановление леса AD. Определение способа восстановления
• Восстановление леса AD — выполнение начального восстановления
• Восстановление леса AD — процедуры
• Восстановление леса AD — часто задаваемые вопросы
• Восстановление леса Active Directory. Восстановление одного домена в лесу с несколькими доменами
• восстановление леса active directory — восстановление леса с контроллерами домена Windows Server 2003

Восстановление леса AD — выполнение начального восстановления

Twitter LinkedIn Facebook Адрес электронной почты

• Статья
• 09/29/2022

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

В этом разделе содержатся следующие шаги:

• Восстановление первого контроллера домена с возможностью записи в каждом домене
• Повторное подключение каждого восстановленного контроллера домена с возможностью записи к сети
• Добавление глобального каталога в контроллер домена в корневом домене леса

Восстановление первого контроллера домена с возможностью записи в каждом домене

Начиная с записываемого контроллера домена в корневом домене леса выполните действия, описанные в этом разделе, чтобы восстановить первый контроллер домена. Корневой домен леса важен, так как он хранит группы администраторов схемы и администраторов предприятия. Она также помогает поддерживать иерархию доверия в лесу. Кроме того, корневой домен леса обычно содержит корневой DNS-сервер для пространства имен DNS леса. Следовательно, зона DNS, интегрированная с Active Directory для этого домена, содержит записи ресурсов псевдонима (CNAME) для всех остальных контроллеров домена в лесу (которые необходимы для репликации) и записи ресурсов DNS глобального каталога.

После восстановления корневого домена леса повторите те же действия, чтобы восстановить оставшиеся домены в лесу. Одновременно можно восстановить несколько доменов; однако всегда восстанавливайте родительский домен перед восстановлением дочернего элемента, чтобы предотвратить разрыв в иерархии доверия или разрешение DNS-имен.

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

Затем выполните следующие действия. Процедуры для выполнения определенных действий находятся в процедуре восстановления леса AD.

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

2. Так как это первый записываемый контроллер домена в домене, необходимо выполнить неавторитическое восстановление AD DS и заслуживающее доверия восстановление SYSVOL. Операция восстановления должна быть завершена с помощью приложения резервного копирования и восстановления с поддержкой Active Directory, например windows Server Backup (т. е. восстановление контроллера домена с помощью неподдерживаемых методов, таких как восстановление моментального снимка виртуальной машины).

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

   Внимание!

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

   • Существует два варианта выполнения неавторитативного восстановления AD DS и заслуживающего доверия восстановления SYSVOL:
   • Выполните полное восстановление сервера, а затем принудительная синхронизация SYSVOL. Подробные инструкции см. в статье «Выполнение полного восстановления сервера » и «Выполнение заслуживающей доверия синхронизации DFSR-реплицированного SYSVOL».
   • Выполните полное восстановление сервера, за которым следует восстановление состояния системы. Для этого параметра необходимо заранее создать оба типа резервных копий: полное резервное копирование сервера и резервное копирование состояния системы. Подробные процедуры см. в статье «Выполнение полного восстановления сервера и выполнение неавторитативного восстановления доменных служб Active Directory».

3. После восстановления и перезапуска записываемого контроллера домена убедитесь, что сбой не повлиял на данные контроллера домена. Если данные контроллера домена повреждены, повторите шаг 2 с другой резервной копией.

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

     HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Repl выполняет начальную синхронизацию

     Создайте запись с типом данных REG_DWORD и значением 0. После полного восстановления леса можно сбросить значение этой записи до 1. Для этого требуется контроллер домена, который перезапускает и удерживает роли главного сервера операций для успешной входящей и исходящей репликации AD DS с известными партнерами-репликами, прежде чем объявлять себя как контроллер домена и начинает предоставлять службы клиентам. Дополнительные сведения о требованиях к начальной синхронизации см. в статье о том, как выполняется синхронизация в доменных службах Azure AD.

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

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

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

   В каждом дочернем домене захватить роли хозяина операций на уровне домена. Хотя роли хозяина операций могут храниться только на восстановленном контроллере домена временно, захват этих ролей гарантирует, какие контроллер домена размещаются на этом этапе в процессе восстановления леса. В рамках процесса после восстановления вы можете повторно распространить роли хозяина операций по мере необходимости. Дополнительные сведения об виртуализации ролей хозяина операций см. в разделе «Захват роли главного сервера операций». Рекомендации по расположению ролей главного сервера операций см. в разделе «Что такое мастеры операций?».

6. Очистите метаданные всех остальных записываемых контроллеров домена в корневом домене леса, которые не восстанавливаются из резервной копии (все записываемые контроллеры домена в домене, кроме первого контроллера домена). При использовании версии пользователей и компьютеров Active Directory или сайтов и служб Active Directory, входящих в состав Windows Server 2008 или более поздней версии или RSAT для Windows Vista или более поздней версии, очистка метаданных выполняется автоматически при удалении объекта контроллера домена. Кроме того, серверный объект и объект компьютера для удаленного контроллера домена также удаляются автоматически. Дополнительные сведения см. в разделе «Очистка метаданных удаленных записываемых контроллеров домена».

   Очистка метаданных предотвращает возможное дублирование объектов параметров NTDS, если AD DS установлен на контроллере домена на другом сайте. Возможно, это также может сохранить средство проверки согласованности знаний (KCC) процесс создания ссылок репликации, когда сами контроллеры домена могут не присутствовать. Кроме того, в рамках очистки метаданных записи ресурсов DNS указателя контроллера домена для всех остальных контроллеров домена в домене будут удалены из DNS.

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

7. Если у вас есть зоны DNS, хранящиеся в AD DS, убедитесь, что служба локального DNS-сервера установлена и запущена на восстановленном контроллере домена. Если этот контроллер домена не был DNS-сервером до сбоя леса, необходимо установить и настроить DNS-сервер.

   Примечание

   Если восстановленный контроллер домена работает под управлением Windows Server 2008, необходимо установить исправление в статье базы знаний 975654 или временно подключить сервер к изолированной сети, чтобы установить DNS-сервер. Исправление не требуется для других версий Windows Server.

   В корневом домене леса настройте восстановленный контроллер домена с собственным IP-адресом (или адресом замыкания на себя, например 127.0.0.1) в качестве предпочтительного DNS-сервера. Этот параметр можно настроить в свойствах TCP/IP адаптера локальной сети (LAN). Это первый DNS-сервер в лесу. Дополнительные сведения см. в разделе «Настройка TCP/IP для использования DNS».

   В каждом дочернем домене настройте восстановленный контроллер домена с IP-адресом первого DNS-сервера в корневом домене леса в качестве предпочтительного DNS-сервера. Этот параметр можно настроить в свойствах TCP/IP адаптера локальной сети. Дополнительные сведения см. в разделе «Настройка TCP/IP для использования DNS».

   В зонах DNS _msdcs и домена удалите записи NS контроллеров домена, которые больше не существуют после очистки метаданных. Проверьте, удалены ли записи SRV удаленных контроллеров домена. Чтобы ускорить удаление записей DNS SRV, выполните следующую команду:

   nltest. exe /dsderegdns:server.domain.tld
   

8. Повышение значения доступного пула RID на 100 000. Дополнительные сведения см. в разделе «Повышение значения доступных пулов RID». Если у вас есть основания полагать, что повышение пула RID на 100 000 недостаточно для конкретной ситуации, следует определить наименьшее увеличение, которое по-прежнему безопасно использовать. Идентификаторы идентификаторов — это конечный ресурс, который не следует использовать без необходимости.

   Если новые субъекты безопасности были созданы в домене после создания резервной копии, используемой для восстановления, эти субъекты безопасности могут иметь права доступа к определенным объектам. Эти субъекты безопасности больше не существуют после восстановления, так как восстановление вернулось к резервной копии; однако их права доступа могут по-прежнему существовать. Если доступный пул RID не создается после восстановления, новые пользовательские объекты, созданные после восстановления леса, могут получить идентичные идентификаторы безопасности (SID) и иметь доступ к этим объектам, которые изначально не были предназначены.

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

9. Отмените текущий пул RID. Текущий пул RID становится недействительным после восстановления состояния системы. Но если восстановление состояния системы не было выполнено, текущий пул RID должен быть недействительным, чтобы предотвратить повторное выдачу идентификаторов riD восстановленного контроллера домена из пула RID, который был назначен во время создания резервной копии. Дополнительные сведения см. в разделе «Недействительный текущий пул RID».

   Примечание

   При первой попытке создать объект с идентификатором безопасности после отмены пула RID вы получите сообщение об ошибке. Попытка создать объект активирует запрос для нового пула RID. Повторная попытка операции завершается успешно, так как будет выделен новый пул RID.

10. Сбросьте пароль учетной записи компьютера этого контроллера домена дважды. Дополнительные сведения см. в разделе Сброс пароля учетной записи компьютера контроллера домена.

11. Сбросьте пароль krbtgt дважды. Дополнительные сведения см. в разделе «Сброс пароля krbtgt».

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

    Примечание

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

12. Если лес содержит несколько доменов, а восстановленный контроллер домена был сервером глобального каталога до сбоя, снимите флажок глобального каталога в свойствах параметров NTDS, чтобы удалить глобальный каталог из контроллера домена. Исключением из этого правила является распространенный случай леса с одним доменом. В этом случае удаление глобального каталога не требуется. Дополнительные сведения см. в разделе «Удаление глобального каталога».

    Восстановление глобального каталога из резервной копии, которая является более поздней, чем другие резервные копии, используемые для восстановления контроллеров домена в других доменах, может привести к тому, что объекты задерживаются. Рассмотрим следующий пример. В домене A dc1 восстанавливается из резервной копии, которая была сделана во время T1. В домене B dc2 восстанавливается из резервной копии глобального каталога, которая была создана во время T2. Предположим, T2 является более поздним, чем T1, и некоторые объекты были созданы между T1 и T2. После восстановления этих контроллеров домена DC2, который является глобальным каталогом, содержит новые данные для частичной реплики домена A, чем домен A, удерживает себя. В этом случае DC2 содержит задерживающиеся объекты, так как эти объекты отсутствуют в DC1.

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

    Вторая проблема заключается в том, что учетная запись пользователя, которая больше не существует, может по-прежнему отображаться в глобальном списке адресов. Третья проблема заключается в том, что универсальная группа, которая больше не существует, может по-прежнему отображаться в маркере доступа пользователя.

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

13. Настройка службы времени Windows. В корневом домене леса настройте эмулятор PDC для синхронизации времени из внешнего источника времени. Дополнительные сведения см. в разделе «Настройка службы времени Windows» в эмуляторе PDC в корневом домене леса.

Повторное подключение каждого восстановленного контроллера домена с возможностью записи к общей сети

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

Примечание

При присоединении физических контроллеров домена к изолированной сети может потребоваться изменить их IP-адреса. В результате IP-адреса записей DNS будут неправильными. Так как сервер глобального каталога недоступен, безопасные динамические обновления для DNS завершаются ошибкой. В этом случае виртуальные контроллеры домена более выгодны, так как они могут быть присоединены к новой виртуальной сети, не изменяя их IP-адреса. Это одна из причин, по которой виртуальные контроллеры домена рекомендуется восстанавливать в качестве первых контроллеров домена во время восстановления леса.

После проверки присоединитесь к рабочей сети контроллеров домена и выполните действия по проверке работоспособности репликации леса.

• Чтобы исправить разрешение имен, создайте записи делегирования DNS и настройте перенаправление DNS и корневые подсказки по мере необходимости. Запустите repadmin /replsum , чтобы проверить репликацию между контроллерами домена.
• Если восстановленные контроллеры домена не являются прямыми партнерами репликации, восстановление репликации будет гораздо быстрее путем создания между ними временных объектов подключения.
• Чтобы проверить очистку метаданных, выполните repadmin /viewlist \* для списка всех контроллеров домена в лесу. Запустите Nltest /DCList:<domain> для списка всех контроллеров домена в домене.
• Чтобы проверить работоспособность контроллера домена и DNS, выполните команду DCDiag /v, чтобы сообщить об ошибках на всех контроллерах домена в лесу.

Добавление глобального каталога в контроллер домена в корневом домене леса

Глобальный каталог необходим по следующим и другим причинам:

• Включение входа для пользователей.
• Чтобы включить службу net Logon, запущенную на контроллерах домена в каждом дочернем домене, необходимо зарегистрировать и удалить записи на DNS-сервере в корневом домене.

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

Примечание

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

Отслеживайте журнал событий службы каталогов в средстве просмотра событий для события с идентификатором 1119, который указывает, что этот контроллер домена является сервером глобального каталога, или убедитесь, что следующий раздел реестра имеет значение 1:

HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Global Catalog Promotion Complete

Дополнительные сведения см. в разделе «Добавление глобального каталога».

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

Next Steps

• Восстановление леса AD — необходимые условия
• Восстановление леса AD — разработка пользовательского плана восстановления леса
• Восстановление леса AD — определение проблемы
• Восстановление леса AD — определение способа восстановления
• Восстановление леса AD — выполнение начального восстановления
• Восстановление леса AD — процедуры
• Восстановление леса AD — часто задаваемые вопросы
• Восстановление леса AD — восстановление одного домена в лесу с несколькими доменами
• Восстановление леса AD — восстановление леса с помощью контроллеров домена Windows Server 2003

AD Forest Recovery — определите, как восстановить лес

• Статья
• 16. 08.2021

Применяется к: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 и 2012 R2, Windows Server 2008 и 2008 R2

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

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

Для каждого домена в лесу должен быть известен пароль учетной записи администратора домена. Желательно, чтобы это был пароль встроенной учетной записи администратора. Вы также должны знать пароль DSRM для выполнения восстановления состояния системы контроллера домена. Как правило, рекомендуется архивировать учетную запись администратора и историю паролей DSRM в безопасном месте до тех пор, пока резервные копии действительны, то есть в течение периода существования захоронения или в течение срока существования удаленного объекта, если корзина Active Directory включен. Вы также можете синхронизировать пароль DSRM с учетной записью пользователя домена, чтобы его было легче запомнить. Дополнительные сведения см. в статье 9 базы знаний.61320. Синхронизация учетной записи DSRM должна быть выполнена до восстановления леса в рамках подготовки.

Примечание

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

Определение резервных копий для использования

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

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

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

Если вам нужно восстановить Active Directory на другом оборудовании, создайте полные резервные копии сервера и запланируйте полное восстановление сервера.

Важно

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

1. Выполните полное восстановление сервера, чтобы восстановить операционную систему, все файлы и приложения.
2. Выполните восстановление состояния системы с помощью wbadmin.exe, чтобы пометить SYSVOL как заслуживающий доверия.

Дополнительные сведения см. в статье базы знаний Майкрософт 249694.

Если время возникновения сбоя неизвестно, выполните дальнейшее исследование, чтобы определить резервные копии, содержащие последнее безопасное состояние леса. Этот подход менее желателен. Поэтому мы настоятельно рекомендуем ежедневно вести подробные журналы о состоянии AD DS, чтобы в случае сбоя в масштабе леса можно было определить приблизительное время сбоя. Вы также должны хранить локальную копию резервных копий, чтобы обеспечить более быстрое восстановление.

Если Корзина Active Directory включена, время жизни резервной копии равно значению для параметраDeletedObjectLifetime или значению tombstoneLifetime , в зависимости от того, что меньше. Дополнительные сведения см. в пошаговом руководстве по использованию корзины Active Directory (https://go. microsoft.com/fwlink/?LinkId=178657).

В качестве альтернативы вы также можете использовать средство подключения базы данных Active Directory (Dsamain.exe) и средство облегченного протокола доступа к каталогам (LDAP), например, Ldp.exe или Active Directory Users and Computers, чтобы определить, какая резервная копия имеет последнее безопасное состояние леса. Средство монтирования базы данных Active Directory, включенное в Windows Server 2008 и более поздние операционные системы Windows Server, предоставляет данные Active Directory, хранящиеся в резервных копиях или моментальных снимках, как сервер LDAP. Затем вы можете использовать инструмент LDAP для просмотра данных. Преимущество этого подхода в том, что вам не требуется перезапускать какой-либо контроллер домена в режиме восстановления служб каталогов (DSRM) для проверки содержимого резервной копии AD DS.

Дополнительные сведения об использовании средства монтирования базы данных Active Directory см. в пошаговом руководстве по средству монтирования базы данных Active Directory.

Вы также можете использовать команду ntdsutil snapshot для создания моментальных снимков базы данных Active Directory. Запланировав задачу для периодического создания моментальных снимков, вы можете со временем получать дополнительные копии базы данных Active Directory. Вы можете использовать эти копии, чтобы лучше определить, когда произошел сбой в масштабе всего леса, а затем выбрать наилучшую резервную копию для восстановления. Для создания снапшотов используйте версию ntdsutil , поставляемый с Windows Server 2008 или средствами удаленного администрирования сервера (RSAT) для Windows Vista или более поздней версии. На целевом контроллере домена может работать любая версия Windows Server. Дополнительные сведения об использовании команды ntdsutil snapshot см. в разделе Снимок.

Определение контроллеров домена для восстановления

Простота процесса восстановления является важным фактором при выборе контроллера домена для восстановления. Рекомендуется иметь выделенный контроллер домена для каждого домена, который является предпочтительным контроллером домена для восстановления. Выделенный контроллер домена восстановления упрощает надежное планирование и выполнение восстановления леса, поскольку вы используете ту же исходную конфигурацию, которая использовалась для выполнения тестов восстановления. Вы можете написать сценарий восстановления, а не соперничать с различными конфигурациями, такими как наличие у контроллера домена ролей хозяина операций или нет, является ли он сервером GC или DNS или нет.

Примечание

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

Выберите контроллер домена, который лучше всего соответствует следующим критериям:

• Контроллер домена, доступный для записи. Это обязательно.

• Контроллер домена под управлением Windows Server 2012 в качестве виртуальной машины на гипервизоре, который поддерживает VM-GenerationID. Этот DC можно использовать как источник для клонирования.

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

• DC с хорошей полной резервной копией сервера. Хорошая резервная копия — это резервная копия, которая может быть успешно восстановлена, сделана за несколько дней до сбоя и содержит как можно больше полезных данных.

• Контроллер домена, который до сбоя был сервером системы доменных имен (DNS). Это экономит время, необходимое для переустановки DNS.

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

  BitLocker Network Unlock как только предохранитель ключа нельзя использовать на контроллерах домена, где вы развернули службы развертывания Windows (WDS), поскольку это приводит к сценарию, в котором первый контроллер домена требует, чтобы Active Directory и WDS работали, чтобы разблокировать. Но до того, как вы восстановите первый контроллер домена, Active Directory еще не доступна для WDS, поэтому его нельзя разблокировать.

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

  .

  HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftSystemCertificatesFVE_NKP

Соблюдайте процедуры безопасности при обработке или восстановлении файлов резервных копий, содержащих Active Directory. Срочность, сопровождающая восстановление леса, может непреднамеренно привести к игнорированию передовых методов обеспечения безопасности. Дополнительные сведения см. в разделе «Создание стратегий резервного копирования и восстановления контроллера домена» в Руководстве по передовому опыту по обеспечению безопасности при установке и повседневных операциях Active Directory: часть II.

Определение текущей структуры леса и функций контроллера домена

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

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

Эмулятор PDC

Имя DC	Операционная система	ФСМО	ГК	RODC	Резервное копирование	DNS	Ядро сервера	ВМ	VM-GenID
DC_1	Windows Server 2012	Мастер схемы, Мастер именования доменов	Да	№	Да	№	№	Да	Да
DC_2	Windows Server 2012	Нет	Да	№	Да	Да	№	Да	Да
DC_3	Windows Server 2012	Мастер инфраструктуры	№	№	№	Да	Да	Да	Да
DC_4	Windows Server 2012	, RID Master	Да	№	№	№	№	Да	№
DC_5	Windows Server 2012	Нет	№	№	Да	Да	№	Да	Да
RODC_1	Windows Server 2008 R2	Нет	Да	Да	Да	Да	Да	Да	№
RODC_2	Windows Server 2008	Нет	Да	Да	№	Да	Да	Да	№

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

В этом примере есть четыре кандидата на резервное копирование: DC_1, DC_2, DC_4 и DC_5. Из этих кандидатов на резервное копирование вы восстанавливаете только один. Рекомендуемым DC является DC_5 по следующим причинам:

• Он удовлетворяет требованиям для использования его в качестве источника для виртуализированного клонирования DC, то есть он запускает Windows Server 2012 как виртуальный DC на гипервизоре, который поддерживает VM-GenerationID, запускает программное обеспечение который разрешено клонировать (или который можно удалить, если он не может быть клонирован). После восстановления роль эмулятора PDC будет присвоена этому серверу, и его можно будет добавить в группу Cloneable Domain Controllers для домена.
• Он запускает полную установку Windows Server 2012. Контроллер домена, на котором выполняется установка Server Core, может быть менее удобным в качестве цели для восстановления.
• Это DNS-сервер. Поэтому DNS не нужно переустанавливать.

Примечание

Поскольку DC_5 не является сервером глобального каталога, его преимущество заключается в том, что после восстановления не нужно удалять глобальный каталог. Но является ли контроллер домена сервером глобального каталога или нет, это не является решающим фактором, поскольку, начиная с Windows Server 2012, все контроллеры домена по умолчанию являются серверами глобального каталога, а удаление и добавление глобального каталога после восстановления рекомендуется как часть леса. процесс восстановления в любом случае.

Изолированное восстановление леса

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

Примечание

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

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

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

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

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

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

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

Контроллеры доменов только для чтения будут по-прежнему разрешать доступ к локальным ресурсам, кэшированным на соответствующих сайтах, пока операции восстановления выполняются параллельно. Для локальных ресурсов, не кэшированных на контроллере домена только для чтения, запросы проверки подлинности будут перенаправляться на доступный для записи контроллер домена. Эти запросы завершатся ошибкой, так как доступные для записи контроллеры домена находятся в автономном режиме. Некоторые операции, такие как изменение пароля, также не будут работать, пока вы не восстановите доступные для записи контроллеры домена.

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

Следующие шаги

• Восстановление леса AD — предварительные условия
• AD Forest Recovery — разработка индивидуального плана восстановления леса
• Восстановление леса AD — определение проблемы
• AD Forest Recovery — определите, как восстановить
• Восстановление леса AD — выполнить начальное восстановление
• Восстановление леса AD — Процедуры
• Восстановление леса AD — часто задаваемые вопросы
• Восстановление леса AD — восстановление одного домена в многодоменном лесу
• Восстановление леса AD — восстановление леса с помощью контроллеров домена Windows Server 2003

Руководство по аварийному восстановлению Active Directory: что нужно знать

Каждой организации нужна надежная стратегия аварийного восстановления Active Directory. Причина проста: каждую секунду, когда ваш Active Directory (AD) не работает, ваш бизнес гибнет.

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

Это очень быстро становится дорогим! На самом деле, 40% предприятий говорят, что один час простоя стоит от 1 до 5 миллионов долларов. В худшем случае потери могут составить миллионов долларов в минуту .

Лучший способ свести к минимуму время простоя и неизбежный ущерб для вашего бизнеса — разработать комплексную стратегию аварийного восстановления Active Directory. Но что такое аварийное восстановление Active Directory и как оно работает? Как на самом деле восстановить контроллер домена из резервной копии? И, что особенно важно, как сделать процесс восстановления максимально быстрым и беспроблемным? Давайте углубимся.

«Процессу восстановления после многих хорошо задокументированных атак программ-вымогателей препятствует отсутствие неповрежденного процесса восстановления Active Directory. »
— Gartner, Inc., «Как восстановиться после атаки программы-вымогателя с помощью современной инфраструктуры резервного копирования», Финтан Куинн, 4 июня 2021 г.

Что влечет за собой процесс аварийного восстановления Active Directory?

Аварийное восстановление Active Directory — это восстановление работоспособности ваших контроллеров домена (DC). Контроллеры домена — это серверы, выполняющие роль доменных служб Microsoft Active Directory, что позволяет им предоставлять важные услуги, такие как проверка подлинности и авторизация. Без хотя бы одного работающего контроллера домена ваша локальная или гибридная экосистема Microsoft не сможет функционировать.

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

Этапы восстановления Active Directory

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

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

Первым шагом является восстановление выбранных контроллеров домена из резервной копии. Ваши варианты здесь зависят от того, какие инструменты у вас есть. При использовании менее комплексного решения вы можете ограничиться восстановлением на уровне образа, например восстановлением на «голое железо» (BMR). Решение корпоративного уровня может также предлагать чистое восстановление операционной системы (ОС), что невозможно при использовании собственных инструментов. Есть два основных фактора, которые следует учитывать, если у вас есть оба варианта.

• Восстановление на «голое железо» требует множества требований. Хотя на целевой машине не требуется предварительно установленная операционная система, для нее требуется такая же структура физического диска. Кроме того, эти диски должны быть не меньше размера исходного контроллера домена, чтобы можно было создать те же разделы, что и на исходном компьютере. Вам также придется побеспокоиться об установке важных для загрузки драйверов, настройке сети вручную (из командной строки) и многом другом. Восстановление чистой ОС не связано с этими проблемами; вы начинаете с сервера Windows, который уже имеет все свои драйверы и легко настраивается в сети с помощью графического интерфейса.
• BMR восстанавливает целые тома (разделы диска), которые включают файлы, не являющиеся частью AD, такие как загрузочный сектор, каталог программных файлов и каталоги Windows и WinSXS. Эти данные могут понадобиться, если ваши контроллеры домена используются для служб, не связанных с AD, таких как размещение зон DNS, которые не интегрированы в AD, запуск центра сертификации или запуск служб файлов и печати. Однако эти дополнительные файлы предоставляют множество мест, где могут спрятаться вредоносные программы. Таким образом, чистое восстановление ОС часто является рекомендуемым подходом, особенно если атака могла использовать эксплойт нулевого дня.

После восстановления из резервной копии необходимо, чтобы контроллеры домена снова обменивались данными и функционировали как лес. Руководство Microsoft по восстановлению леса Active Directory описывает 12 процедур настройки, включающих более 40 шагов, которые необходимо выполнить на каждом контроллере домена, восстановленном из резервной копии. Невыполнение этих шагов должным образом может привести к сбою AD или оставит уязвимости безопасности.

Фаза 2: Продвиньте остальные контроллеры домена . У вас также есть несколько вариантов, в том числе прямой DCPromo, но Microsoft рекомендует продвигать «установить с носителя» (IFM). Поскольку IFM сокращает трафик, отправляемый через вашу сеть, вдвое, это значительно ускоряет процесс продвижения DC.

Сколько времени занимает аварийное восстановление Active Directory?

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

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

Ускорение процесса восстановления AD

Специально разработанное решение аварийного восстановления Active Directory ускоряет восстановление за счет автоматизации многих выполняемых вручную задач. Эта автоматизация позволяет организациям проходить процесс восстановления быстрее и с меньшим количеством ИТ-персонала, обеспечивая при этом выполнение шагов в правильном порядке и без ошибок. Например, с помощью собственных инструментов продвижение контроллеров домена должно выполняться на каждом контроллере домена один за другим, и продвижение каждого сервера займет от нескольких минут до нескольких часов. Стороннее решение может автоматизировать процесс DCPromo с IFM и параллельно продвигать несколько контроллеров домена, что значительно сокращает этап 2 восстановления. Итог. Автоматизированные решения помогут вашей организации значительно сократить время простоя Active Directory, ускорив возвращение к нормальной работе и минимизировав затраты, связанные с аварией.

Более того, лучшие решения для аварийного восстановления Active Directory охватывают восстановление как Active Directory, так и Azure Active Directory в одном наборе инструментов. Эта унифицированная функциональность имеет решающее значение для предотвращения проблем с синхронизацией и обеспечения доступности и целостности как локальной AD, так и Azure AD. С помощью единой панели управления восстановлением ИТ-команда может легко различать гибридные и облачные объекты, сравнивать рабочие резервные копии и резервные копии в реальном времени, а также быстро выполнять операции восстановления.

В идеале инструмент также обеспечивает не только аварийное восстановление, но и выборочное восстановление . Это позволяет ИТ-специалистам восстанавливать определенные объекты (в том числе объекты групповой политики) и атрибуты (например, атрибуты, случайно измененные задачей миграции, или процесс каталога метаданных, выполненный неправильно), не выполняя трудоемкий процесс перезапуска контроллера домена.

Основные советы по созданию надежного плана аварийного восстановления Active Directory

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

Делайте регулярные резервные копии AD и храните их в надежном месте.

Помните печально известную атаку NotPetya в 2017 году? В течение нескольких часов эта вредоносная программа остановила работу компаний по всему миру, в том числе судоходного гиганта Maersk. Хотя у Maersk были резервные копии большей части своих данных, никто не мог найти ни одной резервной копии Active Directory. Пока ИТ-команда карабкалась, компании приходилось перенаправлять корабли, она не могла разгружать грузы в десятках портов и не могла обрабатывать новые заказы. В итоге Maersk спасла только удача: во время атаки один ДЦ в удаленном офисе был отключен. Компания тщательно доставила эту драгоценную машину в свою штаб-квартиру, чтобы обеспечить процесс восстановления AD.

Очевидно, что удача — это не стратегия. Делайте регулярные резервные копии AD, тестируйте их, чтобы убедиться, что они действительны, и храните их в изолированной сети, на сторонней облачной платформе или в другом безопасном месте! Microsoft рекомендует следовать правилу 3-2-1: храните 3 резервные копии данных в 2 разных типах хранилищ и храните как минимум 1 резервную копию вне офиса. Quest рекомендует, чтобы по крайней мере некоторые из ваших резервных копий были изолированы (то есть недоступны из компьютерной сети).

Типы резервных копий

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

• Резервные копии состояния системы — Эти резервные копии включают почти всю операционную систему, а не только части Active Directory. Хотя они содержат все, что нужно для AD, они также содержат гораздо больше, поэтому для киберкатастрофы они могут быть не идеальными.
• Резервные копии для восстановления на «голое железо» — BMR позволяет восстанавливать контроллеры домена Active Directory на различных экземплярах оборудования. Этот вариант особенно ценен в случае физического повреждения контроллеров домена и связанных с ним сценариев аварийного восстановления Active Directory.

Некоторые сторонние решения для аварийного восстановления предоставляют дополнительные параметры резервного копирования:

• Резервные копии Active Directory — Эти резервные копии включают только компоненты, относящиеся к AD: каталог NTDS, SYSVOL (который содержит групповую политику и сценарии входа) и аспекты реестр, которые имеют отношение к AD. Исключая многие другие компоненты из резервной копии состояния системы или BMR, резервные копии AD значительно снижают риск повторного заражения вредоносным ПО после процесса восстановления.
• Резервные копии Azure AD — В гибридных средах AD вам также потребуется стратегия резервного копирования только для облачных объектов и атрибутов. Примеры включают не только лицензии Microsoft 365 и назначения ролей приложений, упомянутые ранее, но также группы Office 365 и Azure AD, облачных пользователей, таких как учетные записи Azure B2B и B2C, а также параметры Azure AD MFA и политики условного доступа. Эти объекты и атрибуты не защищены должным образом собственными инструментами Microsoft и не защищены каким-либо локальным решением для резервного копирования Active Directory. Поэтому без резервных копий Azure AD восстановление часто приводит к проблемам как с бизнесом, так и с безопасностью. Сотрудники могут не иметь доступа к ресурсам, необходимым им для выполнения своей работы, пользователи могут иметь доступ к конфиденциальным ресурсам без прохождения многофакторной аутентификации, а учетные записи партнеров и клиентов могут быть утеряны навсегда.

Как насчет моментальных снимков ВМ?

Обратите внимание, что я не включил снимков ВМ — образы виртуальной машины (ВМ) в данный момент времени. Это связано с тем, что моментальные снимки ВМ не являются адекватными резервными копиями Active Directory. Их использование для восстановления леса почти всегда приводит к трудноразрешимым проблемам согласованности данных. Примеры включают устаревшие объекты (объекты, которые присутствуют на одном контроллере домена, но были полностью удалены с других контроллеров домена) и проблемы с обновлением серийного номера, которые нарушат репликацию. Кроме того, как и резервные копии BMR, моментальные снимки могут содержать вредоносные программы, которые будут восстановлены на контроллере домена вместе со всем остальным.

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

Наличие механизмов экстренной связи, не зависящих от AD.

Необходимо убедиться, что функции бизнеса, ИТ и восстановления могут взаимодействовать друг с другом, даже если служба AD не работает. Поэтому не полагайтесь на ИТ-системы, которые могут быть недоступны, такие как электронная почта или Microsoft Teams. Здесь, в Quest, мы используем безопасное решение для обмена сообщениями, не зависящее от платформы. Мы также делимся номерами мобильных телефонов всех членов критической группы восстановления и настраиваем наши смартфоны, чтобы разрешать уведомления друг от друга, даже если телефон настроен на «не беспокоить».

Пока вы это делаете, убедитесь, что вы храните свой план аварийного восстановления Active Directory где-нибудь, чтобы вы могли получить к нему доступ, даже если Active Directory не работает. Один из вариантов — пойти по старинке и распечатать его; другой — хранить его в отдельном облачном хранилище, таком как Dropbox. Что бы вы ни выбрали, убедитесь, что все заинтересованные стороны знают, как получить к нему доступ, и могут сделать это быстро.

Определите путь эскалации и ключевых лиц, принимающих решения, на каждом уровне пути.

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

Протестируйте план восстановления вместе с ИТ-специалистами, которые его не разрабатывали.

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

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

Практикуйте план не менее двух раз в год.

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

Регулярно обновляйте свой план аварийного восстановления Active Directory.

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

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

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

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

Но вам может понадобиться помощь, чтобы убедить вашу управленческую команду инвестировать средства в инструменты, необходимые для эффективного аварийного восстановления Active Directory! Вот лучшая стратегия, которую я знаю, чтобы привлечь их на борт. Он вдохновлен ироничной балладой Тома Пакстона «Я меняю имя на Крайслер», в которой есть мудрая фраза о людях: «Едва мы встали и пошли, как деньги заговорили».

Расчет стоимости простоя Active Directory

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

• Потеря производительности — Без Active Directory для аутентификации пользователей и предоставления доступа к данным и службам практически никто не сможет выполнять свою работу. Легко подсчитать стоимость этой потерянной производительности. Например, предположим, что средняя заработная плата сотрудников составляет 87 000 долларов в год, а 1000 сотрудников простаивают. В этом случае одна лишь потеря производительности будет стоить организации более трети миллиона долларов в день .
• Упущенная выгода — Какой доход ваша организация получает в день? Умножьте это на количество дней простоя AD. (Спойлер: скорее всего, это тоже огромное число.)
• Потерянный бизнес — простои Active Directory, вероятно, повлияют на вашу способность принимать и обрабатывать заказы и иным образом удовлетворять потребности клиентов. Итак, возместите потерянный будущий поток доходов от разочарованных клиентов, решивших передать свой бизнес вашим конкурентам.
• Штрафы за соблюдение нормативных требований — Если вы подпадаете под действие нормативных требований, вам необходимо добавить расходы на штрафы и дополнительные проверки.
• Судебные издержки и расходы на восстановление — Если данные клиента будут раскрыты, вы также можете столкнуться с судебными издержками и затратами на меры по исправлению положения, такие как бесплатный мониторинг кредитоспособности.
• Холодный, твердый биткойн — Если время простоя связано с атакой программы-вымогателя, и вы решите заплатить выкуп, вам также нужно добавить эту стоимость. (Обратите внимание, что эти деньги, вероятно, потрачены впустую, поскольку только 8 процентов организаций, которые платят выкуп, фактически получают обратно все свои данные.)
• Необратимый ущерб репутации вашей организации — Чем дольше будет продолжаться отключение, тем больше ваша компания будет фигурировать в заголовках. Таким образом, в дополнение к клиентам, которые немедленно отвернутся, вы потеряете доход от всех потенциальных клиентов, которые будут избегать вас в будущем. Действительно, вы можете годами бороться за восстановление своего бренда. Хотя этот ущерб может быть трудно оценить количественно, он может быть самым большим компонентом общей стоимости простоя AD.

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