проверка подлинности Windows Hello для бизнеса
Windows Hello для бизнеса проверка подлинности — это двухфакторная проверка подлинности без пароля. Проверка подлинности с помощью Windows Hello для бизнеса обеспечивает удобный интерфейс входа, который выполняет проверку подлинности пользователя как для Microsoft Entra ID, так и для ресурсов Active Directory.
Microsoft Entra присоединенные устройства проходят проверку подлинности в Microsoft Entra ID во время входа и могут при необходимости пройти проверку подлинности в Active Directory. Microsoft Entra устройства, присоединенные к гибридной среде, проходят проверку подлинности в Active Directory во время входа и Microsoft Entra ID в фоновом режиме.
Microsoft Entra присоединение проверки подлинности к Microsoft Entra ID
Примечание.
Все устройства, присоединенные к Microsoft Entra, проходят проверку подлинности с помощью Windows Hello для бизнеса, чтобы Microsoft Entra ID одинаковым образом. Тип доверия Windows Hello для бизнеса влияет только на то, как устройство проходит проверку подлинности в локальной службе AD.
| Этап | Описание |
|---|---|
| A | Проверка подлинности начинается, когда пользователь закрывает экран блокировки, что активирует Winlogon для отображения поставщика учетных данных Windows Hello для бизнеса. Пользователь предоставляет свой жест Windows Hello (ПИН-код или биометрические данные). Поставщик учетных данных упаковывает эти учетные данные и возвращает их в Winlogon. Winlogon передает собранные учетные данные в lsass. Lsass передает собранные учетные данные поставщику поддержки безопасности облачной проверки подлинности, который называется поставщиком облачной точки доступа. |
| B | Поставщик облачной точки доступа запрашивает nonce у Microsoft Entra ID. Microsoft Entra ID возвращает значение nonce. Поставщик облачной точки доступа подписывает nonce с помощью закрытого ключа пользователя и возвращает подписанный nonce в Microsoft Entra ID. |
| C | Microsoft Entra ID проверяет подписанный nonce с помощью безопасно зарегистрированного открытого ключа пользователя по сигнатуре nonce. Microsoft Entra ID затем проверяет возвращенный подписанный nonce и создает PRT с ключом сеанса, зашифрованным в транспортный ключ устройства, и возвращает его поставщику облачной точки доступа. |
| D | Поставщик облачной точки доступа получает зашифрованный PRT с ключом сеанса. Используя закрытый транспортный ключ устройства, поставщик облачной точки доступа расшифровывает ключ сеанса и защищает ключ сеанса с помощью доверенного платформенного модуля устройства. |
| E | Поставщик облачной точки доступа возвращает успешный ответ проверки подлинности для lsass. Lsass кэширует PRT и сообщает Winlogon об успешной проверке подлинности. Winlogon создает сеанс входа, загружает профиль пользователя и запускает explorer.exe. |
Microsoft Entra присоединение проверки подлинности к Active Directory с помощью облачного доверия Kerberos
| Этап | Описание |
|---|---|
| A | Проверка подлинности в Active Directory с устройства, присоединенного к Microsoft Entra, начинается с первой попытки пользователя использовать ресурс, которому требуется проверка подлинности Kerberos. Поставщик поддержки безопасности Kerberos, размещенный в lsass, использует метаданные из ключа Windows Hello для бизнеса, чтобы получить подсказку о домене пользователя. Используя подсказку, поставщик использует службу DClocator для поиска контроллера домена. |
| B | После обнаружения контроллера домена поставщик Kerberos отправляет контроллеру домена частичный TGT, полученный от Microsoft Entra ID из предыдущей проверки подлинности Microsoft Entra. Частичное TGT содержит только идентификатор безопасности пользователя и подписан Microsoft Entra Kerberos. Контроллер домена проверяет, является ли частичный TGT допустимым. При успешном выполнении KDC возвращает клиенту TGT. |
Microsoft Entra присоединение проверки подлинности к Active Directory с помощью ключа
| Этап | Описание |
|---|---|
| A | Проверка подлинности в Active Directory с устройства, присоединенного к Microsoft Entra, начинается с первой попытки пользователя использовать ресурс, которому требуется проверка подлинности Kerberos. Поставщик поддержки безопасности Kerberos, размещенный в lsass, использует метаданные из ключа Windows Hello для бизнеса, чтобы получить подсказку о домене пользователя. Используя подсказку, поставщик использует службу DClocator для поиска контроллера домена. После того как поставщик находит контроллер домена, поставщик использует закрытый ключ для подписи данных предварительной проверки подлинности Kerberos. |
| B | Поставщик Kerberos отправляет подписанные данные предварительной проверки подлинности и его открытый ключ (в виде самозаверяющего сертификата) в службу Центра распространения ключей (KDC), запущенную на контроллере домена, в виде KERB_AS_REQ. Контроллер домена определяет, что сертификат является самозаверяющий сертификат. Он извлекает открытый ключ из сертификата, включенного в KERB_AS_REQ, и выполняет поиск открытого ключа в Active Directory. Он проверяет имя участника-пользователя на соответствие запросу проверки подлинности имени участника-пользователя, зарегистрированного в Active Directory, и проверяет подписанные данные предварительной проверки подлинности с помощью открытого ключа из Active Directory. При успешном выполнении KDC возвращает клиенту TGT с его сертификатом в KERB_AS_REP. |
| C | Поставщик Kerberos гарантирует, что он может доверять ответу контроллера домена. Во-первых, это гарантирует, что сертификат KDC связан с корневым сертификатом, который является доверенным для устройства. Затем он гарантирует, что сертификат находится в течение срока действия и что он не был отозван. Затем поставщик Kerberos проверяет наличие сертификата проверки подлинности KDC и что альтернативное имя субъекта, указанное в сертификате KDC, соответствует доменному имени, с которым выполняется проверка подлинности пользователя. После прохождения этого условия Kerberos возвращает TGT в lsass, где он кэширован и используется для последующих запросов на запросы на обслуживание. |
Примечание.
У вас может быть локальный домен, федеративный с Microsoft Entra ID. После успешной подготовки Windows Hello для бизнеса ПИН-кода или био на устройстве, присоединенном к Microsoft Entra, все будущие учетные данные входа Windows Hello для бизнеса (PIN-код/Био) будут проходить проверку подлинности непосредственно в Microsoft Entra ID для получения PRT и активации проверки подлинности в контроллере домена (если доступно подключение от лос-к контроллеру домена), чтобы получить Kerberos. Он больше не использует AD FS для проверки подлинности Windows Hello для бизнеса входа.
Microsoft Entra присоединение проверки подлинности к Active Directory с помощью сертификата
| Этап | Описание |
|---|---|
| A | Проверка подлинности в Active Directory с устройства, присоединенного к Microsoft Entra, начинается с первой попытки пользователя использовать ресурс, которому требуется проверка подлинности Kerberos. Поставщик поддержки безопасности Kerberos, размещенный в lsass, использует сведения из сертификата, чтобы получить подсказку о домене пользователя. Kerberos может использовать различающееся имя пользователя, найденного в субъекте сертификата, или имя участника-пользователя, найденного в альтернативном имени субъекта сертификата. Используя подсказку, поставщик использует службу DClocator для поиска контроллера домена. После того как поставщик находит активный контроллер домена, поставщик использует закрытый ключ для подписи данных предварительной проверки подлинности Kerberos. |
| B | Поставщик Kerberos отправляет подписанные данные предварительной проверки подлинности и сертификат пользователя, включающий открытый ключ, в службу центра распространения ключей (KDC), запущенную на контроллере домена, в виде KERB_AS_REQ. Контроллер домена определяет, что сертификат не является самозаверяющий сертификат. Контроллер домена гарантирует, что цепочки сертификатов являются доверенным корневым сертификатом, не имеют срока действия, могут использоваться для проверки подлинности и не были отозваны. Он получает открытый ключ и имя участника-пользователя из сертификата, включенного в KERB_AS_REQ, и выполняет поиск имени участника-пользователя в Active Directory. Он проверяет подписанные данные предварительной проверки подлинности с помощью открытого ключа из сертификата. При успешном выполнении KDC возвращает клиенту TGT с его сертификатом в KERB_AS_REP. |
| C | Поставщик Kerberos гарантирует, что он может доверять ответу контроллера домена. Во-первых, это гарантирует, что сертификат KDC связан с корневым сертификатом, который является доверенным для устройства. Затем он гарантирует, что сертификат находится в течение срока действия и что он не был отозван. Затем поставщик Kerberos проверяет наличие сертификата проверки подлинности KDC и что альтернативное имя субъекта, указанное в сертификате KDC, соответствует доменному имени, с которым выполняется проверка подлинности пользователя. После прохождения этого условия Kerberos возвращает TGT в lsass, где он кэширован и используется для последующих запросов на запросы на обслуживание. |
Примечание.
У вас может быть локальный домен, федеративный с Microsoft Entra ID. После успешной подготовки Windows Hello для бизнеса ПИН-коде или биосреде любой будущий вход Windows Hello для бизнеса (PIN-код или био) будет проходить проверку подлинности непосредственно в Microsoft Entra ID для получения PRT, а также проверки подлинности в контроллере домена (если доступно подключение от лос-к контроллеру домена), чтобы получить Kerberos, как упоминалось ранее. Федерация AD FS используется только в том случае, если из клиента выполняются корпоративные вызовы PRT. Чтобы получить "Корпоративный PRT" из федерации, необходимо включить обратную запись устройства.
Microsoft Entra проверки подлинности гибридного присоединения с помощью облачного доверия Kerberos
| Этап | Описание |
|---|---|
| A | Проверка подлинности начинается, когда пользователь закрывает экран блокировки, что активирует Winlogon для отображения поставщика учетных данных Windows Hello для бизнеса. Пользователь предоставляет свой жест Windows Hello (ПИН-код или биометрические данные). Поставщик учетных данных упаковывает эти учетные данные и возвращает их в Winlogon. Winlogon передает собранные учетные данные в lsass. Lsass запрашивает политику Windows Hello для бизнеса, чтобы проверка, если включено доверие к Kerberos в облаке. Если включено доверие к Облачной службе Kerberos, Lsass передает собранные учетные данные поставщику поддержки безопасности облачной проверки подлинности или облачной точке доступа. Cloud AP запрашивает nonce из Microsoft Entra ID. Microsoft Entra ID возвращает значение nonce. |
| B | Cloud AP подписывает nonce с помощью закрытого ключа пользователя и возвращает подписанный nonce для Microsoft Entra ID. |
| C | Microsoft Entra ID проверяет подписанный nonce с помощью безопасно зарегистрированного открытого ключа пользователя по сигнатуре nonce. После проверки подписи Microsoft Entra ID затем проверяет возвращенный подписанный nonce. После проверки nonce Microsoft Entra ID создает PRT с ключом сеанса, зашифрованным для транспортного ключа устройства, и создает частичный TGT из Microsoft Entra Kerberos и возвращает их в Cloud AP. |
| D | Cloud AP получает зашифрованный PRT с ключом сеанса. Используя закрытый транспортный ключ устройства, cloud AP расшифровывает ключ сеанса и защищает ключ сеанса с помощью доверенного платформенного модуля устройства (если доступно). Cloud AP возвращает успешный ответ проверки подлинности для lsass. Lsass кэширует PRT и Частичный TGT. |
| E | Поставщик поддержки безопасности Kerberos, размещенный в lsass, использует метаданные из ключа Windows Hello для бизнеса, чтобы получить подсказку о домене пользователя. Используя подсказку, поставщик использует службу DClocator для поиска контроллера домена. После обнаружения активного контроллера домена поставщик Kerberos отправляет на контроллер домена частичный TGT, полученный от Microsoft Entra ID. Частичное TGT содержит только идентификатор безопасности пользователя и подписывается Microsoft Entra Kerberos. Контроллер домена проверяет, является ли частичный TGT допустимым. При успешном выполнении KDC возвращает клиенту TGT. Kerberos возвращает TGT в lsass, где он кэширован и используется для последующих запросов на запросы на обслуживание. Lsass сообщает Winlogon об успешной проверке подлинности. Winlogon создает сеанс входа, загружает профиль пользователя и запускает explorer.exe. |
Microsoft Entra проверки подлинности гибридного присоединения с помощью ключа
| Этап | Описание |
|---|---|
| A | Проверка подлинности начинается, когда пользователь закрывает экран блокировки, что активирует Winlogon для отображения поставщика учетных данных Windows Hello для бизнеса. Пользователь предоставляет свой жест Windows Hello (ПИН-код или биометрические данные). Поставщик учетных данных упаковывает эти учетные данные и возвращает их в Winlogon. Winlogon передает собранные учетные данные в lsass. Lsass передает собранные учетные данные поставщику поддержки безопасности Kerberos. Поставщик Kerberos получает указания домена от присоединенной к домену рабочей станции, чтобы найти контроллер домена для пользователя. |
| B | Поставщик Kerberos отправляет подписанные данные предварительной проверки подлинности и открытый ключ пользователя (в виде самозаверяющего сертификата) в службу центра распространения ключей (KDC), запущенную на контроллере домена, в виде KERB_AS_REQ. Контроллер домена определяет, что сертификат является самозаверяющий сертификат. Он извлекает открытый ключ из сертификата, включенного в KERB_AS_REQ, и выполняет поиск открытого ключа в Active Directory. Он проверяет имя участника-пользователя на соответствие запросу проверки подлинности имени участника-пользователя, зарегистрированного в Active Directory, и проверяет подписанные данные предварительной проверки подлинности с помощью открытого ключа из Active Directory. При успешном выполнении KDC возвращает клиенту TGT с его сертификатом в KERB_AS_REP. |
| C | Поставщик Kerberos гарантирует, что он может доверять ответу контроллера домена. Во-первых, это гарантирует, что сертификат KDC связан с корневым сертификатом, который является доверенным для устройства. Затем он гарантирует, что сертификат находится в течение срока действия и что он не был отозван. Затем поставщик Kerberos проверяет наличие сертификата проверки подлинности KDC и что альтернативное имя субъекта, указанное в сертификате KDC, соответствует доменному имени, с которым выполняется проверка подлинности пользователя. |
| D | После прохождения этого условия Kerberos возвращает TGT в lsass, где он кэширован и используется для последующих запросов на запросы на обслуживание. |
| E | Lsass сообщает Winlogon об успешной проверке подлинности. Winlogon создает сеанс входа, загружает профиль пользователя и запускает explorer.exe. |
| F | Пока Windows загружает рабочий стол пользователя, lsass передает собранные учетные данные поставщику поддержки безопасности облачной проверки подлинности, который называется поставщиком облачной точки доступа. Поставщик облачной точки доступа запрашивает nonce у Microsoft Entra ID. Microsoft Entra ID возвращает значение nonce. |
| G | Поставщик облачной точки доступа подписывает nonce с помощью закрытого ключа пользователя и возвращает подписанный nonce в Microsoft Entra ID. Microsoft Entra ID проверяет подписанный nonce с помощью безопасно зарегистрированного открытого ключа пользователя по сигнатуре nonce. После проверки подписи Microsoft Entra ID затем проверяет возвращенный подписанный nonce. После проверки nonce Microsoft Entra ID создает PRT с ключом сеанса, зашифрованным для транспортного ключа устройства, и возвращает его поставщику облачной точки доступа. Поставщик облачной точки доступа получает зашифрованный PRT с ключом сеанса. Используя закрытый транспортный ключ устройства, поставщик облачной точки доступа расшифровывает ключ сеанса и защищает ключ сеанса с помощью доверенного платформенного модуля устройства. Поставщик облачной точки доступа возвращает успешный ответ проверки подлинности для lsass. Lsass кэширует PRT. |
Важно.
В приведенной выше модели развертывания только что подготовленный пользователь не сможет выполнить вход с помощью Windows Hello для бизнеса, пока (a) Microsoft Entra Connect не будет успешно синхронизировать открытый ключ с локальная служба Active Directory и (b) устройство впервые имеет прямой доступ к контроллеру домена.
Microsoft Entra проверки подлинности гибридного присоединения с помощью сертификата
| Этап | Описание |
|---|---|
| A | Проверка подлинности начинается, когда пользователь закрывает экран блокировки, что активирует Winlogon для отображения поставщика учетных данных Windows Hello для бизнеса. Пользователь предоставляет свой жест Windows Hello (ПИН-код или биометрические данные). Поставщик учетных данных упаковывает эти учетные данные и возвращает их в Winlogon. Winlogon передает собранные учетные данные в lsass. Lsass передает собранные учетные данные поставщику поддержки безопасности Kerberos. Поставщик Kerberos получает указания домена от присоединенной к домену рабочей станции, чтобы найти контроллер домена для пользователя. |
| B | Поставщик Kerberos отправляет подписанные данные предварительной проверки подлинности и сертификат пользователя, включающий открытый ключ, в службу центра распространения ключей (KDC), запущенную на контроллере домена, в виде KERB_AS_REQ. Контроллер домена определяет, что сертификат не является самозаверяющий сертификат. Контроллер домена гарантирует, что цепочки сертификатов являются доверенным корневым сертификатом, не имеют срока действия, могут использоваться для проверки подлинности и не были отозваны. Он получает открытый ключ и имя участника-пользователя из сертификата, включенного в KERB_AS_REQ, и выполняет поиск имени участника-пользователя в Active Directory. Он проверяет подписанные данные предварительной проверки подлинности с помощью открытого ключа из сертификата. При успешном выполнении KDC возвращает клиенту TGT с его сертификатом в KERB_AS_REP. |
| C | Поставщик Kerberos гарантирует, что он может доверять ответу контроллера домена. Во-первых, это гарантирует, что сертификат KDC связан с корневым сертификатом, который является доверенным для устройства. Затем он гарантирует, что сертификат находится в течение срока действия и что он не был отозван. Затем поставщик Kerberos проверяет наличие сертификата проверки подлинности KDC и что альтернативное имя субъекта, указанное в сертификате KDC, соответствует доменному имени, с которым выполняется проверка подлинности пользователя. |
| D | После прохождения этого условия Kerberos возвращает TGT в lsass, где он кэширован и используется для последующих запросов на запросы на обслуживание. |
| E | Lsass сообщает Winlogon об успешной проверке подлинности. Winlogon создает сеанс входа, загружает профиль пользователя и запускает explorer.exe. |
| F | Пока Windows загружает рабочий стол пользователя, lsass передает собранные учетные данные поставщику поддержки безопасности облачной проверки подлинности, который называется поставщиком облачной точки доступа. Поставщик облачной точки доступа запрашивает nonce у Microsoft Entra ID. Microsoft Entra ID возвращает значение nonce. |
| G | Поставщик облачной точки доступа подписывает nonce с помощью закрытого ключа пользователя и возвращает подписанный nonce в Microsoft Entra ID. Microsoft Entra ID проверяет подписанный nonce с помощью безопасно зарегистрированного открытого ключа пользователя по сигнатуре nonce. После проверки подписи Microsoft Entra ID затем проверяет возвращенный подписанный nonce. После проверки nonce Microsoft Entra ID создает PRT с ключом сеанса, зашифрованным для транспортного ключа устройства, и возвращает его поставщику облачной точки доступа. Поставщик облачной точки доступа получает зашифрованный PRT с ключом сеанса. Используя закрытый транспортный ключ устройства, поставщик облачной точки доступа расшифровывает ключ сеанса и защищает ключ сеанса с помощью доверенного платформенного модуля устройства. Поставщик облачной точки доступа возвращает успешный ответ проверки подлинности для lsass. Lsass кэширует PRT. |
Важно.
В приведенной выше модели развертывания только что подготовленный пользователь не сможет выполнить вход с помощью Windows Hello для бизнеса, если устройство не имеет прямой видимости контроллера домена.