Планирование развертывания 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 для бизнеса следует учитывать семь main областей:

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

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

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

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

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

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

Примечание.

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

Типы доверия

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

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

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

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

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

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

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

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

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

Совет

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

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

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

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

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

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

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

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

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

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

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

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

Важно.

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

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

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

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

Важно.

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

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

Дополнительные сведения о настройке Microsoft Entra многофакторной проверки подлинности см. в разделе Настройка Microsoft Entra параметров многофакторной проверки подлинности.

Дополнительные сведения о настройке AD FS для многофакторной проверки подлинности см. в статье Настройка Azure MFA в качестве поставщика проверки подлинности с помощью AD FS.

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

Федеративные домены могут настроить флаг 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 ID
Гибридная среда Microsoft Entra ID
Локальная среда AD FS;

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

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

  • Гибридные развертывания используют 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 для выполнения проверки.
Модель развертывания Параметры синхронизации каталогов
Только облако Неприменимо
Гибридная среда Синхронизация Microsoft Entra Connect
Локальная среда Сервер Azure MFA

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

Windows Hello для бизнеса предоставляет широкий набор детализированных параметров политики. Существует два main варианта настройки 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 или поддерживаемый mdm сторонних поставщиков.
  • Вы можете развернуть Windows Hello для бизнеса с помощью Microsoft Entra ID уровня "Бесплатный". Все учетные записи Microsoft Entra ID Free могут использовать Microsoft Entra многофакторную проверку подлинности для функций Windows без пароля.
  • Регистрация сертификата с помощью центра регистрации AD FS требует, чтобы устройства прошли проверку подлинности на сервере AD FS. Для этого требуется обратная запись устройства, функция Microsoft Entra ID P1 или P2
Модель развертывания Тип доверия Лицензии на облачные службы (минимум)
🔲 Только облако Неприменимо не требуется
🔲 Гибридная среда Cloud Kerberos не требуется
🔲 Гибридная среда Раздел не требуется
🔲 Гибридная среда Сертификат Microsoft Entra ID P1
🔲 Локальная среда Раздел Azure MFA, если используется в качестве решения MFA
🔲 Локальная среда Сертификат Azure MFA, если используется в качестве решения 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.

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

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

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

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