Неполномочное восстановление ad ds

Восстановление отдельных объектов в AD

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

Вкратце процедура выглядит следующим образом:

  1. Загрузите DC в DSRM режиме;
  2. Выведите список доступных резервных копий: wbadmin get versions
  3. Запустите восстановление выбранной резервной копии: wbadmin start systemstaterecovery –version:
  4. Подтвердите восстановление DC (в не полномочном режиме);
  5. После перезагрузки запустите: ntdsutil
  6. activate instance ntds
  7. authoritative restore

Укажите полный путь к объекту, который нужно восстановить. Можно восстановить OU целиком:

restore subtree ″OU=Users,DC=winitpro,DC=ru″

Или один объект:

restore object “cn=Test,OU=Users,DC=winitpro,DC=ru”

Данная команда запретит репликацию указанных объектов (путей) с других контроллеров домена и увеличит USN объекта на 100000.

Выйдите из ntdsutil: quit

Загрузите сервер в обычном режиме и убедитесь, что удаленный объект был восстановлен.

Неполномочное восстановление AD DS выполняется средствами Windows Server Backup и может потребоваться в самых разных случаях . Сценарий восстановления также зависит от используемой версии операционной системы и версии гипервизора (если контроллеры домена работают в виртуальной среде). Большинство из возможных вариантов я рассмотрю в этой статье.

Если вам интересна тематика Windows Server, рекомендую обратиться к тегу Windows Server на моем блоге.

Восстановление удаленных объектов в Active Directory Печать

Изменено: Чт, 14 Апр, 2016 на 12:06 AM

Процедура восстановления

В качестве примера возьмем учетную запись пользователя Ivanov Vasiliy и удалим ее. Прощай Vasiliy

Для восстановления воспользуемся утилитой LDP. LDP — это служебная программа для работы с Active Directory, немного схожая с проводником Windows. В Windows Server 2008 она включена в состав операционной системы, в Server 2003 входит в средства поддержки (Support tools) и устанавливается отдельно, с установочного диска.
Для запуска LDP нажимаем Win+R и в строке выполнить вводим ldp. Затем идем в меню Connection, выбираем пункт Connect и в открывшемся окне вводим имя контроллера домена, к которому надо подключиться. Если вы запускаете LDP на контроллере домена, то можно просто ввести localhost.

Теперь необходимо пройти проверку подлинности. Открываем меню Connection, выбираем Bind (Привязка), вводим учетные данные и жмем OK. Для работы нам понадобятся учетные данные пользователя с правами администратора домена или предприятия (только они имеют право просматривать и восстанавливать объекты в контейнере Deleted Objects).

Контейнер Deleted objects надежно скрыт от посторонних глаз, и для того, чтобы его увидеть, необходимо включить элемент управления LDAP «Возврат удаленных объектов». Для этого открываем меню Options и выбираем пункт Controls, чтобы вывести диалог элементов управления. Открываем список Load Predefined, в нем выбираем пункт Return Deleted Objects (Вернуть удаленные объекты) и нажимаем кнопку Check in. Это добавит идентификатор объекта (OID) для элемента управления «Вернуть удаленные объекты» (1.2.840.113556.1.4.417) в список активных элементов управления. Нажимаем OK, чтобы сохранить настройки элемента управления.

Затем открываем меню View, выбираем режим просмотра Tree, в поле BaseDN выбираем DC=contoso,DC=com.

Заходим в корень, раскрываем контейнер Deleted Objects и видим перечень удалённых объектов. В этом перечне находим нужный нам объект-пользователя CN=Ivanov Vasily. Кликаем правой клавишей мыши на найденом объекте и в выпадающем меню выбираем пункт Modify. Кстати, будьте готовы к тому, что в Deleted Objects очень много объектов, что может затруднить поиск.

