Диагностика

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

Исправление

Соответственно первое, что мы сделали, это прописали на оставшихся двух контроллерах домена в качестве DNS серверов 127.0.0.1 и второй контроллер. Затем при помощи утилиты ntdsutil и команды seize мы произвели захват fsmo ролей на один из контроллеров домена. После того, как все роли были перенесены, мы попытались назначить оставшиеся контроллеры домена серверами глобального каталога, но галка «Global Catalog» в свойствах NTDS Settings в оснастке Active Directory Sites and Services была неактивна. Проанализировав записи DNS-серверов, мы обнаружили, что в разделе Forward Lookup Zones\_msdcs.domain.ru\gc\_sites, отсутствовала запись Default-First-Site-Name, а именно в этом сайте находились корневые контроллеры домена. Мы вручную создали запись Default-First-Site-Name\_tcp, где создали 2 SRV-записи, ссылающиеся на 2 оставшихся контроллера домена:

_ldap Service Location (SRV) [0][100][3268] dc2.domain.ru
_ldap Service Location (SRV) [0][100][3268] dc3.domain.ru

После перезагрузки контроллеров домена, нам удалось поставить галку «Global Catalog» для каждого из контроллеров.

К сожалению сейчас не помню всех подробностей, но были ещё какие-то проблемы с записями в DNS, часть из которых была решена утилитой netdiag /fix. Кроме того, на определённом этапе восстановления структуры DNS, галка «Global Catalog» стала активной, но тем не менее, мы обнаружили, что на контроллерах домена служба lsass не слушает порт 3268. И проблема решилась только после того, как мы вручную прописали srv-записи описанным выше способом.

На данном этапе аутентификация  всех пользователей в центральном офисе заработала. Exchange Server также успешно запустился и заработал.

Восстановление репликации

Осталось решить проблему с репликацией 80 дочерних доменов. Топология репликации была таковой, что все дочерние филиалы реплицировались через Default-First-Site-Name. Проблема оказалось в том, что вышедший из строя в главном офисе контроллер домена был назначен единственным «preferred bridgehead» в данном сайте. Таким образом, ни один из 80 дочерних контроллеров домена даже не пытался начать репликацию ни с одним из оставшихся контроллеров домена основного офиса. Кроме того, ниодин из дочерних контроллеров домена более не мог узнать ни о каких изменениях в конфигурации главного сайта, ни о появлении новых bridgehead-ов, ни об удалении старого контроллера домена, в общем, ни о чем!

По умолчанию топологией репликации управляет служба KCC, она выстраивает связи между контроллерами домена в разных сайтах. Если по каким-либо причинам один из контроллеров домена перестаёт отвечать, то связи перестраиваются автоматически. Но в случае, когда bridgehead настроен вручную, служба KCC связи не перестраивает. В центральном филиале мы отключили ручное назначение bridgehead-ов, осталось только рассказать об этом дочерним филиалам.

Мы составили некий алгоритм по восстановлению репликации с каждым дочерним филиалом:

1) Нужно зайти на контроллер домена каждого дочернего филиала, запустить оснастку Active Directory Sites and Services, раскрыть \сайт соответствующего филиала\Servers\контроллер домена\NTDS Settings, и удалить связи, ссылающиеся на удалённый контроллер домена.

2) Затем нажать правой кнопкой на NTDS Settings, нажать New Active Directory Connection, и выбрать из списка любой из двух оставшихся в сайте Default-First-Site-Name контроллеров домена.

3) Затем проделать тоже самое на контроллере домена центрального филиала, желательно на том же, который мы выбрали в предыдущем шаге.

4) Далее сначала в дочернем филиале нажать по вновь созданной связи и выбрать Replicate now. Подождав несколько минут, убедиться что репликация прошла успешно, из Default-First-Site-Name должен исчезнуть удалённый контроллер домена центрального филиала.

5) Далее лучше удалить вручную созданные связи с обоих контроллеров домена и перезапустить службу Kerberos Key Distribution Center, спустя какое-то время (около 15 мин) служба KCC автоматически сгенерирует связь между филиалом и сайтом центрального офиса.

Соответственно данную процедуру  пришлось проделать вручную с каждым из 80 дочерних филиалов!

Восстановление репликации с устаревшими контроллерами

