Корзина Active Directory: как за 30 секунд вернуть удалённого пользователя со всеми правами

Привет! Я Семёнов Евгений Сергеевич, и я директор компании АйТи Фреш. За мои 15 лет администрирования Windows-инфраструктур я насмотрелся на десятки историй, когда HR-менеджер по ошибке удалял из AD совсем не того сотрудника. И что потом? Админ сутками мучился, восстанавливая доступы из бэкапа. Но есть хорошая новость: если у вас активирована корзина Active Directory, этот кошмарный сценарий можно решить одной командой PowerShell всего за полминуты! Никаких откатов, перезагрузок контроллера или лишних нервов. Если же корзина ещё не включена, то, на мой взгляд, пора это срочно исправить. Для этого я и подготовил пошаговый гид.

Зачем нужна корзина Active Directory

Помню, раньше, ещё до появления Windows Server 2008 R2, был лишь один официальный способ вернуть удалённый объект. Это был механизм tombstone reanimation, или, как мы его называли, «оживление» надгробия. Да, он работал, но вот в чём загвоздка: объект возвращался практически «голым». Он терял большинство своих атрибутов: никаких членств в группах, описания, должности, а иногда даже UPN. По сути, такой восстановленный пользователь оказывался просто пустой оболочкой со старым SID. И что делал админ? Правильно, вручную возвращал его во все нужные группы доступа. А теперь представьте: крупный домен, сотня групп… Это отнимало часы, я вам скажу!

К счастью, сегодня у нас есть Корзина Active Directory, или AD Recycle Bin, и она решает эту проблему кардинально! Если корзина включена, удалённые объекты больше не превращаются в tombstone мгновенно. Вместо этого они проходят такую промежуточную стадию, как «logical deletion». По умолчанию она длится 180 дней. Самое главное: все атрибуты и связи полностью сохраняются. И что в итоге? Всего одна команда Restore-ADObject – и объект возвращается на своё исходное место со всеми правами, как будто ничего и не удалялось.

Проверка состояния корзины перед включением

Знаете, прежде чем что-то активировать, я всегда привык проверять текущее состояние системы. Это мой золотой стандарт. Поэтому на любом контроллере домена просто откройте PowerShell, конечно, от имени администратора:

Get-ADOptionalFeature -Filter * | Select-Object Name, EnabledScopes, RequiredDomainMode

Если в выводе у строки Recycle Bin Feature поле EnabledScopes пустое — корзина не активирована. Также убедитесь, что функциональный уровень леса не ниже Windows Server 2008 R2:

Get-ADForest | Select-Object Name, ForestMode
Get-ADDomain | Select-Object Name, DomainMode

Если у вас стоит более ранний уровень — сначала придётся повысить его командой Set-ADForestMode. Помните: повышение функционального уровня необратимо, понизить обратно нельзя.

Включение корзины Active Directory

Когда все проверки пройдены, включаем корзину одной командой. Делать это нужно на контроллере с ролью FSMO Schema Master, иначе репликация может задержаться:

Enable-ADOptionalFeature -Identity 'Recycle Bin Feature' `
  -Scope ForestOrConfigurationSet `
  -Target 'corp.example.ru' -Confirm:$false

Подтверждать включение нужно осознанно: отключить корзину после активации невозможно. Это лимит платформы Microsoft, а не наша придирка. Зато никаких побочных эффектов на работе домена не появляется — функция включается прозрачно для пользователей.

После включения дождитесь завершения межсайтовой репликации (обычно 15–60 минут на средних доменах). Проверить статус репликации:

Get-ADReplicationPartnerMetadata -Target * -Scope Server |
  Select-Object Server, Partner, LastReplicationSuccess

Срок хранения удалённых объектов и его настройка

По умолчанию удалённый объект хранится в корзине 180 дней. После этого он переходит в стадию tombstone (надгробие) и теряет большинство атрибутов. Срок жизни задаётся атрибутом msDS-deletedObjectLifetime на объекте контейнера CN=Directory Service. Я рекомендую увеличивать его до 365 дней, особенно для компаний с длинными отпускными циклами и проектами «уволили — потом вернули»:

$ds = "CN=Directory Service,CN=Windows NT,CN=Services," + `
       (Get-ADRootDSE).ConfigurationNamingContext
Set-ADObject -Identity $ds -Partition (Get-ADRootDSE).ConfigurationNamingContext `
  -Replace @{ "msDS-deletedObjectLifetime" = 365 }

Учтите: чем длиннее срок, тем больше места занимает база NTDS.dit. На домене 5 000 пользователей с активной ротацией кадров за год база может вырасти на 1–2 ГБ. Это не критично, но мониторить надо.

Восстановление пользователя через PowerShell

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

# Находим объект по имени, отображаются только удалённые
Get-ADObject -Filter {DisplayName -eq "Иванова Анна Петровна"} `
  -IncludeDeletedObjects -Properties *

# Восстанавливаем по DN или ObjectGUID
Get-ADObject -Filter {SamAccountName -eq "ivanova"} `
  -IncludeDeletedObjects | Restore-ADObject

После выполнения объект возвращается в исходную OU с теми же членствами, паролем, должностью, телефоном и атрибутом userAccountControl. Я рекомендую сразу проверить через Get-ADUser ivanova -Properties MemberOf — все группы доступа должны быть на месте.

Если объекты с одинаковым именем удалялись несколько раз, фильтруйте по дате удаления:

Get-ADObject -Filter {SamAccountName -eq "ivanova"} `
  -IncludeDeletedObjects -Properties WhenChanged |
  Sort-Object WhenChanged -Descending | Select-Object -First 1 |
  Restore-ADObject

Восстановление через Active Directory Administrative Center

Не все админы любят PowerShell, и для них Microsoft встроила удобный графический интерфейс. Откройте Active Directory Administrative Center (dsac.exe) на любом контроллере или member-сервере с RSAT. В дереве слева — ваш домен, контейнер Deleted Objects. В нём — все удалённые за 180 дней объекты с фильтром по дате, типу и имени.

Просто кликаем правой кнопкой мыши по нужному объекту, выбираем «Restore» — и вуаля, он возвращается в свой исходный OU. А что, если исходного контейнера уже нет? Ну, допустим, сам OU тоже удалили. Тогда просто выбирайте «Restore To...» и указывайте, куда именно хотите его вернуть. Кстати, этот же интерфейс очень выручает, когда нужно просто посмотреть атрибуты удалённого объекта, не восстанавливая его. Это же так удобно, когда пытаешься вспомнить, в каких группах состоял пользователь!

Восстановление целой OU с пользователями

Пожалуй, самый сложный сценарий, с которым мне приходилось сталкиваться, это когда удаляют целое подразделение. Здесь крайне важен порядок восстановления, без него никуда: нужно двигаться строго от родительских контейнеров к дочерним. Сначала возвращаем сам OU, затем уже вложенные OU, и только в самом конце — пользователей и компьютеры. Если вы попытаетесь восстановить пользователя раньше, чем его родительский OU, команда просто-напросто выдаст ошибку: «The specified target object is not a directory object». И это логично.

# Восстанавливаем родительскую OU
Get-ADObject -Filter {Name -eq "Бухгалтерия"} `
  -IncludeDeletedObjects | Restore-ADObject

# Затем все объекты, что были внутри (по lastKnownParent)
Get-ADObject -SearchBase "CN=Deleted Objects,DC=corp,DC=example,DC=ru" `
  -Filter {lastKnownParent -eq "OU=Бухгалтерия,DC=corp,DC=example,DC=ru"} `
  -IncludeDeletedObjects -SearchScope OneLevel | Restore-ADObject

Я рекомендую делать это поэтапно, с проверкой после каждого шага. На крупных OU с 50+ объектами лучше написать скрипт с обработкой ошибок и логированием.

Реальный кейс: 78 удалённых пользователей за вечер

Помню, в августе 2025 года к нам в АйТи Фреш обратилась одна логистическая компания. У них было 190 рабочих мест, а домен работал на 4 контроллерах. И вот что случилось: их штатный администратор писал PowerShell-скрипт для массового отключения сотрудников, уволенных за квартал. И в какой-то момент он по ошибке вместо Disable-ADAccount прописал Remove-ADUser. В итоге, за какие-то три минуты из домена просто пропали 78 учётных записей! Представляете? Среди них были даже аккаунты нескольких действующих топ-менеджеров.

Когда мы, спустя час после звонка, наконец приехали, выяснилось: бэкап, конечно, был. Но только ночной, самый свежий. А это значит, что восстановление через DSRM заняло бы от 6 до 8 часов, плюс пришлось бы останавливать один из контроллеров, да ещё и с риском сломать всю репликацию. Ох, это был бы тот ещё квест! Но, к нашему счастью, корзина AD у них уже была включена. Ещё наши предшественники позаботились об этом. Мы быстро написали скрипт, который выгрузил все объекты, удалённые за последний день, отфильтровали их по времени удаления и восстановили одним пакетом:

$cutoff = (Get-Date).AddHours(-3)
Get-ADObject -SearchBase "CN=Deleted Objects,DC=cargo,DC=local" `
  -Filter {ObjectClass -eq "user" -and WhenChanged -gt $cutoff} `
  -IncludeDeletedObjects -SearchScope OneLevel |
  ForEach-Object {
    try {
      Restore-ADObject -Identity $_.ObjectGUID
      Write-Host "OK: $($_.SamAccountName)" -ForegroundColor Green
    } catch {
      Write-Host "FAIL: $($_.SamAccountName) - $_" -ForegroundColor Red
    }
  }

Весь процесс занял 12 минут. 78 пользователей вернулись со всеми членствами в группах (а это 240+ групп безопасности на сетевые ресурсы, права в 1С, доступ к VPN). Без корзины такая авария обошлась бы клиенту в день простоя и 80–100 тыс. руб. восстановительных работ.

Что НЕ восстанавливает корзина AD

Корзина — это инструмент логического восстановления внутри AD. Она не возвращает:

• Связанные объекты вне AD — почтовые ящики Exchange после Recipient Update, сертификаты в шаблонах, профили Citrix.
• Файлы, к которым у пользователя был доступ — права на NTFS, конечно, остаются на ресурсе по SID, но если SID полностью «утоплен», ACL придётся править.
• Lingering objects на сторонних контроллерах, не получивших репликацию вовремя.
• Изменения схемы и удалённые атрибуты схемы — только сами объекты пользователей, групп, компьютеров и OU.

Поэтому корзина — условие необходимое, но не достаточное для безопасности AD. Регулярный бэкап системного состояния контроллеров через Windows Server Backup или Veeam B&R остаётся обязательным.

Best practices для корзины AD от АйТи Фреш

За 15 лет работы с доменами я выработал короткий чек-лист, который применяю на каждом новом проекте миграции AD:

• Включать корзину сразу после поднятия первого домена в лесу, не откладывая.
• Увеличивать msDS-deletedObjectLifetime до 365 дней — задним числом восстановление просьб «вспомнили через полгода» происходит регулярно.
• Делегировать право восстановления отдельной группе AD Operators — не давать всем админам, чтобы видеть в логах кто что восстанавливал.
• Настроить аудит на контейнер CN=Deleted Objects и Live Reports в Splunk/Wazuh для контроля массовых удалений.
• Раз в квартал делать тестовое восстановление — удалили тестового пользователя, восстановили, сверили атрибуты.
• Никогда не использовать Remove-ADUser -Recursive на OU без двойной проверки — лучше скрипт с явным -Confirm на каждом объекте.

Что делать, если корзина не была включена

Этот раздел для тех, кто пришёл сюда уже после аварии. Без включённой корзины удалённый объект превращается в tombstone, у которого вычищено 90 % атрибутов. Возможные пути восстановления:

1. Tombstone reanimation через ldp.exe или Restore-ADObject. Сработает только в течение Tombstone Lifetime (180 дней), вернёт объект без членств, без атрибутов профиля. Дальше — ручной труд.
2. Восстановление из бэкапа в режиме DSRM. Перезагрузка контроллера в Directory Services Restore Mode, восстановление NTDS.dit из бэкапа, авторитативное восстановление нужных объектов через ntdsutil. На домене 1000+ пользователей — 4–8 часов работы и риск нарушения репликации.
3. Восстановление через изолированную виртуальную машину. Поднимаем копию контроллера из бэкапа на отдельной сети, экспортируем нужные объекты в LDIF и импортируем в продакшн. Безопаснее, но дольше.

Если вдруг вы оказались в ситуации, когда нет ни корзины, ни актуального бэкапа, и, к тому же, не хватает компетенций для работы с DSRM — не отчаивайтесь! Смело звоните нам. Мы регулярно справляемся с такими задачами. Чаще всего, восстановление от 10 до 20 учётных записей укладывается в 4–6 часов нашей работы.

FAQ — частые вопросы по корзине Active Directory

С какой версии Windows Server работает корзина AD?

Корзина Active Directory доступна начиная с Windows Server 2008 R2. Для её включения требуется уровень леса не ниже Windows Server 2008 R2. Включение необратимо — отключить корзину после активации нельзя.

Сколько времени удалённый объект хранится в корзине?

По умолчанию объект хранится 180 дней (msDS-deletedObjectLifetime) — за это время его можно восстановить со всеми атрибутами. После — переходит в стадию tombstone и теряет большинство атрибутов.

Восстанавливаются ли членства в группах при использовании корзины?

Да, при включённой корзине AD пользователь возвращается со всеми членствами в группах безопасности и распространения. Это ключевое отличие от старого механизма tombstone reanimation.

Можно ли восстановить целую OU с пользователями?

Да, но восстанавливать нужно строго в обратном порядке удаления — сначала родительская OU, затем дочерние OU и только потом сами объекты пользователей и компьютеров.

Что делать, если корзина не была включена и объект уже удалён?

Тогда поможет только восстановление из бэкапа Active Directory с использованием режима DSRM или утилиты ntdsutil — сложно, долго и с риском нарушить репликацию. Лучше включить корзину сразу после развёртывания домена.