Восстановление удаленных объектов 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 из резервной копии, в которых нужно четко разобраться перед началом восстановления:

Authoritative Restore (полномочное или авторитативное восстановление) – после восстановления объектов AD выполняется репликация с восстановленного DC на все остальные контроллеры в домене. Этот тип восстановления используется в сценариях, когда упал единственный DC или все DC одновременно (например, в результате атаки шифровальщика или вируса), или когда по домену реплицировалась поврежденная база NTDS.DIT. В этом режиме у всех восстановленных объектов AD значение USN (Update Sequence Number) увеличивается на 100000. Таким образом восстановленные объекты будут восприняты всеми DC как более новые и будут реплицированы по домену. Полномочный способ восстановления нужно использовать очень аккуратно.

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

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

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

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

Для восстановления Actve Directory вам нужно загрузить сервер в режиме восстановления служб каталогов DSRM (Directory Services Restore Mode). Для этого запустите msconfig и на вкладе Boot выберите Safe Boot -> Active Directory repair.

Active Directory repair mode" srcset="http://winitpro.ru/wp-content/uploads/2019/10/safe-boot-greater-active-directory-repair-mode.png 575w, http://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 путь к ней.

wbadmin get versions -backupTarget:D:

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

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

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

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

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

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

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

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

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

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

1. Запустите regedit.exe;
2. Перейдите в ветку HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParameters
3. Измените значение параметра SysvolReady с 0 на 1;
4. Потом перезапустите службу NetLogon: net stop netlogon & net start netlogon

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

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

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

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

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

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

1. Загрузите DC в DSRM режиме;
2. Выведите список доступных резервных копий: wbadmin get versions
3. Запустите восстановление выбранной резервной копии: wbadmin start systemstaterecovery –version:[your_version]
4. Подтвердите восстановление DC (в не полномочном режиме);
5. После перезагрузки запустите: ntdsutil
6. activate instance ntds
7. authoritative restore

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

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

Или один объект:

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

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

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

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

Сегодня я сделал для себя потрясающее открытие. Оказывается, если в Exchange 2007 выбрать почтовый ящик пользователя и по нажатию правой кнопки мыши выбрать пункт «Remove Mailbox», то автоматически произойдет удаление связанного с ящиком пользователя из Active Directory. Можно долго смеятся над «ценностью» подобного открытия, но я, как человек привыкший к Exchange Tasks в Exchange 2003 просто не ожидал подобного подвоха от любимого сервера. Тем не менее это случилось. Я «убил» учетную запись одного из ведущих программистов. Холодный пот, выступивший крупными каплями, сигнализировал о степени моего ужаса по мере того, как до меня доходила вся серьезность ситуации. Мне конец?!

К счастью пригодились определенные знания Active Directory, в частности отрывочные знания о неких «объектах-надгробиях» (Tombstone Objects).

На самом деле в Active Directory встроена неплохая защита «от дурака», такого например, как я. Это те самые Tombstone-объекты. Удаление из базы AD происходит не сразу, в этом и есть счастье. Для начала объект и связанные с ним аттрибуты помещается в скрытый контейнер «Deleted Objects», приобретая при этом некоторые отличительные признаки «удаленного объекта», а именно:

1. Появляется аттрибут isDeleted, могущий принимать булевы значения True и False. Он сигнализирует о том, что объект помечен, как удаленный.

2. В значении аттрибута distinguishedName после имени объекта появляется флаг ADEL.

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

Каждые 15 минут (по умолчанию) по контейнеру Deleted Objects пробегает Сборщик мусора (Garbage Collector или Executioner), который считывает у находящихся в контейнере объектов значение аттрибута Tombstone Lifetime, объекты, значение этого аттрибута у которых достигло порогового значения, удаляются. И вот теперь навсегда. По умолчанию объекты могут хранится в виде объектов-памятников в течение 60 дней (хотя Microsoft рекомендует увеличить это значение до 120 дней)

Значение аттрибутаTombstone Lifetime может быть изменено с использованием ADSIEdit. Перейдите к cn=directory Service,cn=windowsNT,cn=services,cn=configuration,dc=company,dc=com (заменив естественно dc=company,dc=com на Ваши реальные данные). Кликните правой кнопкой мыши на контейнере CN=Directory Service и выберите Properties. Найдите Tombstone Lifetime в списке аттрибутов, нажмите кнопку Edit и введите количество дней, необходимое для хранения удаленных объектов.

Итак, ведущего программиста мы удалили. Что делать? Вариант с Authoritative Restore мне не подходил по ряду причин:

• Требовалась перезагрузка контроллера домена для входа в режим восстановления Active Directory (Active Directory Restore Mode)
• Я не был уверен в актуальности, да и наличии бэкапа в принципе.
• Времени было слишком мало

Было решено пойти другим путем:

Для восстановления удаленного объекта в принципе достаточно удалить аттрибут isDeleted и сменить значение distinguishedName.

Для этого нам понадобится Ldp.exe, утилита входящая в состав Windows Support Tools и позволяющая напрямую подключаться к каталогу по интерфейсу LDAP, с возможностью напрямую править аттрибуты объектов. Для выполнения операций пользователь должен входить в группу Enterprise Admins (кстати Ldp.exe позволяет выполнить вторичный вход в систему с помощью команды Bind).

Запустив Ldp.exe. выбираем из меню Connections команду Connect.

В появившемся окне указываем NetBios имя контроллера домена и порт LDAP, как известно — 389.

Далее выбрав из того же меню Connections команду Bind, авторизуемся на контроллере. Здесь можно пойти двумя путями:

1. Если текущий пользователь является членом группы Enterprise Admins, то используем контекст текущего пользователя.

2. Во всех других случаях — вводим учетные данные пользователя входящего в группу Enterprise Admins.

Далле, необходимо разрешить отображение скрыторго каталога Deleted Objects, для чего в меню Options выбираем команду Controls.

В открывшемся окне в поле Load Predefined из ниспадающего списка выбираем Return deleted objects.

Далее выбираем в меню View пункт Tree, для отображения дерева контейнеров в левой панели.

В окне Tree view в поле BaseDN выбираем корень леса, в моем случае это DC=ad,DC=webzavod,DC=ru.

Дважды щелкнув на корне дерева получаем список контенеров, в котором ищем контейнер CN=Deleted Objects,DC=ad,DC=webzavod,DC=ru, естественно заменив мои данные своими. Раскрываем контейнер и находим в нем удаленный объект, который необходимо восстановить. У меня он назывался примерно так:

CN=Oleg Krylov ADEL :41057e80-84fd-4c96-8e54-26886519b6e8,CN=Deleted Objects,DC=ad,DC=webzavod,DC=ru

Обратите внимание на флаг ADEL. Он имеется 🙂

В правой панели мы видим тот самый злосчастный аттрибут isDeleted: TRUE. Вот оно как вышло то…

Далее все происходит очень быстро:

1. Выделяем объект в левой панели.

2. Правым кликом вызываем контекстное меню, выбираем в нем пункт Modify.

3. В разделе Edit Entry, в поле Attribute вводим isDeleted, в панели Operation выбираем Delete, затем жмем Enter. В результате в поле Entry List появляется строка [Delete]isDeleted:

4.Далее, не предпринимая действий по применению внесенных изменений меняем distiguishedName. Для этого:

• В разделе Edit Entry, в поле Attribute вводим имя аттрибута, т.е. distiguishedName
• В разделе Edit Entry, в поле Values вводим значение аттрибута lastKnownParent, которое берем в правой панели, в списке аттрибутов объекта. В моем случае это OU=Webzavod,DC=ad,DC=webzavod,DC=ru
• В самом начале значения добавляем имя объекта, опять же в моем случае CN=Oleg Krylov, не забыв поставить запятую!
• В итоге получаем значение аттрибута CN=Oleg Krylov,OU=Webzavod,DC=ad,DC=webzavod,DC=ru
• В разделе Operation, выбираем чекбокс — Replace, жмем кнопку Enter

5. В поле Entry List появляется вторая строка, со значением: [Replace]distinguishedName:CN=Oleg Krylov,OU=Webzavod,DC=ad,DC=webzavod,DC=ru

6. Далее, убедившись, что выбраны флаги Synchronous и Extended нажимаем кнопку Run

Об успешном результате нам просигнализирует запись в правой панели вида:

***Call Modify…
ldap_modify_ext_s(ld, ‘CN=Oleg KrylovADEL:41057e80-84fd-4c96-8e54-26886519b6e8,CN=Deleted Objects,DC=ad,DC=webzavod,DC=ru’,[2] attrs, SvrCtrls, ClntCtrls);
Modified «CN=Oleg KrylovADEL:41057e80-84fd-4c96-8e54-26886519b6e8,CN=Deleted Objects,DC=ad,DC=webzavod,DC=ru».

