Active directory authoritative restore windows 2008

Этой статьей я завершаю тему восстановления данных в Active Directory. Напоследок я приберег самый тяжелый вариант — авторитативное восстановление Active Directory из резервной копии.  Авторитативное восстановление (англ. Authoritative restore) — процесс достаточно сложный и долгий, могущий привести к различным неприятным последствиям, поэтому применять его стоит очень аккуратно. Однако ситуации бывают разные, поэтому все, кто работает с Active Directory, должны знать об этом способе восстановления и уметь им пользоваться.

Вот что представляет из себя авторитативное восстановление:

1) Контроллер домена загружается в режиме Directory Services Restore Mode (DSRM).  В этом режиме служба AD не запускается, а база данных переводится в автономный режим;
2) База данных AD восстанавливается из резервной копии;
3) Восстанавливаемые объекты помечаются как авторитативные с помощью утилиты Ntdsutil;
4) Контроллер домена загружается в нормальном режиме.

Это если коротко. Более подробно рассмотрим процесс авторитативного восстановления на примере восстановления удаленной организационной единицы. Все действия будут проводится на Windows Server 2008 R2 с использованием встроенных средств, уровень леса Server 2008 R2.

Для авторитативного восстановления Active Directory нам потребуется резервная копия состояния системы (System State). System State включает в себя:

• Файл ntds.dit – база данных Active Directory;
• Системный реестр контроллера домена;
• База данных Certification Authority (служб сертификации);
• Системный том SYSVOL, хранящий сценарии входа в систему и групповые политики домена;
• Системные файлы, необходимые для загрузки операционной системы;
• База данных регистрации классов COM+, которая содержит информацию о приложениях COM+ ;
• Сведения Cluster Services (служб кластеров),  если данный сервер является компонентом кластера.

Для создания резервной копии я воспользуюсь встроенной в Windows Server 2008 программой для резервного копирования Wbadmin. Открываем командную консоль и создаем бэкап System State на диске E следующей командой:

wbadmin start systemstatebackup -backupTarget:E:

Создав резервную копию, открываем оснастку Active Directory Users and Computers (ADUC) и, совершенно случайно 🙂  удаляем подразделение Managers со всем содержимым.

Кстати, в отличие от других объектов (учетных записей пользователей, компьютеров и групп) у контейнеров предусмотрена защита от случайного удаления. Поэтому, прежде чем удалять объект, в оснастке ADUC в меню View включаем пункт Advanced Features. Затем открываем свойства объекта и на вкладке Object снимаем галку с чек-бокса «Protect object from accidental deletion».

Теперь мы должны перезагрузить контроллер домена в режиме восстановления Directory Services Restore Mode. Если в Windows Server 2003 для этого достаточно было нажать клавишу F8 при загрузке, то в Server 2008 необходимо внести изменения в загрузочное меню. Сделать это можно двумя способами.

Из командной строки, запущенной с правами администратора, введя команду:

bcdedit /set safeboot dsrepair

И перезагрузить сервер:

shutdown -r -t 0

Либо нажать Win+R и в строке выполнить (Run) ввести msconfig. Откроется оснастка System Configuration. В ней на вкладке Boot в поле «Boot options» надо отметить режим Safe boot, установить переключатель на Active Directory repair и нажать OK. И затем перезагрузиться.

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

Приступим к восстановлению. Опять задействуем Wbadmin и восстановим созданный ранее System State командой:

wbadmin start systemstaterecovery -version:11/20/2012-08:29

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

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

У каждого объекта Active Directory существует свойство USN (Update Sequence Numbers), или номер последовательного восстановления. При каждом изменении объекта в Active Directory к его значению USN прибавляется 1. Таким образом Active Directory определяет актуальность информации об объекте, т.е. чем больше USN, тем объект актуальнее.
Каждый контроллер домена имеет свой собственный USN, отличный от других. При репликации контроллеры обмениваются значениями USN и каждый запоминает значение USN партнера по репликации, чтобы после оповещения об изменениях партнер забрал произведенные изменения. Таким образом объект с более низким USN будет при репликации перезаписан объектом с более высоким USN.
Так вот, авторитативное восстановление объекта заключается в том, что значение его USN принудительно увеличивается на 100000. Это делает объект авторитативным, и при последующей репликации он будет сохранен.

На самом деле механизм репликации гораздо сложнее, но для понимания процесса этого хватит.

Чтобы пометить объект как авторитативный:

• В меню Start -> Run набираем ntdsutil и жмем ENTER;
• В строке ntdsutil набираем activate instance ntds и жмем ENTER;
• В строке ntdsutil набираем authoritative restore и жмем ENTER.

Теперь мы находимся в приглашении командной строки утилиты Ntdsutil для авторитативного восстановления. Синтаксис команд следующий:

restore object <DistinguishedName> — помечает одиночный объект (компьютер, пользователя или группу) как авторитативный для репликации;
restore subtree <DistinguishedName> — помечает поддерево (напр. подразделение (OU) со всем содержимым) как авторитативный объект;
restore database — помечает всю базу данных Active Directory как авторитативную. Это приведет к перезаписи содержимого базы данных Active Directory на всех контроллерах домена;
-verinc <increment> — параметр, который позволяет вручную задавать USN. По умолчанию при авторитативном восстановлении USN данных увеличивается на 100000. Параметр verinc оказывается полезен, если выполняется авторитетное восстановление данных поверх других авторитетно восстановленных данных, то есть значение USN должно быть увеличено больше, чем на 100000.

Пометим для восстановления подразделение Managers:

restore subtree ″OU=Managers,DC=contoso,DC=com″ 

Дело практически сделано. Теперь остается загрузить контроллер в нормальном режиме и дождаться репликации. Не забудьте отключить безопасную загрузку, сделать это можно командой bcdedit /deletevalue safeboot или из оснастки System Configuration.

На этом процесс авторитативного восстановления можно считать законченным. Для ускорения репликации можно выполнить команду repadmin /syncall.

Некоторые моменты, с которыми можно столкнуться при авторитативном восстановлении.

1) При авторитативном восстановлении может пропасть членство в группах. На этот случай Ntdsutil создает в процессе специальный ldf-файл примерно такого вида ar_20121120-134529_links_contoso.com.ldf. Для восстановления членства в группах надо запустить команду ldifde -i -k -f <FileName>;
2) И наоборот, возможно восстановление членства пользователей в группах, из которых они были удалены;
3) При наличии в организации Exchange 2003 при авторитативном восстановлении у пользователей могут создасться новые пустые почтовые ящики, подключенные к First Storage Group на First Mailbox Store. Подробнее здесь;
4) И еще, нельзя восстанавливать AD  из архива, который старше чем время жизни объектов-захоронений. Это чревато возникновением USN Rollback (откат USN), в результате чего может быть полностью заблокирована репликация в домене.

Несомненно, многие из Вас неоднократно сталкивались с такой проблемой – удалены учетные записи пользователей. Статей по восстановлению учетных записей много, и, наверное, самая лучшая написана Microsoft, однако им всем не хватает наглядности. Мы постараемся преодолеть этот недостаток, сведя процедуру восстановления учетных записей к простым шагам.
Как Вы знаете, восстанавливать объекты можно различными способами, каждый из которых подходит наилучшим образом в той или иной ситуации.
При этом предпочтительным является восстановление из tombstone-объектов. На это есть несколько причин:

• не требуется выведение контроллера домена в автономный режим (все работают, ничего не отключено)
• восстановление объектов-захоронений гораздо лучше, чем простое воссоздание новой версии удаленного объекта

Часть атрибутов удаляется вместе с удалением объекта – их уже не восстановить. Например, членство в группах безопасности.
Если вы вновь создаете объект, он всегда будет иметь новые атрибуты objectGUID и objectSid (если это участник политики безопасности, такой как пользователь). В результате любые внешние ссылки на объект, такие как ACL, необходимо будет обновлять для отражения нового идентификатора объекта. Это может стать очень большой проблемой.
Поэтому в данном посте сначала будут рассмотрены способы, использующие tombstone-объекты, и лишь в конце приведена информация по принудительному восстановлению. В конце поста будут рассмотрены возможности утилиты восстановления NetWrix Active Directory Object Restore Wizard. Информация для поста взята из документа «Восстановление объектов Active Directory: сборник сценариев», подготовленного NetWrix. Заинтересованных приглашаем под кат.

Что необходимо восстановить: пример

Дано:
Из домена acme.com удалена OU Finance_Department с входящими в нее учетными записями Oleg и Dmitry и вложенной OU Admins, в которой находится учетная запись Sergey.
Задача:
Восстановить OU во всеми членами (включая и вложенную OU) и атрибутами учетных записей.

И решаться эта задача будет всеми возможными способами.

1. Восстановление объектов с помощью ldp.exe

Порядок действий:
1) Включаем отображение в консоли удаленных объектов (CN=Deleted Objects)
Сначала необходимо сделать так, чтобы удаленные объекты отображались (а по умолчанию контейнер CN=Deleted Objects не отображается. Используем ldp.exe в Active Directory (требует членства в Domain Admins).
1. Запускаем ldp.exe. (Пуск – Выполнить – ldp.exe)
2. В меню Options (Параметры) выбираем пункт Controls (Элементы управления)

3. В появившимся диалоговом окне выбираем меню Load Predefined (Предопределенная перезагрузка), в нем выбираем пункт Return deleted objects (Возврат удаленных объектов) и нажимаем Ок
4. Проверьте, как отображается контейнер удаленных объектов:
a. Чтобы подключиться и выполнить привязку к серверу, на котором находится корневой домен леса среды Active Directory, в разделе Connections (Подключение) выберите пункт Connect (Подключить) и нажмите Bind (Привязка).
b. Нажмите кнопку Обзор, выберите пункт Структура и в поле Distinguished Name (DN) введите DC=,DC=.
c. В дереве консоли дважды щелкните различающееся имя (DN) корневого домена и найдите контейнер CN=Deleted Objects, DC=acme,DC=com.

Восстанавливаем объекты:
Рассмотрим восстановление на примере учетной записи Oleg, входящей в OU Finance_Department.

1) Запускаем ldp.exe
2) В разделе Connections (Подключение) выбираем пункт Connect (Подключить) — Bind (Привязка) Подключаемся и осуществляем привязку к серверу, на котором находится корневой домен леса среды Active Directory

3) В дереве консоли переходим в контейнер CN=Deleted Objects (прописываем также DC=acme,DC=com для взятого за пример домена)

Результаты поиска

4) Находим в оснастке в контейнере CN=Deleted Objects объект, который хотим восстановить, щелкаем правой кнопкой на него и выбираем пункт Modify (Изменить).
5) В окне Modify (Изменение) меняем следующие параметры
a. В поле Edit Entry (Изменить запись) атрибута вводим isDeleted
b. Оставляем поле Values (Значение) пустым
c. В разделе Operation (Операция) выбираем Delete (Удалить) и нажимаем клавишу Enter (ВВОД)

d. В поле Edit Entry Attribute (Изменить запись Атрибута) вводим distinguishedName
e. В поле Values (Значения) вводим первоначальное различающееся имя (DN) этого объекта Active Directory.
f. В разделе Operation (Операция) выбираем Replace (Заменить)
g. Устанавливаем флажок Extended (Расширенный), нажимаем клавишу Enter (ВВОД), а затем Run (Выполнить)

Учетная запись восстановлена, но деактивирована. Включить ее необходимо будет вручную. Также вручную необходимо восстановить членство в группах и сбросить пароль.
Те же самые действия повторяем для оставшихся объектов:
OU Finance_Department
OU Admins
Учетной записи Dmitry
Учетной записи Sergey

Итог:

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

2. Используем ADRESTORE

Восстановление объектов-захоронений с помощью LDP дело несложное. Однако неудобное и долгое. Для этих целей есть ADRESTORE, которая предназначена специально для восстановления объектов AD.

Утилита работает в двух режимах:
• Запуск без параметров. Она выведет список всех объектов-захоронений в контейнере CN=Deleted Objects домена по умолчанию. Можно добавить строку для поиска в командной строке, чтобы выбрать объекты для показа:

C:> adrestore Finance_Department   

Выводятся все объекты в контейнере CN=Deleted Objects, которые содержат строку «Finance_Department» в атрибуте CN или OU — используется поисковый фильтр LDAP cn=*Finance_Department* и ou=*Finance_Department*. На рисунке ниже показаны результаты поиска, возвращенного программой ADRESTORE.

• Восстановление объектов
Если нужно восстановить объект-захоронение, а не только найти его, необходимо указать параметр –r вместе с дополнительной строкой, например, вот так:

C:> adrestore –r Finance_Department

Для восстановления учетных записей используем команды:

C:> adrestore –r Oleg
C:> adrestore –r Dmitry
C:> adrestore –r Admins
C:> adrestore –r Sergey

