Восстановление объектов Active Directory с использованием корзины

Майкл Олиг, 6 марта 2019 года

В прошлой заметке этой серии обсуждались прелести восстановления объектов Active Directory в окружении без корзины AD (AD Recycle Bin). Если Вы пропустили этот пост, я настоятельно рекомендую Вам вернуться и прочитать его, поскольку это, пожалуй, самый замечательный пост в блоге, который я когда-либо писал о восстановлении объектов Active Directory в среде без корзины AD. Если коротко, при удалении объекта Active Directory в домене без корзины он становится "надгробным камнем". Этот объект, лишённый большинства своих атрибутов, затем находится в контейнере "Deleted Objects" раздела Active Directory на время, установленное в параметре tombstoneLifetime домена. В течение этого периода объект технически поддаётся восстановлению, но его утраченные атрибуты в общем случае можно считать невосстановимыми. При превышении "надгробным камнем" времени tombstoneLifetime сборщик мусора отправит объект в небытие. Совсем коротко этот процесс выглядит так:

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

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

Объекты в этом новом восстанавливаемом состоянии называются "удалёнными объектами" ("deleted object"), а период времени, в течение которого они сохраняют свои атрибуты, определяется в новом атрибуте msDS-DeletedObjectLifetime. При включении корзины AD значение атрибута msDS-DeletedObjectLifetime по умолчанию соответствует значению атрибута tombstoneLifetime. Если значение атрибута msDS-deletedObjectLifetime является нулевым, либо этот атрибут вообще отсутствует, его значение интерпретируется как эквивалентное значению атрибута tombstoneLifetime. Если также отсутствует и значение tombstoneLifetime, то оба они по умолчанию считаются равными 60 дням.

Если время пребывания объекта в статусе "удалённый объект" превышает период, указанный в msDS-DeletedObjectLifetime, то объект отправляется на переработку. Переработанный объект ("recycled object") подозрительно похож на "надгробный камень" у которого появился атрибут isRecycled, установленный в TRUE. Как и у "надгробного камня" большинство из его атрибутов удаляются, и он присутствует в Active Directory в течение времени tombstoneLifetime, после чего зачищается сборщиком мусора Active Directory.

Упрощённо жизненный цикл удалённого объекта при включённой корзине AD выглядит так:

Теперь, когда у нас есть общее представление о поведении удалённых объектов в среде с корзиной AD, давайте воспользуемся утилитой LDP и поближе познакомимся с моей подопытной учётной записью.

Как видите, благодаря чудесам PowerShell-скрипта, создавшего, а затем и оживившего нашего пользователя, у нас есть множество заполненных атрибутов.

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

Итак, в результате удаления объекта произошли следующие изменения:

1. Объект был перемещён.
   Как и в нашем предыдущем эксперименте без использования корзины, объект был перемещён в контейнер "Deleted Objects" раздела каталога.
2. Объект был переименован.
   Как и в прошлый раз, имя объекта было обновлено по тому же шаблону Common-Name\0ADEL:Object-Guid.
3. У объекта появилось несколько новых атрибутов.
   И снова у нас появился атрибут isDeleted со значением TRUE, а также соответствующим образом заполненный атрибут lastKnownParent с (хотя в данном случае он уже был заполнен в результате удаления и восстановления объекта, которое мы проводили в прошлом эксперименте). Новый атрибут msDS-LastKnownRDN заполняется последним относительным уникальным именем (RDN) объекта. Этот атрибут позволяет корзине AD правильно переназначить RDN объекта при его восстановлении даже в том случае, если переименование объекта привело к усечению его исходного RDN.
