AD Recycle Bin в 2008 R2: восстановление 200 удалённых учёток за несколько минут

Инцидент произошёл в пятницу вечером - как водится. Администратор клиента гнал скрипт PowerShell для зачистки устаревших учёток по фильтру даты последнего входа. Фильтр оказался написан с ошибкой: вместо «не логинились дольше 180 дней» отработало «не логинились за последние 180 минут». Итог - около 200 удалённых объектов, в том числе учётки реальных сотрудников, несколько сервисных аккаунтов и пара групп.

До конца рабочего дня никто не заметил: все уже сидели по домам. Обнаружили в понедельник утром, когда люди начали приходить и не смогли залогиниться.

Как это обычно лечится

До появления AD Recycle Bin восстановление удалённых объектов Active Directory - занятие нервное. Варианта два.

Первый - авторитативное восстановление из System State. Останавливаешь контроллер домена, загружаешься в Directory Services Restore Mode, достаёшь бэкап ntdsutil-ом, помечаешь нужные объекты как авторитативные, перезапускаешь. Процедура рабочая, но небыстрая: только загрузка в DSRM и само восстановление легко занимают час, а потом ещё нужно дождаться репликации на остальные DC. Если бэкап свежий - хорошо. Если последний System State снимался вчера ночью, а инцидент случился сегодня утром - часть изменений в AD за этот период просто пропадёт.

Второй - LDP или ADSI Edit с lostAndFound. Удалённые объекты в AD не исчезают сразу: они перемещаются в контейнер Deleted Objects, становятся «усечёнными» (большинство атрибутов обнуляется) и живут там 180 дней по умолчанию (tombstone lifetime). Можно вытащить объект оттуда через LDP или ADSI Edit, но атрибуты - memberOf, профили, описания, настройки - уже потеряны. Получаешь учётку с именем, но без ничего.

Ни тот ни другой вариант не назовёшь удобным.

AD Recycle Bin: что это такое

В Windows Server 2008 R2 Microsoft наконец добавила то, чего не хватало со времён Windows 2000. AD Recycle Bin работает принципиально иначе: при удалении объект переходит в состояние Deleted, но при этом сохраняются все его атрибуты - включая членство в группах, описания, параметры. Объект остаётся в таком состоянии configurable период, и восстановить его можно одной командой PowerShell без остановки контроллеров, без DSRM, без авторитативного восстановления.

Ограничение одно, но важное: функциональный уровень леса должен быть не ниже Windows Server 2008 R2. Включить Recycle Bin можно только вперёд - назад не откатишь. И включается он один раз на весь лес.

У клиента лес уже был на нужном функциональном уровне - просто Recycle Bin никто не включал, потому что «и так работает».

Восстановление в понедельник утром

К нам позвонили часов в девять. Домен работал, но часть людей не могла войти. На разбор ушло минут двадцать.

Первое, что сделали - проверили tombstone: объекты ещё в Deleted Objects, не вычищены сборщиком мусора. Хорошо. Дальше пошли по старому пути: разворачивать System State с воскресного ночного бэкапа. Процедура заняла около двух часов с учётом поднятия дополнительного DC в DSRM, пометки объектов как авторитативных и ожидания репликации. Всё это время часть сотрудников сидела без доступа.

Восстановились. Потом сели разговаривать с клиентом про то, как такого не допустить в следующий раз.

Включаем Recycle Bin

Разговор оказался коротким. Включить AD Recycle Bin - одна команда в PowerShell (нужен модуль ActiveDirectory и права Schema Admin / Enterprise Admin):

Enable-ADOptionalFeature -Identity 'Recycle Bin Feature' `
    -Scope ForestOrConfigurationSet `
    -Target 'domain.local'

После этого проверяем:

Get-ADOptionalFeature -Filter {Name -eq 'Recycle Bin Feature'}

Включилось. Теперь при удалении объект сохраняет все атрибуты на протяжении deletedItemLifetime (по умолчанию совпадает с tombstone lifetime, настраивается отдельно).

Для демонстрации тут же удалили тестовую учётку и восстановили её:

Get-ADObject -Filter {displayName -eq 'Test User'} `
    -IncludeDeletedObjects | Restore-ADObject

Учётка появилась на месте со всеми атрибутами, включая группы. Заняло секунд десять.

Масштаб восстановления

Для реального инцидента - когда удалены не одна учётка, а двести - скрипт чуть сложнее. Восстанавливать по одному объекту неудобно, проще по контейнеру или фильтру по времени удаления:

$since = (Get-Date).AddHours(-3)
Get-ADObject -Filter {Deleted -eq $true -and WhenChanged -ge $since} `
    -IncludeDeletedObjects -Properties * |
Where-Object { $_.DistinguishedName -like '*OU=Users*' } |
Restore-ADObject

Фильтр по времени и OU нужен, чтобы не восстановить что-нибудь лишнее - например, объекты, которые удалялись намеренно раньше.

Весь такой сценарий при наличии Recycle Bin занял бы минут пятнадцать-двадцать от звонка до «все работают». Вместо двух часов с авторитативным восстановлением.

Что стоит держать в голове

Включать нужно заранее, а не после инцидента. Recycle Bin не работает ретроактивно: если объекты удалили до включения фичи, они восстанавливаются старым способом - с потерей атрибутов.

Функциональный уровень леса 2008 R2 - обязательное условие. Если в инфраструктуре ещё остаются старые DC или не поднят уровень, сначала миграция.

Это не замена бэкапу. Recycle Bin закрывает один конкретный сценарий - случайное удаление объектов. System State бэкапы всё равно нужны: порча базы NTDS, аппаратный сбой, вирус - всё это Recycle Bin не лечит.

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

Если ваша AD работает на 2008 R2 и Recycle Bin ещё не включён - это буквально десять минут работы в рамках сопровождения инфраструктуры.