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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Контроллерам домена для гибридных и локальных развертываний требуется сертификат для устройств Windows, чтобы доверять контроллеру домена как допустимому
• Для развертываний, использующих тип доверия сертификатов, требуется корпоративный PKI и центр регистрации сертификатов (CRA) для выдачи пользователям сертификатов проверки подлинности. AD FS используется в качестве CRA
• Для гибридных развертываний может потребоваться выдача сертификатов VPN пользователям, чтобы включить подключение локальных ресурсов.

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

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

• Федерация с Microsoft Entra ID
• Синхронизация хэша паролей (PHS)
• Сквозная проверка подлинности (PTA)

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

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

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

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

• Настройка Microsoft Entra параметров многофакторной проверки подлинности
• Управление внешним методом проверки подлинности в Microsoft Entra ID

Федеративные домены могут настроить флаг FederatedIdpMfaBehavior . Флаг указывает Microsoft Entra ID принять, применить или отклонить запрос 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 Connect Sync для синхронизации удостоверений Active Directory (пользователей и устройств) или учетных данных между собой и Microsoft Entra ID. В процессе подготовки Window Hello для бизнеса пользователи регистрируют общедоступную часть своих учетных данных Windows Hello для бизнеса с помощью Microsoft Entra ID. Microsoft Entra Connect Sync синхронизирует открытый ключ Windows Hello для бизнеса с Active Directory. Эта синхронизация позволяет единому входу Microsoft Entra ID и его федеративные компоненты.

  Важно!

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

• Локальные развертывания используют синхронизацию каталогов для импорта пользователей из Active Directory на сервер Azure MFA, который отправляет данные в облачную службу MFA для выполнения проверки.

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

• Вариант CSP идеально подходит для устройств, управляемых с помощью решения для мобильных Управление устройствами (MDM), таких как Microsoft Intune. CSP также можно настроить с помощью пакетов подготовки
• Объект групповой политики можно использовать для настройки устройств, присоединенных к домену, и когда устройствами не управляются через MDM

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

• Windows Hello для бизнеса не требует подписки Microsoft Entra ID P1 или P2. Однако некоторые зависимости, такие как автоматическая регистрация MDM и условный доступ
  • Устройствам, управляемым через MDM, не требуется подписка Microsoft Entra ID P1 или P2. Отказав от подписки, пользователи должны вручную зарегистрировать устройства в решении MDM, такие как Microsoft Intune или поддерживаемый mdm сторонних поставщиков.
• Вы можете развернуть Windows Hello для бизнеса с помощью Microsoft Entra ID уровня "Бесплатный". Все учетные записи Microsoft Entra ID Free могут использовать Microsoft Entra многофакторную проверку подлинности для функций Windows без пароля.
  • Для некоторых Microsoft Entra функций многофакторной проверки подлинности требуется лицензия. Дополнительные сведения см. в разделе Функции и лицензии для Microsoft Entra многофакторной проверки подлинности.
• Регистрация сертификата с помощью центра регистрации AD FS требует, чтобы устройства прошли проверку подлинности на сервере AD FS. Для этого требуется обратная запись устройства, функция Microsoft Entra ID P1 или P2

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

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

Минимальные обязательные функциональные уровни домена и леса Windows Server 2008 R2 для всех моделей развертывания.

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

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

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