восстановление active directory windows 10 что это

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

В этой статье мы покажем, как восстановить контроллер домена Active Directory из резервной копии System State, созданной ранее (см. статью Резервное копирование Active Directory) и рассмотрим типы и принципы восстановления DC в AD.

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

Восстановление контроллера домена AD через репликацию

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

Это самый простой способ, который гарантирует что вы не внесете непоправимых изменений в AD. В этом сценарии база ntds.dit, объекты GPO и содержимое папки SYSVOL будут автоматически реплицированы на новый DC с DC-ов, оставшихся онлайн.

Если размер базы ADDS небольшой и другой DC доступен по скоростному каналу, это намного быстрее, чем восстанавливать DC из бэкапа.

Типы восстановления Active Directory: полномочное и неполномочное

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

Восстановление контроллера домена AD из system state бэкапа

Итак, предположим, что у вас в домене только один DC. По какой-то причине вышел из строя физический сервер, на котором он запущен.

У вас есть относительно свежий бэкап System State старого контроллера домена, и вы хотите восстановить Active Directory на новом сервере в режиме полномочного восстановления.

Чтобы приступить к восстановлению, вам нужно установить на новом сервер туже версию Windows Server, которая была установлена на неисправном DC. В чистой ОС на новом сервере нужно установить роль ADDS (не настраивая ее) и компонент Windows Server Backup.

Active Directory repair mode» srcset=»https://winitpro.ru/wp-content/uploads/2019/10/safe-boot-greater-active-directory-repair-mode.png 575w, https://winitpro.ru/wp-content/uploads/2019/10/safe-boot-greater-active-directory-repair-mode-300×196.png 300w» sizes=»(max-width: 575px) 100vw, 575px» />

Перезагрузите сервер. Он должен загрузиться в режиме DSRM. Запустите Windows Server Backup (wbadmin) и в правом меню выберите Recover.

В мастере восстановления выберите, что резервная копия хранится в другом месте (A backup stored on another location).

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

Выберите дату, на которую нужно восстановить резервную копию.

Укажите, что вы восстанавливаете состояние System State.

Выберите для восстановления «Исходное размещение» (Original location) и обязательно установите галочку «Выполнить заслуживающее доверия восстановление файлов Active Directory» (Perform an authoritative restore of Active Directory files).

Система покажет предупреждение, что эта резервная копия другого сервера, и что при восстановлении на другом сервере может не завестись. Продолжаем.

Согласитесь с еще одним предупреждением:

После этого запустится процесс восстановления контроллера домена AD на новом сервере. По завершении сервер потребует перезагрузку (имя нового сервера будет изменено на имя DC из бэкапа).

Загрузите сервер в обычном режиме (отключите загрузку в DSRM режиме)

Авторизуйтесь на сервере под учетной записью с правами администратора домена.

При первом запуске консоли ADUC я получил ошибку:

При этом на сервере нет сетевых папок SYSVOL and NETLOGON. Чтобы исправить ошибку:

Попробуйте открыть консоль ADUC еще раз. Вы должны увидеть структуру вашего домена.

Итак, вы успешно восстановили свой контроллер домен AD в режиме Authoritative Restore. Теперь все объекты в Active Directory будут автоматически реплицированы на другие контроллеры домена.

Если у вас остался единственный DC, проверьте что он является хозяином всех 5 FSMO ролей и выполните их захват, если нужно.

Восстановление отдельных объектов в AD

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

Вкратце процедура выглядит следующим образом:

Укажите полный путь к объекту, который нужно восстановить. Можно восстановить OU целиком:

restore subtree ″OU=Users,DC=winitpro,DC=ru″

restore object “cn=Test,OU=Users,DC=winitpro,DC=ru”

Данная команда запретит репликацию указанных объектов (путей) с других контроллеров домена и увеличит USN объекта на 100000.

Выйдите из ntdsutil: quit

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

Источник

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

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

используйте следующую процедуру, чтобы выполнить полное восстановление сервера для Windows Server 2016, 2012 R2 или 2012.

Полное восстановление сервера Active Directory

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

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

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

Выполните полное восстановление сервера с любым локальным или удаленным образом.

Включение сетевого адаптера для резервного копирования сети

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

запустите программа установки Windows, укажите формат языка, времени и валюты, а также параметры клавиатуры и нажмите кнопку далее.

Нажмите Восстановить компьютер. I

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

Введите следующую команду и нажмите клавишу ВВОД:

Чтобы подтвердить имя сетевого адаптера, введите:

Введите следующие команды и нажмите клавишу ВВОД после каждой команды:

Введите, quit чтобы вернуться в командную строку. Введите, ipconfig /all чтобы проверить, имеет ли сетевой адаптер IP-адрес, и попробуйте проверить связь с IP-адресом сервера, на котором размещена общая папка резервных копий, чтобы подтвердить подключение. После завершения закройте командную строку.

Теперь, когда сетевой адаптер работает, выберите действия, описанные выше, чтобы завершить восстановление.

Источник

Резервное копирование и восстановление контроллеров домена Active Directory

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

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

В этой статье не рассматриваются восстановление элементов из Azure Active Directory. Сведения о восстановлении пользователей Azure Active Directory см. в этой статье.

Рекомендации

Убедитесь, что создается резервная копия по крайней мере для одного контроллера домена. При резервном копировании нескольких контроллеров домена убедитесь, что резервное копирование выполняется для всех контроллеров с ролями FSMO (Flexible Single Master Operation — операции с одним исполнителем).

Регулярно создавайте резервные копии Active Directory. Срок резервного копирования никогда не должен превышать отметку полного удаления (TSL), поскольку объекты, существующие дольше срока TSL, полностью удаляются и больше не считаются допустимыми.

Значение TSL по умолчанию для доменов, созданных на базе Windows Server 2003 SP2 и более поздних версий, составляет 180 дней.

Чтобы проверить настроенный срок TSL, используйте следующий сценарий PowerShell:

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

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

В Azure Backup не предусмотрено восстановление на уровне элементов для Active Directory. Если вы хотите восстановить удаленные объекты и можете получить доступ к контроллеру домена, используйте корзину Active Directory. Если этот метод недоступен, вы можете воспользоваться резервной копией контроллера домена для восстановления удаленных объектов с помощью средства ntdsutil.exe, как описано здесь.

Сведения о выполнении заслуживающего доверия восстановления SYSVOL см. в этой статье.

Резервное копирование контроллеров домена виртуальных машин Azure

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

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

Резервное копирование локальных контроллеров домена

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

Восстановление локальных контроллеров домена (из состояния системы или виртуальных машин) в облаке Azure не поддерживается. Если вы хотите выполнить отработку отказа из локальной среды Active Directory в Azure, рассмотрите возможность использования Azure Site Recovery.

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

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

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

Во время восстановления сервер будет запущен в режиме восстановления служб каталогов (DSRM). Для режима восстановления служб каталогов необходимо указать пароль администратора.

Если вы забыли пароль DSRM, его можно сбросить, следуя этим инструкциям.

Восстановление контроллеров домена виртуальных машин Azure

Сведения о восстановлении контроллера домена виртуальной машины Azure см. в разделе Восстановление виртуальных машин контроллера домена.

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

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

При восстановлении последнего оставшегося контроллера домена в домене или нескольких доменов в одном лесу рекомендуется восстановить лес.

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

Восстановление локальных контроллеров домена

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

Источник

Восстановление доверительных отношений между рабочей станцией и доменом AD

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

Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом

Как проявляется проблема: пользователь пытается авторизоваться на рабочей станции или сервере под своей учетной запись и после ввода пароля появляется ошибка:

Также ошибка может выглядеть так:

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

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

Несколько важных моментов, касающихся паролей компьютеров в AD:

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

Почему это может произойти:

Классический способ восстановить доверительных отношений компьютера с доменом в этом случае:

Этот метод кажется простым, но слишком топорный и требует, как минимум двух перезагрузок компьютера, и 10-30 минут времени. Кроме того, могут возникнуть проблемы с использованием старых локальных профилей пользователей.

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

Проверка и восстановление доверительного отношения компьютера с доменом с помощью PowerShell

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

Откройте консоль PowerShell и с помощью командлета Test-ComputerSecureChannel проверьте соответствует ли локальный пароль компьютера паролю, хранящемуся в AD.

Чтобы принудительно сбросить пароль учётной записи данного компьютера в AD, нужно выполнить команду:

Test-ComputerSecureChannel –Repair –Credential (Get-Credential)

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

После этого нужно еще раз выполнить команду Test-ComputerSecureChannel и убедится, что она возвращает True ( The Secure channel between the local computer and the domain winitpro.ru is in good condition ).

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

dc01.corp.winitpro.ru – имя ближайшего DC, на котором нужно сменить пароль компьютера.

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

С помощью командлета Get-ADComputer (из модуля Active Directory Windows PowerShell) можно проверить время последней смены пароля компьютера в AD:

Также можно проверить наличие безопасного канала между компьютером и DC командой:

Следующие строки подтверждают, что доверительные отношения были успешно восстановлены:

Восстановления доверия с помощью утилиты Netdom

Утилита Netdom включена в состав Windows Server начиная с 2008, а на компьютерах пользователей может быть установлена из RSAT (Remote Server Administration Tools). Чтобы восстановить доверительные отношения, нужно войти в систему под локальным администратором (набрав “.\Administrator” на экране входа в систему) и выполнить такую команду:

Netdom resetpwd /Server:DomainController /UserD:Administrator /PasswordD:Password

Netdom resetpwd /Server:spb-dc01 /UserD:aapetrov /PasswordD:Pa@@w0rd

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

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

Источник

Восстановление после сбоев Active Directory

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

Обычно 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, и наоборот.

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

Используемый сценарий для запуска 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 в домене, выполните команду

в окне командной строки. Затем можно захватить роли 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. Запустите команду

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если была удалена вся организационная единица, объекты нужно восстанавливать в правильном порядке (то есть нельзя восстанавливать объект прежде его родителя), чтобы разместить их в нужных местах. Полезный сценарий 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

Поделитесь материалом с коллегами и друзьями

Источник