Все мы люди и всем нам свойственно совершать ошибки. Некоторые ошибки могут быть несущественными, как, скажем, неправильно указанный адрес пользователя в свойствах его учетной записи, а некоторые могут быть чуть ли не критическими. К таким ошибкам можно отнести удаление объектов Active Directory. Возьмем простейший пример: у вас в компании есть несколько сотен пользователей. В Active Directory было создано подразделение, скажем, «Маркетинг», в которое входят 25 пользователей, включая пользователей Вячеслава и Владислава Овечкиных, причем первый является руководителем всего отдела маркетинга. Владислав увольняется из компании, и, как следствие, вы должны удалить его учетную запись из Active Directory, но случайно удаляете учетную запись начальника отдела. Что же произойдёт дальше?

Не исключено, что Вячеслав сможет нормально доработать в этот день, но на следующее утро у него, а потом и у вас, начнутся проблемы. Если его учетная запись была создана на скорую руку, он не являлся членом каких-либо групп безопасности и на него не были навешаны какие-либо дополнительные права – особых проблем не будет. Вы просто создадите заново учетную запись и все. Но если же Вячеслав состоял в нескольких группах и т.д., то у вас уйдет уйма времени на то, чтобы вернуть все его разрешения на круги своя. Да и есть шанс, что какая-то группа не будет учтена, и этот пользователь рано или поздно вновь столкнется с проблемами. Так существует ли возможность избежать таких неприятных ситуаций?

Конечно, да! О методах восстановления удаленных принципалов безопасности мы с вами далее и поговорим в этой статье.

Как раньше восстанавливали удаленные объекты

К одному из методов защиты от всевозможных «дизастеров», естественно, можно отнести создание и последующее использование бэкапов. Прежде всего вам следует уделить время составлению пошагового плана процесса создания резервных копий и восстановления своих контроллеров домена, так как если удаление какой-то конкретной учетной записи еще можно пережить, то при полном крахе всей активной директории обычным выговором, скорее всего, дело не обойдется. Обязательно проверьте свой план резервного копирования как в лабораторной среде, так и, что желательно, уже после развертывания доменных служб. Так как сам процесс резервного копирования доменных служб со всеми вытекающими нюансами просто невозможно должным образом разъяснить в нескольких абзацах, этой теме будет посвящена отдельная крупная статья, а сейчас вернемся к самому удалению объектов и его последствиям.

Прежде всего стоит помнить, что все объекты Active Directory хранятся в базе доменных служб, то есть, грубо говоря, в файле Ntds.dit, и любое изменение любого объекта, который размещается в такой базе, называется транзакцией. Возьмем простой пример – изменение произвольного атрибута в учетной записи пользователя. Пусть это будет изменение должности вышеупомянутого Вячеслава Овечкина. Сразу же после определения должности для этого сотрудника такое изменение записывается в журнал регистрации транзакции (физически это файл Edb), где, собственно, можно узнать, какие транзакции из журналов регистрации записываются в базу данных доменных служб Active Directory. Если вы локализуете такой файл, а он по умолчанию размещается в папке %systemroot%NTDS, то сразу заметите, что это обыкновенный текстовый файл с расширением .log. Более чем очевидно, что в такие файлы информация будет записываться последовательно (ведь это обыкновенный текстовый файл, иначе тут не получится). Выходит, что информация в такие журналы должна поступать существенно быстрее, чем непосредственно в саму базу данных.

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

Чтобы было понятнее, как физически работают транзакции, рассмотрим два простых примера. Для начала базовый пример – перемещение пользователя из одного подразделения в другое. В этом случае объект создается в целевом подразделении, а после этого удаляется из исходного. Транзакция будет считаться завершенной только в том случае, если оба условия (как создание, так и удаление) выполнятся без ошибок. Если же во время любого условия произойдет ошибка, транзакция обязательно будет возвращена в исходное состояние во избежание последующих ошибок и наличия несогласованных объектов-фантомов.

Возьмем еще один пример, связанный с ошибками во время выполнения транзакций. Вы выполняете какое-либо изменение в базе данных Active Directory, оно записывается в журнал транзакции, а затем в тот момент, когда страница базы данных помещалась в память контроллера домена, произошел сбой. Например, сам сервер отвалился, упал BSOD – да не важно, что именно случилось, главное – операция полностью не была завершена. В таком случае после того, как контроллер домена будет перезапущен, он будет проверять журналы транзакции на наличие изменений, которые еще не были внесены в базу данных. Для того чтобы можно было узнать о такой дельте в кратчайшие сроки, контроллер домена использует файлы контрольных точек. Так как в этом файле можно обнаружить информацию о том, какие транзакции из журнала были внесены в базу данных, то если изменения между базой данных и журналами транзакции присутствуют, они будут внесены в базу данных контроллера домена Active Directory.

