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

Майкл Олиг, 25 февраля 2019 года

Примечание: Для данной статьи будем считать, что в домене не была включена корзина Active Directory (Active Directory Recycle Bin). Корзина AD и её влияние на восстановление объектов будут рассмотрены в следующей статье из этой серии.

Когда какой-либо объект удаляется из Active Directory, он на самом деле не удаляется, по крайней мере, не сразу.

И это не какое-то там особое свойство, а следствие того, как реализована репликация с несколькими главными серверами, применяемая в Active Directory. Такой вариант репликации позволяет любому контроллеру домена создавать или обновлять объект, а затем реплицировать эти изменения на другие контроллеры домена.

Для того, чтобы рассмотреть, что же на самом деле происходит при удалении объекта, давайте воспользуемся утилитой LDP. И поможет нам в этом мистер Delete Q. Me, демонстрационная учётная запись пользователя, любезно созданная моим любимым PowerShell-скриптом.

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

Извини, приятель.

Ну а теперь, когда его не стало, у нас могут возникнуть трудности с поиском нашей мёртвой, но всё ещё не исчезнувшей учётной записи. LDP нужно немного подшаманить, чтобы он стал показывать удалённые объекты. Откроем меню "Options" и выберем пункт "Controls". В диалоговом окне "Controls" откроем выпадающий список "Load Predefined", выберем "Return deleted objects" и нажмём кнопку "OK".

Теперь в корне нашего раздела каталога стал виден контейнер "Deleted Objects". Мы можем развернуть его и поискать наш недавно умерший пользовательский объект.

А вот и он! А теперь давайте коротко разберём, что же произошло в каталоге в результате удаления объекта пользователя:

  1. Объект был перемещён.
    Конечно, Вы обратили внимание, что для того, чтобы найти объект удалённого пользователя, нам пришлось перейти в другое место. У каждого раздела каталога есть свой собственный контейнер "Deleted Objects". Ну, на самом деле не совсем так. У раздела "Schema" нет своего контейнера "Deleted Objects", поскольку удалять объекты из схемы данных каталога нельзя. Как Вы, наверное, уже догадались, предназначение контейнера "Deleted Objects" — хранить удалённые объекты. Active Directory скрывает эти контейнеры, пока Вы их специально не запросите, это Вы тоже уже заметили.
  2. Объект был переименован.
    Имя объекта обновляется с использованием хитроумного шаблона: Common-Name\0ADEL:Object-Guid. Такая схема именования гарантирует уникальность имён объектов даже когда будут удалены несколько объектов с совпадающим относительным уникальным именем.
  3. У объекта появилось несколько новых атрибутов.
    Теперь у нашей старой знакомой учётки три новых атрибута. Первый из них — isDeleted. Если значение этого атрибута "TRUE", значит объект был отмечен для удаления. Следующий новый атрибут — isRecycled. Этот атрибут был добавлен и ему назначено значение только потому, что функциональный уровень данного домена выше, чем Windows 2008. Иначе добавление этого атрибута не имело бы смысла, поскольку в более ранних версиях функционал доменной корзины просто отсутствовал. Наконец, ещё один новый атрибут — lastKnownParent, содержащий уникальное имя последней известной родительской записи для нашего объекта пользователя (оно нам пригодится буквально через пару минут).
  4. Множество атрибутов было удалено.
    При удалении объекта сохраняются только важные атрибуты. Атрибуты, не имеющие флага поиска 0x8 ( PRESERVE_ON_DELETE ), удаляются, так как предполагается, что они больше не нужны. В связи с тем, что я не модифицировал схему данных своего домена так, чтобы по умолчанию иметь возможность сохранить большее количество атрибутов (поскольку это не очень хорошая идея), мой пользовательский объект утратил большинство своих атрибутов вместе со связанными с ними значениями.

Получившийся в итоге объект называют "надгробным камнем" ("tombstone"). И последнее, что мы попробуем в рамках этой демонстрации — "реанимировать" его. Это не шутки, а вполне официальные технические термины.

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

  1. Щёлкните правой кнопкой мыши по "камню" и выберите пункт меню "Modify".
  2. В секции "Edit Entry" в поле "Attribute" введите значение "isDeleted", установите переключатель в секции "Operation" в значение "Delete", и нажмите кнопку "Enter" для добавления сведений об операции в список "Entry List".
  3. В секции "Edit Entry" в поле "Attribute" введите значение "distinguishedName", в поле "Values" введите уникальное имя объекта, которое было у него до удаления, установите переключатель в секции "Operation" в значение "Replace", и нажмите кнопку "Enter" для добавления сведений об операции в список "Entry List".
    Помните, я говорил, что атрибут lastKnownParent может оказаться полезным? Так вот, если Вы не знаете, какое же DN было у объекта до удаления, можно попробовать такой трюк: возьмите текущее DN объекта и замените нуль-символ ("\0A") и всё, что справа от него, на значение атрибута lastKnownParent.
  4. Выберите пункт "Extended" в левом нижнем углу панели.
  5. Нажмите кнопку "Run".

После нажатия кнопки "Run" мы можем найти вновь реанимированный объект и посмотреть, как он выглядит.

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

Обойти проблему потери большинства полезных атрибутов можно, делая регулярные VSS-снапшоты Active Directory. При использовании данного метода, если Вам необходимо восстановить удалённый объект, Вы можете просто найти резервную копию, сделанную до удаления этого объекта, смонтировать снапшот с помощью NTDSUTIL, подключиться к смонтированному снапшоту с помощью LDAP-утилиты, найти объект, экспортировать его в… Ладно, не забивайте себе голову.

Но подождите, тут есть ещё один гадкий момент.

Объекты в контейнере "Deleted Objects" не вечны. Метко названное свойство tombstoneLifetime ("время жизни надгробного камня") объекта CN=Directory Service,CN=Windows NT,CN-Services,CN=Configuration,ForestDistinguishedName определяет количество дней до того момента, как удалённый объект будет навсегда удалён из Active Directory.

Значение свойства tombstoneLifetime основывается на версии Windows Server, с помощью которого был создан лес используемого нами домена. В лесах, созданных с использованием Windows Server выше версии 2003, по умолчанию установлено значение 180 дней (текущий рекомендуемый параметр Microsoft). В более старых версиях значение по умолчанию — 60 дней. Обработка значения свойства tombstoneLifetime — то, на что действительно стоит обратить внимание. Если свойство существует, время жизни надгробного камня будет соответствовать заданному в нём значению. Но только в том случае, если это значение не меньше, чем 2. А если меньше, то по умолчанию время жизни будет 60 дней (для Windows Server от 2000 до 2008) или 2 дня (Windows Server 2008 R2 или выше). Если значение свойства не задано, то время жизни будет 60 дней.

Если Вам интересно, каково значение tombstoneLifetime в Вашем окружении, данный PowerShell-скрипт выдаст его Вам (для его работы требуются инструменты AD DS и AD LDS):

(Get-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,$((Get-ADRootDSE).configurationNamingContext)" -Properties *).tombstoneLifetime

Как только объект провёл в контейнере "Deleted Objects" количество дней, равное значению tombstoneLifetime, он логически удаляется сборщиком мусора Active Directory. В этот момент он уходит от нас навсегда и восстановлению больше не подлежит.

В качестве альтернативы я бы предложил разрабатываемое нами программное решение, как раз направленное на разрешение этой существенной проблемы. StealthRECOVER восстанавливает удалённые объекты в любое зарезервированное до момента их удаления состояние. Оно также способно восстановить объекты, превысившие установленное для леса время tombstoneLifetime.

В следующей заметке из этой серии мы рассмотрим функционал так называемой корзины Active Directory.

Эта страница

Содержание

Восстановление объектов Active Directory
OpenLDAP 2.4 Руководство

Содержание

Введение в службы каталогов OpenLDAPБыстрое развёртывание и начало работыОбщая картина - варианты конфигурацииСборка и установка OpenLDAPНастройка slapd

 

Конфигурационный файл slapdЗапуск slapdКонтроль доступаОграниченияИнструментыМеханизмы манипуляции даннымиНаложенияСпецификация схемы

 

БезопасностьSASLTLSРаспределённая служба каталоговРепликацияОбслуживаниеМониторингПроизводительностьУстранение неполадок
Перевод официального руководства OpenLDAP 2.4 Admin Guide
Полное содержание здесь
LDAP для учёных-ракетчиков

Содержание

О книгеКонцепции LDAPОбъекты LDAPУстановка LDAPПримерыНастройкаРепликация и отсылкиLDIF и DSMLПротоколLDAP API

 

HOWTOНеполадкиПроизводительностьИнструменты LDAPБезопасностьЗаметкиРесурсы LDAPRFC и X.500ГлоссарийОбъекты
Перевод "LDAP for Rocket Scientists"
Полное содержание здесь
Ресурсы

Книги

Руководство OpenLDAP 2.4LDAP для учёных-ракетчиков

Другие

СтатьиТермины LDAPman-страницы OpenLDAP 2.4Список RFCКлиенты LDAPФайлы наборов схемы
Полезные ресурсы
Форум

 

Разделы форумаНепрочитанные сообщенияПоследние сообщения
Форум проекта
Главная

Pro-LDAP.ru

О проектеНовости проектаУчастникиСтаньте участником!Сообщите об ошибке!Об авторских правахСоглашения проекта
Присоединяйсь!