Directory services restore mode windows 7

Обычно 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

Have you ever received the following error message when you tried to sign in on a domain controller? We can’t sign you in with this credential because your domain isn’t available. Scary, huh? With the help of Active Directory’s Directory Services Restore Mode (DSRM), you can recover Active Directory by booting up in safe mode to restore a working configuration of your Active Directory. I hope you still know your DSRM password. If not, I show you how to reset the DSRSM password in this article.

What is Directory Services Restore Mode (DSRM)?

Remember the following screen, which you see during domain controller promotion? When promoting a Windows member server to a domain controller, you have to set a DSRM administrator password.

This password is for the administrator account that you use to log in while in DSRM mode. DSRM is used when something is wrong with your Active Directory, and you can’t start your DC in normal mode. For instance, see the following screenshot, which shows the error We can’t sign you in with this credential because your domain isn’t available.

If you see this error, you need to start your DC in DSRM mode, click the Other user option in the bottom left corner, type .administrator in the username field, and type the DSRM password. If you don’t remember the DSRM password, read the Reset DSRM password section.

Why is DSRM important?

When a domain controller is working in normal mode, the Active Directory database and log files are locked so that you cannot access, copy, or modify them. But when the domain controller is started in DSRM mode, the Active Directory services don’t start, which means the database and log files are no longer locked. You can now copy, move, or do anything with these files, making this mode both powerful and risky. The DSRM is particularly designed for situations in which you need to:

• Perform AD database repairs
• Compress or move AD database/log files
• Perform AD restore from backup or snapshot
• Restore individual objects

DSRM password

Now that you understand what DSRM is and why it is important, let’s talk about security. The DSRM is protected by a password, known as the DSRM password, which is one of the most overlooked passwords by admins. Organizations take various measures to protect domain accounts and other service accounts, but often forget to safeguard the DSRM password. I have seen various AD environments where the DSRM password is either unknown or forgotten by the person who initially set it. In my opinion, the DSRM password is as important as any other and should be updated regularly and maintained by server admins.

How to boot in DSRM

There are multiple ways to boot a domain controller in DSRM. Each way has its own significance. Let’s discuss them quickly.

The F8 key

One way to boot a DC in DSRM mode is to use the F8 key. If you can access the keyboard of the DC while it is booting up, press the F8 key repeatedly right after the POST screen. You will see a black screen with multiple options (usually known as advanced boot options), as shown below:

Select the Directory Services Repair (or Restore) Mode option, and press Enter. Your DC will now start in DSRM mode. After login, you will see a Safe Mode watermark on the desktop, and AD services won’t start.

System configuration utility

The F8 key only works if you can access the keyboard of the DC locally when it is starting up. If it is not locally accessible, you can use the system configuration utility (msconfig.exe) to boot your DC in DSRM. To do so:

1. Open the RUN dialog (Windows key + R).
2. Type msconfig and press Enter. This launches the System Configuration utility.
3. Under the Boot tab, enable the Safe boot checkbox, and select the Active Directory repair option, as shown in the screenshot.

   

   Starting a domain controller in DSRM mode using the system configuration msconfig utility

4. Click Apply and then OK. It will prompt you to restart the computer. Click Restart.

   

   System configuration restart prompt

   The DC now automatically starts in DSRM mode. You could remotely restart your DC in DSRM using this method since it no longer requires any intervention during the boot process.
5. When you’re done repairing your AD, don’t forget to revert the whole process to boot the DC in normal mode. Just launch msconfig again, and under the General tab, select the Normal startup option and click OK.

   

   Disabling the safe boot option on a domain controller using system configuration msconfig utility

Boot configuration editor utility

There are situations when you can neither use the F8 key nor the system configuration utility. Let’s say your Windows is corrupted and you can’t press F8 to bring up the advanced boot options, and you can’t use the msconfig tool either. In this situation, follow these steps to boot the DC in DSRM using the bcdedit command line utility:

1. Boot the server using bootable installation media, such as a DVD or USB.
2. On the Windows Setup screen, press the Shift + F10 keys to invoke a command prompt.

   

   Launch a command prompt using the ShiftF10 keys on the Windows setup screen

3. Once you get the command prompt, type the following command:

   bcdedit /set {default} safeboot dsrepair

   

   Starting a domain controller in DSRM using the bcdedit utility
4. After running this command, your server will boot by default in DSRM mode every time until you manually delete the safeboot value from the BCD store. So don’t forget to delete it when you’re done troubleshooting.
5. Now, close everything to restart the DC. It automatically starts in DSRM mode.
6. When you’re done troubleshooting your DC and ready to restart it in normal mode, type the following command at an elevated command prompt:

   

   Delete the safeboot value from the BCD store to start the domain controller in normal mode

   bcdedit /deletevalue {default} safeboot

7. Now restart the DC to boot up in normal mode.

Reset the DSRM password

If you do not know (or remember) the DSRM password for a domain controller, you can simply reset it. In Windows Server 2000, the setpwd command line utility was used to reset the DSRM password, but starting with Server 2003, this feature is included in the ntdsutil utility. The best thing about ntdsutil is that you can reset the DSRM password for local and remote domain controllers. To reset the DSRM password:

1. Log on to any domain controller using the domain administrator account.
2. Launch an elevated command prompt and run the following commands:

   ntdsutil
   set dsrm password
   reset password on server null
   quit
   quit

   These commands reset the DSRM password for the local domain controller that you’re currently logged in to.

3. To reset the DSRM password for a remote domain controller, use the reset password on server SRV101 command instead of reset password on server null. Of course, replace SRV101 with the name of your remote DC.See the following screenshot for reference:

   

   Reset the DSRM password for local and remote domain controllers using ntdsutil

DSRM password sync

The DSRM password is set individually on each domain controller and doesn’t replicate to other DCs in the domain, making it highly inconvenient for server admins in organizations with domain controllers. You can understand how cumbersome it is to manually set (or reset) a DSRM password on each DC. However, there is a small workaround. To automatically sync the DSRM password on all DCs:

1. Create a regular domain user and set a good password on it. There is no need to manually add this user to any AD group.

   

   Creating a normal user for DSRM sync in Active Directory

2. Open an elevated command prompt or PowerShell console, and type the following command:

   ntdsutil "set dsrm password” “sync from domain account dsrm_user" q q

   Make sure you replace the dsrmuser with the name of the user you created in Step 1.
   

3. Obviously, you would not want to log in to each DC and run this command manually. To automate the password sync process, you could leverage Group Policy to deploy a scheduled task on all your DCs.
4. To do so, open the Group Policy editor (gpmc.msc), create a GPO, and link it to the OU containing all the DCs.
5. Now, create a scheduled task using Group Policy preferences, as shown in the following screenshot.

   

   Create a scheduled task to automatically sync a DSRM password with an AD user

   See how I typed the complete path of ntdsutil.exe and passed additional commands in the arguments field? You can modify the schedule to run the way you want. I am setting it to run at 11:00 p.m. every day.

6. When all your DCs pull this scheduled task from Group Policy and run it at least once, you can verify whether the DSRM password was automatically synchronized using the scheduled task. To do so, start one of your DCs in DSRM mode, and try to log in using the same password that you set for the domain user (dsrmuser) in step 1.
   

The problem with this approach is that it sets the same DSRM password on all DCs, but the trick is particularly useful if you have a lot of DCs that you can’t (or don’t) want to manage individually.

Subscribe to 4sysops newsletter!

I hope you now have a good understanding of Directory Services Restore Mode after reading this post. Let me know in the comment section below if you think I missed something. Did you ever need to boot up in DSRM mode?

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

null

Menu

Directory Services Restore Mode

What is DSRM?

Directory Services Restore Mode (DSRM) is a special boot mode for
repairing or recovering Active Directory. It is used
to log on to the computer when Active Directory has failed or needs to be
restored.

Note: Do not confuse DSRM with Safe Mode. Active Directory will still attempt to start in Safe Mode and if it fails you will not be able to log on. Instead use DSRM.

You can log on to DSRM by using a special DSRM password that you
set when you promoted the domain controller.
Use the logon account name .Administrator (language may vary).

DSRM is only needed when Active Directory is so damaged that you cannot log on using
your normal AD Administrator password. Use DSRM when
doing a domain-wide restore
or a forest-wide restore
when AD is so damaged that it will not boot normally.

How to Log on to DSRM

After booting DSRM (see below)
click on Switch User ->
Other User. When prompted for the logon account name type .Administrator

The initial logon prompt will show
the account name MyDomainAdministrator,
where MyDomain is the name of the domain. This
is incorrect and will not work. You must click on Switch User
and manually type the name .Administrator.

If You Lost the DSRM Password

If you forgot the DSRM password for the .Administrator account you can reset it
using ntdsutil.
See Reset DSRM Password. This requires a working Active Directory.

If Active Directory is also not working
you can reset the DSRM password
by using a standard desktop PC lost-password recovery tool:

• Windows Server 2016-2022 (Windows 10 and Windows 11 recovery tools)
• Windows Server 2012 R2 (Windows 8.1 recovery tools)
• Windows Server 2012 (Windows 8 recovery tools)
• Windows Server 2008 R2 (Windows 7 recovery tools)

If after you boot DSRM you need to recover your Active Directory password for the Domain Administrator account see Changing a Lost Domain Administrator Password.

How to Boot DSRM: F8 Key

To manually boot in Directory Services Restore Mode, press the F8 key
repeatedly. Do this immediately after BIOS POST screen, before
the Windows logo appears. (Timing can be tricky; if the
Windows logo appears you waited too long.)
A text menu menu will appear. Use the up/down arrow keys to
select Directory Services Restore Mode or DS Restore Mode.
Then press the Enter key.

Windows 8 or later: The F8 key is disabled on desktop editions
of Windows 8 or later. If you want to boot into Safe Mode,
run msconfig and select Minimal. Then reboot.

How to Boot DSRM: msconfig.exe

You can configure Windows to boot DSRM using msconfig.exe:

1. Press WIN+R.
2. In the Open box type msconfig and click OK. This will show
   the System Configuration dialog box.
3. Click on the tab Boot (top).
4. Under “Boot options” check the box Safe boot.
5. Select Active Directory repair and click OK.
6. Reboot the computer: Click on Start (or press WIN+X -> Shut down or sign out -> Restart.

This will boot the computer into DSRM.

To boot normally, reverse the procedure:

1. Press WIN+R.
2. In the Open box type msconfig and click OK. This will show
   the System Configuration dialog box.
3. Click on the tab Boot (top).
4. Under “Boot options” uncheck the box Safe boot and click OK.
5. Reboot the computer: Click on Start (or press WIN+X -> Shut down or sign out -> Restart.

This will boot the computer back into normal mode.

How to Boot DSRM: Bcdedit

On Windows Server 2008 or later you can run bcdedit inside of an
administrative console:

1. To boot DSRM, type the command bcdedit /set safeboot dsrepair, then reboot: shutdown /r /f /t 5.
2. When you are ready to boot normally, type bcdedit /deletevalue safeboot, then reboot: shutdown /r /f /t 5.

You can use this procedure when a graphical user interface (GUI) is not available (e.g., on Server Core).

For more information

See also Changing the Domain Administrator Password.

U-Move protects your Active Directory domain controller by offering strong backup and
recovery
protection, along with advanced
upgrade capability.

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

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

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

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

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

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

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

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

DSA Invocation ID

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

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

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

RID Pool

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

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

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

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

SYSVOL restore

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

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

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

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

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

Подготовка

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

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

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

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

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

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

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

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

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

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

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

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

comments powered by HyperComments

Directory Services Restore Mode

Directory Services Restore Mode DSRM is a function on Active Directory Domain Controllers to take the server offline for emergency maintenance, particularly restoring backups of AD objects. It is accessed on Windows Server via the advanced startup menu, similarly to safe mode.

How do I Use Folder Services Restore Mode in Windows 7?

Restart the domain controller .
When the BIOS information appears, press F8.
Select Directory Services Restore Mode, and then press ENTER.
Log on by using the Directory Services Restore Mode password.
Click Start, select Run, type cmd in the Open box, and then click OK.

What is the Directory Services Restore Mode Password?

One of the most overlooked and most important passwords in a Windows network is the Directory Services Restore Mode DSRM password on a domain controller. This password is unique to each DC, and you use it to log on to a DC that youve rebooted into DSRM to take its copy of Active Directory offline.

How do I Get to Directory Services Restore Mode?

To enter DS Restore Mode, you must reboot the server at the console. Press F8 after the power-on self test (POST), which will bring up a menu, as shown in Figure 16-1. From the menu, select Directory Services Restore Mode.

What will Directory Services Repair Mode Password be Used For?

The DSRM password provides the administrator with a back door to boot into Directory Services Restore Mode for performing maintenance and recovery tasks. This account is often forgotten by most AD administrators, which results in a significant security risk.