В наше время, когда затрагивают такой момент, как восстановление удаленных объектов Active Directory, большинство Windows-администраторов сразу подразумевают работу с корзиной Active Directory. Однако обратите внимание на то, что корзина Active Directory появилась относительно недавно (а именно с выходом Windows Server 2008 R2), а необходимость в восстановлении удаленных объектов была всегда, и на результаты подобных механических ошибок нужно было всегда моментально реагировать. Однако прежде тем как мы начнем искать удаленные объекты и будем пробовать их восстановить, следует узнать о том, что же вообще происходит с объектами доменных служб Active Directory после удаления.

После того как вы выбираете команду удаления для любого объекта Active Directory, скажем, учетной записи пользователя, такую учетную запись невозможно будет локализовать ни в оснастках Active Directory, ни средствами Windows PowerShell, однако от такого объекта остаются некоторые останки, которые принято называть объектами-захоронениями. Для того чтобы объект был назначен объектом-захоронением, у атрибута isDeleted удаляемого объекта определяется значение true, и большинство атрибутов такого объекта удаляются. К тем атрибутам, которые после выполнения всех этих действий остаются, можно отнести глобальный уникальный идентификатор GUID, номер последовательного обновления USN (Update Sequence Number), имя, а также SID. После того как такой объект был помечен как удаленный, он перемещается в контейнер CN=Deleted Objects.

Несмотря на то, что, как я уже упомянул ранее, такой объект невозможно найти средствами привычных для вас оснасток, такая устаревшая запись реплицируется и хранится на каждом контроллере домена в рамках всего домена вплоть до завершения жизненного цикла такой записи. Для чего это нужно? Здесь все просто: во избежание конфликтных ситуаций, каждый контроллер домена должен знать, что такой объект был удален.

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

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

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

Если же все проверки прошли без проблем и уже определено, что объект действительно может быть удален, тогда доменные службы начинают переводить объект в состояние объекта-захоронения. Сначала Active Directory удаляет ненужные атрибуты объекта, оставляя лишь около 40-ка атрибутов, в том числе те атрибуты, которые по схеме должны сохраняться у объекта-захоронения. После этого изменяется относительное различающееся имя RDN объекта на CN=<old RDN>ADEL:<objectGUID>, где A означает символ ASCII перевода строки, а <objectGUID> – это objectGUID, выраженный строкой. Это RDN-имя немного ниже вы еще увидите. Атрибут lastKnownParent затем устанавливается на DN-имя родительского контейнера объекта, а атрибут isDeleted, как уже было упомянуто ранее, устанавливается в значение «true». Active Directory затем удаляет из объекта все атрибуты ссылок на предыдущий и следующий элемент. И, в завершение, если в атрибуте systemFlag объекта не установлен бит «disallow move on delete», Active Directory перемещает объект в контейнер CN=Deleted Objects.

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

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

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

Рис. 1. Атрибуты tombstoneLifetime и garbageCollPeriod

Потихоньку будем возвращаться непосредственно к восстановлению объектов доменных служб. К таким, на данный момент устаревшим, методам восстановления удаленных объектов можно отнести:

• Полномочное восстановление (принудительное, авторитативное восстановление);
• Восстановление объектов, с использованием консольной утилиты ADRestore от Sysinternals;
• Восстановление объектов-захоронений (восстановление из Deleted Objects).

Рассмотрим каждый такой метод по порядку.

Полномочное восстановление

Полномочное восстановление – это самый первый метод восстановления случайно удаленных объектов Active Directory, которым пользовался если не каждый, то большинство администраторов уж точно. Полномочное восстановление предоставляет администраторам гарантию того, что после восстановления удаленного объекта, будь то одна учетная запись или же целое подразделение со вложенными удаленными элементами, это отреплицируется на остальные контроллеры домена, и после следующей плановой репликации вы не столкнетесь с какими-либо несоответствиями или проблемами. Получается, у вас восстанавливается Active Directory из созданной до удаления объектов резервной копии, после чего восстановленные данные принудительно реплицируются на все остальные контроллеры домена. Такая вынужденная репликация для восстановленной информации выполняется при помощи порядкового номера обновления (Update Sequence Number, USN).

NTDSUTIL совместно с USN также увеличивает номер версии каждого атрибута на 100 000 за каждый день промежутка между созданием архива и его восстановлением специально для того, чтобы восстановленный объект стал полномочной копией для всего домена. Если же в наличии не имеется атрибутов, которые были изменены более чем 100 000 раз в день, что, между прочим, крайне маловероятно, номер версии восстановленных атрибутов будет значительно больше номера версии, хранящейся на других контроллерах домена. Как следствие, полномочное восстановление реплицирует их на другие контроллеры. Обратите внимание на то, что другие объекты, которые были восстановлены из резервной копии неполномочно, будут обязательно заменены актуальными данными с других контроллеров домена.

Несмотря на название, полномочное восстановление объектов их не «восстанавливает», при этом Active Directory просто реплицирует объекты на другие контроллеры. Для этого NTDSUTIL присваивает следующий доступный USN локальному USN атрибутов объекта. Это приводит к тому, что объект будет отправлен для репликации партнерам при следующем сеансе синхронизации. Обязательно обратите внимание на тот факт, что по завершению процесса полномочного восстановления у восстановленных объектов не восстановится должным образом членство в группах, поэтому нужно будет уделить еще часть времени решению этой проблемы.

Посмотрим, что нужно сделать для полномочного восстановления учетной записи пользователя. В качестве примера будет восстанавливаться удаленная учетная запись пользователя Вячеслава Овечкина. Сейчас для примера будет не только восстановлена учетная запись, но для полноты картины еще и будет сделана резервная копия. Итак:

1. Так как для данного метода должна быть создана резервная копия, а системный компонент, позволяющий управлять резервными копиями по умолчанию не установлен, его нужно будет проинсталлировать. Для этого в диспетчере серверов вызывается мастер добавления ролей и компонентов, где на странице с компонентами следует установить флажок на компоненте «Система архивации данных Windows Server» (Windows Server Backup), как показано ниже:

   

   Рис. 2. Добавление компонента системы архивации данных

2. Следующим делом создается резервная копия. Для этого нужно открыть консоль Windows PowerShell, и выполнить команду WBAdmin start systemstatebackup –backuptarget: и указать путь для резервной копии, например, D:. Учтите, вы не можете использовать в качестве диска, на котором будет размещаться резервная копия, свой системный том. Для подтверждения старта создания резервной копии следует ввести Y. Обратите внимание на то, что конечная папка с резервной копией будет достаточно объемной. Как видно на следующей иллюстрации, у меня пошел процесс создания резервной копии:

   

   Рис. 3. Создание резервной копии

3. Удаляется учетная запись Вячеслава Овечкина, и контроллер домена перезагружается в режиме восстановления служб каталогов (Directory Services Restore Mode, DSRM) из перечня методов загрузки, вызываемого из загрузочного меню по нажатию на клавишу F8. Здесь нужно будет выполнять вход в систему с паролем DSRM, который вы задавали во время конфигурации сервера в качестве контроллера домена;
4. Первым делом после перезагрузки сервера в режиме восстановления служб каталогов следует идентифицировать версию резервной копии, из которой будет восстанавливаться удаленная ранее пользовательская учетная запись. Для этого следует в консоли Windows PowerShell выполнить команду wbadmin get versions –backuptraget: и здесь указывается путь к сохраненным резервным копиям, например, как в данном примере, D:. После вывода команды следует обратить внимание на идентификатор версии. Его следует указать в следующей команде. В данном случае у меня отображается идентификатор 08/11/2014-13:23;
5. Далее происходит процесс восстановления. Выполняется команда WBAdmin start systemstaterecovery –version: идентификатор –backuptarget:d:. Как и в случае с созданием бэкапа, следует подтвердить восстановление. Процесс восстановления изображен ниже:

   

   Рис. 4. Восстановление из резервной копии

6. По завершению восстановления из резервной копии можно перейти непосредственно к самому полномочному восстановлению. Для начала в уже открытой консоли Windows PowerShell следует запустить утилиту NTDSUTIL. Вводим ntdsutil;
7. В строке приглашения следует активировать текущий экземпляр ntds, для чего вводится activate instance ntds;
8. Далее следует перейти к контексту полномочного восстановления. Для этого в консоли вводится authoritative restore. Чтобы восстановить объект, достаточно ввести restore object и указать DN-имя восстанавливаемого объекта. В данном примере таким именем выступает “CN=Вячеслав Овечкин,OU=Пользователи,DC=biopharmaceutic,DC=local”. Между прочим, вы можете выполнять полномочное восстановление не только конкретных объектов, но и целых подразделений. Для этого вместо параметра object следует указать subtree. Мастер отобразит диалог с подтверждением восстановления.
9. По завершению полномочного восстановления вы увидите расположение текстового и, в случае необходимости, LDIF-файла, предназначенного для восстановления некоторых ссылочных объектов, которые получится восстановить при помощи этого метода. В том случае, если полномочное восстановление выполнялось на сервере глобального каталога, у вас будет сгенерировано несколько LDIF-файлов: один файл для локального домена, а другой – для каждого домена, в котором восстановленный пользователь был членом универсальной группы. Сразу отмечу, что восстанавливаются далеко не все связи. Процесс полномочного восстановления отображен ниже:

   

   Рис. 5. Полномочное восстановление

10. Теперь нужно выйти из утилиты Ntdsutil и перезагрузить сервер в нормальном режиме;
11. Чтобы выполнить принудительную репликацию для всех партнеров репликации и восстановить членство в группах, достаточно выполнить в консоли Windows PowerShell команду repadmin /syncall ИМЯ_DC /a /d /A /P /q. Контроллер домена следует указывать тот, на котором выполнялось восстановление удаленных объектов. После этого для восстановления членства выполните команду ldifde –I –k –f имя_файла, который был сгенерирован при помощи утилиты Ntdsutil во время полномочного восстановления. Данная команда обязательно должна выполняться только после репликации полномочного восстановления для всех партнеров репликации.

Восстановление при помощи утилиты ADRestore