При восстановлении репликации описанным выше способом на некоторых контроллерах домена мы столкнулись с ошибкой:

The naming context is in the process of being removed or is not replicated from the specified server.

 Скорее-всего данная ошибка была вызвана тем, что репликация данных контроллеров не производилась уже достаточно давно больше периода времени захоронения tombstone lifetime (128 дней). Для того, чтобы возобновить репликацию не переустанавливая контроллер домена, мы решили отключить проверку целостности и разрешить репликацию с неправильным партнёром. Для этого в реестр каждого контроллера домена были добавлены следующие ключи:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]

«Strict Replication Consistency»=dword:00000000

«Allow Replication With Divergent and Corrupt Partner»=dword:00000001

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

Очистка метаданных.

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

Кстати, если кому-то интересно, то для удобства анализа большого числа данных монитора репликации, очень удобно использовать Excel. Для этого данные можно выгрузить в формат .csv:

repadmin /showrepl * /csv > showrepl.csv

Для удаления контекста именования отсутствующего домена мы решили воспользоваться утилитой ntdsutil и командой metadata cleanup, более подробно об этом написано здесь: http://support.microsoft.com/kb/216498/en-us Но к сожалению данная попытка удаления не увенчалась успехом, мы получили ошибку 0×2162<The requested domain could not be deleted because there exist domain controllers that still host this domain.>. Данная ошибка говорит о том, что невозможно удалить домен, т.к. существуют контроллеры домена, которые содержат данный домен.

Пытаясь найти решение данной ошибки, мы попали на статью: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q235416, которая к сожалению тоже никак не помогла, т.к. ни в одной оснастке уже не отображался ни сайт, относящийся к этому домену, ни сам домен. Но при помощи оснастки ADSI Edit, в разделе Configuration\Partitions\ всё ещё находился раздел этого домена. Попытка его удалить через ADSI Edit приводила к аналогичной ошибке:

Мы решили найти данный контекст именования в удалённых объектах, для этого воспользовались утилитой Active Directory Explorer (ADexplorer) от sysinternals, хотя в принципе с таким же успехом можно было использовать и ldp.exe. В итоге в разделе Configuration\Sites мы обнаружили удалённый сайт, содержащий в себе удалённый объект Servers, внутри которого был удалённый объект контроллера домена, но вот внутри объекта контроллера домена ничего не было, хотя там должен был быть объект NTDS Settings, что нас и навело на определённые мысли.

В итоге мы догадались заглянуть в контейнер LostAndFoundConfig и обнаружили там объект NTDS Settings от данного сайта, который не был удалённым, но принадлежал удалённому серверу и сайту.

После удаления объекта NTDS Settings, мы снова вернулись к ntdsutil > metadata cleanup и успешно удалили остатки старого домена.

Компоненты интеграции предназначены для обоих версий платформы Hyper-V – как для первой версии, входящей в состав Windows Server 2008, так и для второй, входящей в состав Windows Server 2008 R2. Эти компоненты включают в себя:

• драйвер синтетической сетевой карты
• драйвер синтетического адаптера SCSI
• драйвер блочного устройства VSC – поддержка синтетического адаптера IDE для увеличения быстродействия при загрузке

Драйвер мыши для графической оболочки Linux в комплект не входит.

Обращаем внимание, что для большинства виртуальных машин Linux доступно использование только одного виртуального процессора. Полноценная поддержка Hyper-V в ядре начинается с ядра версии 2.6.32.

Журналисты цитируют следующее заявление Дмитрия Сумина, президента Passware: «Полное шифрование диска представляет собой серьезную проблему для следователей. Мы смогли предоставить полиции, правоохранительным органам и частным детективам инструмент, который позволяет обойти BitLocker шифрование.»

Вот лишь некоторые примеры:

http://news.softodrom.ru/ap/b5920.shtml

http://www.inattack.ru/news/3291.html

http://www.xakep.ru/post/50347/

Меня задолбали сообщения в аську от друзей и знакомых, которые увидев подобные новости, спешили проинформировать меня и позлорадствовать «типа поломали твой Microsoft».

Мне эта чушь надоела, и я решил написать статью на блог.

И так, BitLocker – это средство шифрования дисков, которое присутствует в Windows 7 и Vista, Windows Server 2008 и 2008 R2. А весь шум гам  возник, после выхода продукта Passware Kit 9.5, который, по заявлению производителя, теперь умеет взламывать BitLocker.