Открываем Active Directory Users and Computers, в соответствующем OU (том самом, откуда был удален злосчастный объект) находим его живым и здоровым, правда в немного отключенном ссостоянии. При попытке включения получаем ошибку вида:

Для включения потребуется сменить пароль.

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

Огромную благодарность хочу выразить Gary Olsen за приличную статью

Артему Синицыну за поддержку в первые минуты шока и всякие фразы ободряющего толка («Не ссы, все нормально»)

И конечно же Степану Голосунову (см. фото в начале), достойно перенесшему роль жертвы, за понимание.

Как видите, не каждая «безвыходная» ситуация на самом деле безвыходная.

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

Итак, что делать, если вы случайно удалили из Active Directory нужного пользователя (компьютер, группу, контейнер и т.п. )?

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

А дело в том, что Active Directory различает объекты не по имени, а по специальному идентификатору — Security Identifier (SID). Это уникальный идентификатор безопасности, который присваивается объекту в момент его создания и остается с ним даже после удаления. А поскольку каждый SID уникален, то вновь созданный пользователь, вне зависимости от имени, получит свой SID и будет распознан системой как совершенно другой пользователь. При этом будет потеряна вся информация, которая была закреплена за старой учетной записью, и придется все делать заново — раздавать права, включать пользователя в группы, настраивать программы, и много других ″интересных″ моментов.

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

Что происходит с объектом AD при удалении

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

При удалении объекта из каталога происходит следующее: сначала объект помечается как удаленный, для чего атрибуту isDeleted объекта присваивается значение true, затем большинство атрибутов из объекта удаляется, объект переименовывается и перемещается в специальный контейнер — Deleted Objects. Теперь он зовется объектом-захоронением и недоступен для обычных операций в AD.

Объект-захоронение невидим в оснастках управления MMC, а для большинства служебных программ его вообще не существует. Однако физически данные все еще здесь — просто они невидимы. Зачем же Active Directory хранит удаленные объекты в базе данных?

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

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

Срок жизни объекта-захоронения определяется атрибутом tombstoneLifetime и по умолчанию составляет 180 дней (60 дней для лесов Windows 2000). Посмотреть текущее значение tombstoneLifetime и изменить его можно следующим способом.

Открываем редактор ADSIEdit и в качестве точки подключения (Connection Point) выбираем «Select or Type a Distinguished Name or Naming Context». В пустом поле вводим путь CN=Directory Service,CN=Windows NT, CN=Services, CN=Configuration, DC=contoso, DC=com (для домена contoso.com).

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

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

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

В качестве примера возьмем учетную запись пользователя Ivanov Vasiliy и удалим ее. Прощай Vasiliy 🙁

Для восстановления воспользуемся утилитой LDP. LDP — это служебная программа для работы с Active Directory, немного схожая с проводником Windows. В Windows Server 2008 она включена в состав операционной системы, в Server 2003 входит в средства поддержки (Support tools) и устанавливается отдельно, с установочного диска.

Для запуска LDP нажимаем Win+R и в строке выполнить вводим ldp. Затем идем в меню Connection, выбираем пункт Connect и в открывшемся окне вводим имя контроллера домена, к которому надо подключиться. Если вы запускаете LDP на контроллере домена, то можно просто ввести localhost.

Теперь необходимо пройти проверку подлинности. Открываем меню Connection, выбираем Bind (Привязка), вводим учетные данные и жмем OK. Для работы нам понадобятся учетные данные пользователя с правами администратора домена или предприятия (только они имеют право просматривать и восстанавливать объекты в контейнере Deleted Objects).

Контейнер Deleted objects надежно скрыт от посторонних глаз, и для того, чтобы его увидеть, необходимо включить элемент управления LDAP «Возврат удаленных объектов». Для этого открываем меню Options и выбираем пункт Controls, чтобы вывести диалог элементов управления. Открываем список Load Predefined, в нем выбираем пункт Return Deleted Objects (Вернуть удаленные объекты) и нажимаем кнопку Check in. Это добавит идентификатор объекта (OID) для элемента управления «Вернуть удаленные объекты» (1.2.840.113556.1.4.417) в список активных элементов управления. Нажимаем OK, чтобы сохранить настройки элемента управления.

Затем открываем меню View, выбираем режим просмотра Tree, в поле BaseDN выбираем DC=contoso,DC=com.

