- Важность резервного копирования состояния системы и поддерживаемые методы защиты контроллеров домена.
- Различия между авторитетным и неавторитетным восстановлением в Active Directory и когда следует использовать каждый из них.
- Подробные процедуры восстановления физических и виртуальных контроллеров домена, включая проблемы с SYSVOL и откат USN.
- Стратегии смягчения последствий: принудительное снижение производительности, очистка метаданных и реконструкция контроллера домена.
Когда контроллер домена повреждается или восстанавливается некорректно, это вызывает огромный страх: Сбои при входе в систему, прекращение применения групповых политик и сбои в репликации практически без каких-либо подсказок.Хорошая новость заключается в том, что существуют четкие процедуры восстановления физического или виртуального контроллера домена при условии соблюдения общепринятых методов резервного копирования и восстановления.
В современных средах Windows Server восстановление контроллера домена требует хорошего понимания таких концепций, как... Состояние системы, авторитетное/неавторитетное восстановление, откат SYSVOL, DFSR/FRS и USN.Если подходить к этим проблемам поспешно или с использованием несовместимых методов визуализации, результатом может стать множество скрытых несоответствий, которые очень трудно диагностировать.
Почему крайне важно надлежащим образом защитить и восстановить контроллер домена.
Active Directory — это основа аутентификации и авторизации в домене Windows.В ней хранятся данные о пользователях, компьютерах, группах, доверительных отношениях, групповых политиках, сертификатах и других важных элементах. Эта информация находится преимущественно в базе данных. ntds.этосвязанные с ними файлы журналов и папка СИСВОЛсреди прочих компонентов, составляющих так называемое «состояние системы».
Состояние системы включает в себя, помимо прочего, Файлы журналов и данные Active Directory, реестр Windows, системный том SYSVOL, база данных сертификатов (если существует центр сертификации), метабаза IIS, загрузочные файлы и защищенные компоненты операционной системы.Следовательно, любая серьезная стратегия обеспечения непрерывности бизнеса должна включать регулярное резервное копирование состояния системы каждого центра обработки данных.
Когда происходит фактическое повреждение базы данных Active Directory, серьезный сбой репликации или проблема с разрешения на СИСВОЛКонтроллер домена может перестать обрабатывать запросы, не запустить службы Active Directory или вызвать каскадные ошибки во всем лесу. В таких случаях Быстрое и надлежащее восстановление — это то, что отличает серьезный инцидент от затяжной катастрофы..
Прежде чем приступать к восстановлению, крайне важно различать реальную проблему с базой данных и более обыденные сбои. Очень часто... Причина кроется в DNS, изменениях в сети, брандмауэрах или маршрутах, измененных с помощью таких инструментов, как... команда netshПоэтому, прежде чем вносить изменения в базу данных Active Directory, целесообразно сначала исключить эти факторы.
Основные инструменты диагностики и контроля репликации
В случае обнаружения признаков повреждения данных или сбоев репликации, первым разумным шагом является проверка состояния среды с помощью встроенных инструментов. DCDiag, Repadmin, ReplMon (в более старых версиях) и Просмотр событий Они — ваши лучшие союзники, прежде чем рассматривать возможность агрессивной реставрации.
В лице DCDiag Выполняется общая проверка всех контроллеров домена, выявляются проблемы с репликацией, DNS, службами AD DS и т. д. Репамдин Это позволяет просматривать статус репликации, партнеров по репликации, водяные знаки USN и обнаруживать постоянные объекты. В более старых версиях Windows... ReplMon Это позволяло графически отображать ошибки репликации в рамках домена.
В дополнение к этим инструментам, необходимо просмотреть журнал событий на предмет наличия разделов «Службы каталогов» и «Репликация DFS». События, подобные 467 и 1018, указывают на фактическое повреждение базы данных., в то время как события 1113/1115/1114/1116 связаны с включением или отключением репликации ввода/вывода.
Если необходимо временно изолировать подозреваемого в коррупции, чтобы предотвратить распространение ею коррупции, мы можем это сделать. Отключите входящую и исходящую репликацию с помощью Repadmin.:
repadmin /options DCNAME +DISABLE_INBOUND_REPL
repadmin /options DCNAME +DISABLE_OUTBOUND_REPL
А чтобы восстановить нормальную репликацию, просто удалите эти параметры:
repadmin /options DCNAME -DISABLE_INBOUND_REPL
repadmin /options DCNAME -DISABLE_OUTBOUND_REPL
Поддерживается резервное копирование состояния системы на контроллерах домена.
Для того чтобы иметь возможность гарантированно восстановить DC, необходимо иметь Резервное копирование состояния системы выполняется с использованием инструментов, совместимых с Active Directory.Эти инструменты используют API резервного копирования и восстановления Microsoft, а также службу теневого копирования томов (VSS) в поддерживаемом режиме.
К числу наиболее распространенных решений относятся: Резервное копирование Windows Server, сторонние решения, интегрированные с VSS (например, NAKIVO, Backup Exec и другие).или более старые коммунальные услуги, такие как Ntbackup в Windows 2000/2003. Во всех случаях необходимо соблюдать API Active Directory для обеспечения согласованности базы данных и ее реплик после восстановления.
В Windows Server 2012 и более поздних версиях появилось важное новое дополнение: Идентификатор поколения Hyper-V (GenID)Этот идентификатор позволяет виртуальному контроллеру домена обнаружить, что его диск был откачен до предыдущей точки во времени. В этом случае, AD DS генерирует новый InvocationID и обрабатывает ситуацию так, как если бы она была восстановлена из успешной резервной копии.уведомить своих партнеров по репликации, что позволит безопасно перезаписывать данные без отката USN.
Крайне важно уважать надгробный камень жизньЭто показывает, как долго можно использовать резервную копию состояния системы без риска повторного добавления объектов, удаленных много лет назад. В современных версиях это обычно 180 дней, и рекомендуется создавать резервные копии не реже чем каждые 90 дней для поддержания достаточного запаса прочности.
Несанкционированные методы, вызывающие сбои в работе ВМС США.
Одной из наиболее опасных причин скрытых несоответствий в Active Directory является Откат ВМС СШАТакая ситуация возникает, когда содержимое базы данных Active Directory откатывается с использованием неподдерживаемого метода, при этом идентификатор вызова (InvocationID) не восстанавливается, а партнеры по репликации не уведомляются.
Типичный сценарий — загрузка контроллера домена с... образ диска или снимок виртуальной машины, сделанный в прошлом.без использования совместимого средства восстановления системы. Или скопируйте файл Ntds.dit напрямую, используйте программы для создания образов дисков, такие как Ghost, загрузитесь с поврежденного зеркала диска или повторно примените снимок хранилища на уровне массива.
В этих случаях контроллер домена продолжает использовать тот же InvocationID, что и раньше, но его Локальный счётчик ВМС США идёт вспять.Другие контроллеры домена помнят полученные изменения вплоть до высокого значения USN, поэтому, когда контроллер домена, выполнивший откат, пытается отправить обратно уже распознанные значения USN, Их партнеры считают, что они идут в ногу со временем, и перестают принимать конкретные изменения..
В результате происходят определенные модификации (например, Создание пользователей, изменение паролей, регистрация устройств, изменение членства в группах, новые DNS-записи.Эти ошибки никогда не воспроизводятся с восстановленного центра обработки данных в остальную сеть, но инструменты мониторинга могут не показывать явных ошибок. Это крайне опасный скрытый сбой.
Для обнаружения подобных ситуаций драйверы Windows Server 2003 SP1 и более поздних версий записывают соответствующие данные в журнал. Событие 2095 Службы каталогов Когда обнаруживается, что удалённый контроллер домена отправляет уже подтверждённые USN без изменения InvocationID, система Это изолирует затронутый контроллер домена, приостанавливает работу Netlogon и предотвращает дальнейшие изменения. Это не удалось воспроизвести корректно.
В качестве дополнительного судебно-медицинского доказательства это может для ознакомления в Реестре ключ HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters и значения DSA недоступен для записиЕсли это значение установлено (например, 0x4), это указывает на то, что контроллер домена был переведен в состояние, запрещающее запись, в результате обнаружения обратной полярности USN. Изменение этого значения вручную для его "исправления" совершенно не поддерживается. и оставляет базу данных в постоянно несогласованном состоянии.
Общие стратегии в случае повреждения или восстановления контроллера домена
Процедура, которую следует соблюдать при работе с поврежденным или неправильно восстановленным контроллером домена, зависит от нескольких факторов: Количество контроллеров домена в домене/лесу, наличие действительных копий состояния системы, наличие других ролей (FSMO, CA, глобальный каталог) и временной масштаб проблемы..
Если в домене есть другие здоровые ДК и На поврежденном контроллере домена отсутствуют уникальные критически важные данные.Наиболее быстрым и чистым вариантом обычно является удаление контроллера домена и его переустановка. Однако, если это единственный контроллер домена или если на нем размещены конфиденциальные роли и данные, потребуется более тщательное восстановление (с использованием авторитетных или неавторитетных систем).
В общих чертах, варианты следующие:
- Принудительно понизьте статус неисправного контроллера домена и удалите его из домена.Затем следует очистка метаданных и, при необходимости, новое продвижение.
- Восстановите систему из действующей резервной копии состояния системы., как в авторитетном, так и в неавторитетном режиме.
- Восстановите контроллер домена с другого компьютера, используя IFM (установка с носителя).когда нет актуальной копии, но есть другие корректные контроллеры домена.
- Использование снимка виртуального центра обработки данных в формате VHD.Применив дополнительные шаги для пометки базы данных как восстановленной из резервной копии (База данных восстановлена из резервной копии = 1) и обеспечив генерацию нового InvocationID.
Если есть явные подозрения на откат USN (например, после восстановления виртуальной машины из снимка без соблюдения рекомендаций по передовой практике) и появляется событие 2095, наиболее разумным действием обычно является следующее: Выведите этот контроллер домена из эксплуатации и не пытайтесь "починить" его на месте., если только нет возможности восстановить резервную копию состояния поддерживаемой системы, созданную до отката.
Принудительное понижение статуса и очистка метаданных.
Когда контроллер домена настолько поврежден, что его невозможно понизить в статусе обычным способом, или он был неправильно восстановлен, и вы хотите предотвратить распространение проблем, вы можете прибегнуть к следующему методу: принудительное понижение в должности.
В более старых версиях эта операция выполнялась с помощью dcpromo /forceremoval, что Удалите роль AD DS, не пытаясь воспроизвести изменения в остальной части леса.В современных средах мастер настройки изменился, но концепция осталась прежней: удалить проблемный контроллер домена из топологии Active Directory, не допуская его дальнейшего участия в репликации.
После принудительного понижения версии обязательно выполнение команды с работоспособного контроллера домена. очистка метаданных с помощью инструмента NtdsutilЭтот процесс удаляет все ссылки на удаленный контроллер домена (объекты настроек NTDS, ссылки DNS и т. д.) из базы данных Active Directory, так что Никаких «призрачных» остатков, способных запутать репликацию, не осталось..
Если у неисправного контроллера были роли FSMO (эмулятор PDC, мастер RID, мастер схемы и т. д.), потребуется... передает или захватывает эти роли В зависимости от ситуации, до или после понижения статуса контроллера домена можно перенести его на другой контроллер домена. Позже на этом сервере можно переустановить операционную систему и снова повысить его статус до чистого контроллера домена.
Восстановление с использованием неавторитетных и авторитетных методов в Active Directory
При наличии достоверной копии состояния системы восстановление Active Directory может быть выполнено двумя способами: неавторитетный и авторитетныйПонимание разницы между ними — ключ к тому, чтобы не упустить недавние изменения или не скопировать устаревшие данные.
В одном неавторитетная реставрацияТочка подключения возвращается к предыдущей точке, но как только она запускается, Остальные контроллеры домена считаются эталонными.Иными словами, после запуска восстановленный контроллер домена запрашивает входящую репликацию и обновляет свою базу данных, добавляя все недостающие изменения из других контроллеров домена. Этот вариант идеально подходит, когда Есть и другие исправные контроллеры, и мы хотим, чтобы восстановленный догнал их по производительности..
В одном авторитарная реставрацияОднако прямо указано, что Восстановленные данные должны оставаться в силе. по сравнению с другими контроллерами домена. Это означает, что после восстановления восстановленные объекты будут иметь более высокий номер версии, что заставит их реплицироваться с этого контроллера домена на остальную часть домена. Это подходящий выбор, когда Мы случайно удалили объекты или организационные подразделения, или же хотим восстановить содержимое SYSVOL и групповых политик до предыдущего состояния и обеспечить их репликацию..
Важная деталь: авторитетное восстановление не обязательно должно применяться ко всей базе данных. С помощью этой утилиты... Ntdsutil Отдельные объекты, поддеревья (например, организационная единица) или весь домен могут быть помечены как авторитетные. Это обеспечивает значительную гибкость, например, для следующих целей: Получить только пользователя, группу, организационное подразделение или поддерево dc=mycompany,dc=local.
Общая процедура восстановления состояния системы в центре обработки данных.
Базовая схема восстановления состояния системы центра обработки данных (физического или виртуального) с помощью совместимых инструментов всегда схожа: Загрузитесь в режим восстановления служб каталогов (DSRM), восстановите данные с помощью инструмента резервного копирования и перезапустите систему..
Вкратце, типичные шаги для виртуального контроллера домена будут следующими:
- Запустите виртуальную машину в диспетчере загрузки Windows. (Обычно нажатием клавиш F5/F8 во время запуска). Если виртуальная машина управляется гипервизором, может потребоваться приостановить работу машины для захвата нажатия клавиши.
- В дополнительных параметрах загрузки выберите режим восстановления служб каталогов (Режим восстановления служб каталогов). В этом режиме сервер запускается без функционального монтирования базы данных Active Directory.
- Войдите в систему, используя учетную запись администратора DSRM. определяется в процессе первоначального повышения роли контроллера домена (а не с помощью стандартной учетной записи администратора домена).
- Запустите инструмент резервного копирования используется (Windows Server Backup, NAKIVO или другая совместимая программа) и выбирается восстановление состояния системы до желаемой точки резервного копирования.
- Завершите работу мастера восстановления и Перезапустите DC в обычном режиме.При неавторизованном восстановлении сервер инициирует репликацию, чтобы синхронизироваться с другими контроллерами домена.
Когда мы говорим о сторонних продуктах для резервного копирования, таких как NAKIVO Резервное копирование и репликацияВ режиме «с учетом приложений» устройство способно распознать, что восстанавливаемое устройство является центром обработки данных. автоматически корректирует процесс для сохранения согласованности ADВ большинстве случаев при наличии нескольких контроллеров достаточно полного восстановления в неавторитетном режиме.
Авторитетная реставрация с помощью Ntdsutil
Если вы хотите, чтобы изменения на восстановленном контроллере домена имели приоритет над остальными, необходимо добавить дополнительный шаг после неавторитетного восстановления: Используйте Ntdsutil для пометки объектов как авторитетных..
Упрощенная схема будет выглядеть так:
- Восстановите состояние системы стандартным способом, оставив сервер в рабочем состоянии. режим DSRM (Пока не перезапускайте устройство в обычном режиме).
- Открыть командная строка с повышенными привилегиями и беги
ntdsutil. - Активируйте экземпляр Active Directory с помощью активировать экземпляр ntds.
- Вхождение в контекст авторитетной реставрации с авторитетное восстановление.
- Используйте такие команды, как
restore object <DN_objeto>orestore subtree <DN_subarbol>где DN — это отличительное имя объекта или поддерева, которое необходимо восстановить авторитетным образом. - Подтвердите транзакцию, и после ее завершения... Перезапустите DC в обычном режиме. таким образом, отмеченные объекты будут реплицироваться с приоритетом над остальными объектами домена.
Этот вид реставрации требует особой осторожности. Если весь домен восстановлен авторитетным способом, а резервная копия устарела,Существует риск потери легитимных изменений, внесенных после резервного копирования (например, создание пользователей, изменение паролей или групп). Поэтому обычно ограничивают восстановление только строго необходимыми объектами или структурами.
Восстановление и резервирование SYSVOL (FRS против DFSR)
SYSVOL — это ключевой компонент контроллера домена: В нем хранятся сценарии автозапуска, групповые политики, шаблоны безопасности и другие важные общие ресурсы.Сбои в настройках прав доступа, повреждение файлов или проблемы с репликацией могут сделать групповые политики непригодными для использования или вызвать некорректную работу на клиентских компьютерах.
В зависимости от версии Windows Server и состояния миграции, репликация SYSVOL может осуществляться следующим образом: FRS (служба репликации файлов) или DFSR (Distributed File System Replication)Процедура авторитетного восстановления SYSVOL различается в зависимости от того, какая из двух систем используется.
Для этого можно проверить соответствующий ключ в реестре. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalStateЕсли этот подраздел существует и его значение равно 3 (УДАЛЕНО), используется DFSR. Если он не существует или его значение отличается, мы имеем дело со средой, в которой по-прежнему используется FRS.
В средах с FRS авторитетное восстановление SYSVOL обычно включает корректировку значения. Бурфлагс en HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process присваивать определенное значение (например, 212 в десятичной системе / 0xD4 в шестнадцатеричной системе), чтобы указать, что этот DC является авторитетным источником.
Если репликация SYSVOL осуществляется с помощью DFSR, процесс становится несколько сложнее: он включает в себя использование ADSIEdit для изменения объектов подписки SYSVOL (атрибутов) msDFSR-Enabled y msDFSR-Options) на авторитетном контроллере домена, а на остальных принудительно включить репликацию Active Directory, выполнить dfsrdiag pollad и подтвердить в журнале событий появление события 4114, 4602, 4614 и 4604 подтверждают, что SYSVOL был инициализирован и реплицирован корректно.
Восстановление виртуальных контроллеров домена из VHD-файлов
В виртуализированных средах очень часто встречаются следующие случаи: VHD/VHDX файлы контроллеров доменаЕсли у вас нет резервной копии состояния системы, но есть рабочий «старый» VHD-файл, вы можете смонтировать новый контроллер домена с этого диска, хотя делать это нужно очень осторожно, чтобы избежать отката USN.
Рекомендация Не запускайте эту виртуальную машину напрямую в обычном режиме.Вместо этого следует загрузиться с предыдущего VHD-файла. ДСРМОткройте редактор реестра и перейдите по следующему пути: HKLM\SYSTEM\CurrentControlSet\Services\NTDS\ParametersТам целесообразно проверить значение. Количество предыдущих реставраций DSA (если он существует) и, прежде всего, создайте новое значение типа DWORD (32-битное) с именем База данных восстановлена из резервной копии. со значением 1.
Выбрав это значение, Active Directory получает уведомление о том, что база данных была восстановлена из резервной копии, что принудительно запускает процесс восстановления. Создание нового InvocationID при загрузке в обычном режиме.Таким образом, другие контроллеры домена интерпретируют это как новый экземпляр и корректно настраивают свои водяные знаки репликации, предотвращая откат USN.
После перезагрузки контроллера домена в обычном режиме рекомендуется проверить журнал событий, в частности, журнал следующих событий: службы каталогов, ищу событие 1109Это событие подтверждает изменение атрибута InvocationID сервера и отображает старое и новое значения, а также наивысший USN на момент резервного копирования. Кроме того, отображается значение Количество предыдущих реставраций DSA Его следовало увеличить на единицу.
Если эти события не появляются или их количество не увеличивается, следует проверить версии операционной системы и пакеты обновлений, поскольку Определенные модели восстановительного процесса зависят от конкретных участков.В любом случае, всегда рекомендуется работать с копией оригинального VHD-файла, сохраняя нетронутую версию на случай, если процесс потребуется повторить.
Практические сценарии и дополнительные рекомендации
На практике проблемы коррупции или ненадлежащего восстановления часто возникают в повседневной жизни: Ручное изменение разрешений в SYSVOL, попытки обновления шаблонов ADMX/ADML, изменения групповых политик, которые не реплицируются.и т. д. При ручном изменении общих папок относительно легко могут возникнуть несоответствия, например: SYSVOL\Policies без учета возможности воспроизведения.
В случае нарушения репликации основного контроллера домена (как данных Active Directory, так и SYSVOL) и появления сообщений мониторинга типа «Восстановление базы данных было выполнено с использованием неподдерживаемой процедуры. Возможная причина: откат USN.», разумнее всего поступить так:
- Проверить с dcdiag y реадмин масштабы ошибок и наличие «постоянных объектов».
- Проверьте событие 2095 и его значение. DSA недоступен для записи в Реестре.
- Оцените, возможно ли это. Удалите этот DC и соберите его заново. (Если есть три или более других здоровых ДК, это обычно лучший вариант).
- Если это единственный DC или критик, поднимите вопрос. восстановление состояния системы из совместимой резервной копии, в идеале — свежей и относящейся к периоду удаления файла.
В доменах с несколькими контроллерами настоятельно рекомендуется, чтобы контроллеры домена были максимально "чистыми": без дополнительных ролей или локальных пользовательских данныхТаким образом, если один из дисков выйдет из строя или будет поврежден, можно будет отформатировать новый и продвинуть его на основе другого контроллера домена или через IFM, что значительно упростит восстановление.
Кроме того, стоит помнить о таких ограничениях, как... Копии состояния системы действительны только в течение периода "надгробия". (60, 90, 180 дней в зависимости от конфигурации), чтобы избежать восстановления удаленных объектов, и чтобы ключи NTLM машины менялись каждые 7 дней. При восстановлении очень старых данных может потребоваться следующее: сбросить командные учетные записи проблемы, возникающие из-за «Пользователей и компьютеров Active Directory» или даже из-за удаления и повторного подключения их к домену.
Наличие процедур для регулярного резервного копирования состояния системы, Четко задокументируйте роли FSMO, глобальный каталог и топологию репликации.Тестирование этапов восстановления в лабораторных условиях — это вложение времени, которое позволит избежать множества проблем в тот день, когда контроллер домена будет поврежден или кто-то необдуманно применит моментальный снимок.
Страстный писатель о мире байтов и технологий в целом. Мне нравится делиться своими знаниями в письменной форме, и именно этим я и займусь в этом блоге: покажу вам все самое интересное о гаджетах, программном обеспечении, оборудовании, технологических тенденциях и многом другом. Моя цель — помочь вам ориентироваться в цифровом мире простым и интересным способом.