4. Два атрибута были удалены.
   Благодаря корзине AD, было утрачено только два атрибута: objectCategory и sAMAccountType. Фактически, при удалении объекта эти два атрибута всегда удаляются из него, независимо от работы корзины или наличия флага поиска 0x8 ( PRESERVE_ON_DELETE ). При восстановлении объекта значение атрибута objectCategory автоматически устанавливается в наиболее подходящее для объектного класса (атрибут objectClass) данного объекта, а значение sAMAccountType вычисляется на основании либо значения атрибута userAccountControl (для объектов пользователей), либо значения атрибута groupType (для объектов групп).
   Внимательные читатели могут также отметить, что на приведённом скриншоте нет ещё и атрибутов manager и memberOf. На самом деле они просто прячутся. Оба этих типа атрибута имеют так называемые ссылочные значения (то есть они содержат ссылки на другие объекты), и LDAP не возвращает деактивированные ссылки, если не был задан элемент управления с говорящим названием "Return Deactivated Links". Если бы я включил этот элемент управления, атрибуты и их значения были бы видны на моём скриншоте, но тогда я бы упустил случай упомянуть об этом поучительном моменте.

Перейдём к процессу восстановления объекта корзины AD. Хотя выгод от корзины AD довольно много, изначально работа с ней была затруднена тем, что её было относительно сложно использовать. До Windows Server 2012 для просмотра содержимого корзины требовалось использовать инструмент LDAP или PowerShell. Например, вот такой PowerShell-запрос возвращает всё удалённые объекты в домене:

Get-ADObject -filter 'isDeleted -eq $true -and name -ne "Deleted Objects"' -includeDeletedObjects

В моей лаборатории, где Active Directory не используется на всю катушку, такой запрос выводит:

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

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

Restore-ADObject -Identity '562f229c-e03a-4005-a098-10046e9b8942'

Для указания объекта, который я пытаюсь восстановить, задаю его идентификатор ObjectGUID в параметре Identity. Можно было бы поступить и по-другому: напрямую передать результаты запроса Get-ADObject через конвейер командлету Restore-ADObject.

В этом была своя прелесть: если бы корзину AD не было так сложно использовать, было бы труднее проникнуться всей полнотой её полезности. К счастью, после получения Microsoft множества недовольных отзывов от сообщества пользователей, они упростили работу, добавив в Windows Server 2012 функционал корзины в Центр администрирования Active Directory (Active Directory Administrative Center, ADAC).

Давайте заглянем в контейнер "Deleted Objects" с помощью ADAC:

Как видите, те же четыре объекта, которые вернул мой PowerShell-запрос, представлены в гораздо более дружественном для пользователя интерфейсе. Также имеется возможность простой генерации фильтров для ограничения количества отображаемых пользователю объектов, а в списке задач (Tasks) правой части окна предусмотрен пункт Restore. Сейчас я по нему кликну, а затем снова зайду в LDP, чтобы посмотреть на наш свежевосстановленный объект.

Здорово, правда?

Однако перед тем, как все побегут включать корзину Active Directory, необходимо предупредить о непосредственных и потенциально вредных последствиях этого шага:

1. Включение корзины Active Directory влечёт за собой изменение схемы данных каталога.
   В результате такого изменения схемы становится невозможно отключить корзину, не прибегая к полному восстановлению леса. Другими словами, если Вы включите корзину, отключить её Вы уже не сможете.
2. Active Directory станет немного больше.
   После включения корзины AD удалённые объекты сохранят все свои атрибуты до истечения срока своего пребывания в статусе "удалённый объект". И вообще, время нахождения объекта в каталоге увеличится вдвое (на период пребывания в статусе "надгробного камня"). За счёт обоих этих факторов Active Directory будет использовать немного больше дискового пространства, чем раньше.
3. Корзина не может работать ретроспективно.
   Из этого есть очень серьёзное следствие: в момент включения корзины AD все "надгробные камни" в лесу перестают существовать. Если Вы злорадны, можете поискать в Интернете "удалённые объекты, исчезнувшие после включения корзины". Для весьма немалого количества людей знания об этом конкретном следствии стало запоздалым и неприятным откровением.

Хотя мы и должны были об этом предупредить, ни одна из этих проблем не является настолько серьёзной, чтобы перевесить преимущества от включения корзины AD. Но мы также должны отметить, что StealthRECOVER работает как с включённой, так и не с включённой корзиной Active Directory, и предоставляет дополнительный уровень защиты за счёт способности восстанавливать из резервных копий объекты, которые превысили период mdDS-DeletedObjectLifetime своего леса, и более не могут быть восстановлены с помощью корзины AD.

В следующей заметке из этой серии мы перейдём от удаления объектов к вопросу восстановления модифицированных объектов.