Восстановление объектов-захоронений Active Directory

Вероятно, вы не любите об этом думать, но возможность случайной потери данных — это факт, и как специалист по ИТ вы должны быть готовы к любого рода сценариям восстановления. В номере за апрель 2007 журнала TechNet Magazine я рассказывал, как важно иметь план

для восстановления пользователей и групп Active Directory® . В этой статье, которую можно найти на веб-узле technetmagazine.com/issues/2007/04/ADRecovery, я рассмотрел механизмы связи объектов, репликации, удаления и принудительного восстановления. К сожалению, функция полномочного восстановления требует запуска контроллера домена (DC) в режиме восстановления службы каталогов (DSRM). Эта операция выводит контроллер домена из работы на весь период восстановления.

Вы должны знать о существовании другого подхода. Восстановление объектов-захоронений (не имеющее ничего общего с оживлением зомби) предоставляет единственно возможный способ восстановить удаленные объекты без вывода контроллера домена в автономный режим; кроме того, это единственный способ восстановить идентификационные данные удаленного объекта, такие как атрибуты objectGUID и objectSid. Этот подход прекрасно справляется с задачей повторного создания удаленного пользователя или группы и восстановления прежнего списка управления доступом (ACL), содержащим objectSid удаленного объекта. Имейте в виду, что восстановление объектов-захоронений имеет собственные определенные ограничения, о которых я расскажу позже, поэтому принудительное восстановление должно входить в число ваших приемов.

Восстановление объектов-захоронений впервые появилось в Active Directory в Windows Server® 2003 для упрощения восстановления определенных данных. Это свойство основано на том факте, что Active Directory хранит удаленные объекты в базе данных в течение определенного периода времени, перед тем как физически удалить их. В этой статье я подробно расскажу вам, как Active Directory удаляет и восстанавливает объекты, а также покажу, как можно восстановить удаленные объекты, используя стандартный набор инструментов Майкрософт.

Что такое объект-захоронение?

Когда Active Directory удаляет объект из каталога, он не удаляет его из базы данных физически. Вместо этого Active Directory помечает объект как удаленный, устанавливая для атрибута isDeleted объекта значение «истина», удаляя большинство атрибутов из объекта, переименовывая объект, а затем перемещая объект в специальный контейнер в контексте именования (NC) объекта под названием CN=Deleted Objects. Объект, который теперь зовется объектом-захоронением, невидим для обычных операций в каталогах. Он невидим в любых оснастках консоли управления Microsoft® (MMC), а большинство служебных программ протокола LDAP даже не знают о существовании этого объекта-захоронения. Объект-захоронение по существу может называться исчезнувшим. Однако данные все еще здесь — просто они невидимы. Зачем Active Directory хранит объекты-захоронения, или иными словами удаленные объекты, в базе данных?

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

Время жизни объекта-захоронения

Active Directory обычно удаляет объект из каталога в ответ на операцию по удалению протокола LDAP или операцию по удалению диспетчера учетных записей безопасности (SAM). Эта операция называется исходным удалением и отличается от операции удаления, которая выполняется в процессе репликации Active Directory. В этой статье не рассматриваются динамические объекты, которые удаляются совершенно другим способом, а именно удаляются самой средой Active Directory, когда истекает срок их жизни (TTL).

Когда Active Directory получает задание на удаление, среда сначала делает проверку, чтобы убедиться, что объект можно удалить. Этот процесс совершенно необходим, поскольку он проверяет верность следующих критериев:

