Міграція застарілих застосунків до Azure: коли обрати Microsoft Entra Domain Services, а коли контролери домену IaaS
By Mirko Peters ·
Порівняйте Microsoft Entra Domain Services і контролери домену IaaS в Azure. Дізнайтеся про архітектурні компроміси під час міграції застарілих застосунків.
Automatically translated with AI from the original post. Read the English original

Під час переносу застарілих застосунків Windows до Azure архітектори стикаються з критичною дилемою щодо ідентифікації: розгорнути традиційні віртуальні машини контролерів домену Active Directory чи скористатися керованими хмарними службами? У цьому посібнику розглядаються архітектурні компроміси, операційні витрати та наслідки для вартості вибору Microsoft Entra Domain Services замість власних контролерів домену IaaS для застарілих робочих навантажень в Azure.
Головне
- Microsoft Entra Domain Services забезпечує керовані можливості традиційного домену Windows, не вимагаючи від ІT-команд розгортання, оновлення чи відновлення віртуальних машин контролерів домену.
- Розгортання контролерів домену IaaS в Azure дає адміністраторам повний контроль, зокрема доступ через RDP і привілеї Domain Admin, але суттєво збільшує операційне навантаження.
- Застарілі робочі навантаження, які покладаються на LDAP, Kerberos, NTLM або групові політики, можуть безперешкодно працювати в Azure завдяки керованому шару сумісності домену.
- Entra Domain Services застосовує суворо однонаправлену модель синхронізації ідентифікаторів: записи користувачів має керуватися в авторитетному джерелі, а не безпосередньо в керованому домені.
- Вибір правильної архітектури ідентифікації значною мірою залежить від вимог застосунків, зокрема від потреби в запису LDAP та змінах схеми.
Дилема міграції застарілих рішень в Azure
Перенесення застарілого бізнес-застосунку з серверної кімнати на локальному сервері у віртуальну машину Azure автоматично не робить цей застосунок хмарним. Багато усталених застосунків Windows, зокрема застарілі системи планування ресурсів підприємства, фінансові платформи та власні застосунки на .NET, було побудовано на основі традиційного Active Directory. Коли такі робочі навантаження переходять у хмару, вони досі очікують запитів до служб каталогів через LDAP, автентифікації через квитки Kerberos або застосування налаштувань через групові політики.
Хмарні архітектори одразу стоять перед стратегічним рішенням. Можна під'єднати віртуальну мережу Azure назад до локальних контролерів домену через гібридний тунель VPN, але це вносить затримки та створює небезпечну єдину точку відмови, якщо мережеве з'єднання обірветься. Або ж можна створити нові віртуальні машини Windows Server в Azure, підвищити їх до контролерів домену та побудувати абсолютно новий ліс або домен-репліку.
Хоча створення власних віртуальних машин контролерів домену в Azure дає повний контроль, воно також перетворює вашу команду хмарної інфраструктури на адміністраторів Active Directory. Ви повністю відповідаєте за оновлення операційної системи, моніторинг реплікації каталогу, планування аварійного відновлення та захист привілейованих облікових записів від крадіжки обліковихданих. Для організацій, які прагнуть мінімізувати операційні витрати і водночас підтримувати роботу застарілих застосунків, це часто зайвий тягар.
Entra Domain Services та контролери домену IaaS: основні архітектурні відмінності
Розуміння архітектурної різниці між використанням Microsoft Entra Domain Services та побудовою власних контролерів домену на IaaS є важливим для проєктування стійких хмарних середовищ Azure. Entra Domain Services є керованим рівнем сумісності. Microsoft веде та обслуговує базову інфраструктуру контролерів домену у фоновому режимі, забезпечуючи високу доступність, автоматичне резервне копіювання та фонову синхронізацію з Entra ID.
Коли ви використовуєте Entra Domain Services, ваші віртуальні машини Azure можуть приєднуватися до домену, виконувати запити LDAP та обробляти входи через Kerberos або NTLM, а вашим інженерам не потрібно підключатися через віддалений робочий стіл до контролера домену. Однак цей компроміс керованої служби означає, що ви втрачаєте прямий адміністративний контроль. Ви не можете отримати доступ до базової операційної системи, не можете змінювати схему Active Directory і не отримуєте привілеї Domain Admin чи Enterprise Admin.
І навпаки, розгортання контролерів домену на IaaS дає вам повний контроль над архітектурою каталогу. Ви можете розширювати схему, налаштовувати власні відносини довіри, додавати довільні організаційні одиниці та впроваджувати спеціалізовані об’єкти групової політики без жодних обмежень. Ціна за цю гнучкість — обслуговування. Ваша команда має самостійно керувати всім життєвим циклом домену, включно з регулярними перевірками стану, дефрагментацією бази даних і процедурами аварійного відновлення, якщо контролер домену вийде з ладу.
Операційні компроміси та адміністративні обмеження
Перш ніж вибрати керований підхід до доменів в Azure, адміністратори хмари мають ретельно оцінити, як зміниться щоденна робота. З власними контролерами домену на IaaS ваша команда має детальний контроль над кожним аспектом каталогу. Ви можете писати власні скрипти PowerShell для автоматизації адміністративних завдань, встановлювати агенти безпеки сторонніх виробників безпосередньо на контролери домену та усувати помилки реплікації за допомогою вбудованих утиліт, таких як repadmin.
Microsoft Entra Domain Services замінює цей практичний підхід керованими обмеженнями. Адміністрування виконується через спеціальну групу Entra Domain Services Administrators за допомогою утиліт керування, встановлених на окремій віртуальній машині Windows, приєднаній до домену. Хоча ви можете створювати власні організаційні одиниці, керувати записами DNS і застосовувати підтримувані параметри групової політики, доступ до основної інфраструктури для вас суворо закритий.
Крім того, керування ідентифікаторами побудовано за суворою моделлю односторонньої синхронізації. Ідентифікатори користувачів і груп надходять із вашого авторитетного джерела — або це користувачі, створені лише в хмарі в Entra ID, або синхронізовані ідентифікатори з локального Active Directory — до керованого домену. Ніколи не намагайтеся використовувати Entra Domain Services як основний каталог для зміни атрибутів користувачів, адже ці зміни не синхронізуватимуться назад і зрештою будуть перезаписані.
Система прийняття рішень: вибір правильної архітектури
Вибір правильного підходу вимагає оцінки конкретних технічних вимог вашої організації та її довгострокової хмарної стратегії. Якщо ваша основна мета — перенести застарілі робочі навантаження в Azure, позбавившись операційних витрат на обслуговування віртуальних машин Windows Server як контролерів домену, керована служба майже завжди є кращим варіантом.
Використовуйте Microsoft Entra Domain Services, коли:
- ви переносите застарілі застосунки в Azure, які потребують читання через LDAP, Kerberos, NTLM або можливості приєднання до домену.
- Ваша організація хоче уникнути витрат на оновлення, моніторинг і відновлення власних віртуальних машин контролерів домену в Azure.
- Ви працюєте як організація, що орієнтована на хмару або працює лише в хмарі, і вам потрібні традиційні доменні служби для невеликої частини робочих навантажень Azure без створення локальної інфраструктури.
- Застосункам потрібне стандартне застосування групових політик або керування обліковими записами служб у захищеній віртуальній мережі.
Обирайте власні контролери домену на IaaS, коли:
- Вашим застарілим застосункам потрібен доступ на запис через LDAP або вони вимагають змін у схемі Active Directory.
- Ваша корпоративна архітектура вимагає складних лісів із кількома доменами, власних конфігурацій довіри або прямого доступу до операційних систем контролерів домену.
- Ваша команда безпеки вимагає повного адміністративного контролю, включно з привілеями Enterprise Admin і безпосереднім розгортанням спеціалізованих інструментів аудиту каталогу.
Висновки та наступні кроки
Створення надійної архітектури ідентифікації в Azure вимагає співставлення кожного робочого навантаження з моделлю автентифікації, яка йому справді потрібна. Сучасні хмарні застосунки використовують Microsoft Entra ID для безпечного єдиного входу на основі токенів і багатофакторної автентифікації, тоді як застарілі робочі навантаження часто потребують традиційних служб доменів Windows. Рішення щодо розгортання керованих хмарних служб або створення власної інфраструктури IaaS визначає, наскільки великим буде поточне операційне навантаження вашої команди.
Щоб дослідити цю тему глибше та почути думки експертів про безпеку сучасного робочого місця, хмарну архітектуру та стратегії Microsoft 365, послухайте повне обговорення в нашому подкасті. Послухайте повний епізод, щоб глибше зануритися в управління ідентифікацією Microsoft.
Поширені запитання
Чи можна підключитися через RDP до контролерів домену, якщо використовується Entra Domain Services?
Ні. Microsoft повністю керує базовою інфраструктурою контролерів домену, тож у вас немає адміністративного доступу до операційної системи та можливості підключатися до контролерів домену через віддалений робочий стіл.
Що відбувається з паролями користувачів після увімкнення Entra Domain Services?
Для успішної автентифікації Kerberos і NTLM Entra Domain Services потребує спеціальних хеш-даних. Для користувачів, які існують лише в хмарі, це зазвичай означає, що їм потрібно змінити пароль після увімкнення керованого домену, щоб було створено необхідні криптографічні хеші.
Чи можна змінювати схему Active Directory в Entra Domain Services?
Ні. Оскільки це повністю керована хмарна служба, адміністратори не можуть змінювати базову схему Active Directory або виконувати операції запису LDAP, які змінюють основні структури каталогу.
Як ідентифікатори синхронізуються з Entra Domain Services?
Ідентифікатори передаються однонапрямлено від авторитетного джерела (Entra ID для хмарних користувачів або локального Active Directory через Entra Connect) до керованого домену. Зміни, внесені безпосередньо в керованому домені, не синхронізуються назад у джерело.