Восстановление GP с удаленным DC после резервного копирования

Вопрос или проблема

Буду очень благодарен за любую помощь.

Краткая предыстория:
У нас 4 контроллера домена (DC), работающих в 3 местах. Мы столкнулись с проблемой с DFS-шарами и их репликацией. Я работал с представителем Microsoft, чтобы удалить и заново создать DFS-шары. В ходе этого процесса мы воспользовались возможностью, чтобы произвести некоторые очистки и удалили старый tombstoned DC, который был отключен какое-то время. Пока специалист MS помогал мне, нам нужно было очистить некоторые данные ADSI. Проблема с DFS была решена, и всё было в порядке, пока я недавно не заметил, что групповая политика не применяется. Просмотрев ситуацию, я обнаружил, что файл gpi.ini и все .xml файлы для каждой группы отсутствуют. Я предполагаю, что в процессе исправления мы что-то нарушили, связанное с групповой политикой.

У меня есть виртуализированная резервная копия одного из DC. Я открыл GPMC в виртуализированной резервной копии, сделал резервное копирование одной из групповых политик и восстановил эту групповую политику обратно на активный DC через GPMC, чтобы проверить теорию. Всё выглядело хорошо. Когда я попытался экспортировать политику всего домена, это удалось, но с несколькими предупреждениями.

“GPO: Default Domain Controllers Policy… Успешно, но обратите внимание на следующие проблемы:
Безопасный принципал [s-1-5-82….], упомянутый в расширении [Безопасность], не может быть разрешён, но задача продолжится. В будущем вы можете использовать таблицу миграции, чтобы отобразить или удалить этот безопасный принципал. Подробности: Сопоставление между именами учетных записей и идентификаторами безопасности не было выполнено.”

Я получил то же предупреждение три раза.

Остальные групповая политика (GPO) была завершена без проблем/предупреждений.

Вот мои вопросы.
A) Является ли это предупреждение следствием того, что этот единственный DC отключен от остальной части домена, и предупреждение вполне объяснимо.
и, возможно, более важно
B) Будет ли восстановление всей GPO на активный DC иметь какую-либо ссылку на tombstoned DC, который мы удалили в процессе очистки DFS? Я не хочу вводить проблему в процессе восстановления данных групповой политики…. если это имеет смысл. Ничто в какой-либо из групповых политик не указывает на отключенный DC для файлов или чего-либо, связанного с этим сервером. Это был просто DC для удаленного офиса, использовавшийся для DFS-шар.

Надеюсь, это имело смысл… заранее спасибо за любые советы.

Ответ или решение

Конечно, разберем ситуацию детально и по шагам. Ваш случай довольно распространен при администрировании сетей Windows, особенно учитывая работу с доменными контроллерами (DC) и политиками групп (GPO).

Теория

Когда один из доменных контроллеров удаляется, особенно если он был offline или tombstoned, это может затронуть многие аспекты работы Active Directory, включая Group Policy. Политики групп используют объекты безопасности, которые привязаны к SID (Security Identifier), и когда эти обязательства нарушаются, системы не могут всегда корректно резолвить эти идентификаторы, что приводит к предупреждениям, подобным вашему.

Ваше сообщение об ошибке связано с тем, что у GPO есть ссылки на объект безопасности, которые система на данный момент не может разрешить. Это может происходить в том числе из-за того, что контроллер был отключен от домена.

Пример

Представьте, что у вас было два объекта безопасности, где один из них содержал ссылку на старый DC. Когда этот DC удален, любой объект, использовавший его как Security Principal, вызовет некоторые несовпадения, особенно если система пытается разрешить SID для проверки разрешений. Это похоже на проверку списка сотрудников в компании, где старые сотрудники, хотя и удалены из основного списка, все еще числятся в других базах данных. В итоге система не знает, как обработать их записи.

Применение

Теперь, учитывая вашу ситуацию:

A) По поводу предупреждения: да, вполне вероятно, что предупреждение вызвано разрывом связи. Когда DC становится недоступным, любые GPO, которые ссылаются на его SID, будут давать такие ошибки. SID, который система не может разрешить, зачастую связан с теми объектами безопасности, которые больше не могут быть подтверждены, поскольку DC, который их содержал, был удален.

B) Относительно связи между восстановлением всех GPO и удалением DC: если ваши политики не указывают ни на что, что было связано с удаленным контроллером напрямую (например, пути к DFS на том DC), то теоретически восстановление GPO не должно вызвать критических проблем. Однако всегда существует вероятность того, что старые ссылки могут остаться, особенно если какие-то объекты выдавали доверенность или права на основе удаленного DC. В вашем случае уже есть видимые лишние SID. Это полезно учесть при проведении операции.

Что можно сделать:

Использование миграционной таблицы. Это даст возможность конвертировать существующие SID в другой, корректный объем объектов безопасности, и этот инструмент может использоваться для подготовки восстановления GPO без потерь целостности.
Тестирование в изолированной среде. Сделайте клонирование активного домена в изолированной среде или sandbox-е и попробуйте восстановить GPO, чтобы убедиться, что никаких неожиданных проблем нет.
Обзор логов событий и предупреждений: тщательно изучите логи на предмет любых других предупреждений или ошибок, которые могут указать на дальнейшие проблемы или конфликты.

Таким образом, лучший подход — это улучшаеемое понимание механизма, тестирование в безопасных условиях и постепенное применение. Это поможет избежать внедрения потенциальных проблем и обеспечить стабильность вашей среды AD.