• Для атрибута isDeleted объекта еще не установлено значение «истина». (Вы не можете удалить уже удаленный объект!)
• Контрольный флаг «частный объект» дескриптора безопасности, зависящего от ресурса, не установлен в дескрипторе безопасности объекта. (Это недокументированное «свойство». Флаг частного объекта — это бит 1 байта Sbz1 структуры дескриптора безопасности.)
• Бит «запретить удаление» (0x80000000) не установлен в атрибуте systemFlags объекта.
• Для атрибута isCriticalSystemObject объекта не установлено значение «истина».
• Дескриптор безопасности объекта дает соответствующие права доступа пользователю для удаления объекта. (Конкретнее, пользователю позволяют удалить сам объект и удалить дочерний объект из родительского объекта.)
• Объект не является объектом перекрестных ссылок (objectClass = crossRef) для существующего контекста именования.
• У объекта нет никаких подчиненных объектов. (Если операция удаления по протоколу LDAP включает идентификатор объекта управления «удалить дерево» по протоколу LDAP, Active Directory автоматически удалит подчиненные объекты, если их атрибут isCriticalSystemObject не установлен в значение «истина». Это защищает критические системные объекты от непреднамеренного удаления в ходе операции удаления объектов дерева. Разумеется, вы можете удалить эти объекты индивидуально.)
• Объект не является критическим внутренним объектом (например, это не объект nTDSDSA для контроллера домена или не объекты заполнения для предшествующих объектов головных объектов NC).

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

Если определено, что объект действительно может быть удален, Active Directory начинает переводить объект в состояние объекта-захоронения. Сначала Active Directory удаляет ненужные атрибуты объекта, оставляя лишь обозначенные на Рис. 1 и те, которые по схеме должны сохраняться у объекта-захоронения. (Дополнительные сведения об этом можно найти в разделе «Восстановление атрибутов объекта».)

Рис 1  Атрибуты, сохраненные в объекте-захоронении

Жестко заданные для сохранения

attributeID

attributeSyntax

dnReferenceUpdate

dNSHostName

flatName

governsID

groupType

instanceType

lDAPDisplayName

legacyExchangeDN

mS-DS-CreatorSID

mSMQOwnerID

nCName

objectClass

objectGUID

objectSid

oMSyntax

proxiedObejctName

replPropertyMetaData

sAMAccountName

securityIdentifier

sIDHistory

subClassOf

systemFlags

trustPartner

trustDirection

trustType

trustAttributes

userAccountControl

uSNChanged

uSNCreated

whenCreated

Сохраняемые благодаря установке searchFlags

msDS-AdditionalSam­AccountName

msDS-Auxiliary-Classes

msDS-Entry-Time-To-Die

msDS-IntId

msSFU30NisDomain

nTSecurityDescriptor

uid

Затем она изменяет относительное различающееся имя (RDN) объекта на CN=<old RDN>\0ADEL:<objectGUID>, где \0A означает символ ASCII перевода строки, а <objectGUID> – это objectGUID, выраженный строкой. Атрибут lastKnownParent затем устанавливается на различающееся имя (DN) родительского контейнера объекта, а атрибут isDeleted устанавливается в значение «истина». Active Directory затем удаляет из объекта все атрибуты ссылок на предыдущий и следующий элемент. Наконец, если в атрибуте systemFlag объекта не установлен бит «не разрешать перемещение после удаления», Active Directory перемещает объект в контейнер CN=Deleted Objects для NC. (Дополнительные сведения приведены на врезке «Атрибут systemFlags и поведение объекта».)

Необходимо учитывать, что папка CN=Deleted Objects — плоская и не имеет иерархии объектов. Можно предположить, что при удалении двух разных объектов с одним CN могут возникнуть конфликты с именем. Этого не произойдет. Поскольку objectGUID включен в RDN каждого объекта-захоронения, RDN каждого объекта-захоронения является уникальным в рамках контейнера CN=Deleted Objects.

Очевидно, объекты не остаются в контейнере CN=Deleted Objects навсегда. По умолчанию срок жизни объекта-захоронения составляет 60 дней для лесов, построенных при помощи Windows® 2000 и Windows Server 2003, и 180 дней для лесов, построенных при помощи Windows Server 2003 SP1. Срок жизни объекта-захоронения можно изменить, установив атрибут tombstoneLifetime в объекте CN=Directory Service,CN=Windows NT, CN=Services, CN=Configuration, DC=<корневой домен>.

Каждые 12 часов контроллер домена начинает процесс сборки мусора. (Это можно изменить, установив новое значение для атрибута garbageCollPeriod объекта CN=Directory Service,CN=Windows NT, CN=Services, CN=Configuration, DC=<корневой домен>.) Сборщик мусора проверяет все объекты-захоронения на контроллере домена и физически удаляет те, чей срок жизни больше, чем срок жизни объектов-захоронений.

Использование LDP для поиска объектов-захоронений

LDP — это служебная программа, схожая с проводником Windows, для работы с Active Directory. LDP была изначально создана группой разработчиков Active Directory для тестирования кода протокола LDAP, когда Active Directory находилась в разработке. Теперь, будучи частью средств поддержки Windows Server 2003, LDP развилась в надежное средство для работы с Active Directory.

Хотя объекты-захоронения невидимы для обычных операций с каталогами, можно обнаружить объекты-захоронения в Active Directory, используя поисковые операции LDAP и специальные расширения протокола LDAP, называемые элементами управления. Элементы управления — это механизм, определяемый в стандарте LDAP и используемый для расширения протокола LDAP с целью обеспечения дополнительной функциональности помимо той, что определена в стандарте LDAP, сохраняя при этом совместимость с другими программами, поддерживающими LDAP. Active Directory поддерживает 22 элемента управления, включая элемент управления «Возврат удаленных объектов». Если этот элемент управления используется для расширения операции поиска LDAP, он выявляет удаленные объекты, которые в другом случае оставались бы невидимыми.

Чтобы продемонстрировать, как это работает, я войду в домен foo.local, используя учетные данные администратора предприятия, а затем воспользуюсь оснасткой ММС «Active Directory — Пользователи и компьютеры» (ADUC) для создания объекта пользователя (CN=John Smith,CN=Users,DC=foo, DC=local), как показано на Рис. 2. Затем, используя ADUC, я удаляю объект пользователя.

Рис. 2 Использование ADUC для создания пользователя

Теперь я могу запустить программу LDP и использовать ее для показа объекта-захоронения для удаленного пользователя. Первый этап — подключить LDP к определенному контроллеру домена и пройти проверку подлинности, используя соответствующие учетные данные. Для соединения с DC я использую пункт Connect (Подключить) из меню Connection (Подключение). Поскольку я запускаю LDP на контроллере домена, я просто нажимаю кнопку OK, чтобы подключиться к локальному контроллеру домена. Если вы запускаете LDP удаленно, вы должны указать имя контроллера домена, к которому нужно подключиться. После успешного подключения LDP показывает атрибуты rootDSE — сюда входят атрибуты, описывающие состояние и настройку самого контроллера домена (см. Рис. 3).

Рис. 3 LDP подключен к контроллеру домена

Теперь, чтобы пройти проверку подлинности на контроллеру, используя учетные данные администратора домена или предприятия, я выбираю Bind (Привязать) из меню подключения. Поскольку я уже вошел в сеть как администратор предприятия для леса (администраторы домена и администраторы предприятия по умолчанию имеют право выводить список и восстанавливать объекты в контейнере CN=Deleted Objects), я просто оставляю поля имени пользователя и пароля пустыми в диалоге привязки и нажимаю OK. В другой ситуации я могу ввести соответствующие учетные данные в диалогом окне привязки.

Далее я хочу вывести содержание контейнера CN=Deleted Objects,DC=foo=DC=local. Обычно увидеть контейнер CN=Deleted Objects нельзя, поскольку сам контейнер отмечен как удаленный. Единственный способ произвести поиск в контейнере CN=Deleted Objects — это использовать элемент управления протокола LDAP «Вернуть удаленные объекты».

Для использования этого элемента управления при помощи LDP перейдите в меню Browse (Обзор) и выберите Search (Поиск). Появится диалоговое окно поиска, показанное на Рис. 4. Поле Base Dn позволяет вам указать место в дереве каталогов, с которого следует начать поиск. Я ввожу DN контейнера Deleted Objects для домена – в данном примере DN – это CN=Deleted Objects,DC=foo,DC=local.

Рис. 4 Диалог поиска в LDP

