Выполнение отката значений и восстановления атрибутов объекта Active Directory

Майкл Олиг, 28 марта 2019 года

Предыдущие две части данной серии были сфокусированы на восстановлении удалённых объектов Active Directory. В этой заметке мы разберём другой тип восстановления Active Directory. Рассмотрим следующий сценарий:

В начале истории перед нами возникает ещё не набивший достаточного количества шишек IT-специалист, недавно взявшийся за изучение PowerShell. Заметив, что в большинстве учётных записей пользователей домена нет никакой информации о почтовом адресе, наш главный герой быстро приходит к пониманию, что у него есть прекрасная возможность использовать свои зарождающиеся сверхспособности в области написания сценариев.

Затем наш герой решает, что наилучшим решением в данной ситуации будет сначала идентифицировать все учётки, у которых отсутствуют атрибуты адреса, а затем обновить эти объекты, указав в незаполненных атрибутах почтовый адрес главного офиса их организации. Это всё-таки лучше, чем ничего, верно? Усилия нашего героя вылились в следующий скрипт:

Get-ADUser -Filter {streetAddress -ne '*'} | Set-ADUser -streetAddress '123 Main Street' -l 'Madison' -st 'Wisconsin' -postalCode '53701'

К несчастью для нашего вундеркинда PowerShell, используемый в фильтре оператор -ne является оператором равенства. Эта невинная оплошность вкупе с необъяснимой беспечностью, в результате которой скрипт не был протестирован (впрочем, необходимой, чтобы наш поучительный пример имел хоть какой-то шанс) привели к созданию сценария PowerShell, применимого лишь для обновления всех адресных атрибутов в каждом объекте пользователя в домене, у которого значение атрибута streetAddress явно не соответствует символу "звёздочка".

Да, неловко получилось…

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

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

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

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

Один из вариантов — использовать инструмент Microsoft’s Windows Server Backup ("WBADMIN"). При инсталляции функционала резервного копирования Windows Server (Windows Server Backup) будет установлен инструмент командной строки wbadmin.exe. Кроме того, станут доступны командлеты Windows PowerShell для Windows Server Backup, а также MMC-оснастка Windows Server Backup.

Все три указанных варианта — это просто разные способы использования одного и того же базового приложения, соответственно, резервная копия, созданная одним из них, будет восприниматься и всеми остальными.

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

Ничего не мешает сделать batch-скрипт, который будет создавать внутри заданного UNC-пути папку с именем, сформированным на основе текущей даты в формате YYYYMMDD, а затем выполнять в эту папку резервирование файла Active Directory ntds.dit с помощью команды START BACKUP инструмента WBADMIN:

@echo off
set backupRoot=\\FILESHARE\NtdsBackups\
set backupFolder=%date:~-4,4%%date:~-10,2%%date:~7,2%
set backupPath=%backupRoot%%backupFolder%
mkdir %backupPath%
wbadmin start backup -backuptarget:%backupPath% -include:C:\Windows\NTDS\ntds.dit -quiet

В результате такой операции вы получите VSS-снапшот (Volume Shadow Copy Service) файла ntds.dit. Из недостатков данного подхода можно отметить то, что в результате создаётся файл, по размерам значительно превышающий исходные файлы: в моей лаборатории ntds.dit занимает 20 Мбайт, а полученный снапшот гораздо больше 20 Мбайт. В лабораторных условиях это не имеет принципиального значения, но в производственной среде может приводить к значительному расходу дискового пространства.

Другой вариант решения от Microsoft — NTDSUTIL.exe, утилита командной строки для доступа и управления базой данных Windows Active Directory. NTDSUTIL — экстремально мощный инструмент, и Ваше рабочее окружение — неподходящее место для изучения его возможностей. Набор полезных команд его невероятно широк, но в рамках данной заметки нас интересует команда SNAPSHOT, которая фиксирует состояние Active Directory на момент создания снапшота:

Большим недостатком данного подхода является то, что NDTSUTIL записывает резервные копии на тот же том, где размещается Active Directory, что не идеально.

Эти два варианта далеко не единственные, но с их помощью мы уже получили множество резервных копий на выбор для выполнения восстановления. Пришла пора открыть их и заглянуть внутрь. Для того чтобы сделать это мы воспользуемся инструментом Active Directory Domain Services Database Mounting Tool ("DSAMAIN"). DSAMAIN позволяет монтировать файлы ntds.dit, прячущиеся в наших резервных копиях, после чего мы можем исследовать их с помощью LDAP.

Начнём с одного из VHD-образов, созданных WBADMIN. В первую очередь нужно найти один из наших VHD, смонтировать его и назначить буквенный идентификатор диска его первичному разделу.

Затем нам нужно определить путь к файлу ntds.dit в смонтированной резервной копии, открыть командную строку с правами администратора и выполнить следующую команду для монтирования этого файла ntds.dit:

dsamain -dbpath "E:\Windows\NTDS\ntds.dit" -ldapport 10389

При закрытии окна командной строки DSAMAIN остановится, так что не закрывайте её пока не закончите процедуру восстановления.

А теперь, когда мы подключили каталог из резервной копии WBADMIN, смонтируем снимок, сделанный NTDSUTIL. Для этого откроем ещё один экземпляр командной строки с правами администратора и с помощью команды snapshot утилиты ntdsutil сначала просмотрим список наших резервных копий, смонтируем одну из них и скопируем путь к диску, назначенный утилитой NTDSUTIL.

Затем нам нужно найти путь к файлу ntds.dit внутри пути, назначенного NTDSUTIL, открыть ещё один экземпляр командной строки с правами администратора и с помощью следующей команды смонтировать нужный нам файл ntds.dit:

dsamain -dbpath "C:\$SNAP_201903261110_VOLUMEC$\Windows\NTDS\ntds.dit" -ldapport 20389

Смонтировав две разных резервных копии, можно приступать к экспериментам. Я поменял значение атрибута Description моего старого товарища — тестовой учётной записи Delete Q. Me.

Открыв PowerShell, мы можем с помощью командлета Get-ADUser взглянуть на нашего тестового пользователя. По умолчанию Active Directory ожидает подключения на порту 389. Вы наверняка обратили внимание, что смонтированные нами резервные копии ожидают соединения на портах 10389 и 20389. С помощью дополнительного параметра Server мы можем посмотреть как наш тестовый пользователь выглядит в живом каталоге и в обеих наших смонтированных резервных копиях.

Как видите, текущее значение атрибута Description — "Oops", а в обеих резервных копиях содержится предыдущее значение — "Demo User Account".

Мы можем использовать тот же PowerShell-командлет Get-ADUser так, чтобы с его помощью получить данные для восстановления нужного нам атрибута до значения, найденного в наших резервных копиях. Если мы получим копию объекта из одной из смонтированных резервных копий, мы можем использовать значение атрибута из неё для восстановления значения атрибута живого объекта:

$UserBackup = Get-ADUser -Identity dqme -Properties Description -Server dc01:10389
Set-ADUser -Identity dqme -Description $UserBackup.Description -Server dc01:389

На практике это выглядит так. Обратите внимание, что значение атрибута Description было восстановлено до значения, полученного из смонтированной резервной копии.

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

В последней заметке данной серии будет рассмотрено резервирование и восстановление объектов групповых политик.