Второй метод, который мы сейчас рассмотрим, с натяжкой можно назвать штатным, так как объекты будут восстанавливаться при помощи утилиты Марка Руссиновича, которая называется ADRestore. Она абсолютно бесплатная, и ее можно загрузить по адресу http://technet.microsoft.com/en-us/sysinternals/bb963906.aspx. Как и в случае со всеми утилитами Sysinternals, для работы с ADRestore никакой установки не требуется, достаточно только скопировать ее в какое-то удобное расположение. Использование данной утилиты удобнее предыдущего метода тем, что вам не нужно перезагружать контроллер домена в режиме восстановления доменных служб и не нужно тратить много времени на восстановление контроллера домена из резервной копии. В определенном смысле это весомое преимущество. Что же собой представляет данная утилита?

Текущую утилиту можно использовать в двух режимах: для поиска и для восстановления удаленных объектов. В том случае, если вы запустите данную утилиту без параметров, вам будет предоставлен перечень всех объектов-захоронений, которые были обнаружены в контейнере Deleted Objects, о котором шла речь немного ранее. В том случае, если вы рядом с наименованием утилиты укажите имя потенциально восстанавливаемого объекта, утилита покажет все совпадения, будь то учетная запись или удаленное подразделение. Утилита при поиске использует поисковые фильтры LDAP CN=*Keyword* и OU=*Keyword*, однако в случае с кириллическими именами вы обнаружите некоторые проблемы, о которых немного ниже.

В качестве примера создается еще одна учетная запись Вячеслава (уже с другой фамилией), и оба Вячеслава удаляются из Active Directory. Также создается пользователь Slava LastName и удаляется.

Теперь попробуем найти наших пользователей среди объектов-захоронений. Для этого выполняются две команды: adrestore Слав и adrestore Slav. Как видите на следующей иллюстрации, в случае с кириллическими именами утилита для таких объектов не отображает distinguishedName (между прочим, это же заметно и в случае с OU для пользователя, который был добавлен на английском языке):

Рис. 6. Поиск объектов захоронений при помощи ADRestore

Чтобы восстановить найденные объекты, нужно лишь указать перед именем восстанавливаемой учетной записи параметр –r (сокращенное от restore). Утилита выдаст запрос о восстановлении и восстановит объект непосредственно в то подразделение, которое было указано в атрибуте lastKnownParent объекта-захоронения. Иначе говоря, у вас нет никакого способа указать другое подразделение при помощи данной утилиты. В том случае, если вы будете восстанавливать сразу несколько объектов (как в случае с кириллическими Вячеславами), нужно будет несколько раз подтвердить процесс восстановления. После выполнения восстановления такие объекты будут отключены.

Восстановление объектов-захоронений средствами LDP

Переходим к самому сложному методу восстановления объектов-захоронений – восстановлению при помощи утилиты LDP. LDP – это служебная утилита, предназначенная для работы с доменными службами Active Directory, от которой многие системные администраторы стараются держаться подальше. Несмотря на свой устрашающий вид, по свой архитектуре она чем-то похожа на штатный проводник Windows. В свое время администраторам не нужно было даже знать о данном средстве, так как изначально LDP была разработана группой разработчиков Active Directory специально для тестирования кода протокола LDAP. Но тем не менее данная утилита представляет собой отличное средство для выполнения различных нештатных задач при работе с доменными службами Active Directory.

Несмотря на то, что раньше объекты-захоронения были попросту невидимыми для обычных операций с доменными службами, существовала возможность локализации объектов-захоронений Active Directory, при помощи поисковых операций LDAP, а также специфических расширений LDAP-протокола, которые называются элементами управления. Согласно официальной терминологии, элементы управления представляют собой механизм, определяемый в стандарте LDAP, и применяются для расширения LDAP-протокола с целью обеспечения дополнительных функциональных возможностей помимо тех, которые определены в стандарте LDAP, сохраняя при этом совместимость с другими программами, которые поддерживают LDAP. С выходом операционной системы Windows Server 2012 R2 Active Directory уже поддерживает 37 элементов управления, включая элемент управления «LDAP_SERVER_SHOW_DELETED_OID» (Возврат удаленных объектов). Этот элемент управления используется для расширения операции поиска LDAP и возвращает удаленные объекты. Подробнее об элементах управления вы можете почитать в статье LDAP Extended Controls на MSDN.

Потихоньку разберемся с утилитой LDP по ходу действия. Сейчас снова удалим учетные записи обоих Вячеславов и попробуем их найти и восстановить при помощи данной утилиты. Итак:

1. Из диалогового окна «Выполнить» (Run) откройте утилиту «LDP». Для того чтобы вы могли локализовать и впоследствии восстановить объект-захоронение, выберите из меню «Подключение» (Connection) опцию «Подключить» (Connect), в отобразившемся диалоговом окне укажите имя контроллера домена (в том случае, если вы открыли инструмент непосредственно на контроллере, не обязательно что-либо вводить), а затем нажмите на кнопку «OK»:

   

   Рис. 7. Подключение к контроллеру домена

2. Следующим предварительным этапом будет привязка средства LDP к административным учетным данным. Для того, чтобы можно было пройти проверку подлинности на контроллере домена, следует из меню «Подключение» (Connection) выбрать опцию «Привязка» (Bing) и, в том случае, если вы выполнили вход не под административной учетной записью (пользователь с правами администратора домена или администратора предприятия), нужно установить переключатель на опцию привязки с учетными данными и ввести таковые. В противном случае можно оставить все без изменений и нажать на кнопку «ОК»;
3. Теперь, чтобы просмотреть содержимое контейнера Deleted Objects с соответствующими объектами-захоронениями, вам нужно воспользоваться вышеупомянутыми элементами управления LDAP и осуществить поиск в соответствующем контейнере. Такие сложности получаются по той причине, что сам контейнер в доменных службах отмечен как удаленный, и получить к нему непосредственный доступ вы не можете. Следовательно, разверните меню «Обзор» (Browse) и выберите опцию «Найти» (Search);
4. В отобразившемся окне поиска вам нужно указать контейнер, в котором будет выполняться поиск, а также сам критерий поиска. Для этого в текстовом поле «Базовое DN» (Base DN) введите путь к самому контейнеру, то есть CN=Deleted Objects,DC=biopharmaceutic,DC=local, а в поле «Фильтр» (Filter) укажите требуемый класс. Изначально поиск производится по всем объектам, так как в качестве поискового класса установлено * — все объекты, которые обладают атрибутом objectClass. Ввиду того, что после удаления объекта такой класс остается у пользовательских учетных записей, и мы точно знаем, что нужно найти учетную запись пользователя, можно смело изменять фильтр на objectClass=user.

   Также стоит обратить внимание на группу «Область» (Scope). При помощи данной группы вы можете указать глубину поиска. Например, по умолчанию выбран одноуровневый поиск. Это означает, что поиск объектов будет выполняться непосредственно в том контейнере, который был указан в качестве базового DN. Если же вам нужно искать объекты еще и во встроенных контейнерах, можно установить переключатель на опцию «Поддерево» (Subtree). Так как в данном примере контейнер Deleted Objects не обладает встроенными контейнерами, можно оставить опцию, установленную по умолчанию.

   Так как нам нужно, чтобы поиск вернул только удаленные объекты, то есть использовать элемент управления LDAP возвращения удаленных объектов, параметры поиска следует подкорректировать под свои нужды. Для этого нажмите на кнопку «Параметры» (Options). Поскольку необходимо указать элемент расширения, в диалоговом окне параметров поиска нужно выбрать тип поиска вызова «Расширенный» (Extended). Только этот тип поиска работает с элементами управления. Для выбора конкретного элемента управления нажмите на кнопку «Элементы управления» (Controls).

   В отобразившемся, третьем по счету, диалоговом окне из раскрывающегося списка «Предопределенная загрузка» (Load Predefined) выберите элемент управления «Return Deleted Objects» и, в том случае, если области активных элементов управления не появился идентификатор объекта (OID) 1.2.840.113556.1.4.417, нажмите на кнопку «Вернуть» (Check in). При выборе элемента управления будьте очень внимательны, так как при ошибочном выборе вам может понадобиться несколько раз нажать на кнопки «Извлечь» (Check Out) и «Вернуть». Все три диалоговых окна поиска изображены на следующей иллюстрации:

   

   Рис. 8. Параметры поиска LDP

5. После того как все параметры будут предопределены, нажмите на «ОК» в каждом диалоговом окне и выполните поиск. Как видно на следующей иллюстрации, поиск мне вернул три объекта-захоронения: два для господина Овечкина, так как эта учетная запись до первого восстановления создавалась и удалялась дважды, а также один для другого Владислава, который специально в качестве теста был удален.

   Сразу видно, что одна из учетных записей Овечкина имеет DN CN=Вячеслав ОвечкинADEL:5a3cf2e7-de7b-4c94-aa84-516d34103e0c,CN=Deleted Objects,DC=biopharmaceutic,DC=local, а в качестве значения атрибута objectClass фигурирует user, что означает, что мы уже обнаружили удаленную учетную запись. Это различающееся имя для восстановления нас и интересует. На вывод результатов можете посмотреть на этом изображении:

   

   Рис. 9. Результаты поиска удаленных объектов

6. Чтобы восстановить удаленный объект при помощи средства LDP, нужно для объекта-захоронения изменить значения нескольких атрибутов. Для этого проверяется, выбран ли элемент управления возвратом удаленных объектов. Нужно выбрать из меню «Параметры» (Options) опцию «Элементы управления» (Controls), а потом в уже известном вам диалоговом окне добавить к активным элементам управления элемент Return deleted objects;
7. Далее из меню «Обзор» (Browse) выберите опцию «Изменить» (Modify). В диалоговом окне изменения введите в текстовое поле «Различающееся имя (DN)» (DN) имя восстанавливаемого объекта-захоронения (оно должно полностью совпадать с именем, которое отображается в списке возвращенных результатов). Переходим к атрибутам. Сейчас нужно удалить атрибут isDeleted, свидетельствующий о том, что объект удален, а также заменить атрибут distinguishedName желаемым различающимся именем восстановленного объекта-захоронения. Следовательно, в текстовое поле «Атрибут» (Attribute) вводим имя атрибута isDeleted, а затем в группе «Операция» (Operation) устанавливаем переключатель на «Удалить» (Delete) и нажимаем на кнопку «Ввод» (Enter). После этого в текстовое поле атрибута вводится имя distinguishedName, в поле «Значения» (Values) – первоначальное различающееся имя объекта, например, «CN=Вячеслав Овечкин,OU=Пользователи,DC=biopharmaceutic,DC=local», и устанавливается переключатель на опцию «Заменить» (Replace). Далее снова нужно нажать на кнопку «Ввод» (Enter).

   Так как нам необходимо, чтобы отработал элемент управления изменения удаленных объектов, нужно снизу установить флажок на опцию «Расширенный» (Extended), после чего можно нажимать на кнопку «Выполнить» (Run). Данное диалоговое окно изображено на следующей иллюстрации:

   

   Рис. 10. Диалоговое окно изменения

8. В окне результатов должно отобразиться приблизительно следующее:————***Call Modify…ldap_modify_ext_s(ld, ‘CN=Вячеслав ОвечкинADEL:008d8e3e-6da4-4b2f-a203-a7da8c5627bf,CN=Deleted Objects,DC=biopharmaceutic,DC=local’,[2] attrs, SvrCtrls, ClntCtrls);

   Modified «CN=Вячеслав ОвечкинADEL:008d8e3e-6da4-4b2f-a203-a7da8c5627bf,CN=Deleted Objects,DC=biopharmaceutic,DC=local».

   ————

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

Как я уже упоминал раньше, при работе с текущим методом функция восстановления представляет собой специальную операцию протокола LDAP по изменению, которая должна включать две определенные модификации атрибутов, а именно: следует не просто установить для атрибута isDeleted значение «false», а полностью его удалить, а также переместить объект в другое подразделение. В отличие от рассмотренной ранее утилиты Руссиновича, в данном случае вы можете указать любое расположение для восстанавливаемого объекта захоронения.

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

Также помните, что восстановление объекта схемы не допускается ни при каких обстоятельствах. В принципе, это не сильно страшно, так как штатными и допустимыми корпорацией Microsoft методами вы этого не сделаете. Ну а если уже сделали, то тут вам Microsoft вряд ли поможет.

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

• Удалит атрибут isDeleted;
• objectCategory настроит на наиболее конкретный objectClass, который указан в объекте-захоронении;
• а также изменит RDN и объект запишет в новое подразделение.

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

К одной из основных проблем после устаревших методов восстановления можно отнести то, что для объекта пользователя не восстанавливается членство пользователя в группах. Эта проблема обусловлена тем, что список членства объекта группы содержит отличительные теги имен (Distinguished Name Tag, DNT) для членов группы. Отношения членства сохраняются и реплицируются при помощи атрибута члена объектов групп (ссылки вперед), а не атрибута memberOf пользователя (ссылки назад). Ссылка назад создается в объекте пользователя для обращения к группе, поддерживается доменными службами и не может изменяться администратором. Так как такие ссылки не подлежат репликации, проблема заключается в том, чтобы найти членство пользователей в старой группе и, узнав это, правильно их восстановить.

Корпорация Майкрософт постоянно вносит улучшения в процесс восстановления членства в группах, поэтому используемая методика зависит от версии Active Directory.

Определить членство пользователя в старых группах достаточно просто: посмотрите атрибут ссылки назад на восстановленном контроллере домена — в данном случае это атрибут memberOf объекта пользователя. Атрибут memberOf будет содержать все сведения о членстве в локальных и глобальных группах домена пользователя. И если в списке группового членства содержится член, не принадлежащий к локальному домену, в таком случае в доменных службах создается фантомный объект, содержащий objectGUID, objectSid и различающееся имя нового участника. Таким образом, создается идентификатор различающегося имени, который может храниться в атрибуте членства в группе. Контроллер домена, обладающий ролью FSMO мастера инфраструктуры, проверяет элементы в своей таблице данных по отношению к глобальному каталогу и, если выясняется, что объект перемещен, переименован или удален, обновляет фантомные объекты в таблице данных, а также реплицирует изменения на другие контроллеры домена.

Помимо описанных трех методов восстановления удаленных объектов доменных служб еще существует такое понятие, как неполномочное восстановление. Неполномочное восстановление (неавторитативное, непринудительное восстановление), по большому счету, представляет собой восстановление удаленных объектов из резервной копии. Оно было рассмотрено в разделе полномочного восстановления до пятого пункта включительно. То есть после того, как утилита wbadmin вам предложит перезагрузить компьютер, вы просто его перезагружаете и не переходите к работе с утилитой ntdsutil. Так как данный метод не наилучшим образом подходит для восстановления удаленных пользовательских учетных записей, он отдельно в статье не рассматривался, а о резервных копиях более подробно речь пойдет в другой статье по доменным службам Active Directory.

А что изменилось?

С устаревшими методами восстановления удаленных объектов Active Directory, полагаю, мы немного разобрались. Пора двигаться дальше. Начиная с операционной системы Windows Server 2008 R2, корпорация Microsoft предоставляет системным администраторам, обслуживающим доменные службы Active Directory, новую функциональную возможность восстановления удаленных объектов. Эта возможность решает чуть ли не все проблемы, которые были связаны с принудительным восстановлением, а также с реанимацией отметок полного удаления.

Такая возможность, естественно, как знает практически каждый администратор доменных служб, называется корзиной Active Directory. Согласно официальному определению, корзина Active Directory позволяет вам существенно уменьшить время простоя службы каталогов, тем самым улучшая возможность сохранения и восстановления случайно удаленных объектов в доменных службах Active Directory без какой-либо необходимости выполнения устаревших операций, к которым относятся восстановления данных Active Directory из архивов, перезапуск доменных служб Active Directory или перезагрузка контроллеров домена. Следовательно, если вы включаете корзину Active Directory, то все ссылочные и нессылочные атрибуты удаленных объектов, о которых речь шла немного ранее, сохраняются, а сами объекты вы уже сможете полностью восстановить, причем после восстановления, в отличие от всех предыдущих методов, они будут в том же состоянии, в коем они находились перед удалением. Скажем, вы удалили учетную запись пользователя, который состоял в 5 различных группах безопасности и у него было настроено большинство атрибутов. Так вот, после восстановления такого объекта все членства в группах, соответствующие права доступа, а также все атрибуты, которыми был наделен такой пользователь, все еще будут действительны, и вам не нужно будет тратить свое время на восстановление таких «связей» и значений.

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

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

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

Чтобы было немного понятнее: утилизированный объект в современных серверных операционных системах сохраняет точно такой же набор атрибутов, что и объект с отметкой полного удаления в операционных системах Windows Server 2003 и Windows Server 2008. Чтобы изменить набор атрибутов, сохраненный в утилизированном объекте, вам нужно установить для атрибута searchFlags в схеме Active Directory значение 0x00000008.

Так как появилось новое значение, появился и новый атрибут. Сейчас за время существования удаленного объекта отвечает значение атрибута msDS-deletedObjectLifetime. Время существования утилизированного объекта определяется значением рассмотренного ранее устаревшего атрибута tombstoneLifetime. По умолчанию для атрибута msDS-deletedObjectLifetime определяется значение NULL, означающее, что время существования удаленного объекта должно совпадать со временем, указанным для утилизированного объекта. Естественно, если вы укажете для этого атрибута любое значение, доменные службы моментально переназначат время для удаленных объектов. Изначально может быть непонятно, что же это за период, так как по умолчанию для атрибута tombstoneLifetime также установлено значение NULL. Здесь просто следует помнить, что если такой атрибут обладает значением NULL, то время существования утилизированного объекта просто составляет 180 дней. В том случае, если вас такое время существования объектов не устраивает, вы всегда можете при помощи реактора ADSI изменить значения для атрибутов msDS-deletedObjectLifetime и tombstoneLifetime.

Для того чтобы определить, можно ли использовать резервную копию базы данных доменных служб Active Directory для успешного восстановления ранее удаленного объекта с помощью полномочного восстановления, следует проверить значение времени существования результирующего архива в лесу Active Directory. Значение времени существования результирующего архива в лесу Active Directory задает число дней, в течение которых любая резервная копия, взятая в этом лесу, позволяет наиболее эффективно восстановить среду Active Directory. Значение времени существования результирующего архива — это наименьшее значение из двух атрибутов msDS-deletedObjectLifetime и tombstoneLifetime. Поскольку, как мы уже выяснили, по умолчанию значения обоих атрибутов 180 дней — значение времени существования результирующего архива будет составлять 180 дней.

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

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

Требований для полноценного функционирования корзины Active Directory не так уж и много. Прежде всего, вы должны убедиться в том, что режим работы леса Active Directory сконфигурирован как минимум под Windows Server 2008 R2. В этом лесу все контроллеры домена должны работать как минимум на этой же серверной операционной системе, а также, если у вас развернуты службы AD LDS, вам следует удостовериться в том, что режим работы набора конфигурации работает на уровне Windows Server 2008 R2 или выше.

Проверяем работоспособность корзины Active Directory

В общих чертах с тем, что собой представляет корзина Active Directory, полагаю, мы разобрались, поэтому стоит переходить к практической части. Далее вы узнаете, как при помощи «Центра администрирования Active Directory» можно включить корзину (по умолчанию она отключена), а также о том, как можно при помощи данной функциональной возможности восстановить удаленную учетную запись нашего многострадального Вячеслава Овечкина. Итак:

1. Откройте консоль «Центр администрирования Active Directory» (Active Directory Administrative Center) и перейдите в области навигации к своему домену. Когда корзина Active Directory была впервые представлена на всеобщее обозрение, в Windows Server 2008 R2, по сути, нельзя было работать с корзиной средствами графического интерфейса. Теперь же, как вы видите на следующей иллюстрации, включить корзину вы можете непосредственно из области задач, нажав на кнопку «Включить корзину» (Enable Recycle Bin) и удовлетворительно ответив на всплывающее предупреждение, что сейчас и будет сделано:

   

   Рис. 11. Включение корзины Active Directory средствами графического интерфейса

2. Чтобы вы могли воспользоваться всеми преимуществами корзины, в центре администрирования Active Directory вам будет отображено сообщение, свидетельствующее о том, что нужно обновить консоль и подождать, пока изменения в конфигурации доменных служб отреплицируются на все остальные корпоративные контроллеры домена. После обновления консоли вы обнаружите, что в области просмотра появился новый контейнер – Deleted Objects, который, собственно, и будет использоваться для восстановления удаленных объектов;
3. Настало время удалить учетную запись пользователя. Для этого в области навигации выбирается требуемое подразделение, локализуется удаляемый пользователь, например, наш Вячеслав Овечкин, и из контекстного меню выбирается команда удаления объекта доменных служб;
4. Находясь в этой же консоли, перейдите к контейнеру Deleted Objects и локализуйте удаленную учетную запись. В том случае, если у вас в этом контейнере много удаленных объектов, вы всегда можете воспользоваться гибкими возможностями фильтрации. К сожалению, в графическом интерфейсе вы не можете просматривать все атрибуты удаленного объекта, так как доступны лишь его имя, дата удаления, атрибут «Last known parent», а также GUID. Однако если вы выберете в качестве фильтра номер телефона или должность и попробуете локализовать пользователя по этим критериям, поиск завершится удачно, и вы сможете быстро локализовать восстанавливаемого пользователя. Итак, выделите учетную запись восстанавливаемого объекта и для восстановления в подразделение, в котором изначально находился пользователь, из контекстного меню выберите команду «Восстановить» (Restore). В том случае, если вы хотите изменить целевое подразделение, выберите команду «Восстановить в…» (Restore To…) и в отобразившемся диалоговом окне выберите необходимое подразделение. Сам процесс восстановления изображен на следующей иллюстрации:

   

   Рис. 12. Восстановление удаленного объекта Active Directory средствами корзины

5. Объект моментально переместится в целевое подразделение и будет обладать всеми атрибутами и правами, которые были у него настроены еще до удаления.

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

Управляем корзиной средствами Windows PowerShell

Средства графического интерфейса, это, без сомнений, хорошо, но так как речь шла о том, что в Windows Server 2008 R2 можно было управлять корзиной только средствами Windows PowerShell, также неплохо было бы знать и о том, каким образом можно работать с этой функциональной возможностью средствами данной оболочки командной строки.

Прежде всего, включение корзины. Для того чтобы включить данную функциональную возможность, вам нужно в консоли PowerShell ввести:

Enable-ADOptionalFeature -Confirm:$false -Identity:»CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=biopharmaceutic,DC=local» -Scope:»ForestOrConfigurationSet» -Target:»biopharmaceutic.local»

Чтобы найти объект в контейнере с удаленными объектами, вы должны воспользоваться командлетом Get-ADObject, где в параметре –SearchBase нужно указать CN данного контейнера, то есть «CN=Deleted Objects,DC=biopharmaceutic,DC=local», а в качестве фильтра – свой поисковый запрос. Например, чтобы реализовать поиск по последнему подразделению, в котором находился пользователь, следует указать -Filter {lastKnownParent –eq ‘OU=Пользователи,DC=biopharmaceutic,DC=local’}. Также, так как вы выполняете поиск среди удаленных объектов, вам следует еще включить в данную команду параметр –IncludeDeletedObjects.

Далее вы можете либо после вывода команды найти восстанавливаемый объект и запомнить его objectGUID, чтобы следующей командой Restore-ADObject его восстановить, добавив таковой в качестве значения параметра –Identity, либо после первой команды вы можете воспользоваться конвейером и указать дополнительно командлет Restore-ADObject без каких-либо параметров. В первом случае команды и вывод консоли будут выглядеть следующим образом:

Get-ADObject –SearchBase «CN=Deleted Objects,DC=biopharmaceutic,DC=local» -Filter {lastKnownParent –eq ‘OU=Пользователи,DC=biopharmaceutic,DC=local’} –IncludeDeletedObjects

Restore-ADObject -Identity:»008d8e3e-6da4-4b2f-a203-a7da8c5627bf»

Рис. 13. Использование Windows PowerShell для восстановления удаленных объектов средствами корзины Active Directory

Заключение

В этой статье вы узнали о том, что происходит с объектами Active Directory после их удаления, а также о методах их восстановления. Было рассмотрено полномочное восстановление объектов и восстановление членства в группах, восстановление средствами утилиты от Sysinternals, которая называется ADRestore, восстановление средствами инструмента LPD.exe, а также при помощи корзины Active Directory, причем как средствами графического интерфейса, так и при помощи Windows PowerShell. Более того, было рассказано о таких понятиях, как объекты-захоронения, логически удаленные объекты и утилизированные объекты. А приходилось ли Вам восстанавливать удаленные объекты и к какому способу Вы прибегали?