Для восстановления объекта надо провести две операции:
1) Удалить отметку об удалении — набираем в строке Attribute: isDeleted, в поле Operation выбираем Delete и нажимаем Enter;
2) Переместить из Deleted objects в исходный контейнер — набираем в поле Attribute: distinguishedName, в поле Values пишем: CN=Ivanov Vasily, OU=Managers, DC=contoso, DC=com (это исходный DN пользователя). Исходный контейнер пользователя можно посмотреть в правом окне, он записан в атрибуте lastKnownParent. В качестве операции выбираем Replace и опять нажимаем Enter.
Далее отмечаем оба пункта Synchronous и Extended и жмём кнопку Run.

Всё! Теперь объект пользователя полностью восстановлен, в чем можно убедиться, открыв консоль Active Directory Users and Computers.

Была ли эта статья полезной?
Да
Нет

Отправить отзыв К сожалению, мы не смогли помочь вам в разрешении проблемы. Ваш отзыв позволит нам улучшить эту статью.

Восстановление удаленных объектов в Active Directory Печать

Изменено: Чт, 14 Апр, 2016 at 12:06 AM

Процедура восстановления

В качестве примера возьмем учетную запись пользователя Ivanov Vasiliy и удалим ее. Прощай Vasiliy

Для восстановления воспользуемся утилитой LDP. LDP — это служебная программа для работы с Active Directory, немного схожая с проводником Windows. В Windows Server 2008 она включена в состав операционной системы, в Server 2003 входит в средства поддержки (Support tools) и устанавливается отдельно, с установочного диска.
Для запуска LDP нажимаем Win+R и в строке выполнить вводим ldp. Затем идем в меню Connection, выбираем пункт Connect и в открывшемся окне вводим имя контроллера домена, к которому надо подключиться. Если вы запускаете LDP на контроллере домена, то можно просто ввести localhost.

Теперь необходимо пройти проверку подлинности. Открываем меню Connection, выбираем Bind (Привязка), вводим учетные данные и жмем OK. Для работы нам понадобятся учетные данные пользователя с правами администратора домена или предприятия (только они имеют право просматривать и восстанавливать объекты в контейнере Deleted Objects).

Контейнер Deleted objects надежно скрыт от посторонних глаз, и для того, чтобы его увидеть, необходимо включить элемент управления LDAP «Возврат удаленных объектов». Для этого открываем меню Options и выбираем пункт Controls, чтобы вывести диалог элементов управления. Открываем список Load Predefined, в нем выбираем пункт Return Deleted Objects (Вернуть удаленные объекты) и нажимаем кнопку Check in. Это добавит идентификатор объекта (OID) для элемента управления «Вернуть удаленные объекты» (1.2.840.113556.1.4.417) в список активных элементов управления. Нажимаем OK, чтобы сохранить настройки элемента управления.

Затем открываем меню View, выбираем режим просмотра Tree, в поле BaseDN выбираем DC=contoso,DC=com.

Заходим в корень, раскрываем контейнер Deleted Objects и видим перечень удалённых объектов. В этом перечне находим нужный нам объект-пользователя CN=Ivanov Vasily. Кликаем правой клавишей мыши на найденом объекте и в выпадающем меню выбираем пункт Modify. Кстати, будьте готовы к тому, что в Deleted Objects очень много объектов, что может затруднить поиск.

Для восстановления объекта надо провести две операции:
1) Удалить отметку об удалении — набираем в строке Attribute: isDeleted, в поле Operation выбираем Delete и нажимаем Enter;
2) Переместить из Deleted objects в исходный контейнер — набираем в поле Attribute: distinguishedName, в поле Values пишем: CN=Ivanov Vasily, OU=Managers, DC=contoso, DC=com (это исходный DN пользователя). Исходный контейнер пользователя можно посмотреть в правом окне, он записан в атрибуте lastKnownParent. В качестве операции выбираем Replace и опять нажимаем Enter.
Далее отмечаем оба пункта Synchronous и Extended и жмём кнопку Run.

Всё! Теперь объект пользователя полностью восстановлен, в чем можно убедиться, открыв консоль Active Directory Users and Computers.

Была ли эта статья полезной?
Да
Нет

Отправить отзыв К сожалению, мы не смогли помочь вам в разрешении проблемы. Ваш отзыв позволит нам улучшить эту статью.

How to Backup Active Directory (Full Server Backup)

I prefer to use the full backup option instead of the system state backup. This option allows you to easily restore if the operating system or Active Directory becomes corrupt.

It includes the system state so you can choose to restore the entire server or just the system state.

The steps for backing up just the system state are the same you will just choose custom instead of full server.

Here are the settings that will be configured for this backup:

  • Daily Backup
  • 1 full backup then 14 incremental backups – Windows server backup automatically handles the full and incremental backups no additional configuration is needed.
  • The backup destination will be a volume mounted as a local disk. I’m using a SAN with replication to another datacenter for disaster recovery.
  • My domain controllers are virtual running in a VMWare environment.
  • The domain controller is Windows Server 2016

Step 1: Create a dedicated disk for backups.

Important: When doing a full backup the disk cannot be larger than the one you are restoring to. So if the server you are backing up has a disk size of 50GB, the backup disk cannot be larger than this. The Windows backups are very efficient, the first backup is full then it will do incremental backups. I like to make the backup disk slightly smaller than the disk I’ll be backing up.

Step 2: Configure Windows Server Backup

Open the Windows Server Backup Utility

Click on “Backup Schedule” on the right-hand side

Click next on the Getting started page

Select “Full Server” and click next.

If you want to backup just the system state select “Custom”.

In the above screenshot, the backup configuration will tell you how large the backup size will be. Unless you have 3rd party programs and files on your domain controller the backup should be fairly small. After the first backup, it will do an incremental and only backup the changes.

Click the “Advanced settings” button

Click “VSS Settings” then select “VSS full backup”. Click OK

This is recommended if you are not using any other backup product to backup Active Directory.

Configure the backup schedule that works best for you. In my environment, I configured a daily backup at 7:00 PM.

If you have a large environment with lots of AD changes you should consider twice a day backups.

On the specify destination type screen choose “Back up to a hard disk that is dedicated for backups”.

DO NOT choose “Back up to a shared network folder” This option does not support incremental backups it will overwrite the backup each time.

Confirm backup settings and click finish.

The backup configuration is complete but we need to change a few settings in the scheduled task that was created.

Task Scheduler Settings

Just type in “Task Scheduler” in the search bar and click the app.

Browse to Task Scheduler Library -> Microsoft -> Windows -> Backup

You will see the windows backup scheduled task.

Double click on the task name to open it up.

On the General screen, ensure the task is running as the SYSTEM account and change the configure for to the correct operating system. I’m running 2016 so that is what I have selected.

On the settings screen change the task to stop running if it runs longer than 2 hours.  Also, check the box to allow the task to be run on demand.

Click OK. That completes the changes for the scheduled task.

If you want you could right click the task and run it. The backup process may cause a bit of CPU usage so you may need to wait.

The first backup will be a full backup. The next 14 backups will be incremental then it will do another full backup.

You can check the status of backups, disk space used, and much more in the backup utility.

The backup configuration is complete, Active Directory will now backup on a daily basis (or whatever schedule you configured it for).

In the next section, I will show you how to easily monitor the backups.

Восстановление отдельных объектов в AD

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

Вкратце процедура выглядит следующим образом:

  1. Загрузите DC в DSRM режиме;
  2. Выведите список доступных резервных копий: wbadmin get versions
  3. Запустите восстановление выбранной резервной копии: wbadmin start systemstaterecovery –version:
  4. Подтвердите восстановление DC (в не полномочном режиме);
  5. После перезагрузки запустите: ntdsutil
  6. activate instance ntds
  7. authoritative restore

Укажите полный путь к объекту, который нужно восстановить. Можно восстановить OU целиком:

