Переход в облако
После выравнивания организации к прекращению роста объема ресурсов Active Directory можно сосредоточиться на перемещении существующих локальных рабочих нагрузок в идентификатор Microsoft Entra. В этой статье описаны несколько рабочих потоков такой миграции. Указанные в этой статье рабочие потоки можно выполнять в зависимости от приоритетов и ресурсов.
Стандартный рабочий поток миграции состоит из следующих этапов:
Обнаружение. Определение текущего содержимого среды.
Пилотное развертывание. Развертывание новых облачных возможностей для небольшого подмножества (пользователей, приложений или устройств, в зависимости от рабочего потока).
Горизонтальное увеличение масштаба. Развертывание пилотного проекта по переносу некоторой возможности в облако.
Прямая миграция (если применимо). Прекращение использования старой локальной рабочей нагрузки.
Пользователи и группы
Включение функции самостоятельного управления паролями
Рекомендуем перейти на среду без пароля. До этого можно перенести рабочие процессы самообслуживания паролей из локальных систем в идентификатор Microsoft Entra, чтобы упростить среду. Самостоятельный сброс пароля (SSPR) идентификатора Microsoft Entra ID позволяет пользователям изменять или сбрасывать пароль без участия администратора или службы технической поддержки.
Чтобы включить возможности самообслуживания, выберите соответствующие способы проверки подлинности для вашей организации. После обновления методов проверки подлинности можно включить возможность самостоятельного пароля пользователя для вашей среды проверки подлинности Microsoft Entra. Рекомендации по развертыванию см . в рекомендациях по развертыванию для самостоятельного сброса пароля Microsoft Entra.
К числу дополнительных соображений относятся:
- Разверните защиту паролей Microsoft Entra в подмножестве контроллеров домена с режимом аудита , чтобы собрать сведения о влиянии современных политик.
- Постепенно включите объединенную регистрацию для SSPR и многофакторной проверки подлинности Microsoft Entra. Например, развертывайте эту возможность для пользователей из определенных регионов, филиалов или отделов.
- Проведите цикл смены пароля для всех пользователей, чтобы устранить ненадежные пароли. По завершении цикла установите время истечения действия политики.
- В конфигурации защиты паролем на контроллерах домена переключите режим на Принудительно. Дополнительные сведения см. в разделе "Включить локальную защиту паролей Microsoft Entra".
Примечание.
- Для плавного развертывания мы рекомендуем информировать и агитировать пользователей. Ознакомьтесь с примерами материалов по выпуску SSPR.
- Если вы используете Защита идентификации Microsoft Entra, включите сброс пароля в качестве элемента управления в политиках условного доступа для пользователей, помеченных как рискованные.
Перемещение управления группами
Чтобы преобразовать группы и списки рассылки, сделайте следующее:
Для групп безопасности примените существующую бизнес-логику, которая назначает пользователей в группы безопасности. Перенос логики и возможностей в идентификатор Microsoft Entra и динамические группы членства.
Что касается возможностей самостоятельного управления группами, которые предоставляет Microsoft Identity Manager, ее следует заменить самостоятельным управлением группами.
Вы можете преобразовать группы рассылки в группы Microsoft 365 с помощью Outlook. Этот подход — отличный способ предоставить вашей организации список всех функций и функций групп Microsoft 365.
Обновите списки рассылки до групп Microsoft 365 в Outlook и выведите из эксплуатации локальный сервер Exchange Server.
Перемещение подготовки пользователей и групп в приложения
Вы можете упростить среду, удалив потоки подготовки приложений из локальных систем управления удостоверениями, таких как Microsoft Identity Manager. На основе данных обнаружения приложений классифицируйте приложение по следующим характеристикам:
Приложения в вашей среде с интеграцией подготовки с коллекцией приложений Microsoft Entra.
приложения, которые не входят в коллекцию, но поддерживают протокол SCIM 2.0. Эти приложения изначально совместимы со службой подготовки облака Microsoft Entra.
локальные приложения, для которых доступны соединители ECMA. Эти приложения можно интегрировать с локальной подготовкой приложений Microsoft Entra.
Дополнительные сведения см. в описании плана автоматического развертывания подготовки пользователей для идентификатора Microsoft Entra.
Переход на облачную подготовку для управления персоналом
Вы можете сократить объем локального пространства, переместив рабочие процессы подготовки кадров из локальных систем IDM, таких как Microsoft Identity Manager, в идентификатор Microsoft Entra. Для подготовки облачных кадров Microsoft Entra доступны два типа учетных записей:
Для новых сотрудников, которые используют исключительно приложения, использующие идентификатор Microsoft Entra, можно подготовить облачные учетные записи. Такая подготовка помогает ограничить использование Active Directory.
Для новых сотрудников, которым нужен доступ к приложениям, зависящим от Active Directory, вы можете подготовить гибридные учетные записи.
Подготовка облачных кадров Microsoft Entra также может управлять учетными записями Active Directory для существующих сотрудников. Дополнительные сведения см. в разделе "Планирование облачного приложения кадров" для подготовки пользователей Microsoft Entra и планирование проекта развертывания.
Перемещение рабочих процессов жизненного цикла
Оцените существующие рабочие процессы и процессы соединения, перемещения и выхода для применимости и релевантности в облачной среде Microsoft Entra. Затем можно упростить эти рабочие процессы и создать новые с помощью рабочих процессов жизненного цикла.
Перемещение системы управления внешними удостоверениями
Если ваша организация подготавливает в Active Directory или других локальных каталогах учетные записи для внешних участников (поставщиков, подрядчиков, консультантов и т.ак далее), вы можете упростить среду, передав управление сторонними объектами пользователей в облако. Ниже приведены некоторые возможные причины.
Для новых внешних пользователей используйте Внешняя идентификация Microsoft Entra, которая останавливает следы пользователей Active Directory.
Для существующих учетных записей Active Directory, которые вы предоставляете внешним сторонам, можно избавиться от затрат на управление локальными учетными данными (например, паролями), настроив для них Совместную работу B2B. Инструкции по этому процессу см. в статье Приглашение внутреннего пользователя в службу совместной работы B2B.
Используйте управление правами Microsoft Entra для предоставления доступа к приложениям и ресурсам. В большинстве компаний для этой цели выделены системы и рабочие процессы, которые теперь можно переместить из локальных средств.
Используйте проверки доступа для удаления прав доступа и (или) внешних удостоверений, которые больше не нужны.
.
Перемещение рабочих станций с ОС, отличными от Windows
Вы можете интегрировать рабочие станции, отличные от Windows, с идентификатором Microsoft Entra, чтобы улучшить взаимодействие с пользователем и воспользоваться облачными функциями безопасности, такими как условный доступ.
Для macOS:
Зарегистрируйте macOS в Идентификатор Microsoft Entra ID и зарегистрируйте и управляйте ими с помощью решения для управления мобильными устройствами.
Разверните подключаемый модуль Microsoft Enterprise SSO (единый вход) для устройств Apple.
Запланируйте развертывание единого входа на платформу для macOS 13
Для Linux вы можете войти в виртуальную машину Linux с помощью учетных данных Microsoft Entra.
Замена других версий Windows для рабочих станций
Если у вас есть следующие операционные системы на рабочих станциях, рассмотрите возможность обновления до последних версий, чтобы воспользоваться облачным управлением (присоединение к Microsoft Entra и унифицированное управление конечными точками):
Windows 7 или 8.x
Windows Server
Решение VDI
В этом проекте есть две основные инициативы.
Новые развертывания: развертывание облачного решения инфраструктуры виртуальных рабочих столов (VDI), например Windows 365 или Виртуального рабочего стола Azure, для которого не требуется локальная служба Active Directory.
Существующие развертывания. Если существующее развертывание VDI зависит от Active Directory, используйте бизнес-цели и цели, чтобы определить, поддерживаете ли решение или переносите его в идентификатор Microsoft Entra.
Дополнительные сведения см. в разделе:
Развертывание виртуальных машин, присоединенных к Microsoft Entra, в виртуальном рабочем столе Azure
Приложения
Чтобы обеспечить безопасную среду, идентификатор Microsoft Entra поддерживает современные протоколы проверки подлинности. Чтобы перенести проверку подлинности приложения из Active Directory в идентификатор Microsoft Entra, необходимо:
Определите, какие приложения могут перенестися в идентификатор Microsoft Entra без изменений.
определить, какие приложения имеют путь обновления, позволяющий выполнить миграцию с обновлением;
определить, какие приложения требуют замены или значительных изменений кода для миграции.
Результатом инициативы по обнаружению приложений должен стать список портфеля приложений с указанием приоритета очередности переноса. Этот список содержит приложения, которые:
требуют обновления программного обеспечения и имеют доступный путь обновления;
требуют обновления программного обеспечения, но не имеют доступного пути обновления.
По этому списку вы можете дополнительно оценить приложения, у которых нет пути обновления. Определите, рентабельно ли обновлять программное обеспечение. Возможно, целесообразнее прекратить его поддержку. Если некоторое программное обеспечение придется вывести из эксплуатации, нужно принять решение о необходимости замены.
На основе результатов можно изменить аспекты преобразования из Active Directory в идентификатор Microsoft Entra. Существуют подходы (совокупно известные как "lift and shift"), которые позволяют расширить локальную службу Active Directory на платформу Azure IaaS (инфраструктура как услуга) для приложений, которые используют неподдерживаемые протоколы проверки подлинности. Мы рекомендуем создать политику, которая требует использовать этот подход для исключений.
Обнаружение приложений
Завершив сегментирование портфеля приложений, распределите приоритеты миграции с учетом ценности для бизнеса и бизнес-приоритетов. Вы можете использовать специальные средства для создания или обновления списка приложений.
Ниже перечислены три основных подхода к определению категорий для приложений.
Современные приложения проверки подлинности. Эти приложения используют современные протоколы проверки подлинности (например, OIDC, OAuth2, SAML или WS-Federation) или службу федерации, например службы федерации Active Directory (AD FS).
Средства управления веб-доступом (WAM). В этих приложениях для единого входа используются заголовки, файлы cookie и другие подобные методы. Для таких приложений обычно требуется поставщик удостоверений WAM, например Symantec Site Minder.
Устаревшие приложения. Эти приложения используют устаревшие протоколы, такие как Kerberos, LDAP, Radius, удаленный рабочий стол, NTLM и так далее. Мы рекомендуем избавляться от них.
Идентификатор Microsoft Entra можно использовать с каждым типом приложения для предоставления уровней функциональности, которые приводят к различным стратегиям миграции, сложности и компромиссам. В некоторых организациях уже есть готовый список приложений, которые можно использовать в качестве стартовой информации для инициативы обнаружения. (Обычно эти списки не полны или не обновляются.)
Для обнаружения приложений современной аутентификации сделайте следующее:
Если вы работаете с AD FS, воспользуйтесь отчетом о действиях приложения AD FS.
Если вы используете другой поставщик удостоверений, используйте данные журналов и конфигурации.
Следующие средства помогают обнаруживать приложения, использующие протокол LDAP.
Event1644Reader. Пример средства для сбора данных о запросах LDAP, выполненных к контроллерам домена, по журналам инженерных служб.
Microsoft 365 Defender для удостоверений. Решение для безопасности, которое использует функцию мониторинга операций входа. (Обратите внимание, что он фиксирует привязки по протоколу LDAP, а не LDAPS.)
PSLDAPQueryLogging. Средство GitHub для создания отчетов о запросах LDAP.
Перенос служб AD FS или других служб федерации
При планировании миграции на идентификатор Microsoft Entra рекомендуется сначала перенести приложения, использующие современные протоколы проверки подлинности (например, SAML и OpenID Connect). Эти приложения можно перенастроить для проверки подлинности с помощью идентификатора Microsoft Entra ID с помощью встроенного соединителя из коллекции приложение Azure или регистрации в идентификаторе Microsoft Entra.
После перемещения приложений SaaS, которые были федеративны в идентификатор Microsoft Entra ID, необходимо выполнить несколько действий, чтобы вывести из эксплуатации локальную систему федерации:
Перемещение проверки подлинности приложения в идентификатор Microsoft Entra
Перемещение удаленного доступа к внутренним приложениям, если вы используете прокси приложения Microsoft Entra
Внимание
Если вы используете другие функции, обязательно перенесите соответствующие службы до вывода службы федерации Active Directory из эксплуатации.
Перемещение приложений с проверкой подлинности WAM
Этот проект посвящен переносу возможностей единого входа из систем WAM в идентификатор Microsoft Entra. Дополнительные сведения см. в статье "Миграция приложений из Symantec SiteMinder в идентификатор Microsoft Entra ID".
Определение стратегии управления для сервера приложений
С точки зрения управления инфраструктурой локальные среды часто используют сочетание объектов групповой политики (ГОП) и функций Microsoft Configuration Manager для сегментирования обязанностей управления. Например, можно выделить следующие обязанности: управление политиками безопасности, управление обновлениями, управление конфигурацией и мониторинг.
Active Directory предназначен для локальных ИТ-сред, а идентификатор Microsoft Entra предназначен для облачных ИТ-сред. Их функции не полностью аналогичны, поэтому у вас есть несколько методов для управления серверами приложений.
Например, Azure Arc помогает объединить многие функции, существующие в Active Directory, в одно представление при использовании идентификатора Microsoft Entra для управления удостоверениями и доступом (IAM). Вы также можете использовать доменные службы Microsoft Entra для серверов, присоединенных к домену, в идентификаторе Microsoft Entra, особенно если эти серверы будут использовать объекты групповой политики для конкретных бизнес-целей или технических причин.
Следующая таблица поможет определить, какие средства на основе Azure можно использовать для замены локальной среды.
| Область управления | Локальная возможность (Active Directory) | Эквивалентная функция Microsoft Entra |
|---|---|---|
| управление политиками безопасности; | GPO, Microsoft Configuration Manager | Microsoft 365 Defender для облака |
| Управление обновлениями | Microsoft Configuration Manager, Windows Server Update Services | Управление обновлениями в службе автоматизации Azure |
| Управление конфигурацией | GPO, Microsoft Configuration Manager | Конфигурация состояния служба автоматизации Azure |
| Наблюдение | System Center Operations Manager | Azure Monitor Log Analytics |
Приведенные ниже сведения помогут вам с управлением сервером приложений.
Azure Arc позволяет применять возможности Azure к виртуальным машинам на основе других платформ. Например, вы можете использовать его для получения функций Azure для Windows Server при использовании локальной среды или в Amazon Web Services или аутентификации на компьютерах Linux с помощью SSH.
Если необходимо дождаться миграции или выполнить частичную миграцию, можно использовать объекты групповой политики с доменными службами Microsoft Entra.
Если вам требуется управление серверами приложений с помощью Microsoft Configuration Manager, вы не сможете достичь этого требования с помощью доменных служб Microsoft Entra. Microsoft Configuration Manager не поддерживается для запуска в среде доменных служб Microsoft Entra. Вместо этого необходимо расширить экземпляр локальная служба Active Directory на контроллер домена, работающий на виртуальной машине Azure. Кроме того, необходимо развернуть новый экземпляр Active Directory в виртуальной сети Azure IaaS.
Определение стратегии миграции для устаревших приложений
Устаревшие приложения имеют зависимости от Active Directory следующих типов.
Аутентификация и авторизация пользователей: Kerberos, NTLM, привязка LDAP, списки контроля доступа.
Доступ к данным каталога: запросы LDAP, расширения схем, чтение и запись объектов каталога.
Управление сервером: определяется стратегией управления сервером.
Чтобы уменьшить или устранить эти зависимости, можно использовать три основных подхода.
Способ 1
В рамках этого подхода, который мы рекомендуем использовать, реализуются проекты по переходу с устаревших приложений на альтернативные решения SaaS с современной проверкой подлинности. Выполните проверку подлинности альтернативных вариантов SaaS непосредственно в идентификаторе Microsoft Entra ID:
Разверните доменные службы Microsoft Entra в виртуальной сети Azure и расширьте схему , чтобы включить дополнительные атрибуты, необходимые приложениям.
Поднимите и переместите устаревшие приложения на виртуальные машины в виртуальной сети Azure, присоединенной к доменным службам Microsoft Entra.
Публикация устаревших приложений в облаке с помощью прокси приложения Microsoft Entra или партнера по безопасному гибридному доступу.
Так как устаревшие приложения удаляются с помощью аттестации, в конечном итоге выведите из эксплуатации доменные службы Microsoft Entra, работающие в виртуальной сети Azure.
Примечание.
- Используйте доменные службы Microsoft Entra, если зависимости соответствуют общим сценариям развертывания для доменных служб Microsoft Entra.
- Чтобы проверить, подходят ли службы доменов Microsoft Entra, можно использовать такие инструменты, как Azure Monitor VM insights для аналитики виртуальных машин [https://learn.microsoft.com/azure/azure-monitor/vm/vminsights-overview].
- Проверьте, можно ли перенести экземпляры SQL Server в другой домен. Если служба SQL работает на виртуальных машинах, воспользуйтесь этим руководством.
Способ 2.
Если первый подход невозможен и приложение имеет сильную зависимость от Active Directory, вы можете расширить локальную службу Active Directory в Azure IaaS.
Вы можете изменить формат для поддержки современного бессерверного размещения, например, использовать формат PaaS (платформа как услуга). Кроме того, можно обновить код для поддержки современной проверки подлинности. Вы также можете включить интеграцию приложения с идентификатором Microsoft Entra ID напрямую. Сведения о библиотеке проверки подлинности Майкрософт на платформе удостоверений Майкрософт.
Подключите виртуальную сеть Azure к локальной сети через виртуальную частную сеть (VPN) или Azure ExpressRoute.
Разверните новые контроллеры домена для локальной службы Active Directory в качестве виртуальных машин в виртуальной сети Azure.
Перенесите устаревшие приложения на присоединенные к домену виртуальные машины в виртуальной сети Azure.
Публикация устаревших приложений в облаке с помощью прокси приложения Microsoft Entra или партнера по безопасному гибридному доступу.
И наконец, выведите из эксплуатации локальную инфраструктуру Active Directory и используйте только Active Directory в виртуальной сети Azure.
По мере вывода устаревших приложений из эксплуатации отключите, наконец, и экземпляр Active Directory в виртуальной сети Azure.
Способ 3
Если первый путь миграции невозможен и приложение имеет сильную зависимость от Active Directory, вы можете расширить локальную службу Active Directory в Azure IaaS. Сохраните приложения в статусе устаревших на некоторый период и отключите их, как только появится такая возможность.
Такой подход позволяет отвязать приложение от существующего экземпляра Active Directory для уменьшения контактной зоны. Мы рекомендуем рассматривать такой вариант только в крайнем случае.
Разверните новый экземпляр Active Directory в качестве виртуальных машин в виртуальной сети Azure.
Перенесите устаревшие приложения методом "lift and shift" на виртуальные машины в виртуальной сети Azure, присоединенные к домену, развернутому на новом экземпляре Active Directory.
Публикация устаревших приложений в облаке с помощью прокси приложения Microsoft Entra или партнера по безопасному гибридному доступу.
По мере вывода устаревших приложений из эксплуатации отключите, наконец, и экземпляр Active Directory в виртуальной сети Azure.
Сравнение стратегий
| Стратегия | Доменные службы Microsoft Entra | Расширение Active Directory в IaaS | Независимый экземпляр Active Directory в IaaS |
|---|---|---|---|
| Избавление от привязки к локальной службе Active Directory | Да | No | Да |
| Разрешение расширений схемы | No | Да | Да |
| Полный административный контроль | No | Да | Да |
| Потребуется перенастройка для некоторых приложений (например, списков управления доступом или авторизации) | Да | No | Да |
Перенос проверки подлинности VPN
Этот проект посвящен перемещению проверки подлинности VPN в идентификатор Microsoft Entra. Важно знать, что существует несколько конфигураций для подключений к VPN-шлюзу. Вам нужно определить, какая из конфигураций наилучшим образом соответствует вашим требованиям. Дополнительные сведения о проектировании решения см. в статье Структура VPN-шлюза.
Ниже приведены ключевые моменты использования идентификатора Microsoft Entra для проверки подлинности VPN:
Проверьте, поддерживают ли поставщики VPN современную проверку подлинности. Например:
Для устройств Windows 10 рекомендуется интегрировать поддержку Microsoft Entra в встроенный VPN-клиент.
После оценки этого сценария можно реализовать решение для удаления зависимости от локальной среды при проверке подлинности VPN.
Перемещение возможностей удаленного доступа к внутренним приложениям
Чтобы упростить среду, вы можете использовать прокси приложения Microsoft Entra или безопасный гибридный доступ для предоставления удаленного доступа . Это позволяет удалить зависимость от локальных решений обратного прокси-сервера.
Важно отметить, что включение удаленного доступа к приложению с использованием предыдущих технологий следует считать временным решением. Чтобы полностью отделить приложение от Active Directory, необходимо выполнить большую работу.
Доменные службы Microsoft Entra позволяют перенести серверы приложений в облако IaaS и отделить от Active Directory, используя прокси приложения Microsoft Entra для обеспечения удаленного доступа. Дополнительные сведения об этом сценарии см . в статье "Развертывание прокси приложения Microsoft Entra" для доменных служб Microsoft Entra.