Давайте разберёмся, как же работает сие чудо. Для так называемого взлома зашифрованного тома программе требуется предоставить собственно дамп зашифрованного тома и (внимание!) дамп физической памяти компьютера! Мало того, дамп должен быть сделан, после того, как вы ввели правильный пароль и разблокировали зашифрованный диск!

Товарищи, о чём мы говорим? Где здесь взлом?

Естественно, что в процессе работы с зашифрованным томом, в оперативной памяти находятся ключи шифрования. Но как только вы компьютер выключили, память очищается! Даже если вдруг, к злоумышленнику попадёт включенный компьютер, но залоченный, всё равно шансы извлечь ключи из памяти практически равны нулю.  (не надо мне только про жидкий азот). Ещё один способ получить дамп памяти – это использовать файл hiberfil.sys. Но вопервых этот файл создаётся только, когда используется режим гибернации, а во вторых он располагается на системном томе, который по идее тоже должен быть зашифрован.

Сами разработчики, так вообще предлагают сделать дамп памяти при помощи утилиты MDD от компании ManTech, которая для работы требует администраторские права, пытается установить неподписанный драйвер, что естественно блокируется системой. Но даже после всего этого у меня на Windows 7 x64 утилита, так и не смогла сделать дамп.

Так, что мне вообще не понятен практический смысл возможности «взлома» BitLocker, предлагаемый Passware. М.б. кто-то объяснит?

PS.

Кстати, Passware Kit включает в себя достаточно много средств взлома. Но на своём опыте могу сказать, что и они не отличаются особой эффективностью. Так например, уже достаточно давно Passware предлагает нам средства взлома EFS. Кто-нибудь его взломал? Нет? А почему? Да потому, что предлагается почти тоже самое, для взлома нужно предоставить сертификат с закрытым ключом, которым всё шифровалось, да и ещё кажется и пароль. – ну это же бред! С паролем и сертификатом и сам Windows может всё открыть.

По моему ничего эффективнее ректотермального криптоанализа ещё не изобрели.

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

Проблема случилась у одного из наших клиентов, ИТ-инфраструктуру которого мы обслуживаем по договору ИТ-аутсорсинга. Компания занимается разработкой систем биометрической аутентификации. В рамках одного из плановых аудитов информационной системы инженеры отдела сервисного обслуживания заметили аномальное увеличение размера базы данных службы каталогов ntds.dit. Когда проблема была обнаружена, размер ntds.dit составлял 2 ГБ, но в течение недели он вырос до 8 ГБ. В компании работает всего 50 человек, и в аналогичных компаниях размер базы данных службы каталогов варьируется от 20 до 40 МБ. Поиски в Интернете ни к чему не привели, поэтому нам пришлось разбираться самим. Параллельно мы открыли инцидент в службе поддержки Microsoft, которая в данном случае нам не помогла. Кто-то из специалистов мне пытался объяснить, что мне следует почистить Event Logs, по его мнению они хранились в Active Directory. А я всю жизнь думал, что они хранятся в C:\WINDOWS\system32\config\. Ну да ладно, может быть в тот раз трубку взяла уборщица, кто его знает

Локализация проблемы.

Проблему удалось локализовать в течение одной недели. Просматривая службу каталогов низкоуровневой утилитой ldp.exe, мы обнаружили огромное количество однотипных объектов в контейнере CN=Deleted Objects. В имени всех объектов содержалось название программного обеспечения биометрической аутентификации, которое как раз и разрабатывает эта компания. Мы немедленно обратились к разработчикам и сообщили о проблеме. Мы глубоко не погружались в технологию работы их программного обеспечения, но смысл был в том, что ПО генерировало маркер доступа, сохраняло его в AD, затем считывало и удаляло. И так создавалось и удалялось несколько миллионов объектов в день. Но, видимо, никто не учёл, что удалённые объекты в AD хранятся ещё 180 дней. И таким образом, они всё время накапливались. Разработчики поправили ошибку, и перед нами осталась только одна проблема – Как теперь уменьшить размер БД и избавиться от удалённых объектов?

Решение проблемы.

