Как работает подготовка Windows Hello для бизнеса
Windows Hello для бизнеса подготовка позволяет пользователю зарегистрировать новые надежные двухфакторные учетные данные, которые можно использовать для проверки подлинности без пароля. Процесс подготовки зависит от:
- Присоединение устройства к Microsoft Entra ID
- Тип развертывания Windows Hello для бизнеса
- Если среда является управляемой или федеративной
Примечание.
Потоки в этом разделе не являются исчерпывающими для всех возможных сценариев. Например, федеративное доверие к ключам также поддерживается конфигурацией.
Подготовка для Microsoft Entra присоединенных устройств с управляемой проверкой подлинности
| Этап | Описание |
|---|---|
| A | Приложение подготовки, размещенное в узле cloud Experience Host (CXH), начинает подготовку, запрашивая маркер доступа для службы регистрации устройств Azure (ADRS). Приложение выполняет запрос с помощью подключаемого модуля диспетчера веб-учетных записей Microsoft Entra. Пользователи должны предоставить два фактора проверки подлинности. На этом этапе пользователь уже предоставил один фактор проверки подлинности, обычно это имя пользователя и пароль. Служба многофакторной проверки подлинности Microsoft Entra предоставляет второй фактор проверки подлинности. Если пользователь выполнил Microsoft Entra многофакторной проверки подлинности в течение последних 10 минут, например при регистрации устройства из готового интерфейса (OOBE), он не запрашивает MFA, так как текущая MFA остается действительной. Microsoft Entra ID проверяет запрос маркера доступа и связанное с ним утверждение MFA, создает маркер доступа ADRS и возвращает его приложению. |
| B | После получения маркера доступа ADRS приложение обнаруживает, есть ли на устройстве Windows Hello биометрический совместимый датчик. Если приложение обнаруживает биометрический датчик, оно дает пользователю возможность зарегистрировать биометрические данные. После завершения или пропуска биометрической регистрации приложение требует от пользователя создать ПИН-код и стандартный (и обратный жест при использовании с биометрией). Пользователь предоставляет и подтверждает свой ПИН-код. Затем приложение запрашивает пару ключей Windows Hello для бизнеса из пула предварительного отрождения ключей, который включает данные аттестации. Это ключ пользователя (ukpub/ukpriv). |
| C | Приложение отправляет маркер ADRS, ukpub, данные аттестации и сведения об устройстве в ADRS для регистрации ключа пользователя. Azure DRS проверяет, что утверждение MFA остается актуальным. При успешной проверке Azure DRS находит объект пользователя в Microsoft Entra ID, записывает ключевые сведения в атрибут с несколькими значениями. Основные сведения включают ссылку на устройство, с которого оно было создано. Microsoft Entra ID возвращает приложению идентификатор ключа, который сигнализирует о завершении подготовки пользователей и завершении работы приложения. |
Подготовка для Microsoft Entra присоединенных устройств с федеративной проверкой подлинности
| Этап | Описание |
|---|---|
| A | Приложение подготовки, размещенное в узле cloud Experience Host (CXH), начинает подготовку, запрашивая маркер доступа для службы регистрации устройств Azure (ADRS). Приложение выполняет запрос с помощью подключаемого модуля диспетчера веб-учетных записей Microsoft Entra. В федеративной среде подключаемый модуль отправляет запрос маркера в локальную службу stS, например службы федерации Active Directory (AD FS). Локальная служба stS проверяет подлинность пользователя и определяет, должен ли пользователь выполнять другой фактор проверки подлинности. Пользователи должны предоставить два фактора проверки подлинности. На этом этапе пользователь уже предоставил один фактор проверки подлинности, обычно это имя пользователя и пароль. Служба многофакторной проверки подлинности Microsoft Entra предоставляет второй фактор проверки подлинности. Если пользователь выполнил Microsoft Entra многофакторной проверки подлинности в течение последних 10 минут, например при регистрации устройства из готового интерфейса (OOBE), он не запрашивает MFA, так как текущая MFA остается действительной. Локальный сервер STS выдает корпоративный токен при успешной MFA. Приложение отправляет маркер в Microsoft Entra ID. Microsoft Entra ID проверяет запрос маркера доступа и связанное с ним утверждение MFA, создает маркер доступа ADRS и возвращает его приложению. |
| B | После получения маркера доступа ADRS приложение обнаруживает, есть ли на устройстве Windows Hello биометрический совместимый датчик. Если приложение обнаруживает биометрический датчик, оно дает пользователю возможность зарегистрировать биометрические данные. После завершения или пропуска биометрической регистрации приложение требует от пользователя создать ПИН-код и стандартный (и обратный жест при использовании с биометрией). Пользователь предоставляет и подтверждает свой ПИН-код. Затем приложение запрашивает пару ключей Windows Hello для бизнеса из пула предварительного отрождения ключей, который включает данные аттестации. Это ключ пользователя (ukpub/ukpriv). |
| C | Приложение отправляет маркер ADRS, ukpub, данные аттестации и сведения об устройстве в ADRS для регистрации ключа пользователя. Azure DRS проверяет, что утверждение MFA остается актуальным. При успешной проверке Azure DRS находит объект пользователя в Microsoft Entra ID, записывает ключевые сведения в атрибут с несколькими значениями. Основные сведения включают ссылку на устройство, с которого оно было создано. Microsoft Entra ID возвращает приложению идентификатор ключа, который сигнализирует об окончании подготовки пользователей и завершении работы приложения. |
Подготовка в облачной модели развертывания доверия Kerberos с управляемой проверкой подлинности
| Этап | Описание |
|---|---|
| A | Приложение подготовки, размещенное в узле cloud Experience Host (CXH), начинает подготовку, запрашивая маркер доступа для службы регистрации устройств Azure (ADRS). Приложение выполняет запрос с помощью подключаемого модуля диспетчера веб-учетных записей Microsoft Entra. Пользователи должны предоставить два фактора проверки подлинности. На этом этапе пользователь уже предоставил один фактор проверки подлинности, обычно это имя пользователя и пароль. Служба многофакторной проверки подлинности Microsoft Entra предоставляет второй фактор проверки подлинности. Если пользователь выполнил Microsoft Entra многофакторной проверки подлинности в течение последних 10 минут, например при регистрации устройства из готового интерфейса (OOBE), он не запрашивает MFA, так как текущая MFA остается действительной. Microsoft Entra ID проверяет запрос маркера доступа и связанное с ним утверждение MFA, создает маркер доступа ADRS и возвращает его приложению. |
| B | После получения маркера доступа ADRS приложение обнаруживает, есть ли на устройстве Windows Hello биометрический совместимый датчик. Если приложение обнаруживает биометрический датчик, оно дает пользователю возможность зарегистрировать биометрические данные. После завершения или пропуска биометрической регистрации приложение требует от пользователя создать ПИН-код и стандартный (и обратный жест при использовании с биометрией). Пользователь предоставляет и подтверждает свой ПИН-код. Затем приложение запрашивает пару ключей Windows Hello для бизнеса из пула предварительного отрождения ключей, который включает данные аттестации. Это ключ пользователя (ukpub/ukpriv). |
| C | Приложение отправляет маркер ADRS, ukpub, данные аттестации и сведения об устройстве в ADRS для регистрации ключа пользователя. Azure DRS проверяет, что утверждение MFA остается актуальным. При успешной проверке Azure DRS находит объект пользователя в Microsoft Entra ID, записывает ключевые сведения в атрибут с несколькими значениями. Основные сведения включают ссылку на устройство, с которого оно было создано. Microsoft Entra ID возвращает приложению идентификатор ключа, который сигнализирует о завершении подготовки пользователей и завершении работы приложения. |
Примечание.
Windows Hello для бизнеса облачное доверие Kerberos не требует синхронизации ключей пользователей из Microsoft Entra ID в Active Directory. Пользователи могут немедленно пройти проверку подлинности в Microsoft Entra ID и AD после подготовки своих учетных данных.
Подготовка в гибридной модели развертывания доверия к ключу с управляемой проверкой подлинности
| Этап | Описание |
|---|---|
| A | Приложение подготовки, размещенное в узле cloud Experience Host (CXH), начинает подготовку, запрашивая маркер доступа для службы регистрации устройств Azure (ADRS). Приложение выполняет запрос с помощью подключаемого модуля диспетчера веб-учетных записей Microsoft Entra. Пользователи должны предоставить два фактора проверки подлинности. На этом этапе пользователь уже предоставил один фактор проверки подлинности, обычно это имя пользователя и пароль. Служба многофакторной проверки подлинности Microsoft Entra предоставляет второй фактор проверки подлинности. Если пользователь выполнил Microsoft Entra многофакторной проверки подлинности в течение последних 10 минут, например при регистрации устройства из готового интерфейса (OOBE), он не запрашивает MFA, так как текущая MFA остается действительной. Microsoft Entra ID проверяет запрос маркера доступа и связанное с ним утверждение MFA, создает маркер доступа ADRS и возвращает его приложению. |
| B | После получения маркера доступа ADRS приложение обнаруживает, есть ли на устройстве Windows Hello биометрический совместимый датчик. Если приложение обнаруживает биометрический датчик, оно дает пользователю возможность зарегистрировать биометрические данные. После завершения или пропуска биометрической регистрации приложение требует от пользователя создать ПИН-код и стандартный (и обратный жест при использовании с биометрией). Пользователь предоставляет и подтверждает свой ПИН-код. Затем приложение запрашивает пару ключей Windows Hello для бизнеса из пула предварительного отрождения ключей, который включает данные аттестации. Это ключ пользователя (ukpub/ukpriv). |
| C | Приложение отправляет маркер ADRS, ukpub, данные аттестации и сведения об устройстве в ADRS для регистрации ключа пользователя. Azure DRS проверяет, что утверждение MFA остается актуальным. При успешной проверке Azure DRS находит объект пользователя в Microsoft Entra ID, записывает ключевые сведения в атрибут с несколькими значениями. Основные сведения включают ссылку на устройство, с которого оно было создано. Microsoft Entra ID возвращает приложению идентификатор ключа, который сигнализирует о завершении подготовки пользователей и завершении работы приложения. |
| D | Microsoft Entra Connect запрашивает обновления для следующего цикла синхронизации. Microsoft Entra ID отправляет открытый ключ пользователя, который был безопасно зарегистрирован путем подготовки. Microsoft Entra Connect получает открытый ключ и записывает его в атрибут пользователя msDS-KeyCredentialLink в Active Directory. |
Важно.
Только что подготовленный пользователь не сможет войти с помощью Windows Hello для бизнеса, пока Microsoft Entra Connect не синхронизировать открытый ключ с локальная служба Active Directory.
Подготовка в гибридной модели развертывания доверия сертификатов с федеративной проверкой подлинности
| Этап | Описание |
|---|---|
| A | Приложение подготовки, размещенное в узле cloud Experience Host (CXH), начинает подготовку, запрашивая маркер доступа для службы регистрации устройств Azure (ADRS). Приложение выполняет запрос с помощью подключаемого модуля диспетчера веб-учетных записей Microsoft Entra. В федеративной среде подключаемый модуль отправляет запрос маркера в локальную службу stS, например службы федерации Active Directory (AD FS). Локальная служба stS проверяет подлинность пользователя и определяет, должен ли пользователь выполнять другой фактор проверки подлинности. Пользователи должны предоставить два фактора проверки подлинности. На этом этапе пользователь уже предоставил один фактор проверки подлинности, обычно это имя пользователя и пароль. Служба многофакторной проверки подлинности Microsoft Entra (или служба MFA, не относяющаяся к Корпорации Майкрософт) предоставляет второй фактор проверки подлинности. Локальный сервер STS выдает корпоративный токен при успешной MFA. Приложение отправляет маркер в Microsoft Entra ID. Microsoft Entra ID проверяет запрос маркера доступа и связанное с ним утверждение MFA, создает маркер доступа ADRS и возвращает его приложению. |
| B | После получения маркера доступа ADRS приложение обнаруживает, есть ли на устройстве Windows Hello биометрический совместимый датчик. Если приложение обнаруживает биометрический датчик, оно дает пользователю возможность зарегистрировать биометрические данные. После завершения или пропуска биометрической регистрации приложение требует от пользователя создать ПИН-код и стандартный (и обратный жест при использовании с биометрией). Пользователь предоставляет и подтверждает свой ПИН-код. Затем приложение запрашивает пару ключей Windows Hello для бизнеса из пула предварительного отрождения ключей, который включает данные аттестации. Это ключ пользователя (ukpub/ukpriv). |
| C | Приложение отправляет маркер ADRS, ukpub, данные аттестации и сведения об устройстве в ADRS для регистрации ключа пользователя. Azure DRS проверяет, что утверждение MFA остается актуальным. При успешной проверке Azure DRS находит объект пользователя в Microsoft Entra ID, записывает ключевые сведения в атрибут с несколькими значениями. Основные сведения включают ссылку на устройство, с которого оно было создано. Microsoft Entra ID возвращает в приложение идентификатор ключа и квитанцию ключа, представляющую конец регистрации ключа пользователя. |
| D | Часть подготовки запроса сертификата начинается после того, как приложение получит успешный ответ от регистрации ключа. Приложение создает запрос сертификата PKCS#10. Ключ, используемый в запросе сертификата, является тем же ключом, который был подготовлен безопасно. Приложение отправляет запрос на получение ключа и сертификат, который включает открытый ключ, в центр регистрации сертификатов, размещенный в ферме службы федерации Active Directory (AD FS) (AD FS). После получения запроса на сертификат центр регистрации сертификатов запрашивает в Active Directory список зарегистрированных открытых ключей msDS-KeyCredentialsLink. |
| E | Центр регистрации проверяет, что открытый ключ в запросе сертификата соответствует зарегистрированным ключу пользователя. Если открытый ключ в сертификате не найден в списке зарегистрированных открытых ключей, он проверяет получение ключа, чтобы убедиться, что ключ был безопасно зарегистрирован в Azure. После проверки квитанции ключа или открытого ключа центр регистрации подписывает запрос на сертификат, используя сертификат агента регистрации. |
| F | Центр регистрации отправляет запрос на сертификат в центр сертификации предприятия, выдающего сертификаты. Центр сертификации проверяет, что запрос сертификата подписан действительным агентом регистрации и после успешного выполнения выдает сертификат и возвращает его в центр регистрации, который затем возвращает сертификат приложению. |
| G | Приложение получает только что выданный сертификат и устанавливает его в личное хранилище пользователя. Это сигнализирует о завершении подготовки. |
Важно.
Синхронная регистрация сертификата не зависит от Microsoft Entra Connect для синхронизации открытого ключа пользователя для выдачи сертификата проверки подлинности Windows Hello для бизнеса. Пользователи могут выполнить вход с помощью сертификата сразу после завершения подготовки. Microsoft Entra Connect продолжает синхронизировать открытый ключ с Active Directory, но не отображается в этом потоке.
Подготовка в локальной модели развертывания доверия к ключу
| Этап | Описание |
|---|---|
| A | Приложение подготовки, размещенное в узле cloud Experience Host (CXH), начинает подготовку с запроса маркера доступа для службы регистрации корпоративных устройств (EDRS). Приложение выполняет запрос с помощью подключаемого модуля диспетчера веб-учетных записей Microsoft Entra. В локальном развертывании подключаемый модуль отправляет запрос маркера в локальную службу безопасности, например службы федерации Active Directory (AD FS). Локальная служба stS проверяет подлинность пользователя и определяет, должен ли пользователь выполнять другой фактор проверки подлинности. Пользователи должны предоставить два фактора проверки подлинности. На этом этапе пользователь уже предоставил один фактор проверки подлинности, обычно это имя пользователя и пароль. Microsoft Entra сервер многофакторной проверки подлинности (или служба MFA сторонних поставщиков) обеспечивает второй фактор проверки подлинности. Локальный сервер STS выдает корпоративный маркер DRS при успешном выполнении MFA. |
| B | После получения маркера доступа EDRS приложение обнаруживает, имеет ли устройство Windows Hello биометрический совместимый датчик. Если приложение обнаруживает биометрический датчик, оно дает пользователю возможность зарегистрировать биометрические данные. После завершения или пропуска биометрической регистрации приложение требует от пользователя создать ПИН-код и стандартный (и обратный жест при использовании с биометрией). Пользователь предоставляет и подтверждает свой ПИН-код. Затем приложение запрашивает пару ключей Windows Hello для бизнеса из пула предварительного отрождения ключей, который включает данные аттестации. Это ключ пользователя (ukpub/ukpriv). |
| C | Приложение отправляет токен EDRS, ukpub, данные аттестации и сведения об устройстве в enterprise DRS для регистрации ключа пользователя. Enterprise DRS проверяет, что утверждение MFA остается актуальным. После успешной проверки enterprise DRS находит объект пользователя в Active Directory и записывает ключевые сведения в атрибут с несколькими значениями. Основные сведения включают ссылку на устройство, с которого оно было создано. Enterprise DRS возвращает приложению идентификатор ключа, который представляет конец регистрации ключа пользователя. |
Подготовка в локальной модели развертывания доверия сертификатов
| Этап | Описание |
|---|---|
| A | Приложение подготовки, размещенное в узле cloud Experience Host (CXH), начинает подготовку с запроса маркера доступа для службы регистрации корпоративных устройств (EDRS). Приложение выполняет запрос с помощью подключаемого модуля диспетчера веб-учетных записей Microsoft Entra. В локальном развертывании подключаемый модуль отправляет запрос маркера в локальную службу безопасности, например службы федерации Active Directory (AD FS). Локальная служба stS проверяет подлинность пользователя и определяет, должен ли пользователь выполнять другой фактор проверки подлинности. Пользователи должны предоставить два фактора проверки подлинности. На этом этапе пользователь уже предоставил один фактор проверки подлинности, обычно это имя пользователя и пароль. Microsoft Entra сервер многофакторной проверки подлинности (или служба MFA сторонних поставщиков) обеспечивает второй фактор проверки подлинности. Локальный сервер STS выдает корпоративный маркер DRS при успешном выполнении MFA. |
| B | После получения маркера доступа EDRS приложение обнаруживает, имеет ли устройство Windows Hello биометрический совместимый датчик. Если приложение обнаруживает биометрический датчик, оно дает пользователю возможность зарегистрировать биометрические данные. После завершения или пропуска биометрической регистрации приложение требует от пользователя создать ПИН-код и стандартный (и обратный жест при использовании с биометрией). Пользователь предоставляет и подтверждает свой ПИН-код. Затем приложение запрашивает пару ключей Windows Hello для бизнеса из пула предварительного отрождения ключей, который включает данные аттестации. Это ключ пользователя (ukpub/ukpriv). |
| C | Приложение отправляет токен EDRS, ukpub, данные аттестации и сведения об устройстве в enterprise DRS для регистрации ключа пользователя. Enterprise DRS проверяет, что утверждение MFA остается актуальным. После успешной проверки enterprise DRS находит объект пользователя в Active Directory и записывает ключевые сведения в атрибут с несколькими значениями. Основные сведения включают ссылку на устройство, с которого оно было создано. Enterprise DRS возвращает приложению идентификатор ключа, который представляет конец регистрации ключа пользователя. |
| D | Часть подготовки запроса сертификата начинается после того, как приложение получит успешный ответ от регистрации ключа. Приложение создает запрос сертификата PKCS#10. Ключ, используемый в запросе сертификата, является тем же ключом, который был подготовлен безопасно. Приложение отправляет запрос на сертификат, включающий открытый ключ, в центр регистрации сертификатов, размещенный в ферме службы федерации Active Directory (AD FS) (AD FS). После получения запроса на сертификат центр регистрации сертификатов запрашивает в Active Directory список зарегистрированных открытых ключей msDS-KeyCredentialsLink. |
| E | Центр регистрации проверяет, что открытый ключ в запросе сертификата соответствует зарегистрированным ключу пользователя. После проверки открытого ключа центр регистрации подписывает запрос на сертификат, используя сертификат агента регистрации. |
| F | Центр регистрации отправляет запрос на сертификат в центр сертификации предприятия, выдающего сертификаты. Центр сертификации проверяет, что запрос сертификата подписан действительным агентом регистрации и после успешного выполнения выдает сертификат и возвращает его в центр регистрации, который затем возвращает сертификат приложению. |
| G | Приложение получает только что выданный сертификат и устанавливает его в личное хранилище пользователя. Это сигнализирует о завершении подготовки. |