Cross-forest Міграція Active Directory - Kagarlickij Dmitriy
Міграція Active Directory – відносно рідкісне завдання, яке найчастіше виникає у зв'язку з реструктуризацією бізнесу.
У статті буде розглянута Cross-forest міграція, як комплексніша задача, розібравшись з якою міграція між доменами одного лісу (найпоширеніший сценарій) не викликає труднощів.
Переноситимемо основні об'єкти Active Directory – Користувачів, Групи та Комп'ютери, крім того, розглянемо міграцію поштових скриньок Exchange.
У своїй статті я наголосю на виконанні масових операцій.
Основна умова – з боку користувача міграція має пройти максимально передбачувано та з мінімальними втратами робочого часу.
Повернувшись за робоче місце, користувач зможе ввести свій існуючий логін і пароль і використовувати існуючий профіль з усіма даними та індивідуальними налаштуваннями.
Доступ до всіх корпоративних ресурсів (ERP, Fileshare, Email, Printers) залишиться без змін незалежно від того, що «переїхали» ці ресурси в новий ліс або залишаються в старому.
Лабораторне середовище
Для написання цієї статті я розгорнув таке лабораторне середовище:
| Server | OS | Software / Roles | IP/28 | RAM |
| EDGE | WS 2008R2 SP1 | Exchange 2010 SP3 | 192.168.0.2 | 1 |
| DC1 | WS 2008R2 SP1 | AD DS, DNS, AD CS | 192.168.1.2 | 1 |
| MAIL1 | WS 2008R2 SP1 | Exchange 2010 SP3 | 192.168.1.3 | 4 |
| FS | WS 2008R2 SP1 | Fileserver | 192.168.1.5 | 1 |
| WS1 | Windows 7 SP1 | Office 2010 SP2 | 192.168.1.6 | 1 |
| WS2 | Windows 7 SP1 | Office 2010 SP2 | 192.168.1.7 | 1 |
| WS3 | Windows 8.1 | Office 2013 SP1 | 192.168.1.8 | 1 |
| DC2 | WS 2012R2 | AD DS, DNS | 192.168.2.2 | 1 |
| MAIL2 | WS 2012R2 | Exchange 2013 SP1 | 192.168.2.3 | 12 |
| SRV1 | WS 2012R2 | ADMT 3.2 | 192.168.2.4 | 1 |
| SRV2 | WS 2012R2 | SQL 2014 | 192.168.2.5 | 1 |
| SRV3 | WS 2008R2 SP1 | PES 3.2 | 192.168.1.4 | 1 |
Як бачите, подібну інфраструктуру можна розгорнути практично на будь-якому хості віртуалізації з достатньою кількістю оперативної пам'яті та дискового простору (у мене було зайнято менше 512Gb).
Я наводжу у прикладі 2008R2 та 2012R2, але матеріал може бути використаний і для інших версій Windows Server.
Для емуляції «вмісту» який буде переноситися я використав:
| User | Email /UPN | Security Group | Distribution Group | PC |
| user1 | [email protected] | sg1 | [email protected] | WS1 |
| user2 | [email protected] | sg1 | [email protected] | WS2 |
| user3 | [email protected] | sg2 | [email protected] | WS3 |
Перед початком міграції увас має коректно функціонувати мережа та середовище віртуалізації, в якій буде розгорнутий новий ліс Active Directory.
Налагодження довірчих відносин між лісами
Залежно від цілей та умов міграції двосторонні довірчі відносини між Source та Target лісами можуть бути неприпустимі, але в моєму випадку я вважаю їх доречними (докладніше про те, на якому етапі міграції, хто кому повинен довіряти описано в ADMT Guide).
Для коректного дозволу імен між лісами існує кілька способів, наприклад я використовуватиму Conditional Forwarders:
Не важливо який спосіб виберете ви, але в результаті імена повинні вирішуватися коректно:
Коли ця умова виконана, на Source DC відкриємо mmc Active Directory Domains and Trusts, запустимо майстер у якому створимо та підтвердимо таку конфігурацію:
Я не описую натискання Next => Next => OK, якщо у вас це викликає труднощі – і Мережі достатня кількість матеріалів з покрокової настройки довірчих відносин.
Після завершення роботи Майстра переконаємося, що в Target DC також було створено траст:
DNS Suffix
Припускаючи, що користувачі будуть (тимчасово або постійно) використовувати ресурси обох лісів і знаючи що використання srvshare викликає менше проблем, ніж srv.dom2.locshare створимо і застосуємо такі групові політики в Source і Target лісах відповідно:
В результаті застосування політики суфікси виглядатимуть так (для Source domain):
Перевірити результат досить просто – я запрошу резолв звичного користувачам ресурсу, який знаходиться в Source з Target лісу:
Припустимо, що у новому лісірозгорнуть нова PKI, а PKI зі старого лісу вносити зміни не будемо.
Користувачі довіряють сертифікатам ЦС, з яким знаходяться в одному лісі, але не ЦС довіреного лісу, в якому знаходиться частина ресурсів, які вони використовують.
Для вирішення цієї ситуації створимо та застосуємо такі групові політики у Source та Target лісах відповідно:
В результаті ресурси довірених лісів будуть виглядати коректно (зрозуміло, точки розповсюдження CRL повинні бути доступні):
Builtin об'єкти
Builtin об'єкти скрізь мають однакові SIDи, тому при міграції за допомогою ADMT мігровані вони не будуть.
Потрібно перевірити членство в цих групах, і членство цих об'єктів в інших групах (взагалі, рекомендую Builtin використовувати якнайменше).
Обліковий запис для ADMT
ADMT буде встановлена в Target лісі, відповідно обліковий запис для неї створимо також там.
В ADMT Guide є детальний опис необхідних прав для цього облікового запису на різних етапах міграції, але я не кривлятимусь і включу її до групи Domain admins у Target forest і до групи Administrators у Source Domain:
Перевіримо результат на робочій станції:
Правила Брандмауера
Для роботи агента ADMT створимо винятки в брандмауері за допомогою групової політики в обох лісах (я дозволив доступ тільки з сервера, на якому працюватиме ADMT):
Active Directory Audit, SID Filter & SID history
Міграція атрибуту SID history є ключовим моментом, адже саме завдяки SID history користувач, перебуваючи в Target лісі, зможе отримувати доступ до ресурсів, які залишилися в Source лісі.
Зверніть увагу, укористувача може бути кілька SID в SID history.
Насамперед створимо та застосуємо політики аудиту в Source та Target лісах:
Потім виключимо фільтрацію SID в обох доменах: