Миграция объектов между доменами Active Directory

В этой статье я расскажу о том, как правильно организовать процесс миграции пользователей и ресурсов между доменами Active Directory без прерывания доступа. В статье будут рассмотрены:

• общий подход к миграции
• как работает SID History
• сценарии миграции и подход к администрированию для каждого из них

Для понимания изложенного в данной статье материала требуется понимание предыдущей статьи — Построение ролевой модели в Active Directory.

Содержание

• Общий подход к миграции
• Сценарии миграции объектов Active Directory
  • Сценарий 0 — исходное состояние
  • Сценарий 1.1 — миграция пользователей в целевой домен
  • Сценарий 1.2 — создание новых пользователей в целевом домене
  • Сценарий 2.1 — развёртывание ресурсов в целевом домене
  • Сценарий 2.2 — развёртывание ресурсов в исходном домене
  • Сценарий 2.3 — миграция ресурсов в целевой домен
  • Сценарий 3 — все пользователи и ресурсы мигрированы
• Заключение
• Полезные ссылки

Общий подход к миграции

Пока компания работает в одном домене AD, необходимость в четкой ролевой модели с использованием AGULP не очевидна.

Если для компании настало время реструктуризации, слияний и поглощений, приведение ролевой модели к AGULP является необходимостью для обеспечения предсказуемой работы AD в сложных конфигурациях с несколькими лесами / доменами.

Использование ролевой модели на основе AGULP позволяет проводить процедуры миграции объектов AD так, как задумывалось разработчиками:

• Миграции пользователей и ресурсов могут проходить отдельными, слабо зависимыми друг от друга потоками
• При этом в любой момент времени доступ всех пользователей ко всем ресурсам сохраняется в прежнем объеме

Сценарии миграции объектов Active Directory

Рассмотрим возможные сценарии в период миграции Active Directory.

Сценарий 0 — исходное состояние

• пользователи и ресурсы находятся в исходном домене

Если ролевая модель ещё не приведена к AGULP, то это необходимо сделать на данном этапе, поскольку все рассмотренные далее сценарии подразумевают приведённую к AGULP ролевую модель.

Важное примечание

Встроенные группы, такие как: Domain Users, Domain Admins, Remote Desktop Users и другие, — не могут быть мигрированы в другой домен, поскольку их SID/RDN во всех доменах одинаков.

Из этого вытекает важное правило: не используйте встроенное группы для назначения разрешений. Если со своим предупреждением я опоздал… Для сохранения доступа пользователей во времена миграции вам необходимо перед миграцией переназначить все разрешения, со встроенных групп на обычные.

Полный список встроенных групп можно найти в статье Active Directory Security Groups.

Сценарий 1.1 — миграция пользователей в целевой домен

• часть пользователей мигрирована в целевой домен
• в исходном домене остались ресурсы, к ним необходимо сохранить доступ

Пользователи и группы должны мигрировать в новый домен с сохранением SID History и всех связей групп безопасности.

При обращениях пользователей, мигрированных в целевой домен, к ресурсам исходного домена, используется набор родных SID-ы из целевого домена и SID History:

• Набор родных SID-ов из целевого домена включает SID пользователя и SID-ы всех групп, в которых он состоит в целевом домене (Account Domain).
• SID History включает скопированные при миграции SID пользователя и SID-ы всех групп, в которых он состоял в исходном домене.
• SID-ы локальных групп (в том числе мигрированных c SID History), отфильтровываются при прохождении через доверительные отношения и не предъявляются в домене ресурса.
• Оставшиеся SID-ы проверяются на членство в локальных группах домена ресурса (Resource Domain). Если в домене ресурса обнаружены группы, в членах которых состоят предъявленные пользователем SID-ы, то SID-ы таких локальных групп включаются в токен доступа пользователя.
• Таким образом, результирующий токен доступа пользователя в домене ресурсов включает SID-ы из: Account Domain (user, global groups, universal groups), SID History (user, global groups, universal groups), Resource Domain (local groups).

Так как в ACL на ресурсах прописаны SID-ы групп доступа исходного домена, ресурсы идентифицируют мигрированных пользователей по описанному выше алгоритму, доступ мигрированных пользователей сохраняется в прежнем объеме, каким он был до миграции.

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

Сценарий 1.2 — создание новых пользователей в целевом домене

• часть пользователей мигрирована в целевой домен
• в целевом домене создаются новые пользователи

Описанные в предыдущих сценариях механизмы администрирования ресурсов должны сохраняться.

Создаваемых в целевом домене пользователей необходимо включать в мигрированные из исходного домена ролевые группы.

Администрирование групп (вложенность в группы доступа и другие ролевые группы) должно производится в исходном домене.

Для того, чтобы изменения в ролевых группах в исходном домене действовали в целевом домене требуется регулярно выполнять повторную миграцию групп из исходного домена в целевой с обновлением членства.

Сценарий 2.1 — развёртывание ресурсов в целевом домене

• часть пользователей мигрирована в целевой домен
• в целевом домене необходимо развёртывать новые ресурсы

Описанные в предыдущих сценариях механизмы администрирования ресурсов должны сохраняться.

Ресурсы, которые разворачиваются в целевом домене, должны иметь разрешения, назначенные на локальные группы в целевом домене в соответствии с моделью AGULP. В группы доступа к ресурсам должны быть включены:

• мигрированные ролевые группы в целевом домене (для доступа к ресурсам мигрированных и новых пользователей, созданных только в целевом домене)
• ролевые группы из исходного домена (для доступа к ресурсам еще не мигрированных пользователей)

Администрирование доступа к развернутым в целевом домене ресурсам должно осуществляется через группы доступа в целевом домене.

Сценарий 2.2 — развёртывание ресурсов в исходном домене

• часть пользователей мигрирована в целевой домен
• в исходном домене необходимо развёртывать новые ресурсы

Описанные в предыдущих сценариях механизмы администрирования ресурсов должны сохраняться.

Ресурсы, которые разворачиваются в исходном домене, должны иметь разрешения, назначенные на локальные группы в этом же домене в соответствии с моделью AGULP. В группы доступа к ресурсам должны быть включены:

• ролевые группы из исходного домена (для доступа к ресурсам еще не мигрированных пользователей)
• мигрированные ролевые группы в целевом домене (для доступа к ресурсам новых пользователей, созданных только в целевом домене)

Администрирование доступа к развернутым в исходном домене ресурсам должно осуществляется через группы доступа в этом же домене.

Данный сценарий зеркально повторяет предыдущий.

Сценарий 2.3 — миграция ресурсов в целевой домен

• часть пользователей мигрирована в целевой домен
• из исходного домена необходимо мигрировать ресурс в целевой домен

Описанные в предыдущих сценариях механизмы администрирования ресурсов должны сохраняться.

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

ADMT работает так, что во время миграции объектов (пользователей, групп) в целевой домен, ссылки на эти объекты в уже мигрированных группах (ссылки объекты в других доменах возможны только в локальных группах) заменяются на мигрированные в целевой домен объекты.

Рассмотрим это поведение на примере:

Состояние	Группа	Member
Исходное	source\Local Group 1	source\Global Group 1
Миграция локальной группы в целевой домен	target\Local Group 1	source\Global Group 1
Миграция ролевой группы в целевой домен	target\Local Group 1	target\Global Group 1

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

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

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

Подробности на картинке ниже.

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

После миграции ресурса, доступ через группы доступа из старого домена перестанет работать, поскольку они локальные и их SID фильтруется при прохождении через доверительные отношения. Доступ продолжит предоставляться только через мигрированные в целевой домен группы.

Администрирование доступа к мигрированным в целевой домен ресурсам должно осуществляться:

• если в целевом домене остались немигрированные ресурсы, которые используют те же группы доступа, что и мигрированные ресурсы — администрирование доступа должно производиться через группы доступа в исходном домене, изменения в целевой домен должны приходить через периодическую ре-миграцию групп
• если все ресурсы и их группы доступа уже в целевом домене — администрирование доступа должно производиться через мигрированные в целевой домен группы, группы доступа оставшиеся в исходном домене больше не нужны

Сценарий 3 — все пользователи и ресурсы мигрированы

К этому моменту все пользователи и ресурсы мигрированы в целевой домен, администрирование доступа производится только в целевом домене.

Повторная миграция групп из исходного домена в целевой с обновлением членства больше не требуется.

Для очистки ACL на ресурсах от избыточных записей следует провести трансляцию в режиме удаления. При этом в ACL останутся лишь мигрированные в целевой домен группы.

Заключение

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

Надеюсь, мои рекомендации по сценариям помогут вам выработать правильный план действий на ваших проектах по миграции.

Надеюсь, статья будет ещё дорабатываться, читабельность улучшаться, косноязычие — устраняться. Буду рад комментариям!

Полезные ссылки

• Построение ролевой модели в Active Directory
• ADMT Guide: Migrating and ADMT Guide: Migrating and Restructuring Active Directory Domains