Поделиться через

Рекомендации по переносу приложений и проверки подлинности в идентификатор Microsoft Entra

  • Статья

Вы слышали, что Azure Active Directory теперь является идентификатором Microsoft Entra ID , и вы думаете, что это хорошее время для переноса службы федерации Active Directory (AD FS) в облачную проверку подлинности (AuthN) в идентификаторе Microsoft Entra ID. При просмотре параметров ознакомьтесь с нашими обширными ресурсами для переноса приложений в идентификатор Microsoft Entra ID и рекомендации.

Пока вы не сможете перенести AD FS в идентификатор Microsoft Entra, защитите локальные ресурсы с помощью Microsoft Defender для удостоверений. Вы можете найти и исправить уязвимости заранее. Используйте оценки, аналитику и аналитику данных, оценку приоритета исследования пользователей и автоматическое реагирование на скомпрометированные удостоверения. Миграция в облако означает, что ваша организация может воспользоваться современной проверкой подлинности, например методами без пароля для проверки подлинности.

Ниже приведены причины, по которым вы можете не перенести AD FS:

  • В вашей среде есть неструктурированные имена пользователей (например, идентификатор сотрудника).
  • Вам нужны дополнительные возможности для пользовательских поставщиков многофакторной проверки подлинности.
  • Вы используете решения проверки подлинности устройств из сторонних систем мобильных Управление устройствами (MDM), таких как VMware.
  • Ad FS — это двойное питание с несколькими облаками.
  • Необходимо, чтобы сети зазора воздуха.

Перенос приложений

Планирование поэтапного развертывания миграции приложений и выбор пользователей для проверки подлинности в идентификаторе Microsoft Entra. Используйте рекомендации, планируйте миграцию приложений в идентификатор Microsoft Entra ID и ресурсы для переноса приложений в идентификатор Microsoft Entra.

Дополнительные сведения см. в следующем видео: "Миграция приложений без усилий" с помощью идентификатора Microsoft Entra.

Средство миграции приложений

В настоящее время в предварительной версии миграция приложений AD FS для перемещения приложений AD FS в идентификатор Microsoft Entra — это руководство для ИТ-администраторов для переноса приложений проверяющей стороны AD FS из AD FS в идентификатор Microsoft Entra ID. Мастер миграции приложений AD FS предоставляет унифицированный интерфейс для обнаружения, оценки и настройки новых приложений Microsoft Entra. Она имеет конфигурацию с одним щелчком для базовых URL-адресов SAML, сопоставления утверждений и назначений пользователей для интеграции приложения с идентификатором Microsoft Entra. Существует сквозная поддержка миграции локальных приложений AD FS с этими функциями:

  • Чтобы определить использование и влияние приложения, оцените действия входа в приложение проверяющей стороны AD FS
  • Чтобы определить блокировщики миграции и необходимые действия для миграции приложений в идентификатор Microsoft Entra ID, проанализируйте AD FS в microsoft Entra migration feasibility
  • Чтобы автоматически настроить новое приложение Microsoft Entra для приложения AD FS, настройте новые приложения Microsoft Entra с помощью процесса миграции приложений с одним щелчком мыши.

Этап 1. Обнаружение приложений и определение их области действия

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

Используйте отчет о действиях для перемещения приложений AD FS в идентификатор Microsoft Entra. Этот отчет помогает определить приложения, которые могут перенестися в идентификатор Microsoft Entra. Он оценивает приложения AD FS для совместимости Microsoft Entra, проверяет наличие проблем и предоставляет рекомендации по подготовке отдельных приложений для миграции.

Используйте AD FS для средства миграции приложений Microsoft Entra для сбора приложений проверяющей стороны с сервера AD FS и анализа конфигурации. Из этого анализа в отчете показано, какие приложения имеют право на миграцию на идентификатор Microsoft Entra. Для неисправных приложений можно просмотреть объяснения того, почему они не могут перенести.

Установите Microsoft Entra Connect для локальных сред с помощью агентов работоспособности Ad FS Microsoft Entra Connect.

Дополнительные сведения см. в статье "Что такое Microsoft Entra Connect?

Этап 2. Классификация приложений и планирование пилотного проекта

Классификация миграции приложений является важным упражнением. Планирование миграции и перехода приложений на этапах после принятия решения о порядке миграции приложений. Включите следующие критерии классификации приложений:

  • Современные протоколы проверки подлинности, такие как сторонние приложения Software как услуга (SaaS) в коллекции приложений Microsoft Entra, но не через идентификатор Microsoft Entra.
  • Устаревшие протоколы проверки подлинности для модернизации, такие как сторонние приложения SaaS (не в коллекции, но можно добавить в коллекцию).
  • Федеративные приложения, использующие AD FS и которые могут перейти на идентификатор Microsoft Entra.
  • Устаревшие протоколы проверки подлинности НЕ модернизируются. Модернизация может исключить протоколы прокси веб-приложения (WinSCP (WAP), которые могут использовать прокси приложения Microsoft Entra и контроллеры доставки приложений или приложений, которые могут использовать безопасный гибридный доступ.
  • Новые бизнес-приложения (LOB).
  • Приложения для нерекомендуемого использования могут иметь функциональные возможности, избыточные с другими системами, и ни один владелец бизнеса или использование.

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

Этап 3. Планирование миграции и тестирования

Средства миграции и тестирования включают набор средств миграции приложений Microsoft Entra для обнаружения, классификации и переноса приложений. Ознакомьтесь со списком руководств по приложению SaaS и плану развертывания Единого входа (SSO), который описывает комплексный процесс.

Узнайте о прокси-сервере приложения Microsoft Entra и используйте полный план развертывания прокси приложения Microsoft Entra. Рассмотрите возможность безопасного гибридного доступа (SHA) для защиты локальных и облачных устаревших приложений проверки подлинности, подключив их к идентификатору Microsoft Entra. Используйте Microsoft Entra Connect для синхронизации пользователей и групп AD FS с идентификатором Microsoft Entra.

Этап 4. Управление планами и аналитика

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

В Центре администрирования Microsoft Entra выполните аудит всех приложений с помощью следующих методов:

  • Аудит приложений с помощью корпоративных приложений, аудита или доступа к той же информации из API отчетов Microsoft Entra для интеграции с любимыми инструментами.
  • Просмотр разрешений приложения с корпоративными приложениями, разрешениями для приложений с помощью Open Authorization (OAuth)/OpenID Connect.
  • Получите аналитические сведения о входе с помощью корпоративных приложений, входа и из API отчетов Microsoft Entra.
  • Визуализировать использование приложений из книг Microsoft Entra.

Подготовка среды проверки

Управление, устранение неполадок и отчет о продуктах и службах Microsoft Identity с помощью MSIdentityTools в коллекция PowerShell. Отслеживайте инфраструктуру AD FS с помощью Microsoft Entra Connect Health. Создавайте тестовые приложения в AD FS и регулярно создавайте действия пользователей, отслеживая действия в Центре администрирования Microsoft Entra.

При синхронизации объектов с идентификатором Microsoft Entra проверьте правила утверждений доверия ad FS проверяющей стороны для групп, пользователей и атрибутов пользователей, используемых в правилах утверждений, доступных в облаке. Убедитесь, что синхронизация контейнеров и атрибутов.

Различия в сценариях миграции приложений

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

  • Сертификаты. (сертификат глобальной подписи AD FS). В идентификаторе Microsoft Entra можно использовать один сертификат для каждого приложения или один сертификат для всех приложений. Срок действия stagger и настройка напоминаний. Делегировать управление сертификатами наименее привилегированным ролям. Ознакомьтесь с общими вопросами и сведениями , связанными с сертификатами, создаваемыми идентификатором Microsoft Entra, для установления федеративного единого входа в приложения SaaS.
  • Правила утверждений и базовое сопоставление атрибутов. Для приложений SaaS может потребоваться только базовое сопоставление атрибутов и утверждений. Узнайте, как настроить утверждения токена SAML.
  • Извлеките имя пользователя из имени участника-пользователя. Идентификатор Microsoft Entra поддерживает преобразование на основе регулярных выражений (также связано с настройкой утверждения токена SAML).
  • Групповые утверждения. Выдает утверждения группы, отфильтрованные пользователями, которые являются участниками и назначены приложению. Вы можете настроить групповые утверждения для приложений с помощью идентификатора Microsoft Entra.
  • Прокси веб-приложения. Публикация с помощью прокси приложения Microsoft Entra для безопасного подключения к локальным веб-приложениям без VPN. Предоставление удаленного доступа к локальным веб-приложениям и собственной поддержке устаревших протоколов проверки подлинности.

План процесса миграции приложений

Рассмотрите возможность включения следующих шагов в процесс миграции приложений.

  • Клонируйте конфигурацию приложения AD FS. Настройте тестовый экземпляр приложения или используйте макет приложения в тестовом клиенте Microsoft Entra. Сопоставление параметров AD FS с конфигурациями Microsoft Entra. Планирование отката. Переключите тестовый экземпляр на идентификатор Microsoft Entra и проверьте его.
  • Настройте утверждения и идентификаторы. Чтобы подтвердить и устранить неполадки, имитирует рабочие приложения. Наведите тестовый экземпляр приложения на тестовое приложение Microsoft Entra ID. Проверка и устранение неполадок с доступом, обновление конфигурации по мере необходимости.
  • Подготовьте рабочий экземпляр для миграции. Добавьте рабочее приложение в идентификатор Microsoft Entra на основе результатов теста. Для приложений, которые позволяют нескольким поставщикам удостоверений (IDP), настройте идентификатор Microsoft Entra в качестве добавленного поставщика удостоверений в рабочий экземпляр.
  • Переключите рабочий экземпляр на использование идентификатора Microsoft Entra. Для приложений, разрешающих несколько одновременных поставщиков удостоверений, измените идентификатор поставщика удостоверений по умолчанию на идентификатор Microsoft Entra. В противном случае настройте идентификатор Microsoft Entra в качестве поставщика удостоверений в рабочем экземпляре. Обновите рабочий экземпляр, чтобы использовать рабочее приложение Microsoft Entra в качестве основного поставщика удостоверений.
  • Миграция первого приложения, выполнение тестов миграции и устранение проблем. Справочные сведения о состоянии миграции в отчетах о действиях приложений AD FS, которые предоставляют рекомендации по устранению потенциальных проблем миграции.
  • Миграция в большом масштабе. Перенос приложений и пользователей на этапах. Используйте идентификатор Microsoft Entra для управления перенесенными приложениями и пользователями при достаточном тестировании проверки подлинности.
  • Удалите федерацию. Убедитесь, что ферма AD FS больше не используется для проверки подлинности. Используйте резервные копии, резервное копирование и экспорт связанных конфигураций.

Миграция проверки подлинности

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

Политики паролей и проверки подлинности

С выделенными политиками для локальной службы AD FS и идентификатора Microsoft Entra выравнивайте политики истечения срока действия пароля в локальной среде и в идентификаторе Microsoft Entra. Рассмотрите возможность реализации объединенной политики паролей и проверьте наличие слабых паролей в идентификаторе Microsoft Entra. После перехода на управляемый домен применяются обе политики истечения срока действия пароля.

Разрешить пользователям сбрасывать забытые пароли с помощью самостоятельного сброса пароля (SSPR) для снижения затрат на службу поддержки. Ограничение методов проверки подлинности на основе устройств. Модернизируйте политику паролей, чтобы не было периодических истечений срока действия с возможностью отзыва при угрозе. Блокировать слабые пароли и проверять пароли в списках запрещенных паролей. Включите защиту паролей как для локальной службы AD FS, так и для облака.

Перенос устаревших параметров политики идентификатора Microsoft Entra, которые отдельно управляют многофакторной проверкой подлинности и SSPR в унифицированное управление с помощью политики методов проверки подлинности. Перенос параметров политики с помощью обратимого процесса. Вы можете продолжать использовать многофакторную проверку подлинности на уровне клиента и политики SSPR при настройке методов проверки подлинности точно для пользователей и групп.

Так как для входа в Windows и других методов без пароля требуется подробная настройка, включите вход с помощью Microsoft Authenticator и ключей безопасности FIDO2. Используйте группы для управления развертыванием и областью пользователей.

Вы можете настроить автоматическую настройку входа с помощью обнаружения домашней области. Узнайте, как использовать автоматический вход, чтобы пропустить экран входа пользователя и автоматически перенаправить пользователей в федеративные конечные точки входа. Запретите автоматическое выполнение входа с помощью политики обнаружения домашней области несколькими способами управления способами проверки подлинности пользователей.

Политики истечения срока действия учетной записи

Атрибут accountExpires для управления учетными записями пользователей не синхронизируется с идентификатором Microsoft Entra. В результате истекший срок действия учетной записи Active Directory в среде, настроенной для синхронизации хэша паролей, активен в идентификаторе Microsoft Entra. Используйте запланированный сценарий PowerShell, чтобы отключить учетные записи Microsoft Windows Server Active Directory после истечения срока действия, например командлет Set-ADUser. И наоборот, при удалении срока действия из учетной записи Microsoft Windows Server Active Directory повторно заменяемую учетную запись.

С помощью идентификатора Microsoft Entra можно предотвратить атаки с помощью смарт-блокировки. Блокировка учетных записей в облаке перед блокировкой локальных учетных записей для устранения атак подбора. У вас есть более короткий интервал для облака, гарантируя, что локальное пороговое значение не менее двух–трех раз больше порога Microsoft Entra. Задайте длительность блокировки Microsoft Entra дольше локальной длительности. После завершения миграции настройте защиту Smart Lockout (ESL) AD FS Экстрасети.

Планирование развертывания условного доступа

Гибкость политики условного доступа требует тщательного планирования. Перейдите к плану развертывания условного доступа Microsoft Entra для планирования действий. Ниже приведены ключевые моменты, которые следует учитывать:

  • Черновик политик условного доступа с значимыми соглашениями об именовании
  • Используйте электронную таблицу точек принятия решений конструктора со следующими полями:
    • Факторы назначения: пользовательские, облачные приложения
    • Условия: расположения, тип устройства, тип клиентских приложений, риск входа
    • Элементы управления: блокировка, многофакторная проверка подлинности, гибридное присоединение к Microsoft Windows Server Active Directory, соответствующее требованиям устройство, утвержденный тип клиентского приложения
  • Выбор небольших наборов тестовых пользователей для политик условного доступа
  • Тестирование политик условного доступа в режиме только для отчетов
  • Проверка политик условного доступа с помощью средства политики
  • Используйте шаблоны условного доступа, особенно если ваша организация не является новой для условного доступа

Политики условного доступа

Завершив проверку подлинности первого фактора, примените политики условного доступа. Условный доступ не является передней защитой для таких сценариев, как атаки типа "отказ в обслуживании" (DoS). Но условный доступ может использовать сигналы от этих событий, такие как риск входа и расположение запроса для определения доступа. Поток политики условного доступа рассматривает сеанс и его условия, а затем передает результаты в ядро центральной политики.

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

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

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

Оцените пользовательские элементы управления в условном доступе. Пользователи перенаправляются в совместимую службу для удовлетворения требований проверки подлинности за пределами идентификатора Microsoft Entra. Идентификатор Microsoft Entra проверяет ответ и, если пользователь прошел проверку или проверку, он продолжает работать в потоке условного доступа. Как упоминалось в предстоящих изменениях в пользовательских элементах управления, возможности проверки подлинности, предоставляемые партнером, легко работают с администратором Microsoft Entra и интерфейсом конечных пользователей.

Пользовательские решения многофакторной проверки подлинности

Если вы используете пользовательские поставщики многофакторной проверки подлинности, рассмотрите возможность миграции с сервера Многофакторной идентификации на многофакторную проверку подлинности Microsoft Entra. При необходимости используйте программу миграции сервера Многофакторной идентификации для миграции на многофакторную проверку подлинности. Настройте взаимодействие с конечным пользователем с параметрами порогового значения блокировки учетной записи, оповещения о мошенничестве и уведомления.

Узнайте, как выполнить миграцию на многофакторную проверку подлинности и проверку подлинности пользователя Microsoft Entra. Переместите все приложения, службу многофакторной идентификации и проверку подлинности пользователей в идентификатор Microsoft Entra.

Вы можете включить многофакторную проверку подлинности Microsoft Entra и узнать, как создать политики условного доступа для групп пользователей, настроить условия политики, которые запрашивают многофакторную проверку подлинности, а также проверить конфигурацию пользователя и использовать многофакторную проверку подлинности.

Расширение сервера политики сети (NPS) для многофакторной проверки подлинности добавляет облачные возможности многофакторной проверки подлинности в инфраструктуру проверки подлинности с помощью серверов. Если вы используете многофакторную проверку подлинности Microsoft Entra с NPS, определите, что можно перенести на современные протоколы, такие как язык разметки утверждений безопасности (SAML) и OAuth2. Оцените прокси приложения Microsoft Entra для удаленного доступа и используйте безопасный гибридный доступ (SHA) для защиты устаревших приложений с помощью идентификатора Microsoft Entra.

Мониторинг входов

Используйте Connect Health для интеграции входов AD FS, чтобы сопоставить несколько идентификаторов событий из AD FS в зависимости от версии сервера для получения сведений о запросе и ошибках. Отчет о входе в Microsoft Entra содержит сведения о том, когда пользователи, приложения и управляемые ресурсы входят в идентификатор Microsoft Entra и получают доступ к ресурсам. Эта информация коррелирует со схемой отчета о входе Microsoft Entra и отображается в пользовательском интерфейсе отчета о входе в Microsoft Entra. В отчете поток Log Analytics предоставляет данные AD FS. Используйте и измените шаблон книги Azure Monitor для анализа сценариев. Примеры включают блокировку учетных записей AD FS, неудачные попытки пароля и увеличение непредвиденных попыток входа.

Microsoft Entra регистрирует все входы в клиент Azure, включающий внутренние приложения и ресурсы. Просмотрите ошибки входа и шаблоны, чтобы получить представление о том, как пользователи получают доступ к приложениям и службам. Журналы входа в идентификатор Microsoft Entra — это полезные журналы действий для анализа. Настройте журналы с хранением данных до 30 дней в зависимости от лицензирования и экспортируйте их в Azure Monitor, Sentinel, Splunk и другие системы управления безопасностью и событиями (SIEM).

Внутри утверждений корпоративной сети

Независимо от того, где возникают запросы или какие ресурсы они обращаются, модель нулевого доверия учит нас "Никогда не доверять, всегда проверять". Защитите все расположения, как будто они находятся за пределами корпоративной сети. Объявите внутри сетей в качестве надежных расположений для уменьшения ложноположительных срабатываний защиты идентификации. Принудительное применение многофакторной проверки подлинности для всех пользователей и установка политик условного доступа на основе устройств.

Запустите запрос к журналам входа, чтобы обнаружить пользователей, которые подключаются из корпоративной сети, но не являются гибридными присоединениями или совместимыми с Microsoft Entra. Рассмотрим пользователей на совместимых устройствах и использовании неподдерживаемых браузеров, таких как Firefox или Chrome без расширения. Вместо этого используйте домен компьютера и состояние соответствия требованиям.

Поэтапное тестирование миграции проверки подлинности и переключение

Для тестирования используйте облачную проверку подлинности Microsoft Entra Connect с поэтапной развертыванием для управления тестовой проверкой подлинности пользователей с группами. Выборочно тестируйте группы пользователей с возможностями облачной проверки подлинности, такими как многофакторная проверка подлинности Microsoft Entra, условный доступ и Защита идентификации Microsoft Entra. Однако не используйте поэтапное развертывание для добавочных миграций.

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

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

Включите преобразование управляемых доменов в федеративные домены в процессе отката. Используйте командлет New-MgDomainFederationConfiguration. При необходимости настройте дополнительные правила утверждений. Чтобы обеспечить завершенный процесс, оставьте откат поэтапного развертывания в течение 24 до 48 часов после переключение. Удалите пользователей и группы из поэтапного развертывания, а затем отключите его.

После перехода каждые 30 дней переверните ключ для простого единого входа:

Update-AzureADSSOForest -OnPremCredentials $creds -PreserveCustomPermissionsOnDesktopSsoAccount

Отмена эксплуатации AD FS

Мониторинг действий AD FS из Службы "Аналитика использования работоспособности" для AD FS. Сначала включите аудит для AD FS. Перед выводом фермы AD FS убедитесь, что нет действий AD FS. Используйте руководство по списанию AD FS и справочник по выводу ad FS. Ниже приведена сводка по этапам вывода из эксплуатации ключей.

  1. Создайте окончательную резервную копию перед выводом серверов AD FS.
  2. Удалите записи AD FS из внутренних и внешних подсистем балансировки нагрузки.
  3. Удалите соответствующие записи DNS-сервера для имен ферм серверов AD FS.
  4. На основном сервере AD FS выполните команду Get-ADFSProperties и найдите CertificateSharingContainer.

    Примечание.

    Удалите доменное имя (DN) в конце установки после нескольких перезагрузок и, когда он больше недоступен.

  5. Удалите базу данных конфигурации AD FS, если она использует экземпляр базы данных SQL Server в качестве хранилища.
  6. Удалите серверы WAP.
  7. Удалите серверы AD FS.
  8. Удаление сертификатов SSL уровня secure Sockets (AD FS) из каждого хранилища сервера.
  9. Повторное форматирование серверов AD FS с полным форматированием диска.
  10. Удалите учетную запись AD FS.
  11. Чтобы удалить содержимое DN CertificateSharingContainer , используйте интерфейсы служб Active Directory (ADSI).

Следующие шаги