В поле фильтра я указываю критерий поиска для LDP. Класс по умолчанию — (objectClass=*), который дает поиску указание возвращать все объекты, у которых есть значение атрибута objectClass. Поскольку даже удаленные объекты в Active Directory имеют значение для objectClass, фильтр по умолчанию вернет каждый объект в области поиска. В этом примере я изменяю фильтр на (objectClass=user), ограничивая поиск только объектами-пользователями. Таким образом мне будет легче найти удаленного пользователя Джона Смита среди тысяч объектов-захоронений в контейнере CN=Deleted Objects.

Можно обнаружить, что в контейнере CN=Deleted Objects гораздо больше объектов, чем Active Directory может вернуть в результате одного поиска. Чтобы решить эту проблемы, можно использовать постраничный поиск LDAP, возвращающий результаты по группам. Тем не менее, LDP не позволяет указать одновременно постраничный и расширенный поиск. Поэтому придется поработать с фильтром LDAP, чтобы обнаружить нужный объект.

Переключатели Scope позволяют указать долю дерева каталогов для поиска. Начальный поиск вернет только объект, указанный при помощи поля Base Dn. Одноуровневый поиск вернет объекты, находящиеся в непосредственном подчинении объекту Base Dn. Поиск в поддереве вернет все объекты в подчинении объекту Base Dn. Поскольку папка CN=Deleted Objects плоская, я использую одноуровневый поиск для выявления всех объектов-захоронений.

Я сделал набросок обычного поиска LDAP. Если бы мне пришлось запускать его сейчас, программа LDP выдала бы ошибку, которая бы сообщала, что CN=Deleted Objects,DC=foo,DC=com не существует, поскольку он отмечен как удаленный. В поиск мне нужно включить элемент управления LDAP «Возврат удаленных объектов». Для этого я нажимаю кнопку Options (Параметры) в диалоговом окне поиска и выбираю Extended (Расширенный) для типа поиска, как показано на Рис. 5. Этот режим позволяет указать элементы управления для поиска. Кроме того, я изменяю список атрибутов на *. В результате LDP покажет все обычные атрибуты для каждого выявленного объекта вместо набора атрибутов, используемых в LDP по умолчанию.

Рис. 5 Поиск LDP Диалог Options (Параметры)

Теперь я нажимаю кнопку Controls (Элементы управления), чтобы вывести диалог элементов управления. Диалоговое окно элементов управления LDP не очень удобное, поэтому внимательно выполняйте указания для добавления элемента управления «Вернуть удаленные объекты».

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

Рис. 6 Добавление элемента управления «Вернуть удаленные объекты»

Диалоговое окно элементов управления ведет себя весьма оригинальным способом. Например, даже если в списке активных элементов управления появляется OID, это не обязательно означает, что элемент управления активирован. Иногда необходимо взять элемент управления для изменения, а затем вернуть его после изменения снова, чтобы убедиться, что он будет использоваться в следующей операции протокола LDAP.

Теперь я готов к поиску. Я нажимаю кнопку OK в диалоговом окне поиска LDP, и LDP выводит все объекты пользователя из контейнера CN=Deleted Objects для этого домена. Результаты показаны на Рис. 7.

Рис. 7 Результаты из контейнера CN=Deleted Objects

Анализ результатов LDP

Мой поиск выявил два объекта-захоронения. Во-первых, можно видеть DN первого объекта-захоронения: CN=John Smith\0ADEL:41800281-6bc4-42c3-a99b-b283022b3af8,CN=Deleted Objects,DC=foo,DC=local. objectGUID удаленного объекта представлен в виде строки (41800281-6bc4-42c3-a99b-b283022b3af8). Под DN расположен список атрибутов, показывающих значения для objectClass, cn, distinguishedName, и т.д. Видно, что значение атрибута isDeleted есть «истина», что означает, что объект на самом деле удален. Кроме того, видно, что в объекте-захоронении сохранен objectSid — это важно для восстановления объекта-захоронения пользователя и группы, о чем я расскажу дальше. Атрибут lastKnownParent, представляющий DN объекта, который содержал удаленный объект до того, как он стал объектом-захоронением, также очень важен для восстановления объектов-захоронений.

В моем примере LDP вывел два объекта-захоронения, оба из которых были объектами-пользователями, под названием CN=John Smith, изначально содержащимися в контейнере CN=Users,dc=foo,dc=local. Как могли два разных объекта с одним и тем же RDN появиться из одного и того же контейнера? Этому есть очень простое объяснение. Перед тем как запустить LDP на поиск объектов-захоронений, я создал объект пользователя CN=John Smith в контейнере CN=Users,DC=foo,DC=local и удалил его. Затем я создал еще один объект пользователя с такими же атрибутами и также удалил его. Поскольку я уже удалил первый объект пользователя CN=John Smith, было вполне разумным создать второй, несмотря на то, что у него было точно такое же имя. Однако это два отдельных, уникальных объекта, отличающиеся своими идентификаторами objectGUID. Поскольку Active Directory включает objectGUID в DN объекта-захоронения, они появляются как отдельные объекты в контейнере CN=Deleted Objects.

Как восстанавливается объект-захоронение

Active Directory предлагает механизм для восстановления объекта-захоронения до состояния нормального объекта. Это, по существу, функция восстановления для удаленных объектов. Функция представляет собой специально созданную операцию протокола LDAP по изменению, которая должна включать две конкретные модификации атрибута: она должна удалять атрибут isDeleted (а не просто устанавливать для него значение «ложь»), а также перемещать объект в другой контейнер, изменяя различающееся имя объекта. Новое различающееся имя обычно (но не обязательно) использует атрибут lastKnownParent в качестве контейнера и сохраняет то же RDN минус компонент \0ADEL:<objectGUID>, который был добавлен Active Directory при создании объекта-захоронения.

Перед восстановлением объекта-захоронения Active Directory производит проверку того, чтобы определенные необходимые условия являлись верными. Расширенное право доступа пользователя к восстановленному объекту-захоронению должно быть определено в дескрипторе NC контейнера NC, содержащего объект-захоронение. Пользователь не может восстанавливать свой собственный объект. Атрибут isDeleted объекта-захоронения должен быть установлен в значение «истина». Идентификатор безопасности (SID) владельца объекта, как определено в дескрипторе безопасности, должен иметь SID из одного из доменов леса или доверенного домена.

Если рассматриваемый объект находится в контексте именования конфигурации или схемы, в атрибуте systemFlags объекта-захоронения должны быть установлены биты FLAG_CONFIG_ALLOW_RENAME и FLAG_ CONFIG_ALLOW_MOVE. Если объект находится в контексте именования конфигурации или схемы с установленным флагом FLAG_CONFIG_ALLOW_LIMITED_MOVE, объект может быть перемещен только в контейнер с тем же прародителем — другими словами, объект должен сохранить своего прапрародителя после перемещения, а если объект находится в контексте именования домена или раздела приложения, то биты FLAG_DOMAIN_DISALLOW_RENAME и FLAG_DOMAIN_DISALLOW_MOVE не должны устанавливаться в атрибуте systemFlags объекта-захоронения.

Пользователь должен иметь право, как определено в дескрипторе безопасности, изменять RDN (обычно CN, но не всегда) и добавлять объект в новый родительский контейнер. Новый родительский контейнер должен иметь возможность быть старшим для objectClass объекта-захоронения, как определено в схеме. Хотя перемещения внутрь и за пределы системного контейнера обычно не разрешены (если только параметр реестра Unlock system поддерева не равен нулю), восстановление объекта-захоронения в системный контейнер допускается.

Восстановление объекта схемы не допускается ни при каких обстоятельствах. Это, тем не менее, не является большой проблемой, поскольку вы не можете законным образом удалить объект из контекста именования схемы.

Если все проверки прошли успешно и необходимые требования соблюдаются, Active Directory произведет следующие действия по восстановлению объекта-захоронения:

• Атрибут isDeleted удаляется.
• Если операция изменения не предписывает иного, objectCategory настраивается на наиболее конкретный objectClass, указанный в объекте-захоронении.
• RDN изменяется, и объект записывается в новый родительский контейнер.

