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

Планирование развертывания Windows Hello для бизнеса

  • Статья
  • Применяется к:
    ✅ Windows 11, ✅ Windows 10

Это руководство по планированию поможет вам разобраться в различных топологиях, архитектурах и компонентах, составляющих инфраструктуру Windows Hello для бизнеса.

В этом руководстве описывается роль каждого компонента Windows Hello для бизнеса, а также влияние определенных решений при развертывании на другие аспекты инфраструктуры.

Совет

Если у вас есть клиент Microsoft Entra ID, вы можете использовать интерактивный мастер без пароля в Интернете, который использует те же варианты, а не руководство, приведенное ниже. Мастер без пароля доступен в Центре администрирования Microsoft 365.

Использование этого руководства

Существует множество вариантов развертывания Windows Hello для бизнеса, которые обеспечивают совместимость с различными организационными инфраструктурами. Хотя процесс развертывания может показаться сложным, большинство организаций обнаружит, что они уже реализовали необходимую инфраструктуру. Важно отметить, что Windows Hello для бизнеса — это распределенная система, требующая надлежащего планирования в нескольких командах в организации.

Это руководство призвано упростить процесс развертывания, помогая принимать обоснованные решения по каждому аспекту развертывания Windows Hello для бизнеса. Он предоставляет сведения о доступных вариантах и помогает выбрать подход к развертыванию, который лучше всего подходит для вашей среды.

Как продолжить работу

Прочтите этот документ и запишите свои решения. По завершении у вас должны быть все необходимые сведения для оценки доступных вариантов и определения требований к развертыванию Windows Hello для бизнеса.

При планировании развертывания Windows Hello для бизнеса следует учитывать семь основных областей:

Варианты развертывания

Задача Windows Hello для бизнеса — обеспечить варианты развертывания для всех организаций независимо от размера и сценария. Чтобы обеспечить столь детальное развертывание, Windows Hello для бизнеса предоставляет широкий выбор вариантов развертывания.

Модели развертывания

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

Существует три модели развертывания, из которых можно выбрать:

Модель развертывания Описание
🔲 Только облако Для организаций, имеющих только облачные удостоверения и не имеющих доступа к локальным ресурсам. Эти организации обычно присоединяются к облаку и используют исключительно ресурсы в облаке, такие как SharePoint Online, OneDrive и другие. Кроме того, так как пользователи не используют локальные ресурсы, им не нужны сертификаты для таких вещей, как VPN, так как все, что им нужно, размещено в облачных службах.
🔲 Гибридная среда Для организаций с удостоверениями, синхронизированными из Active Directory в Microsoft Entra ID. Эти организации используют приложения, зарегистрированные в Microsoft Entra ID, и хотят использовать единый вход (SSO) как для локальных ресурсов, так и для ресурсов Microsoft Entra.
🔲 Локальная среда Для организаций, которые не имеют облачных удостоверений или используют приложения, размещенные в Идентификаторе Microsoft Entra. Эти организации используют локальные приложения, интегрированные в Active Directory, и хотят использовать единый вход при доступе к ним.

Примечание.

  • Основной вариант использования локального развертывания — для "административных сред повышенной безопасности", также известных как "Красные леса".
  • Для миграции из локального развертывания в гибридное требуется повторное развертывание.

Типы доверия

Тип доверия развертывания определяет, как клиенты Windows Hello для бизнеса проходят проверку подлинности в Active Directory. Тип доверия не влияет на проверку подлинности для Идентификатора Microsoft Entra. По этой причине тип доверия неприменим к модели развертывания только в облаке.

Проверка подлинности Windows Hello для бизнеса в Microsoft Entra ID всегда использует ключ, а не сертификат (за исключением проверки подлинности со смарт-картой в федеративной среде).

Тип доверия определяет, вы выдаете ли пользователям сертификаты проверки подлинности. Одна модель доверия не более безопасна, чем другая.

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

Существует три типа доверия, из которых можно выбрать:

Тип доверия Описание
🔲 Cloud Kerberos Пользователи проходят проверку подлинности в Active Directory, запрашивая TGT из Идентификатора Microsoft Entra с помощью Microsoft Entra Kerberos. Локальные контроллеры домена по-прежнему отвечают за билеты службы Kerberos и авторизацию. Cloud Kerberos trust использует ту же инфраструктуру, что и для входа с ключом безопасности FIDO2, и ее можно использовать для новых или существующих развертываний Windows Hello для бизнеса.
🔲 Ключ Пользователи проходят проверку подлинности в локальной службе Active Directory с помощью привязанного к устройству ключа (оборудования или программного обеспечения), созданного во время подготовки Windows Hello. Он требует распространения сертификатов между контроллерами домена.
🔲 Сертификат Тип доверия сертификата выдает пользователям сертификаты проверки подлинности. Пользователи проходят проверку подлинности с помощью сертификата, запрошенного с помощью привязанного к устройству ключа (оборудования или программного обеспечения), созданного во время подготовки Windows Hello.

Доверие к ключам и сертификату используют kerberos на основе сертификата при запросе kerberos ticket-granting-tickets (TGT) для локальной проверки подлинности. Этот тип проверки подлинности требует PKI для сертификатов контроллера домена и сертификатов конечного пользователя для доверия сертификатов.

Цель облачного доверия Kerberos в Windows Hello для бизнеса — обеспечить более простое развертывание по сравнению с другими типами доверия:

  • Нет необходимости развертывать инфраструктуру открытых ключей (PKI) или изменять существующую PKI
  • Не нужно синхронизировать открытые ключи между Идентификатором Microsoft Entra и Active Directory, чтобы пользователи обращались к локальным ресурсам. Между подготовкой Windows Hello для бизнеса и возможностью проверки подлинности в Active Directory нет никакой задержки.
  • Вход с ключом безопасности FIDO2 можно развернуть с минимальной дополнительной настройкой.

Совет

Облачная модель доверия Kerberos в Windows Hello для бизнеса — это рекомендуемая модель развертывания по сравнению с ключевой моделью доверия. Это также предпочтительная модель развертывания, если не требуется поддержка сценариев проверки подлинности сертификатов.

Для доверия Cloud Kerberos требуется развертывание Microsoft Entra Kerberos. Дополнительные сведения о том, как Microsoft Entra Kerberos обеспечивает доступ к локальным ресурсам, см. в статье Включение входа без ключа безопасности в локальные ресурсы.

Требования К PKI

Доверие Cloud Kerberos — это единственный вариант гибридного развертывания, который не требует развертывания сертификатов. Другие гибридные и локальные модели зависят от корпоративной PKI в качестве привязки доверия для проверки подлинности:

  • Контроллерам домена для гибридных и локальных развертываний требуется сертификат для устройств Windows, чтобы доверять контроллеру домена как допустимому
  • Для развертываний, использующих тип доверия сертификатов, требуется корпоративный PKI и центр регистрации сертификатов (CRA) для выдачи пользователям сертификатов проверки подлинности. AD FS используется в качестве CRA
  • Для гибридных развертываний может потребоваться выдача сертификатов VPN пользователям, чтобы включить подключение локальных ресурсов.
Модель развертывания Тип доверия Требуется PKI?
🔲 Только облако Неприменимо Нет
🔲 Гибридная среда Cloud Kerberos Нет
🔲 Гибридная среда Раздел Да
🔲 Гибридная среда Сертификат Да
🔲 Локальная среда Раздел Да
🔲 Локальная среда Сертификат Да

Проверка подлинности в Идентификаторе Microsoft Entra

Пользователи могут пройти проверку подлинности в Microsoft Entra ID с помощью федеративной или облачной (нефедерированной) проверки подлинности. Требования зависят от типа доверия:

Модель развертывания Тип доверия Проверка подлинности в Идентификаторе Microsoft Entra Требования
🔲 Только облако Неприменимо Облачная проверка подлинности Неприменимо
🔲 Только облако Неприменимо Федеративная проверка подлинности Служба федерации сторонних поставщиков
🔲 Гибридная среда Доверие к Cloud Kerberos Облачная проверка подлинности Синхронизация хэша паролей (PHS) или сквозная проверка подлинности (PTA)
🔲 Гибридная среда Доверие к Cloud Kerberos Федеративная проверка подлинности AD FS или служба федерации сторонних поставщиков
🔲 Гибридная среда Доверие на основе ключей Облачная проверка подлинности Синхронизация хэша паролей (PHS) или сквозная проверка подлинности (PTA)
🔲 Гибридная среда Доверие на основе ключей Федеративная проверка подлинности AD FS или служба федерации сторонних поставщиков
🔲 Гибридная среда Доверие на основе сертификатов Федеративная проверка подлинности Эта модель развертывания не поддерживает PTA или PHS. Active Directory должна быть федеративной с идентификатором Microsoft Entra с помощью AD FS

Дополнительные сведения:

Регистрация устройств

Для локальных развертываний сервер с ролью служб федерации Active Directory (AD FS) отвечает за регистрацию устройств. Для облачных и гибридных развертываний устройства должны регистрироваться в идентификаторе Microsoft Entra.

Модель развертывания Поддерживаемый тип соединения Поставщик службы регистрации устройств
Только облако Присоединено к Microsoft Entra
Зарегистрировано в Microsoft Entra		 Идентификатор Microsoft Entra
Гибридная среда Присоединено к Microsoft Entra
Гибридное присоединение к Microsoft Entra
Зарегистрировано в Microsoft Entra		 Идентификатор Microsoft Entra
Локальная среда Присоединение к домену Active Directory AD FS;

