Миграция устаревших приложений в Azure: когда выбрать Microsoft Entra Domain Services, а когда контроллеры домена IaaS

By Mirko Peters · 2026-08-14

Сравните Microsoft Entra Domain Services и контроллеры домена IaaS в Azure. Изучите архитектурные компромиссы при миграции устаревших приложений.

Automatically translated with AI from the original post. Read the English original

При переносе устаревших приложений Windows в Azure методом lift and shift архитекторы сталкиваются с важной дилеммой в области идентификации: развернуть классические виртуальные машины контроллеров домена 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 использует строгую модель односторонней синхронизации identity: учётные записи пользователей必须 управляться в авторитетном источнике, а не непосредственно в управляемом домене.
• Выбор правильной архитектуры identity во многом зависит от требований приложений, таких как доступ на запись по LDAP и изменение схемы.

Дилемма миграции устаревших приложений в Azure

Перенос устаревшего бизнес-приложения из локальной серверной в виртуальную машину Azure автоматически не делает это приложение облачным. Многие давно используемые приложения Windows, такие как устаревшие системы ERP, финансовые платформы и самописные приложения на .NET, создавались на основе традиционного Active Directory. Попав в облако, они по-прежнему ожидают запросов к службам каталога по LDAP, аутентификации через билеты Kerberos или применения параметров через групповые политики.

Облачным архитекторам сразу приходится принимать стратегическое решение. Можно подключить виртуальную сеть Azure к локальным контроллерам домена через гибридный туннель VPN, но это добавляет задержки и создаёт опасную единую точку отказа при обрыве канала. Либо можно развернуть в Azure новые виртуальные машины с Windows Server, повысить их до контроллеров домена и построить новый лес или домен-реплику.

Собственные виртуальные машины контроллеров домена в 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) в управляемый домен. Изменения, внесённые непосредственно в управляемом домене, обратно в исходную систему не синхронизируются.