restore subtree ″OU=Users,DC=winitpro,DC=ru″

Или один объект:

restore object “cn=Test,OU=Users,DC=winitpro,DC=ru”

Данная команда запретит репликацию указанных объектов (путей) с других контроллеров домена и увеличит USN объекта на 100000.

Выйдите из ntdsutil: quit

Загрузите сервер в обычном режиме и убедитесь, что удаленный объект был восстановлен.

Переносимость баз данных

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

Дополнительные сведения см. в статье Переносимость баз данных. Дополнительные сведения об использовании переносимости баз данных см. в статье Перемещение базы данных почтовых ящиков с помощью переносимости базы данных.

Что такое VSS

Volume Shadow Copy Service (VSS) — это фича Windows Server, которая поз­воля­ет тихо, незамет­но и цен­тра­лизо­ван­но бэкапить поль­зователь­ские дан­ные.

Пред­ставь, что у тебя есть фай­ловый сер­вер, бэкап которо­го дела­ется ежед­невно. Утром ты внес изме­нения в кри­тичес­ки важ­ный документ, а в кон­це рабоче­го дня что‑то напутал и слу­чай­но уда­лил этот файл. Вос­ста­новить его из бэкапа будет невоз­можно, так как в утреннюю сес­сию он не попал. Одна­ко если на сер­вере вклю­чена служ­ба VSS, то мож­но не торопить­ся ломать кла­виату­ру об колено и кидать монитор в окош­ко — файл мож­но будет спас­ти!

По сути, VSS копиру­ет всю информа­цию, хра­нящу­юся на дис­ке, но при этом отсле­жива­ет изме­нения и берет толь­ко нуж­ные бло­ки. Сами копии дела­ются авто­мати­чес­ки каж­дый час, и по умол­чанию Windows хра­нит их в количес­тве 64 штук. VSS — шту­ка удоб­ная и пов­семес­тно исполь­зует­ся в домен­ных сетях.

вторник, 21 июля 2015 г.

Резервное копирование и восстановление Active Directory на Windows Server 2012

Для выполнения резервного копирования сервера на Windows 2012 вполне достаточно встроенного компонента «Система архивации данных Windows Server«. Сначала добавьте сервис через «Мастер добавления ролей и компонентов«.

Далее можно приступать непосредственно к настройке бэкапа: 1. Откройте консоль «Система архивации данных Windows Server» и запустите мастер «Расписание архивации. «.

2. На первом шаге просто нажмите «Далее«.

3. В конфигурации архивации выберите «Настраиваемый«.

4. Установите галочку напротив «Состояния системы«. Этого будет вполне достаточно для восстановления.

5. Задайте расписание архивации.

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

7. Далее укажите точный путь к сетевой папке.

8. Перед завершением мастера ещё раз проверьте корректность всех настроек и нажмите «Готово«.

Рассмотрим два сценария восстановления:

Первый, когда выходит из строя аппаратная часть, и необходимо её полностью заменить. При этом понадобится предварительно установить на новый сервер чистую ОС той же версии, с тем же сервис паком, которая была на контроллере. Желательно, чтобы совпадали и версии браузера IE. Также нужно заранее добавить компонент «Система архивации данных Windows Server«.

Последовательность действий такая: 1. Находясь в режиме DSRM, откройте консоль «Система архивации данных Windows Server» и запустите мастер «Восстановить. «.

2. Укажите, что архив находится в другом расположении.

3. Далее выберите удалённую общую папку.

4. Выберите нужный архив.

5. Укажите, что хотите восстановить состояние системы.

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

7. После сделанных настроек запускаем восстановление, соглашаясь со всеми предупреждениями системы.

8. По окончании сервер необходимо будет перезагрузить. Все изменения в Active Directory, сделанные после резервного копирования, будут автоматически реплицированы с других контроллеров домена.

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

Восстановление контроллера домена AD из system state бэкапа

Итак, предположим, что у вас в домене только один DC. По какой-то причине вышел из строя физический сервер, на котором он запущен.

У вас есть относительно свежий бэкап System State старого контроллера домена, и вы хотите восстановить Active Directory на новом сервере в режиме полномочного восстановления.

Чтобы приступить к восстановлению, вам нужно установить на новом сервер туже версию Windows Server, которая была установлена на неисправном DC. В чистой ОС на новом сервере нужно установить роль ADDS (не настраивая ее) и компонент Windows Server Backup.

Для восстановления Actve Directory вам нужно загрузить сервер в режиме восстановления служб каталогов DSRM (Directory Services Restore Mode). Для этого запустите msconfig и на вкладе Boot выберите Safe Boot -> Active Directory repair.

Active Directory repair mode” srcset=”https://winitpro.ru/wp-content/uploads/2019/10/safe-boot-greater-active-directory-repair-mode.png 575w, https://winitpro.ru/wp-content/uploads/2019/10/safe-boot-greater-active-directory-repair-mode-300×196.png 300w” sizes=”(max-width: 575px) 100vw, 575px” />

Перезагрузите сервер. Он должен загрузиться в режиме DSRM. Запустите Windows Server Backup (wbadmin) и в правом меню выберите Recover.

wbadmin get versions -backupTarget:D:

Выберите дату, на которую нужно восстановить резервную копию.

Выполнить заслуживающее доверия восстановление файлов Active Directory» (Perform an authoritative restore of Active Directory files

Авторизуйтесь на сервере под учетной записью с правами администратора домена.

При первом запуске консоли ADUC я получил ошибку:

При этом на сервере нет сетевых папок SYSVOL and NETLOGON. Чтобы исправить ошибку:

  1. Запустите regedit.exe;
  2. Перейдите в ветку HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParameters
  3. Измените значение параметра SysvolReady с 0 на 1;
  4. Потом перезапустите службу NetLogon: net stop netlogon & net start netlogon

Попробуйте открыть консоль ADUC еще раз. Вы должны увидеть структуру вашего домена.

Authoritative Restore.

Если у вас остался единственный DC, проверьте что он является хозяином всех 5 FSMO ролей и выполните их захват, если нужно.

Automate AD Backup Monitoring (Email Alerts)

To automate monitoring of the backups you will configure a scheduled task to trigger an action when event ID 4 has been logged.

Step 1: Setup PowerShell Script

Copy the script below and paste it into a text file. Save it as AD-Backup-Success.ps1

You need to change the from address, to address and the SMTP address.

Step 2: Setup Scheduled Task

Open the scheduled task app, in the task scheduler library create a new task.

On the general screen set the following

  • Name: AD Backup Success Notification
  • Use the following account: SYSTEM
  • Set to “Run whether user is logged on or not”
  • Run with highest privileges
  • Configure for: Choose your operating system

On the Triggers screen click on new and set the following:

  • Begin the task: On an event
  • Log: Microsoft-Windows-Backup/Operational
  • Source: Backup
  • Event ID: 4

On the Actions screen click new and configure the following:

  • Action: Start a program
  • Program/script: C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe
  • Add arguments: Path to the script from step 1. Example c:\it\AD-Backup-sucess.ps1

Click ok and the task setup is complete.

Поддерживаемые методы резервного копирования Active Directory на контроллерах домена под управлением Windows Server 2012 и более поздних версий

Windows Server 2012 добавлена поддержка идентификатора поколения Hyper-Visor (GenID). Это позволяет виртуальному гостю обнаруживать тома диска с новым идентификатором и реагировать на новый GenID. В Active Directory службы каталогов реагируют так, как если бы контроллер домена был восстановлен из резервной копии. Затем создается новый идентификатор вызова. Используя новый идентификатор вызова, экземпляр базы данных может безопасно повторно ввести репликацию в лесу.

Это один из сценариев, описанных в статье Развертывание и настройка виртуализированного контроллера домена.

Установка и Настройка службы DNS-сервера

если контроллер домена, восстановленный из резервной копии, выполняется Windows сервере 2003, можно установить DNS-сервер без подключения контроллера домена к любой сети.

Установка и Настройка службы DNS-сервера

  1. откройте мастер Windows компонентов. Чтобы открыть мастер, сделайте следующее:

    • Щелкните Пуск, нажмите Панель управления, а затем Установка и удаление программ.
    • щелкните добавить или удалить Windows компоненты.
  2. В окне компоненты установите флажок Сетевые службы и нажмите кнопку сведения.

  3. В области «Сетевые службы» установите флажок Служба доменных имен (DNS) , нажмите кнопку ОК, а затем нажмите кнопку Далее.

  4. При появлении запроса в поле Copy files from (копирование файлов из) введите полный путь к файлам распространения и нажмите кнопку ОК.

    После установки выполните следующие действия, чтобы настроить DNS-сервер.

  5. Нажмите кнопку Пуск, укажите пункт все программы, затем Администрирование и щелкните DNS.

  6. Создайте зоны DNS для тех же доменных имен DNS, которые были размещены на DNS-серверах до критического сбоя. Дополнительные сведения см. в разделе Добавление зоны прямого просмотра ( https://go.microsoft.com/fwlink/?LinkId=74574 ).

  7. Настройте данные DNS в том виде, в котором они существовали до критического сбоя. Пример:

    • Настройте зоны DNS, которые будут храниться в AD DS. Дополнительные сведения см. в разделе Изменение типа зоны ( https://go.microsoft.com/fwlink/?LinkId=74579 ).
    • Настройте зону DNS, которая является полномочным для записей ресурсов локатора контроллеров доменов (локатора контроллера домена), чтобы разрешить безопасное динамическое обновление. Дополнительные сведения см. в разделе разрешение только безопасных динамических обновлений ( https://go.microsoft.com/fwlink/?LinkId=74580 ).
  8. Убедитесь, что родительская зона DNS содержит записи ресурсов делегирования (записи ресурсов сервера имен (NS) и узлов (A)) для дочерней зоны, размещенной на этом DNS-сервере. Дополнительные сведения см. в разделе Создание делегирования зоны ( https://go.microsoft.com/fwlink/?LinkId=74562 ).

  9. После настройки DNS в командной строке введите следующую команду и нажмите клавишу ВВОД:

    net stop netlogon

  10. Введите следующую команду и нажмите клавишу ВВОД.

    net start netlogon

    Примечание

    Команда Net Logon регистрирует записи ресурсов локатора контроллеров домена в DNS для этого контроллера домена. Если служба DNS-сервера устанавливается на сервере в дочернем домене, этот контроллер не сможет немедленно зарегистрировать свои записи. Это связано с тем, что в настоящее время он изолирован как часть процесса восстановления, а его основной DNS-сервер — корневой DNS-сервер леса. Настройте этот компьютер с тем же IP-адресом, который использовался до аварии, чтобы избежать сбоев поиска в службе контроллера домена.

Жизненный цикл объекта Active Directory

Итак, почему же так важно понимать, как функционируют системы более ранних версий? Потому что современная логика и привычная функциональность в этих случаях неприменимы. До появления Windows Server 2008 R2 жизненный цикл объектов Active Directory выглядел следующим образом:. Удаление объекта Active Directory не приводит к его физическому удалению – а происходит вот что:

Удаление объекта Active Directory не приводит к его физическому удалению – а происходит вот что:

  1. Active Directory скрывает удаленный объект, меняя значение атрибута isDeleted на TRUE.
  2. Затем большинство атрибутов объекта сбрасывается, а сам объект переименовывается и перемещается в специальный контейнер (CN=Deleted Objects). С этого момента объект получает статус «tombstone», и стандартные средства Active Directory не знают о его существовании.
  3. В этом специальном состоянии объект находится в течение установленного периода (60 дней в Windows Server 2000/2003 и 180 дней в Windows 2003 SP1/2008). Это делается, чтобы гарантировать успешное выполнение репликации данных в системе.
  4. По окончании отведенного времени существования в состоянии «tombstone» осуществляется вызов специального процесса (так называемый сборщик мусора), который физически удаляет объект из базы данных.

И вот здесь возникает вопрос: если «tombstone» объект не удаляется физически в течение некоторого времени, нельзя ли его восстановить? Коротко говоря — можно. Хотя такой механизм удаления объектов не был предназначен для использования в качестве временной корзины, а удаленные объекты не предполагалось восстанавливать, технически это возможно. Далее я расскажу, как это можно сделать.

Как работает ShadowCoerce

Для ShadowCoerce дос­тупен PoC, который демонс­три­рует зло­упот­ребле­ние эти­ми фун­кци­ями. Исполне­ние кода зас­тавля­ет учет­ную запись кон­трол­лера домена зап­росить общий ресурс NETLOGON или SYSVOL из сис­темы, находя­щей­ся под кон­тро­лем зло­умыш­ленни­ка. При­нуди­тель­ная аутен­тифика­ция выпол­няет­ся через SMB, в отли­чие от дру­гих подоб­ных методов при­нуж­дения (PrinterBug и PetitPotam).

При экс­плу­ата­ции уяз­вимос­ти NTLMv2-хеш учет­ной записи хос­та кон­трол­лера домена ока­зыва­ется зах­вачен. Затем этот хеш переда­ется в центр сер­тифика­ции, что­бы зарегис­три­ровать сер­тификат. Пос­ле чего его мож­но исполь­зовать для аутен­тифика­ции на кон­трол­лере домена через служ­бу Kerberos.

В жур­нале событий кон­трол­лера домена видим, как запус­кает­ся сам про­цесс и служ­ба VSS.

Под­клю­чение к сетево­му ресур­су от име­ни userЗа­пуск про­цес­са fssagent и служ­бы VSS

Да­вай раз­берем сам про­цесс ата­ки ShadowCoerce.

Для ее про­веде­ния зло­умыш­ленник выпол­няет сле­дующие дей­ствия.

  1. Под­клю­чает­ся к сетево­му ресур­су с помощью экс­пло­ита и зло­упот­ребля­ет фун­кци­ями и  в про­токо­ле MS-FSRVP.
  2. По­луча­ет NTLMv2-хеш от кон­трол­лера домена (SMB). Вре­донос­ный код при­нуж­дает учет­ную запись кон­трол­лера домена к аутен­тифика­ции по про­токо­лу SMB на зах­вачен­ном компь­юте­ре.
  3. Пе­ренап­равля­ет хеш в центр сер­тифика­ции (LDAP).
  4. По­луча­ет сер­тификат в Base64.

Типичное поведение, возникающее при восстановлении резервной копии состояния системы с поддержкой Active Directory

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

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

Идентификатор вызова определяет версию или экземпляр базы данных Active Directory, запущенной на заданном контроллере домена.

При восстановлении Active Directory на контроллере домена с помощью API и методов, разработанных и протестированных корпорацией Майкрософт, идентификатор вызова правильно сбрасывается на восстановленном контроллере домена. контроллеры домена в лесу получают уведомление о сбросе вызова. Поэтому они соответствующим образом корректируют свои значения высоких водяных знаков.

Обнаружение отката USN на контроллере домена Windows Server

Так как откат usN трудно обнаружить, Windows Сервер 2003 SP1 или более поздний контроллер домена версии регистрировать событие 2095, когда контроллер домена источника отправляет ранее признанный номер USN контроллеру домена назначения без соответствующего изменения в коде вызовов.

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

На контроллере домена записывают сообщения событий, похожие на следующие, если верны следующие условия:

  • Контроллер домена источника отправляет ранее признанный номер USN контроллеру домена назначения.
  • Соответствующие изменения в ID-вызове не изменяются.

Эти события могут быть запечатлены в журнале событий службы каталогов. Однако они могут быть перезаписаны до наблюдения администратора.

Вы можете подозревать, что откат USN произошел. Однако в журнале событий службы каталогов не видятся соотносимые события.
В этом сценарии проверьте запись реестра Dsa Not Writable. В этой записи приводится судебно-медицинская экспертиза о том, что произошло откат usN.

  • Подкайка реестра:
  • Запись реестра: Dsa Not Writable
  • Значение: 0x4

Удаление или вручную изменение значения записи записи реестра Dsa Not Writable ставит контроллер отката домена в постоянно неподдержку. Поэтому такие изменения не поддерживаются. В частности, изменение значения удаляет поведение карантина, добавленное кодом обнаружения отката usN. Разделы Active Directory на контроллере отката домена будут постоянно несовместимы с прямыми и транзитными партнерами репликации в том же лесу Active Directory.

Очистка корня DFS

Если вы используете корень DFS а тем более если вы используете репликацию в DFS, то у вас после восстановления службы FRS может сохраниться событие 13508 в журнале, а DCDIAG в результатах может выдавать такую ошибку «Conflict Mangled Value». Это происходит из-за разных причин, но в основном из-за вручную удаленных объектов репликации.

Если ссылок в корне DFS не много, то самым быстрым способом будет пересоздать все ссылки, очистив дерево. При этом очистив дерево от ненужных объектов, а также очистив реестры всех контроллеров домена. Тогда при повторном создании корня DFS все объекты дерева и ветки реестра будут созданы заново.

Итак, что я удаляю в такой ситуации:

Сначала я запускаю оснастку «Distributed File System». У меня всего две корневых ссылки, в одной из них включена репликация.

Затем я удаляю целевые папки

Если вы удаляете последнюю целевую папку для корневой ссылки, то при этом удаляется и сама ссылка.

Удаляю оставшуюся корневую ссылку

Теперь удаляю корневые целевые папки, папку с текущего контроллера удаляю последней

Удаление последней целевой папки удаляю весь корень DFS.

Все, корень DFS удален, но в дереве все объекты остались, удаляем и их. Делаю это с помощью ADSIedit.

Первый объект, который я удаляю, это объектCN=DFS Volumes,CN=File Replication Service,CN=System,DC=test,DC=com. Удаляю его полностью со всем содержимым.

Второе место в котором я чищу ссылки это объект «CN=NTFRS Subscriptions» для каждого контроллера домена, который участвовал в репликации. В моем случае:

«CN=DFS Volumes\0ACNF:98627048-5ae0-492c-b929-911c72c54100,CN=NTFRS Subscriptions,CN=DC1,OU=Domain Controllers,DC=test,DC=com» — для контроллера DC1

«CN=DFS Volumes\0ACNF:2d3688fd-094c-4bdd-b017-8e2b29a51c5f,CN=NTFRS Subscriptions,CN=DC2,OU=Domain Controllers,DC=test,DC=com» — для контроллера DC2

Так как контроллер DC3 не учувствовал в репликации ссылок DFS, то у него и не создавались подобные объекты.

После очистки дерева необходимо почистить реестр каждого контроллера домена. Запускаю regedit и открываю ветку реестра «HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Replica Sets». В этой ветке должно быть несколько реплик, которые относятся к службе FRS. Нахожу реплики, которые относятся к DFS. У этих реплик значение параметра «Replica Set Type» будет равно «DFS»

Репликиудаляю в двух ветках реестра:

  • «HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Replica Sets»
  • «HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets»

Все реплики удалены

Аналогично удаляю на всех контроллерах домена.

После создания корня DFS заново все выглядит вот так:

А в системных событиях появились записи о событиях 13553 и 13554 говорящие о успешном запуске репликации ссылок DFS.

Понравилась статья? Поделиться с друзьями:
Быть в курсе нового
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: