Быстрое восстановление случайно удаленных объектов Active Directory

Сегодня я сделал для себя потрясающее открытие. Оказывается, если в 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 KrylovADEL: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 за приличную статью

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

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

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