Сейчас точно не вспомню, но удалённых объектов накопилось более 100 миллионов. По умолчанию удалённые объекты хранятся 180 дней. Чтобы началось их удаление, мы уменьшили время хранение удалённых объектов до 1 дня. Для этого запустили ADSIEdit.msc и в разделе Configuration\Services\Windows NT\Directory Service, задали значение атрибута tombstonelifetime = 2.

Но не всё оказалось так просто. Захоронённые объекты даже с истёкшим сроком хранения не удаляются сразу. Их удаление происходит при запуске процесса Garbage Collector, который запускается 1 раз в 12 часов и удаляет не более 5000 объектов. Затем мы сократили интервал запуска процесса Garbage Collector до 1 часа.  Для этого запустили ADSIEdit.msc и в разделе Configuration\Services\Windows NT\Directory Service, задали значение атрибута garbageCollPeriod = 1.

Но это не сильно спасло ситуацию. Т.к. удаление 100 000 000 объектов продолжалось бы боле 2-х лет!   (100000000/5000/24/365=2,28 лет).  А по умолчанию, так и вообще более 27 лет.

Честно-говоря, нам не хотелось столько ждать,  и мы обратились за помощью к разработчикам Active Directory. После переписки с Тимом Спрингстоном (Tim Springston), у нас получилось удалить все захоронённые объекты в течение нескольких дней.  Для запуска непрерывного процесса удаления захороненных объектов мы использовали процедуру DoGarbageCollector.

Для её запуска используется LDP.EXE. Запускаем ldp.exe в меню Connection выбираем connect, подключаемся к контроллеру домена, затем выбираем Connection\bind и вводим учётные данные. Затем нажимаем Browse\Modify и заполняем соответствующие поля.
Attribute: DoGarbageCollection
Value: 1
Нажимаем Enter, а затем Run.

Чтобы отслеживать процесс, можно запустить логирование. Для этого меняем соответствующее значение реестра:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics
6 Garbage Collection = 3

В Event Viewer смотрим события 1005, 1006 – они говорят о работе Garbage Collector, после завершения его работы, появляется событие: 1646, в котором будет указано на сколько может быть уменьшена БД AD оффлайновой дефрагментацией.

После этого перезагрузились в режиме Directory Service Restore Mode, и использовали ntdsutil для offline дефрагментации ntds.dit. Не буду расписывать процесс дефрагментации, боюсь наврать, но в нём ничего сложного нет, читайте тут: http://support.microsoft.com/kb/232122.

Проблема в обновлении KB974571 – «MS09-056: Vulnerabilities in CryptoAPI could allow spoofing». После установки этого обновления службы Front-End, Access Edge не запустятся.

Например, для Office Communications Server 2007 R2 в журнале событий появляются записи:

Event Type: Error
Event Source: OCS Server
Task Category: (1000)
Event ID: 12290
Description:
The evaluation period for Microsoft Office Communications Server 2007 R2 has expired. Please upgrade from the evaluation version to the full released version of the product.



Event Type: Error
Event Source: OCS Server
Task Category: (1000)
Event ID: 12299
Description:
The service is shutting down due to an internal error.
Error Code: C3E93C23 (SIPPROXY_E_INVALID_INSTALLATION_DATA)
Resolution:
Check the previous event log entries and resolve them. Restart the server. If the problem persists contact product support.


Решение: если вы еще не разворачивали обновления – не устанавливайте обновление KB974571. Если уже установили – деинсталлируйте это обновление.

Поскольку данное обновление имеет статус «Критическое» – его установка в дальнейшем крайне желательна. Ожидаем разрешения проблемы и свежего обновления от Microsoft.

Немного больше повезло тем, кто использует Symantec BackUp Exec. Он умеет восстанавливать объекты из архива без перезагрузки контроллера домена. Но во-первых далеко не все используют Symantec BackUp Exec, а во-вторых под рукой может не оказаться актуальной резервной копии службы каталогов (вы как часто её резервируете?).

В Windows Server 2008 R2 появилось очень много новых возможностей, одной из которых является корзина Active Directory (Active Directory Recycle Bin).

Кстати, компания ЛанКей совместно с компанией Microsoft проводит бесплатные презентации Windows Server 2008 R2 в рамках акции «Время вперёд», которая продлится до 31 декабря. Так, что если у вашей компании возникло желание узнать о всех возможностях Windows Server 2008 R2, вы можете заказать бесплатную консультацию, пройдя по данной ссылке и выбрав партнёра LanKey (Москва). Презентация проводится сертифицированными инженерами в офисе заказчика.

И так, вернёмся к нашей теме. Корзина Active Directory – это специальная функция/фича/возможность восстановления удалённых объектов. Теперь после удаления объекта из Active Directory, он не просто удаляется, а перемещается в специальный контейнер Deleted Objects (хотя и раньше объект не просто удалялся, но об этом ниже). И если вы потом захотите восстановить объект, то это можно будет сделать, вытащив его из контейнера Deleted Objects.

Функция Корзины Active Directory работает только в режиме работы леса и домена Windows Server 2008 R2! И кроме того эта функция по умолчанию  выключена.

Включаем корзину Active Directory.

>У меня домен зовется net.local, поэтому вы меняйте эти значения на свои.

Включить функцию корзины можно двумя способами, либо через ldp.exe либо при помощи командлетов PowerShell.

1) При помощи ldp.exe (входит в состав Support Tools).

Запускаем Ldp.exe. Затем нажимаем Connection>Connect, пишем localhost, порт 389. Затем нажимаем View>Tree, в BaseDN выбираем CN=Configuration,DC=net,DC=local. Раскрываем CN=Configuration…. переходим к CN=Partitions…, нажимаем правой кнопкой по CN=Partitions… и выбираем Modify. Очищаем поле DN, в строке Attribute пишем: enableOptionalFeature, в строке Values пишем CN=Partitions,CN=Configuration,DC=net,DC=local:766ddcd8-acd0-445e-f3b9-a7f9b6744f2a, выбираем Add и нажимаем Enter и потом Run.

2) При помощи PowerShell:

Запускаем Пуск\Administrative Tools\Active Directory Module for Windows PowerShell и пишем:

Enable-ADOptionalFeature –Identity ‘CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration, DC=net,DC=local’ -Scope ForestOrConfigurationSet -Target ‘net.local’

Восстанавливаем удалённые объекты.

Способа восстановления удалённых объектов стандартными средствами два, при помощи ldp.exe или при помощи PowerShell. В тестовых целях я создал пользователя «robot», включил его в группу Domain Admins, а затем удалил. Теперь будем пытаться его восстановить.

1) Восстанавливаем удалённые объекты при помощи ldp.exe:

Запускаем Ldp.exe. Затем нажимаем Connection>Connect, пишем localhost, порт 389. Нажимаем Options>Controls, в меню Load Predefined выбираем Return deleted objects, жмём OK. Затем нажимаем View>Tree, в BaseDN выбираем DC=net,DC=local. Раскрываем корень DC=net,DC=local, и видим контейнер Deleted Objects, дважды по нему щелкаем и видим перечень удалённых объектов.

Я вижу здесь удалённого мной ранее пользователя robot. Чтобы его восстановить, я нажимаем по нему правой кнопкой и выбираем Modify.

Пишем в строке Attribute: isDeleted, ниже выбираем Delete, нажимаем кнопку Enter, затем пишем в поле Attribute: distignuishedName, в поле Values пишем: CN=robot,CN=Users,DC=net,DC=local (это исходный DN пользователя). Если вы не знаете исходный ОГП пользователя, то его можно посмотреть в правом окне, он записан в атрибуте lastKnownParent. Далее ставим обе галки Synchronous и Extended и жмём Run. Всё! Теперь объект пользователя полностью восстановлен, в чем вы можете убедиться, открыв консоль Active Directory Users and Computers.

2) Восстанавливаем удалённые объекты при помощи PowerShell:

Для того, чтобы найти объекты, используется командлет Get-ADObject. Чтобы он искал и удалённые объекты, нужно использовать ключ -IncludeDeletedObjects. А для восстановления объектов используется командлет Restore-ADObject. Когда необходимо восстановить объект, или тем более несколько объектов, удобнее всего использовать перенаправление (pipeline) вывода командлета Get-ADObject на вход командлета Restore-ADObject:

Get-ADObject -Filter {sAMAccountName -eq «robot»} -IncludeDeletedObjects | Restore-ADObject
Здесь я задал фильтр, чтобы укзать что я хочу восстановить только объект, который имеет атрибут sAMAccountName: robot. В общем, одна такая простая строчка, и объект полностью восстановлен!

Естественно, что использование PowerShell намного удобнее и предпочтительнее, чем восстановление при помощи ldp.exe.

Восстановление удалённых объектов Active Directory в Windows 2003.

Некоторые из вас, кто слышал о таком понятии, как Tombstone Lifetime, наверняка сейчас задались вопросом: «А что изменилось в Windows Server 2008 R2? Захоронённые объекты Active Directory можно было восстанавливать и раньше!».

Да, вы отчасти правы! Действительно в более старых версиях, например Windows Server 2003, в Active Directory удалённые объекты тоже окончательно не удалялись, и тоже помещались в тот же контейнер Deleted Objects. Хранились объекты в этом контейнере по умолчанию 128 дней (в WS 2003 sp1, и 64 дня в WS 2003 rtm), и по истечении этого срока, объекты окончательно удалялись процессом Garbage Collector. В принципе в Windows Server 2008 R2 всё осталось точно также, за исключением того, что теперь объекты, сначала помечаются удалёнными на 128 дней с сохранением всех своих атрибутов, и только затем помечаются как захоронённые и сохраняются ещё 128 дней. Т.е. первые 128 дней объекты можно восстановить с соханением всех исходных атрибутов, членствах в группах и даже пароля. При восстановлении удалённого пользователя в предыдущих версиях Windows Server, он сохранял лишь ограниченный набор атрибутов. По сути оставались лишь sAMAccountName, SID и GUID. Т.е., восстановив пользователя мы должны были заново прописать все его атрибуты, Полное имя, UPN, включить в нужные группы, задать новый пароль и т.д. Хотя сам процесс восстановления был почти таким же. Привожу небольшой пример восстановления удалённого пользователя в домене Windows 2003.

>Как и в предыдущем примере, я создал пользователя «robot», включил его в группу Domain Admins, а затем удалил. В данном примере у меня домен называется olddomain.local, так, что вы меняйте эти значения на свои.

Запускаем Ldp.exe. Затем нажимаем Connection>Connect, пишем localhost, порт 389. Нажимаем Options>Controls, в меню Load Predefined выбираем Return deleted objects, жмём OK. Затем нажимаем View>Tree, в BaseDN выбираем DC=olddomain,DC=local. Раскрываем корень DC=olddomain,DC=local, и видим контейнер Deleted Objects, дважды по нему щелкаем и видим перечень удалённых объектов.

Я вижу здесь удалённого мной ранее пользователя robot. Чтобы его восстановить, нажимаем по нему правой кнопкой и выбираем Modify. Пишем в строке Attribute: isDeleted, ниже выбираем Delete, нажимаем кнопку Enter, затем пишем в поле Attribute: distignuishedName, в поле Values пишем: CN=robot,CN=Users,DC=olddomain,DC=local (это исходный DN пользователя). Если вы не знаете исходный ОГП пользователя, то его можно посмотреть в правом окне, он записан в атрибуте lastKnownParent. Далее ставим обе галки Synchronous и Extended и жмём Run. Запускаем оснастку Active Directory Users and Computers и видим, что пользователь появился, но он отключен.

Нажимаем по нему правой кнопкой и выбираем Enable Account, и получаем ошибку:

Ошибка говорит о том, что у восстановленного пользователя нет пароля, поэтому его нужно сначала задать. Т.е. нужно нажать правой кнопкой по пользователю robot и выбрать Reset password. После того, как новый пароль будет задан, можно будет активировать учётную запись пользователя. Всё! Учтеная запись восстановлена, но она потеряла почти все свои неосновные атрибуты и членства в группах так, что теперь вручную нужно будет восстановить все атрибуты, членства в группах, имена, телефоны, и проч.

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

PS: Кстати, кроме ldp.exe и PowerShell (в WS 2k8 R2) есть ещё один способ восстановления удалённых объектов Active Directory – это использование бесплатной утилиты от Sysinternals AdRestore. Причем данная утилита работает и в Windows 2003 и в Windows 2008. Утилита очень проста в использовании. Для восстановления пользователя robot, достаточно было написать:

adrestore.exe -r robot

Результат использования AdRestore  ничем не отличается от ldp.exe или от Restore-ADObject.