Команда предложит восстановить каждый удовлетворяющий условию объект-захоронение. Объект восстанавливается в контейнер, указанный атрибутом lastKnownParent объекта-захоронения (и никакой другой).
Эта команда предложит восстановить каждый подходящий объект-захоронение. ADRESTORE всегда восстанавливает объект в контейнер, указанный атрибутом lastKnownParent объекта-захоронения, нет никакого способа указать другой контейнер.

Итог:

ADRESTORE легче использовать, чем LDP.
Утилита позволяет относительно быстро восстановить объекты, но опять-таки без необходимых атрибутов — членство в группах и пароли придется восстановить вручную. Один из самых популярных способов восстановления объектов.

3. Использование AD Recycle Bin (Windows Server 2008 R2)

В Windows Server 2008 R2 появилась корзина Active Directory Recycle Bin (AD RB), Чтобы ее активировать, необходимо, чтобы уровень леса был Windows Server 2008 R2. AD RB напоминает обыкновенную корзину Windows — случайно удаленный объект может быть быстро и со всеми атрибутами восстановлен. Причем восстановленный из AD RB объект сразу же получает и все свои атрибуты. По умолчанию время «жизни» удаленного объекта в AD RB составляет 180 дней, после этого переходит в состояние Recycle Bin Lifetime, теряет атрибуты и через некоторое время полностью удаляется.
В самом простом случае восстановление объекта происходит с помощью Powershell командлетов Get-ADObject и Restore-ADObject (в том случае, если Вы точно знаете, что именно Вам необходимо восстановить). Командлет Get-ADObject используется для извлечения удаленного объекта, который затем передается с помощью конвейера в командлет Restore-ADObject:

1. Запускаем от имени администратора Модуль Active Directory для Windows PowerShell.
2. В командной строке Active Directory module for Windows PowerShell введите следующую команду:

PS C:> Get-ADObject -Filter {displayName -eq "user"} -IncludeDeletedObjects | Restore-ADObject

В данном примере
-Filter {displayName -eq «user»} указывает, что какую информацию об объекте AD необходимо получить (в примере – об объекте с отображаемым именем пользователя “user),
-IncludeDeletedObjects означает, что поиск осуществляется по удаленным объектам
Restore-ADObject непосредственно осуществляет восстановление объекта AD.

Поиск удаленных объектов
1. Запускаем от имени администратора Модуль Active Directory для Windows PowerShell.
2. В командной строке Active Directory module for Windows PowerShell вводим следующие команды для получения необходимой информации:

Вывод информации об удаленных объектах в домене acme.com

Get-ADObject -SearchBase "CN=Deleted Objects,DC=acme,DC=com"  –IncludeDeletedObjects 

Получаем информацию о том, в какой OU состоял удаленный пользователь

Get-ADObject -SearchBase "CN=Deleted Objects,DC=acme,DC=com" -ldapFilter:"(msDs-lastKnownRDN=User)" –IncludeDeletedObjects –Properties lastKnownParent

Где User – отображаемое имя пользователя

В итоге получаем информацию о принадлежности к OU указанного пользователя (с помощью -Properties lastKnownParent)

Поиск всех удаленных объектов, которые входили в данную OU

В качестве примера берем различающееся имя OU Finance_Department, которое было получено после запуска предыдущего командлета (Finance_Department\0ADEL:e954edda-db8c-41be-bbbd-599bef5a5f2a).

Get-ADObject –SearchBase "CN=Deleted Objects,DC=acme,DC=com" -Filter {lastKnownParent -eq 'OU=Finance_Department\0ADEL:e954edda-db8c-41be-bbbd-599bef5a5f2a,CN=Deleted Objects,DC=acme,DC=com'} -IncludeDeletedObjects -Properties lastKnownParent | ft

Внимание! Если у Вас имеется вложенная OU, восстановление осуществляется начиная с наивысшего уровня иерархии. В данном случае таковым является OU=Finance_Department.

Восстановление объектов

1. Запускаем Модуль Active Directory для Windows PowerShell
2. Восстанавливаем подразделение Finance_Department, выполнив в командной строке следующую команду:

Get-ADObject -ldapFilter:"(msDS-LastKnownRDN=Finance_Department)" –IncludeDeletedObjects | Restore-ADObject

3. Восстанавливаем учетные записи и OU, которые являются непосредственными дочерними объектами OU Finance_Department (помните, что на этом этапе различающееся имя Finance_Department уже восстановлено в значение OU=Finance_Department,DC=acme,DC=com)

Get-ADObject -SearchBase "CN=Deleted Objects,DC=acme,DC=com" -Filter {lastKnownParent -eq "OU=Finance_Department,DC=acme,DC=com"} -IncludeDeletedObjects | Restore-ADObject

Опционально (восстановление вложенных OU)

4. Восстанавливаем учетные записи, входящие во вложенную OU (например, OU Admins, которая входит в состав OU Finance Department. Различающееся имя в нашем примере было восстановлено в значение OU=Admins,OU=Finance_Department,DC=acme,DC=com)

Get-ADObject -SearchBase "CN=Deleted Objects,DC=acme,DC=com" -Filter {lastKnownParent -eq "OU=Admins,OU=Finance_Department,DC=acme,DC=com"} -IncludeDeletedObjects | Restore-ADObject

Подробную справку о командлетах и их параметрах вызвав командлет Get-Help, например Get-Help Get-ADObject

Итог:
Объекты будут восстановлены в первоначальный вид – со всеми атрибутами.
Однако, как мы можем видеть, данный метод довольно сложен, когда приходится работать с большим количеством объектов.
Также требуется, все сервера в лесу должны быть Windows 2008 R2.
Для восстановления объектов с атрибутами при включенной корзине AD можно использовать описанные выше инструменты LDP и AdRestore.

4. Принудительное восстановление с помощью NTDSUTIL

Стандартным способом (но, однако, не самым подходящим) является принудительное восстановление из резервной копии в режиме Directory Service Restore Mode. Он обладает серьезными недостатками: нужно перезагружать сервер, а во-вторых, восстанавливать из резервной копии состояние системы и помечать, какие объекты не будут перезаписаны процессом репликации.
Восстановление осуществляется с помощью утилиты командной строки NTDSUTIL. Утилита становится доступной после установки роли AD DS. Используя ее, можно восстановить как OU со всем содержимым, так и отдельный объект.
Работа утилиты основана на мгновенных снимках (снапшотах) Active Directory, которые делаются при помощи службы VSS.

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

Порядок действий:
1. Нам необходимо восстановить OU Finance_Department из домена acme.com
2. Загружаемся в режиме DSRM (в загрузочном меню вызывается нажатием клавиши F8) и выполните регистрацию с паролем, DSRM, заданным во время работы Dcpromo. AD не загружается, база данных переводится в автономный режим.