После восстановления у объекта будут те же атрибуты objectGUID и objectSid, которые были у него изначально. Это означает, что внешние ссылки на объект, например в ACL, не нужно перенастраивать, как в случае повторного создания удаленного объекта. Восстановленный объект выглядит и ведет себя точно так же, как до того, как он был удален. Существует, тем не менее, одно важное различие: в восстановленном объекте не будет атрибутов, которые не были сохранены в объекте-захоронении.

Атрибут systemFlags и поведение объекта

Атрибут systemFlags — это дополнительный атрибут, определенный для вершины класса, что делает systemFlags дополнительным атрибутом для каждого класса Active Directory. Это 32-разрядное целочисленная маска, контролирующая перемещение и удаление объекта. Вот краткое описание важных флагов.

FLAG_DISALLOW_DELETE (0x80000000)

Если этот флаг установлен, система не допустит удаления или перемещения объекта в другой домен.

FLAG_CONFIG_ALLOW_RENAME (0x40000000)

Объекты в контекстах именований конфигурации и схемы не могут быть переименованы, пока этот флаг не будет установлен в атрибуте systemFlags.

FLAG_CONFIG_ALLOW_MOVE (0x20000000)

Объекты в контекстах именований конфигурации и схемы не могут быть перемещены, пока этот флаг не будет установлен в атрибуте systemFlags.

FLAG_CONFIG_ALLOW_MOVE (0x20000000)

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

FLAG_DOMAIN_DISALLOW_RENAME (0x08000000)

По умолчанию объекты в контексте именования домена или приложения могут быть переименованы. Однако если этот флаг установлен в атрибуте объекта systemFlags, система не позволит переименовать объект.

FLAG_DOMAIN_DISALLOW_RENAME (0x08000000)

По умолчанию объекты в контексте именования домена или приложения могут быть перемещены в другой контейнер. Однако если этот флаг установлен в атрибуте объекта systemFlags, система не позволит переместить объект.

FLAG_DISALLOW_MOVE_ON_DELETE (0x02000000)

Если этот флаг установлен, система не будет перемещать объект в контейнер CN=Deleted Objects его контекста именования. Он просто установит атрибут isDeleted, переименует объект и удалит атрибуты, не предназначенные схемой для сохранения. Это означает, что не все удаленные объекты появляются в контейнере CN=Deleted Objects для контекста именования; некоторые остаются в исходном родительском контейнере.

Использование LDP для восстановления объектов-захоронений

Теперь, когда я рассказал, как работают процессы восстановления, я хочу показать, как я использую LDP для восстановления пользователя CN=John Smith, которого я удалил. Сначала я подключусь к DC и пройду проверку подлинности. Теперь я могу выполнить операцию по изменению, используя LDP. В параметрах операции по изменению я могу удалить атрибут isDeleted и в то же время указать новое различающееся имя.

Поскольку я провожу операцию на объекте-захоронении, я должен указать элемент управления протокола LDAP «Вернуть удаленные объекты». Чтобы установить этот элемент управления для операции по изменению в LDP, в меню параметров выберите Controls (Элементы управления), затем выберите Return deleted objects (Вернуть удаленные объекты) в раскрывающемся списке Load Predefined (Загрузить назначенное), нажмите кнопку Check In (Вернуть после изменения) и нажмите кнопку ОК, чтобы сохранить параметры элемента управления.

Теперь я выбираю Modify (Изменить) в меню Browse (Oбзoр), чтобы открыть диалоговое окно изменения, и ввожу различающееся имя объекта-захоронения, который нужно восстановить. Самый простой способ сделать это — это скопировать и вставить различающееся имя из результатов поиска, который я проводил до этого.

Далее мне нужно ввести список операций с атрибутами для выполнения. Для восстановления объекта-захоронения необходимо выполнить две операции с атрибутами: удалить атрибут isDeleted и заменить атрибут distinguishedName желаемым различающимся именем восстановленного объекта-захоронения, поэтому я ввожу isDeleted в поле атрибута и выбираю кнопку-переключатель Delete (Удалить). Когда я нажимаю клавишу ВВОД, операция атрибута добавляется в лист ввода, как показано на Рис. 8.

Рис. 8 Указание операций с атрибутами

Затем я ввожу различающееся имя в поле атрибута, выбираю кнопку-переключатель Replace (Заменить) и ввожу новое различающееся имя объекта в поле значений. В этом случае я использую оригинальное различающееся имя пользователя: CN=John Smith,CN=Users,DC=foo,DC=local. Когда я нажимаю клавишу ВВОД, операция изменения добавляется в список ввода.

Поскольку мне нужно включить элемент управления LDAP «Вернуть удаленные объекты» в операцию по изменению, я должен использовать расширенное изменение LDAP. Для этого я установлю флажок на расширение. После того как настройка произведена, как показано на Рисунке 9, я нажимаю кнопку Run, чтобы произвести изменения. LDP покажет результаты в большом текстовом окне.

Рис. 9 Изменить distinguishedName

Когда я возвращаюсь к оснастке ММС «Active Directory — пользователи и компьютеры» и заглядываю в контейнер CN=Users, я обнаруживаю, что однажды удаленный объект пользователя находится там, где и был. Однако у этого объекта будет несколько важных отличий от оригинального объекта, о которых я вскоре расскажу.

Использование ADRESTORE для восстановления объектов-захоронений

Как только вы поймете, как использовать LDP, восстановление объекта-захоронения станет делом очень несложным. Однако эта процедура не очень удобная. К счастью, умельцы из Sysinternals (компания, которая теперь входит в Майкрософт) разработали средство командной строки для упрощения процесса восстановления. Это средство под названием ADRESTORE можно загрузить с веб-узла Майкрософт по адресу microsoft.com/technet/ sysinternals/utilities/AdRestore.mspx. Его очень просто установить. Просто скопируйте исполняемый файл в соответствующий каталог на вашем компьютере, например C:\WINDOWS\SYSTEM32.

Программа ADRESTORE работает в двух режимах. При запуске без параметров она выведет список всех объектов-захоронений в контейнере CN=Deleted Objects домена по умолчанию. Можно добавить строку для поиска в командной строке, чтобы выбрать объекты для показа, например:

C:\> adrestore John

Результатом будут все объекты-захоронения в контейнере CN=Deleted Objects, которые содержат строку «John» в атрибуте CN или OU — программа использует поисковый фильтр LDAP cn=*John* и ou=*John*. Это не самый гибкий способ поиска объектов-захоронений, но во многих ситуациях он работает очень хорошо. На Рис. 10 показаны результаты поиска, возвращенного программой ADRESTORE.

Рис. 10 Атрибуты, сохраненные в объекте-захоронении

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

C:\> adrestore –r John

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

ADRESTORE предлагает удобный интерфейс командной строки для использования функции восстановления Active Directory. Хотя он не очень гибкий, его легче использовать, чем LDP. Тем не менее, ADRESTORE не решает двух основных проблем, связанных с восстановлением объектов-захоронений: восстановление атрибутов, удаленных из объекта во время удаления самого объекта, и восстановление объектов, удаленных из контекста именования конфигурации.

Восстановление атрибутов объекта

В плане восстановления данных восстановление объекта-захоронения имеет больше преимуществ, чем принудительное восстановление: восстановление объекта-захоронения не требует выведения контроллера домена в автономный режим, а восстановление объектов-захоронений гораздо лучше, чем простое воссоздание новой версии удаленного объекта. Если вы вновь создаете объект, он всегда будет иметь новые атрибуты objectGUID и objectSid (если это участник политики безопасности, такой как пользователь). В результате любые внешние ссылки на объект, такие как ACL, необходимо будет обновлять для отражения нового идентификатора объекта. Это может стать очень большой проблемой.

Некоторые атрибуты удаляются вместе с удалением объекта, и эти атрибуты не восстанавливаются вместе с восстановлением объекта-захоронения. Но Active Directory сохраняет основные атрибуты в объекте-захоронении, самые важные из которых — атрибуты, относящиеся к идентификации, такие как objectGUID и objectSid. Также по умолчанию сохраняются многие другие атрибуты (см. Рис. 1). Большинство жестко установленных для сохранения атрибутов не очень интересны, особенно при обсуждении восстановления удаленных объектов пользователя, однако можно указать дополнительные атрибуты для сохранения в объекте-захоронении, установив бит 3 (0x00000008) атрибута searchFlags соответствующего объекта attributeSchema object в схеме Active Directory. В некоторых атрибутах этот бит уже может быть установлен в схеме Windows Server 2003 R2 (они также показаны на Рис. 1).

Установка некоторых приложений может изменить бит 3 в searchFlags существующих атрибутов или даже добавить новые атрибуты, у которых установлен бит 3. Exchange Server, например, настраивает некоторые дополнительные атрибуты для сохранения в объекте-захоронении.

Active Directory не будет сохранять атрибуты ссылок вперед и назад в объекте-захоронении, даже если указать на необходимость этого в атрибуте searchFlags объекта схемы. В частности, Active Directory не сохраняет такие вещи, как атрибут членства в группе или атрибут пользователя memberOf attribute. Таким образом, восстановление объекта-захоронения не предоставляет возможности восстановления членства в группе в Active Directory, см. мою статью «Аварийное восстановление: Active Directory — пользователи и группы» на веб-узле technetmagazine.com/issues/2007/04/ADRecovery. Вам все равно придется найти альтернативный механизм для восстановления этой информации при восстановлении объектов-захоронений.

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

Восстановление объектов из контекста именования конфигурации

Еще одним существенным ограничением при восстановлении объектов-захоронений является то, что нельзя восстанавливать объекты, удаленные из контекста именования конфигурации. Эти объекты подчиняются особенным правилам в отношении перемещения и переименования, как определено в атрибуте объекта systemFlags. Если иное не указано в атрибуте systemFlags, объекты в контексте именования конфигурации не могут перемещаться или переименовываться, что означает, что их объекты-захоронения не могут быть восстановлены. Active Directory обеспечивает определенные значения для атрибута systemFlags, когда создает объекты конкретных классов, как показано на Рис. 11.

Рис 11  Параметры systemFlags по умолчанию

Класс Параметр по умолчанию

server	FLAG_DISALLOW_MOVE_ON_DELETE FLAG_CONFIG_ALLOW_RENAME FLAG_CONFIG_ALLOW_LIMITED_MOVE
site	FLAG_DISALLOW_MOVE_ON_DELETE
serversContainer	FLAG_DISALLOW_MOVE_ON_DELETE
nTDSDSA	FLAG_DISALLOW_MOVE_ON_DELETE
siteLink	FLAG_CONFIG_ALLOW_RENAME
siteLinkBridge	FLAG_CONFIG_ALLOW_RENAME
nTDSConnection	FLAG_CONFIG_ALLOW_RENAME

Обратите внимание на то, что Active Directory применяет побитовую логическую операцию ИЛИ к этим значениям в сочетании с любым значением systemFlags, указанным в операции добавления. Таким образом, даже если в приложении указано другое значение для атрибута systemFlags, необходимые биты будут установлены правильно.

Единственными объектами в контексте именования конфигурации, которые можно восстанавливать при нормальных обстоятельствах, являются серверные объекты. Интересно, что когда Active Directory удаляет серверный объект, объект-захоронение не перемещается в контейнер CN=Deleted Objects для контекста именования конфигурации; объект-захоронение просто остается там, где находится объект. Это позволяет средству проверки согласованности знаний (KCC), являющемуся процессом, ответственным за расчет топологии репликации Active Directory, автоматическое восстановление в определенных ситуациях, где удаленные серверные объекты могли препятствовать правильной репликации, поэтому, если вы пытаетесь восстановить серверный объект, помните, что вы не найдете его в контейнере CN=Deleted Objects.

Восстановление объектов-захоронений в плане восстановления

Восстановление объектов-захоронений должно быть основной частью вашего набора средств по восстановлению данных. Этот механизм — единственный способ восстановить удаленные объекты без вывода контроллера домена в автономный режим и, что не менее важно, это единственный способ восстановить идентификационную информацию удаленного объекта. Это очень хорошо решает проблему восстановления удаленного пользователя или группы и последующего постановлениях старых ссылок ACL.

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