Важно.

Рекомендации по гибридному присоединению к Microsoft Entra см. в статье Планирование реализации гибридного присоединения Microsoft Entra.

Многофакторная идентификация

Цель Windows Hello для бизнеса — отодвинуть организации от паролей, предоставив им надежные учетные данные , которые обеспечивают простую двухфакторную проверку подлинности. Встроенный интерфейс подготовки принимает слабые учетные данные пользователя (имя пользователя и пароль) в качестве первого фактора проверки подлинности. Однако пользователь должен указать второй фактор проверки подлинности, прежде чем Windows подготовит надежные учетные данные:

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

Важно.

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

С 30 сентября 2024 г. развертывания сервера Многофакторной идентификации Azure больше не будут обслуживать запросы MFA. Чтобы обеспечить бесперебойную проверку подлинности и оставаться в поддерживаемом состоянии, организациям следует перенести данные проверки подлинности пользователей в облачную службу Azure MFA.

Модель развертывания Параметры MFA
🔲 Только облако Microsoft Entra MFA
🔲 Только облако Не microsoft MFA с помощью внешнего метода проверки подлинности в Microsoft Entra ID или федерации
🔲 Гибридная среда Microsoft Entra MFA
🔲 Гибридная среда Не microsoft MFA с помощью внешнего метода проверки подлинности в Microsoft Entra ID или федерации
🔲 Локальная среда Адаптер MFA AD FS

Дополнительные сведения:

MFA и федеративная проверка подлинности

Федеративные домены могут настроить флаг FederatedIdpMfaBehavior . Флаг указывает идентификатору Microsoft Entra принять, применить или отклонить запрос MFA от федеративного поставщика удостоверений. Дополнительные сведения см. в разделе Значения federatedIdpMfaBehavior. Чтобы проверить этот параметр, используйте следующую команду PowerShell:

Connect-MgGraph
$DomainId = "<your federated domain name>"
Get-MgDomainFederationConfiguration -DomainId $DomainId |fl

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

Update-MgDomainFederationConfiguration -DomainId $DomainId -FederatedIdpMfaBehavior rejectMfaByFederatedIdp

Если вы настроили флаг со значением acceptIfMfaDoneByFederatedIdp (по умолчанию) или enforceMfaByFederatedIdp, необходимо убедиться, что федеративный поставщик удостоверений настроен правильно и работает с адаптером и поставщиком MFA, используемыми поставщиком удостоверений.

Регистрация ключей

Встроенный интерфейс подготовки Windows Hello для бизнеса создает связанную с устройством асимметричную пару ключей в качестве учетных данных пользователя. Закрытый ключ защищен модулями безопасности устройства. Учетные данные являются ключом пользователя, а не ключом устройства. Процесс подготовки регистрирует открытый ключ пользователя в поставщике удостоверений:

Модель развертывания Поставщик службы регистрации ключей
Только облако Идентификатор Microsoft Entra
Гибридная среда Идентификатор Microsoft Entra
Локальная среда AD FS;

Синхронизация каталогов

Однако в гибридных и локальных развертываниях синхронизация каталогов используется для разных целей:

  • Гибридные развертывания используют Microsoft Entra Connect Sync для синхронизации удостоверений Active Directory (пользователей и устройств) или учетных данных между собой и Идентификатором Microsoft Entra. В процессе подготовки Window Hello для бизнеса пользователи регистрируют общедоступную часть своих учетных данных Windows Hello для бизнеса с идентификатором Microsoft Entra. Синхронизация Microsoft Entra Connect синхронизирует открытый ключ Windows Hello для бизнеса с Active Directory. Эта синхронизация обеспечивает единый вход в Microsoft Entra ID и его федеративные компоненты.

    Важно.

    Windows Hello для бизнеса связана между пользователем и устройством. Объект пользователя и устройства должен быть синхронизирован между Идентификатором Microsoft Entra и Active Directory.

  • Локальные развертывания используют синхронизацию каталогов для импорта пользователей из Active Directory на сервер Azure MFA, который отправляет данные в облачную службу MFA для выполнения проверки.
Модель развертывания Параметры синхронизации каталогов
Только облако Неприменимо
Гибридная среда Синхронизация Microsoft Entra Connect
Локальная среда Сервер Azure MFA

Важно.

С 30 сентября 2024 г. развертывания сервера Многофакторной идентификации Azure больше не будут обслуживать запросы MFA. Чтобы обеспечить бесперебойную проверку подлинности и оставаться в поддерживаемом состоянии, организациям следует перенести данные проверки подлинности пользователей в облачную службу Azure MFA.