Внимание! Невозможно выполнить восстановление, если на контроллерах домена Server 2008 и выше остановлена служба NTDS AD.

3. Восстановите системное состояние из резервной копии, созданной до аварии.

Внимание! Не перезагружайте компьютер.

В снимке, полученном при помощи ntdsutil, присутствует как сам объект, так и его атрибуты. Образ можно монтировать и подключать в качестве виртуального LDAP-сервера, экспортирующего объекты. Запускаем ntdsutil:

> ntdsutil
ntdsutil: snapshot

Просматриваем список доступных снимков:

снимок: list all

1: 2009/04/22:23:18 {8378f4fe-94c2-4479-b0e6-ab46b2d88225}

2: C: {732fdf7f-9133-4e62-a7e2-2362227a8c8e}

3: 2009/04/23:00:19 {6f7aca49-8959-4bdf-a668-6172d28ddde6}

4: C: {cd17412a-387b-47d1-9d67-1972f49d6706}

Монтируем командой mount c указанием номера или {ID}:

снимок: mount 4
Снимок {cd17412a-387b-47d1-9d67-1972f49d6706} установлен как C:$SNAP_200904230019_VOLUMEC$

Снимок смонтирован.

4. Запустите команду

Для восстановления подразделения Finance_Department

> ntdsutil "authoritative restore" "restore subtree ou=Finance_Department,dc=acme,dc=com" q q

В итоге будет восстановлена OU Finance_Department с входящими в нее учетными записями и вложенной OU Admins
Для восстановления отдельной учетной записи, например, c отображаемым именем Oleg

> ntdsutil "authoritative restore" "restore object cn=Oleg,ou=Finance_Department,dc=acme,dc=com" q q

5. Необходимо подтвердить предупреждения безопасности. Затем будет выдано сообщение, подобное показанному на рисунке 3. Обратите внимание на сформированные текстовые и LDIF-файлы.

Перезагрузите DC в нормальном режиме запуска операционной системы.
7. Зарегистрируйтесь на DC и откройте командную строку. Импортируйте LDIF-файл, экспортированный на шаге 5, выполнив команду

ldifde -i -f
ar_20110221-151131_links_contoso.com.ldf

где ar_20110221-151131_links_contoso.com.ldf – имя созданного LDIF-файла.
8. В результате будут импортированы значения связанных атрибутов (такие, как членство в группах) для восстановленных объектов

Внимание! Если в лесу содержится несколько доменов, необходимо использовать текстовый файл, экспортированный на шаге 6 для восстановления членства в локальных группах других доменов.

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

5. NetWrix Active Directory Object Restore Wizard

Процесс восстановления объектов можно очень сильно упростить, если воспользоваться утилитой NetWrix Active Directory Object Restore Wizard.
Сразу хочется отметить, что в нашу компанию постоянно обращаются администраторы, которые удалили объекты AD и теперь хотят их восстановить. Предлагаемое нами решение – NetWrix Active Directory Object Restore Wizard — хоть и позволяет упростить процесс восстановления объектов (например, восстановить OU со всеми объектами и их атрибутами за пару кликов), однако все равно не творит чудеса – программа должна быть установлена в домене и периодически делать снимки AD. Поэтому рекомендуем после прочтения статьи все-таки поставить программу работать (есть бесплатная версия с периодом восстановления за последние 4 дня), чтобы в следующий раз не испытывать таких проблем с восстановлением объектов.
Утилита позволяет восстанавливаться удаленные объекты за пару кликов, а в том случае, если программа работала до удаления объектов в домене, то восстановление происходит со всеми атрибутами. В итоге Вы получаете возвращенные учетные записи за пару минут без серьезных сбоев в работе организации. Также следует отметить то, что программа позволяет восстанавливать удаленные почтовые ящики.

Работа с программой сводится к следующим шагам:
1. Запускается мастер NetWrix Active Directory Object Restore Wizard.

2. Выбирается режим восстановления:
• Только из tombstone-объектов (если программа не была установлена до этого в домене)
• Восстановление с использованием снапшотов (если программа была установлена и был сделан хотя бы один снапшот)

3. По результатам анализа выводится список удаленных объектов с их первоначальной иерархией и объектами

4. Выберите те OU или объекты, которые необходимо восстановить, и нажмите далее
5. В зависимости от того, была ли установлена программа раньше или нет:
• Если не была, то необходимо вручную восстановить членство в группах и пароли пользователей
• Если программа была установлена, то восстановление на этом закончено и все будет работать так, как будто ничего не произошло.

Как Вы можете видеть, восстановление объектов занимает гораздо меньше времени, нежели с использованием штатных инструментов восстановления объектов Active Directory.
Но восстановление объектов – это только одна из сторон программы. Вы также можете откатывать изменения объектов – вплоть до значения одного атрибута – программа предназначена и для этого.

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

Все эти способы восстановления приведены в «Наборе первой помощи для восстановления объектов AD», который Вы можете скачать на нашем сайте

First published on TechNet on Mar 31, 2011

[Today’s post comes to us courtesy of Shawn Sullivan from Commercial Technical Support]

If you have ever been in the situation where you had to recover an Active Directory object that was accidentally deleted within a multiple Domain Controller environment, then you are probably somewhat familiar with the term “authoritative restore” and what it does. This

link

gives a pretty in-depth look at the procedure, however, some important points I want to call out on this post are:

• An authoritative restore is used if you are recovering objects from Active Directory that have either been deleted or changed and you need to restore those objects to their previous state.
  

  • An object change or deletion will replicate to the other Domain Controllers in your network.
  • The state of the object in the backup is considered “out-of-date” unless you specifically mark the restore of this object as authoritative.
  • If you restore the system state and boot the server into normal mode before you mark the object for an authoritative restore, you will find that the object is once again changed or deleted when the server receives inbound replication from its partner.

• Be as specific as possible when targeting the objects that you intend to restore. For example, if you simply need to recover a deleted user account, don’t mark the entire OU that contains it for an authoritative restore. Just mark the user account itself.
  

  • Avoid unnecessarily or undesirably reverting any objects to their previous state that are not related to the deletion. You could inadvertently restore attributes like passwords, profile paths, and group memberships that may no longer be valid.
  • Minimize the amount of data requiring replication across the network.

• If you are recovering a Domain Controller from a full or system state backup and wish to restore it back into the domain without making any changes to the state or content of the domain, then you
  
  should not
  
  perform an authoritative restore.
  

  • This is usually in scenarios where something other than Active Directory needs to be recovered on a Domain Controller. For example, a server with a corrupted file system or failing hardware.
  • In this scenario, a healthy copy of Active Directory in the desired state still remains within the other Domain Controllers in the network. When the Domain Controller is restored, its copy of Active Directory will be brought up to date when it receives inbound replication from its partner.

Scenarios where you would mark the entire copy of Active Directory as authoritative are rare and the situation is most likely catostrophic. If you believe you might be in a situation like this, you should probably contact Microsoft Product Support Services for troubleshooting assistance.

Performing an authoritative restore of objects in Active Directory can become a very complicated proposition, depending on what it is that you intend to recover. There are just too many variables and different situations you could find yourself in to cover in one comprehensive article. However, to give you a good idea of the whole process, we will go through the common scenario where you wish to restore a single user account to its complete original state.

Note:

There are tools, such as

ADRestore

, that can pull a deleted object out of its tombstone and place it in its previous location. However, certain attributes that are stripped from the object when it was deleted cannot be restored by such tools; for instance passwords and group memberships for user accounts. A tool like ADRestore is meant to be used if you do not have system state backup, not as a replacement for a system state backup.

1. Boot the SBS server into Directory Services Restore Mode and restore the system state backup with your chosen backup application:

   1. After the POST, press F8 to enter the advanced boot options, choose
      
      Directory Services Restore Mode
      
   2. Concerning the username and password that you will use to login to the server after it has booted into DSRM, review the following

      post

   3. If you have taken your backup using SBS Backup or Windows Server Backup, review the following

      post

      . Here I have used
      
      wbadmin
      
      to obtain the ID for my available system state backup and to begin the restore procedure:

      
      
      
      

2. 
   Before
   
   you boot into normal mode, launch
   
   NTDSUTIL
   
   and mark the user account you wish to recover for authoritative restore:

   1. Activate the NTDS instance:
      
      Activate Instance NTDS
      
      (see below).
   2. Enter the
      
      Authoritative Restore
      
      context (see below).
   3. Mark the object for authoritative restore:
      
      Restore Object “cn=
      
      username
      
      ,ou=
      
      organizational unit
      
      ,dc=
      
      domain
      
      ,dc=
      
      local
      
      ”
      
      (see below).
   4. Click
      
      Yes
      
      to confirm

      

      

      
      

      Note:

      
      The .txt. and .ldf files that are created during the restore process (see the output above) are for use in situations where you are recovering users and security groups that may have been migrated at some point in time from SBS 2000. For an explanation on this, see the sections “LVR and Restoration of Group Memberships” and “Files for Recovering Group Memberships Following Authoritative” under the following technet article :

      http://technet.microsoft.com/en-us/library/690730c7-83ce-4475-b9b4-46f76c9c7c90

You can see from the output that the attribute’s version number was incremented by 100000, which essentially make it more up-to-date as compared with what the remaining Domain Controllers have for this object. You can also see that 4 records were updated, this is the security group membership held by the account that I had deleted. In a simple recovery of a single user account, we do not have to take any further action at this point other than rebooting the server into normal mode.

New for SBS 2011 Standard

Windows 2008 R2 introduces a new feature called the AD Recycle Bin, which allows you to restore a deleted object in its entirety without having to go through the process I just talked about. This can save you quite a bit of time, but there are some caveats:

• This is not enabled by default on SBS 2011 Standard.
• To enable this feature, you must raise the forest functional level to Windows 2008 R2. This means you cannot have any domain controllers running Windows 2008 and earlier in the SBS domain.
• There is no simple GUI interface for this feature. You have to go through either LDP.exe or PowerShell to use it.
• This
  
  is not
  
  a replacement for system state backups. This is for recovering individual objects only, not the entire server.

You can find a step-by-step walkthrough at the following link, this covers everything from raising the functional level to performing a restore:

http://technet.microsoft.com/en-us/library/dd392261(WS.10).aspx

Рубрика: Администрирование /  Продукты и решения

Facebook Twitter Мой мир Вконтакте Одноклассники Google+

The process of executing an authoritative restore starts off the same as with a non-authoritative restore:

1. Boot the domain controller into DSRM.

2. Uuse wbadmin to restore system state data.

3. Before a reboot takes place, mark a subtree or an entire domain as authoritatively restored using ntdsutil.

4. Once in an elevated command line, type the following commands:

Ntdsutil [ENTER]

Activate instance «NTDS» [ENTER] Authoritative restore [ENTER]

Restore subtree dc=flexecom,dc=local [ENTER] Quit [ENTER] Quit [ENTER]

This completes the authoritative restore, in this example, for the entire domain naming context of flexecom.local. Now reboot your domain controller and monitor how restored changes make their way to the rest of the domain controllers.

Note that with Windows Server 2008 you no longer have to reboot domain controllers in order to be able to recover the Active Directory Domain Services database. This new recovery process is covered in the next section.

You do not have to type full commands in Ntdsutil. It is sufficient to type just a few letters to make sure the input can be parsed into commands unambiguously. Authoritative restore, for example, can be shortened to auth res.

on the

Table 7-1 describes four main command choices, one of which must be executed while in the authoritative restore command context, to make this restore authoritative.

Why would you want to specify the version increment manually? It is conceivable that one authoritative restore was already performed and was not successful, that there was a very long delay since the most recent system state backup was taken, or that a large update operation may need to be undone. This is where you may need to jump ahead of USNs by a safe margin. Instead of the default 100,000, you might want to specify, say, 300,000.

Another important thing to keep in mind here is that you will want to minimize the extent of the authoritative restore in the partition, because restoring the entire configuration or domain partition may revert computer and trust passwords to their states at the time of backup on a larger scale, and you might have to do more work by resetting them manually (or rejoining the domain) after the restore.

Upon rebooting your domain controller, two things will happen. The restored Active Directory will receive and commit to its database the changes made from the time of backup, but only for those naming contexts (aka, partitions), or portions of naming contexts, that were not marked as authoritative. Those naming contexts, or subtrees of naming contexts that were marked as authoritative, will replicate to other domain controllers in the organization (the domain context to domain controllers in the same domain, and the configuration context to all domain controllers in the forest).

Ntdsutil Authoritative Restore Commands

Command	Description
Restore database	This will mark entire configuration and domain partitions as authoritative. USN version numbers are increased by 100,000.
Restore database verinc <number>	This will mark entire configuration and domain partitions as authoritative and increase USN version numbers by <number> value.
Restore subtree <LDAP path>	This will mark a portion of either configuration or domain data as authoritative, as specified in <LDAP path>. This must be an absolute, not relative, reference to an LDAP container. In practical terms, container here means OU. Note that this will restore all child objects in the OU, all of its subcontainers, and their respective child objects as well. USN version numbers are increased by 100,000 by default.
Restore subtree <LDAP path> verinc <number>	This command is similar to the preceding one in what it will mark as authoritative. The difference here is that you have control over the default USN version number increment value.

Continue reading here: Using ntdsutil to Seize an FSMO Role

Was this article helpful?

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

Масштабы аварий AD могут быть очень разными. Это может быть просто сбой единственного контроллера домена (DC) или случайное удаление одного объекта. Сложнее, если случайно удалена целая иерархия организационных единиц (OU). В худшем случае требуется восстанавливать целый домен или лес.

.

Стратегия резервного копирования

В первую очередь необходимо иметь материал для восстановления. По меньшей мере, требуются последние резервные копии состояния системы не менее чем двух контроллеров домена в каждом домене леса. Последние резервные копии состояния системы можно получить с помощью Windows Server Backup (Windows Server 2008 и более новые версии), NTBackup (Windows Server 2003 и Windows 2000 Server) и большинства других инструментов резервного копирования. Однако лучше всего проверить резервные копии, чтобы убедиться в их исправности. Важно использовать инструмент резервного копирования, совместимый со службой Volume Shadow Copy Service (VSS). Программы резервного копирования, в которых применяются образы дисков или моментальные снимки виртуальных машин, как правило, несовместимы с AD. Восстановление резервной копии с помощью одного из этих инструментов может привести к серьезным проблемам репликации, известным как возврат номера последовательного обновления (USN).

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

Чтобы смягчить эти проблемы, я часто применяю двухуровневый подход к резервному копированию DC. С помощью сценария Windows Server Backup запускается на DC каждый вечер, а резервные копии за одну или две недели хранятся локально на DC. Папка, содержащая резервные копии, объявляется общей, и доступ к ней ограничивается инструментом резервного копирования, так как многие инструменты могут работать с общей папкой без агента. Кроме того, иногда я сохраняю файлы архива на соседних DC внутри сайта. Поэтому, например, если в сайте имеются контроллеры домена DC1 и DC2, резервные копии DC1 хранятся в общей папке на DC2, и наоборот.

Перечислим преимущества двухуровневого подхода.

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

Используемый сценарий для запуска Windows Server Backup вместе с соответствующими инструкциями опубликованы в блоге по адресу briandesmond.com/blog/managing-local-backups-withwindows-server-backup/.

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

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

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

netdom query fsmo

в окне командной строки. Затем можно захватить роли FSMO с использованием утилиты Ntdsutil. Следуйте инструкциям в разделе Seize FSMO roles в статье Microsoft «Using Ntdsutil.exe to Transfer or Seize FSMO Roles to a Domain Controller» (support.microsoft.com/kb/255504). При захвате роли FSMO не рекомендуется подключать к сети первоначального обладателя роли.

Поскольку нельзя вернуть первоначального владельца роли FSMO, второй шаг — удалить метаданные конфигурации отказавшего контроллера домена в AD. Это можно сделать с помощью утилиты Ntdsutil. Выполните действия, описанные в статье Microsoft «How to Remove Data in Active Directory After an Unsuccessful Domain Controller Demotion» (support.microsoft.com/kb/216498). Однако, если используется версия оснастки Active Directory Users and Computers для Server 2008 (или более новой), это можно сделать, удалив учетную запись DC в организационной единице Domain Controllers.

Повторное назначение компьютера контроллером домена через сеть может оказаться неприемлемым, если из-за большого объема реплицируемых данных сеть подвергается перегрузке. В этом случае существует еще два варианта. Первый — восстановить состояние системы DC из резервной копии и продолжать работу. Второй — использовать функцию восстановления с носителя (Install from Media, IFM), появившуюся в Windows 2003. Благодаря IFM можно задействовать резервную копию состояния системы (подготовленную с помощью NTBackup в Windows 2003) или носитель IFM (созданный с использованием Ntdsutil в Server 2008 или новой версии) и указать Dcpromo базу данных на IFM-носителе. IFM-носитель, подготовленный в Windows 2003, необходимо сначала восстановить в другом месте файловой системы (в этом случае его может использовать Dcpromo). DC внесет необходимые изменения в базу данных на носителе и реплицирует только изменения, так как носитель был создан через сеть.

Жизненный цикл объекта AD

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

Рисунок 1. Обычный срок существования объекта AD

При удалении объекта из AD атрибуту isDeleted присваивается значение True, и почти все атрибуты объекта удаляются. Объект перемещается в контейнер Deleted Objects, а атрибут lastKnownParent отмечается различающимся именем (DN) родительского объекта, прежде чем объект удаляется. Объект, отмеченный как удаленный, невидим для любых инструментов, опрашивающих AD, если не добавить специальный элемент управления LDAP, указывающий на необходимость показывать помеченные к удалению объекты в поисковых результатах AD. Этот элемент управления есть в различных бесплатных инструментах формирования запросов LDAP (таких, как AdFind из www.joeware.net).

Объект останется удаленным в течение определенного времени. По умолчанию время существования «захоронения» в лесу определяется операционной системой первого DC леса. В таблице показано время существования «захоронений» по умолчанию. При обновлении AD время существования «захоронений» для леса не меняется.

Таблица. Обычное время существования «захоронения» в новых лесах

Периодически на каждом DC запускается фоновый процесс, именуемый «сбором мусора». «Сборщик мусора» просматривает базу данных в поисках «захоронений» старше установленного для леса срока их существования и удаляет их из базы данных AD.

До того как «захоронение» удалено «сборщиком мусора», можно восстановить объект, реанимировав его. После реанимации восстанавливаются лишь немногие атрибуты, сохранившиеся в процессе «захоронения». Например, атрибуты, сохраненные для объекта пользователя, включают SID пользователя, журнал SID и имя пользователя (sAMAccountName). Обратите внимание, что в этом списке отсутствуют такие атрибуты, как пароль пользователя, членство в группах или демографическая информация (например, имя и подразделение). Списком атрибутов, сохраняемых при «захоронении» объекта, можно управлять, изменяя атрибут searchFlags в определении индивидуального атрибута в схеме. Количество атрибутов не ограничено, но нельзя добавлять связанные атрибуты, такие как членство в группе или база данных почтовых ящиков, содержащая почтовый ящик пользователя.

В лесу AD на функциональном уровне леса (FFL) Server 2008 R2 можно активировать новую функцию — корзину Active Directory Recycle Bin. Как показано на рисунке 2, благодаря корзине Active Directory появляется промежуточное состояние между удалением и «захоронением» объекта. Объект, находящийся в новом удаленном состоянии, не отображается в результатах поиска, но все его атрибуты (в том числе связанные атрибуты, такие как членство в группах) сохраняются.

Рисунок 2. Срок существования объекта AD при включенной корзине Active Directory

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

После окончания срока существования объекта, отмеченного как удаленный, «сборщик мусора» перемещает объект на этап утилизации. Утилизация — функциональный эквивалент «захоронения», с одним отличием: нельзя реанимировать утилизированный объект или восстановить его из резервной копии.

Механизмы восстановления объектов

С каждым новым выпуском AD становится все более зрелой, и механизмы восстановления удаленных объектов совершенствуются. В Windows 2000 единственным способом восстановить объект, отмеченный как удаленный, было выполнить принудительное восстановление из резервной копии. Вместе с Windows 2003 появилась концепция реанимации из «захоронений», чтобы получить частичную копию удаленного объекта, не восстанавливая его из резервной копии. В Server 2008 R2 добавилась корзина Active Directory, что позволяет полностью вернуть удаленный объект без восстановления.

Важно отметить, что срок хранения резервной копии AD (а также носителя IFM) — такой же, как у «захоронения». Если включена корзина Active Directory, срок хранения равен меньшему из сроков существования объекта, отмеченного как удаленный, и утилизированного объекта. Например, если срок существования объекта, отмеченного как удаленный, — 180 дней, а утилизированного объекта — 60 дней, то срок хранения будет 60 дней. Таким образом, невозможно восстановить отмеченный как удаленный объект из резервной копии, которая старше этих значений.

Принудительное восстановление

Если требуется получить объект или группу объектов из резервной копии, часто приходится использовать принудительное восстановление. Пункт Directory Services Restore Mode (DSRM) в загрузочном меню (вызываемом нажатием клавиши F8) DC предназначен для принудительного восстановления. Если выполнить загрузку в режиме DSRM, AD не запускается, а база данных переводится в автономный режим. Можно восстановить базу данных AD из резервной копии в режиме DSRM, а затем выбрать восстанавливаемые объекты с помощью Ntdsutil. Обратите внимание, что невозможно выполнить восстановление, если на контроллерах домена Server 2008 и более новых версий остановлена служба NTDS AD.

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

Часто принудительно восстанавливаются организационные единицы (OU), содержащие множество объектов (учетные записи пользователей, групп, компьютеров, других OU). Предположим, случайно удалена организационная единица Executives из домена contoso.com. Чтобы вернуть OU и все ее содержимое, необходимо выполнить следующие шаги.

1. Загрузитесь в режиме DSRM и выполните регистрацию с паролем DSRM, заданным во время работы Dcpromo.

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

3. Откройте командную строку и запустите Ntdsutil.

4. Запустите команду

authoritative restore

5. Воспользуйтесь командой

restore subtree
   OU=Executives, DC=contoso, DC=com

6. Просмотрите и подтвердите предупреждения безопасности. Затем будет выдано сообщение, подобное показанному на рисунке 3. Обратите внимание на сформированные текстовые и LDIF-файлы.

Рисунок 3. Сообщение об успешном принудительном восстановлении

7. Перезагрузите DC в нормальном режиме запуска операционной системы.

8. Зарегистрируйтесь на DC и откройте командную строку. Импортируйте LDIF-файл, экспортированный на шаге 6, выполнив команду

ldifde -i -f
   ar_20110221-151131_links_contoso
      . com.ldf

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

Если нужно восстановить лишь один объект (например, отмеченный как удаленный объект — компьютер), можно воспользоваться командой restore object вместо команды restore subtree на шаге 5. Если в лесу содержится несколько доменов, необходимо использовать текстовый файл, экспортированный на шаге 6 для восстановления членства в локальных группах других доменов.

Реанимация «захоронений»

Существует несколько инструментов для реанимации, но в сущности, все они выполняют одни и те же действия. В качестве примера рассмотрим шаги, необходимые для реанимации отмеченной как удаленная учетной записи пользователя John Doe с использованием утилиты AdRestore (technet.microsoft.com/en-us/sysinternals/bb963906).

1. Откройте командную строку и выполните поиск учетной записи пользователя с помощью команды

adrestore Doe

AdRestore ищет удаленные объекты, соответствующие шаблону *doe*, и выдает результаты, как показано на рисунке 4.

Рисунок 4. Пример вывода утилиты AdRestore

2. Проверьте наличие реанимируемого объекта, а затем вновь запустите AdRestore с ключом -r:

adrestore -r Doe

3. Подтвердите свое намерение реанимировать объект. AdRestore реанимирует объект в том месте, где он находился ранее.

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

Восстановление из корзины Active Directory

Корзина Active Directory, несомненно, лучший вариант восстановления, поскольку восстанавливаются все атрибуты, в том числе связанные, такие как членство в группах. Однако, как отмечалось выше, для этого лесу необходим функциональный уровень Windows Server 2008 R2.

Активировать корзину Active Directory можно с использованием Windows PowerShell, выполнив команду

Enable-ADOptionalFeature -Identity
   'CN=Recycle Bin Feature,
   CN=Optional Features,
   CN=Directory Service,
   CN=Windows NT, CN=Services,
   CN=Configuration, DC=contoso, DC=com'
   -Scope ForestOrConfigurationSet
   -Target 'contoso.com'

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

Любые объекты, удаленные после активации корзины Active Directory, можно полностью восстановить в течение срока существования удаленных объектов леса. Есть несколько способов удалять объекты, но самый простой — использовать команды PowerShellТs Restore-ADObject. Например, для восстановления пользователя с именем John Doe нужно выполнить следующие шаги.

1. Запустите модуль Active Directory для Windows PowerShell из раздела Administrative Tools из меню Start.

2. Выполните поиск удаленного объекта, запустив команду

Get-ADObject -SearchBase
   "CN=Deleted
      Objects, DC=contoso, DC=com"
   -ldapFilter:" (msDs-lastKnownRDN=John
      Doe)"
   -IncludeDeletedObjects
   -Properties lastKnownParent

Убедитесь, что это единственный объект в наборе результатов.

3. Восстановите объект с помощью команды

Get-ADObject -SearchBase
   "CN=Deleted
      Objects, DC=contoso, DC=com"
   -ldapFilter:" (msDs-lastKnownRDN=John
      Doe)"
   -IncludeDeletedObjects
   -Properties lastKnownParent |
   Restore-ADObject

Если была удалена вся организационная единица, объекты нужно восстанавливать в правильном порядке (то есть нельзя восстанавливать объект прежде его родителя), чтобы разместить их в нужных местах. Полезный сценарий PowerShell для восстановления дерева объектов опубликован по адресу technet.microsoft.com/en-us/library/dd379504(WS.10).aspx на сайте Microsoft.

Сложная задача

Планирование аварийных мер для AD — сложная задача из-за огромного разнообразия возможных ошибок. Однако, зная способы восстановления отказавшего DC и случайно удаленного объекта или целого дерева объектов (такого, как OU), можно надежно застраховаться от неприятностей.

Брайан Десмонд (brian@briandesmond.com) — старший консультант компании Moran Technology Consulting (Чикаго). Имеет сертификат Directory Services MVP. Автор книги «Active Directory», ведет блог www.briandesmond.com

In this article we’ll show how to restore Active Directory domain controller from a System State backup created earlier (see the article Active Directory backup) and discuss the types and principles of AD DC recovery.

Suppose, your AD domain controller has failed, and you want to restore it from a backup copy. Before you start to restore your DC, you must understand which scenario to use. It depends on whether you have other domain controllers in your network and the health of the Active Directory database on them.

How to Restore a Domain Controller Using Replication?

DC recovery through standard AD replication is not quite a restoration of a DC from a backup. You can use this scenario if you have multiple domain controllers in your enterprise network, and all of them are operable. This scenario involves new server installation with its further promotion to a new ADDS domain controller on the same site. The old DC is simply removed from AD.

It is the easiest way that is not related to any irreversible AD changes. In this scenario, the ntds.dit database, GPO files and the contents of the SYSVOL folder will be automatically replicated to the new domain controller from the DCs that have stayed online.

If the ADDS database is small and another DC is available over a high-speed network link, the method described above is faster than to restore a DC from a backup copy.

Active Directory Restore Types: Authoritative & Non-Authoritative

There are two types of Active Directory DC restore from a backup that you must clearly understand prior you try to do it:

• Authoritative Restore — after you have restored your AD objects, the replication is performed from the restored DC to all other domain controllers. This restore type is used in the scenarios when a single DC or all DCs have failed at the same time (for example, after a ransomware or virus attack) or a damaged NTDS.DIT database was replicated across a domain. In this mode the USN (Update Sequence Number) value of all restored AD objects is increased by 100,000. Thus, DCs will see all restored objects as newer ones and they will be replicated in the domain. Use the Authoritative Restore very carefully!!!

  At the Authoritative Restore you will lose most AD changes made after you have created your backup (AD group membership, Exchange attributes, etc.).

• Non-authoritative Restore — after you have restored your AD database, the controller informs other DCs that it has been restored from a backup and needs the latest AD changes (a new DSA Invocation ID is created for the DC). You can use this recovery method on remote sites when it is hard to quickly replicate a large AD database through a slow WAN channel or if you had some important data or apps on your server.

Restore Active Directory Domain Controller from a System State Backup

Suppose, you have only one DC in your domain. On some reason a physical server it has been running on failed.

You have a relatively recent System State of your domain controller, and you want to restore Active Directory on a brand new server using Authoritative Restore.

To start the DC restore, you must install the same Windows Server version you had on a failed DC. Install the ADDS role (don’t configure it) and Windows Server Backup feature in the Windows Server you have just installed.

In order to restore your Active Directory you must boot the server in the DSRM (Directory Services Restore Mode). To do it, run msconfig and select the option Safe Boot -> Active Directory repair in the Boot tab.

Restart you server. It will boot in the DSRM. Run the Windows Server Backup (wbadmin) and select Recover in the right menu.

In the Recovery Wizard, check ‘A backup stored on another location.’

Then select the disk, on which the backup of the old AD domain controller is stored or specify the UNC path to it.

To make WSB see your backup on the disk, place the WindowsImageBackup directory with your backup to the root drive folder. You can make sure that there are backups on your drive using this command:
wbadmin get versions -backupTarget:D:

Select the date of the backup to be used for recovery.

Check System State to restore it.

Select Original location and do check Perform an authoritative restore of Active Directory files.

The system will show a warning that it is another server backup and if recovered on a different server it may not work. Click OK.

Agree to another warning as well:

Windows Server Backup
Note: This recovery option will cause replicated content on the local server to re-synchronize after recovery. This may cause potential latency or outage issues.

Then the process of AD domain controller recovery on a new server will start. When it is over, the server will require a reboot (the name of the new server will be changed to the DC hostname from the backup).

Boot the server in the normal mode (disable the DSRM using msconfig).

Login to the server using an account with the domain administrator privileges.

When I ran the Active Directory Users and Computers (ADUC) console for the first time, I got the following error:

Active Directory Domain Services
Naming information cannot be located for the following reason:
The server is not operational.

There were no SYSVOL and NETLOGON folders on the restored domain controller To fix this error:

1. Run the regedit.exe;
2. Go to the registry key HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParameters;
3. Change the SysvolReady value from 0 to 1;
4. Then restart the NetLogon service: net stop netlogon & net start netlogon

Try to open ADUC again. You will see your domain structure.

So you have successfully recovered your AD domain controller in the Authoritative Restore mode. Then all objects in Active Directory will be automatically replicated to other domain controllers.

If you have the only DC left, make sure that it owns all 5 FSMO roles and seize them if needed.

How to Restore Separate AD Objects from a Backup?

If you want to restore specific AD objects, use the Active Directory Recycle Bin. If the tombstone lifetime has already expired or Active Directory Recycle Bin is not enabled, you can recover separate AD objects using the Authoritative Restore mode.

In brief, the procedure has the following steps:

1. Boot the DC in the DSRM mode;
2. Display the list of available backups: wbadmin get versions
3. Start the recovery of the selected backup: wbadmin start systemstaterecovery –version:[your_version]
4. Confirm the DC restore (in the Non-Authoritative mode)
5. After the restart, run the ntdsutil
6. activate instance ntds
7. authoritative restore

Specify the ful LDAPl path to the object you want to restore. You can restore the entire OU:

restore subtree ″OU=Users,DC=woshub,DC=com″

Or a single AD object:

restore object “cn=Test,OU=Users,DC=woshub,DC=com”

This command will deny the replication of the specified objects (paths) from other domain controllers and increase the object USN by 100,000.

Exit ntdsutil: quit

Boot the DC in the normal mode and make sure that the object has been restored.