Заходим в корень, раскрываем контейнер Deleted Objects и видим перечень удалённых объектов. В этом перечне находим нужный нам объект-пользователя CN=Ivanov Vasily. Кликаем правой клавишей мыши на найденом объекте и в выпадающем меню выбираем пункт Modify. Кстати, будьте готовы к тому, что в Deleted Objects очень много объектов, что может затруднить поиск.

Для восстановления объекта надо провести две операции:

1) Удалить отметку об удалении — набираем в строке Attribute: isDeleted, в поле Operation выбираем Delete и нажимаем Enter;
2) Переместить из Deleted objects в исходный контейнер — набираем в поле Attribute: distignuishedName, в поле Values пишем: CN=Ivanov Vasily, OU=Managers, DC=contoso, DC=com (это исходный DN пользователя). Исходный контейнер пользователя можно посмотреть в правом окне, он записан в атрибуте lastKnownParent. В качестве операции выбираем Replace и опять нажимаем Enter.

Далее отмечаем оба пункта Synchronous и Extended и жмём кнопку Run.

Всё! Теперь объект пользователя полностью восстановлен, в чем можно убедиться, открыв консоль Active Directory Users and Computers.

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

AdRestore предлагает достаточно удобный и простой интерфейс командной строки для восстановления объектов Active Directory. Хотя он не очень гибок, использовать его гораздо легче, чем LDP. При запуске без параметров AdRestore выдаст список всех объектов-захоронений в контейнере Deleted Objects дефолтного домена. Для поиска конкретного объекта в качестве параметра можно использовать имя (частично или полностью) объекта, например:

В результате этой команды будут выведены все объекты-захоронения в контейнере CN=Deleted Objects, которые содержат строку ivanov в атрибуте CN или OU — программа использует поисковый фильтр LDAP cn=*ivanov* и ou=*ivanov*. Не самый гибкий способ поиска, но в большинстве ситуаций он работает.

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

adrestore -r ivanov

Эта команда предложит восстановить каждый подходящий объект-захоронение. И еще, AdRestore всегда восстанавливает объект в контейнер, указанный в атрибуте lastKnownParent объекта-захоронения, нет никакого способа указать другой контейнер.

Ну и для тех, кому не подходят первые два варианта, есть графическая утилита ADRestore.NET. Она абсолютно бесплатна, взять ее можно здесь. ADRestore.NET позволяет производить поиск объекта по нескольким параметрам, а также дает возможность выбрать определенный контроллер домена и авторизоваться под пользователем, отличным от текущего. Пользоваться программой очень просто. Нажимаем на кнопку Enumerate Tombsones, и нам выдается список удаленных объектов. Выбираем нужный объект и жмем Restore Object. Вот и все.

Атрибуты объекта

При удалении объекта и помещении его в контейнер Deleted Objects удаляется большая часть его атрибутов. Так у объекта пользователя сохраняются только идентификаторы SID и GUID, а также LastKnownParent (контейнер, в котором находился объект до удаления) и SAMAccountName (имя учетной записи SAM). Соответственно, при возвращении объекта к жизни любым из вышеописанных способов восстановятся только эти атрибуты, все остальное придется вводить заново.

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

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

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

Для примера возьмем атрибут Description учетной записи пользователя.

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

Найдя атрибут, открываем его двойным щелчком мыши и заходим в свойства. Нас интересует параметр searchFlags, который отвечает за сохранение атрибута в объекте-захоронении. У каждого атрибута он свой, в нашем случае searchFlags вообще не задан, т.е. равен 0.

Для того, чтобы заданный атрибут не удалялся, необходимо у searchFlags включить третий бит, или другими словами, выставить третий бит равным 1. Поскольку searchFlags представлен в десятичном виде, то сначала переведем его в двоичный. Получится двоичное число 0000. Биты нумеруются справа-налево, начиная с нулевого бита. Находим третий бит (он будет четвертым по счету справа) и ставим его равным 1. Получаем двоичное число 1000. Переводим его обратно и получаем 8 в десятичной системе. Ставим 8 в значении searchFlags. Если все сделано правильно, то в значении параметра появится надпись «Сохранять при удалении» (PRESERVE_ON_DELETE).

Теперь даже при удалении и восстановлении учетной записи пользователя атрибут Description будет сохранен. Однако этот способ подходит не для всех атрибутов. Так например атрибуты, описывающие членство в группах Active Directory, подобным образом сохранить невозможно. Для решения этой проблемы в Windows Server 2008 R2 появился новый инструмент под названием Active Directory Recycle Bin, или корзина Active Directory. О ней я расскажу во второй части статьи…