Параметры конфигурации устройства

Windows Hello для бизнеса предоставляет широкий набор детализированных параметров политики. Существует два основных варианта настройки Windows Hello для бизнеса: поставщик служб конфигурации (CSP) и групповая политика (GPO).

  • Вариант CSP идеально подходит для устройств, управляемых с помощью решения управления мобильными устройствами (MDM), например Microsoft Intune. CSP также можно настроить с помощью пакетов подготовки
  • Объект групповой политики можно использовать для настройки устройств, присоединенных к домену, и когда устройствами не управляются через MDM
Модель развертывания Параметры конфигурации устройства
🔲 Только облако CSP
🔲 Только облако Объект групповой политики (локальный)
🔲 Гибридная среда CSP
🔲 Гибридная среда Объект групповой политики (Active Directory или локальный)
🔲 Локальная среда CSP
🔲 Локальная среда Объект групповой политики (Active Directory или локальный)

Требования к лицензированию облачных служб

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

  • Для Windows Hello для бизнеса не требуется подписка Microsoft Entra ID P1 или P2. Однако некоторые зависимости, такие как автоматическая регистрация MDM и условный доступ
    • Устройствам, управляемым через MDM, не требуется подписка Microsoft Entra ID P1 или P2. Отказав от подписки, пользователи должны вручную зарегистрировать устройства в решении MDM, такие как Microsoft Intune или поддерживаемые устройства, отличные от Microsoft MDM.
  • Вы можете развернуть Windows Hello для бизнеса с помощью уровня Microsoft Entra ID Free. Все учетные записи Microsoft Entra ID Free могут использовать многофакторную проверку подлинности Microsoft Entra для функций Windows без пароля.
  • Регистрация сертификата с помощью центра регистрации AD FS требует, чтобы устройства прошли проверку подлинности на сервере AD FS. Для этого требуется обратная запись устройства, функция Microsoft Entra ID P1 или P2
Модель развертывания Тип доверия Лицензии на облачные службы (минимум)
🔲 Только облако Неприменимо не требуется
🔲 Гибридная среда Cloud Kerberos не требуется
🔲 Гибридная среда Раздел не требуется
🔲 Гибридная среда Сертификат Идентификатор Microsoft Entra P1
🔲 Локальная среда Раздел Azure MFA, если используется в качестве решения MFA
🔲 Локальная среда Сертификат Azure MFA, если используется в качестве решения MFA

Важно.

С 30 сентября 2024 г. развертывания сервера Многофакторной идентификации Azure больше не будут обслуживать запросы MFA. Чтобы обеспечить бесперебойную проверку подлинности и оставаться в поддерживаемом состоянии, организациям следует перенести данные проверки подлинности пользователей в облачную службу Azure MFA.

Требования к операционной системе

Требования к Windows

Все поддерживаемые версии Windows можно использовать с Windows Hello для бизнеса. Однако для облачного доверия Kerberos требуются минимальные версии:

Модель развертывания Тип доверия Версия Windows
🔲 Только облако Неприменимо Все поддерживаемые версии
🔲 Гибридная среда Cloud Kerberos — Windows 10 21H2 с KB5010415 и более поздними версиями
— Windows 11 21H2 с KB5010414 и более поздними версиями
🔲 Гибридная среда Раздел Все поддерживаемые версии
🔲 Гибридная среда Сертификат Все поддерживаемые версии
🔲 Локальная среда Раздел Все поддерживаемые версии
🔲 Локальная среда Сертификат Все поддерживаемые версии

Требования к Windows Server

Все поддерживаемые версии Windows Server можно использовать с Windows Hello для бизнеса в качестве контроллера домена. Однако для облачного доверия Kerberos требуются минимальные версии:

Модель развертывания Тип доверия Версия ОС контроллера домена
🔲 Только облако Неприменимо Все поддерживаемые версии
🔲 Гибридная среда Cloud Kerberos — Windows Server 2016 с KB3534307 и более поздними версиями
— Windows Server 2019 с KB4534321 и более поздними версиями
— Windows Server 2022
🔲 Гибридная среда Раздел Все поддерживаемые версии
🔲 Гибридная среда Сертификат Все поддерживаемые версии
🔲 Локальная среда Раздел Все поддерживаемые версии
🔲 Локальная среда Сертификат Все поддерживаемые версии

Подготовка пользователей

Когда вы будете готовы включить Windows Hello для бизнеса в организации, подготовьте пользователей, объяснив, как подготовить и использовать Windows Hello.

Дополнительные сведения см. в статье Подготовка пользователей.

Дальнейшие действия

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

Чтобы узнать больше о процессе развертывания, выберите модель развертывания и тип доверия в следующих раскрывающихся списках: