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

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

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

Эта статья поможет устранить известные проблемы с развертыванием Windows Hello для бизнеса.

Сброс ПИН-кода на устройствах присоединения к Microsoft Entra завершается ошибкой Не удается открыть страницу

Для сброса ПИН-кода на устройствах, присоединенных к Microsoft Entra, используется поток, называемый веб-входом , для проверки подлинности пользователя выше блокировки. Веб-вход позволяет переходить только к определенным доменам. Если веб-вход пытается перейти к домену, который не разрешен, отображается страница с сообщением Об ошибке Не удается открыть страницу прямо сейчас.

Определение проблемы с разрешенным доменом сброса ПИН-кода

Пользователь может запустить поток сброса ПИН-кода с экрана блокировки, используя ссылку I for forgot my PIN в поставщике учетных данных ПИН-кода. При выборе ссылки запускается полноэкранный пользовательский интерфейс для интерфейса ПИН-кода на устройствах присоединения к Microsoft Entra. Как правило, в пользовательском интерфейсе отображается страница проверки подлинности, где пользователь проходит проверку подлинности с помощью учетных данных Microsoft Entra и завершает MFA.

В федеративных средах проверка подлинности может быть настроена для маршрутизации к AD FS или поставщику удостоверений сторонних поставщиков. Если поток сброса ПИН-кода запускается и пытается перейти на страницу сервера федеративного поставщика удостоверений, он завершается ошибкой и отображает ошибку Не удается открыть эту страницу прямо сейчас , если домен для страницы сервера не включен в список разрешений.

Если вы являетесь клиентом облака Azure для государственных организаций США , сброс ПИН-кода также пытается перейти к домену, который не включен в список разрешенных по умолчанию. В результате появится сообщение Не удается открыть страницу прямо сейчас.

Устранение проблемы с разрешенным доменом сброса ПИН-кода

Чтобы устранить эту ошибку, можно настроить список разрешенных доменов для сброса ПИН-кода с помощью политики ConfigureWebSignInAllowedUrls . Сведения о настройке политики см. в статье Настройка разрешенных URL-адресов для федеративных поставщиков удостоверений на устройствах, присоединенных к Microsoft Entra.

Вход с доверием к гибридному ключу нарушен из-за удаления открытого ключа пользователя

Относится к:

  • Гибридные развертывания доверия к ключам
  • Windows Server 2016, сборки с 14393.3930 по 14393.4048
  • Windows Server 2019, сборки с 17763.1457 по 17763.1613

В гибридных развертываниях с доверием к ключу с контроллерами домена под управлением определенных сборок Windows Server 2016 и Windows Server 2019 ключ Windows Hello для бизнеса удаляется после входа пользователя. Последующие входы завершаются ошибкой, пока ключ пользователя не будет синхронизирован во время следующего цикла разностной синхронизации Microsoft Entra Connect.

Выявление проблемы с удалением открытого ключа пользователя

После того как пользователь подготавливает учетные данные Windows Hello для бизнеса в гибридной среде доверия ключей, ключ должен синхронизироваться с Идентификатором Microsoft Entra с Active Directory во время цикла синхронизации Microsoft Entra Connect. Открытый ключ пользователя записывается в msDS-KeyCredentialLink атрибут объекта user.

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

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

После первоначальной попытки входа открытый ключ Windows Hello для бизнеса пользователя удаляется из msDS-KeyCredentialLink attribute. Вы можете проверить удаление, запросив атрибут пользователя msDS-KeyCredentialLink до и после входа. Вы можете запросить msDS-KeyCredentialLink в AD, используя Командлет Get-ADUser и указав msds-keycredentiallink для -Properties параметра .

Устранение проблемы с удалением открытого ключа пользователя

Чтобы устранить эту проблему, обновите контроллеры домена Windows Server 2016 и 2019 с помощью последних исправлений. В Windows Server 2016 поведение исправлено в сборке 14393.4104 (KB4593226) и более поздних версиях. В Windows Server 2019 поведение исправлено в сборке 17763.1637 (KB4592440).

Присоединенный к Microsoft Entra доступ устройства к локальным ресурсам с помощью доверия ключа и центра сертификации сторонних разработчиков (ЦС)

Относится к:

  • Развертывания с доверием к ключам, присоединенные к Microsoft Entra
  • Центр сертификации сторонних корпораций (ЦС), выдающий сертификаты контроллера домена

Windows Hello для бизнеса использует проверку подлинности на основе смарт-карт для многих операций. Этот тип проверки подлинности имеет специальные рекомендации при использовании ЦС сторонних корпораций для выдачи сертификатов, некоторые из которых применяются к контроллерам домена. Эти конфигурации требуются не для всех типов развертывания Windows Hello для бизнеса. Доступ к локальным ресурсам с устройства, присоединенного к Microsoft Entra, требует специальной настройки при использовании ЦС сторонних разработчиков для выдачи сертификатов контроллера домена.

Дополнительные сведения см. в статье Руководство по включению входа с помощью смарт-карты в центрах сертификации, отличных от Майкрософт.

Выявление проблем с доступом к локальным ресурсам в центрах сертификации сторонних поставщиков

Проблему можно определить с помощью трассировки сети или ведения журнала Kerberos из клиента. В трассировке сети клиенту не удается разместить TGS_REQ запрос, когда пользователь пытается получить доступ к ресурсу. На клиенте это можно увидеть в журнале событий операции Kerberos в разделе Application and Services/Microsoft/Windows/Security-Kerberos/Operational. Журналы отключены по умолчанию. Событие сбоя в этом случае содержит следующие сведения:

Log Name:      Microsoft-Windows-Kerberos/Operational
Source:        Microsoft-Windows-Security-Kerberos
Event ID:      107
GUID:          {98e6cfcb-ee0a-41e0-a57b-622d4e1b30b1}
Task Category: None
Level:         Error
Keywords:
User:          SYSTEM
Description:

The Kerberos client received a KDC certificate that does not have a matched domain name.
Expected Domain Name: ad.contoso.com
Error Code: 0xC000006D

Устранение проблемы с доступом к локальным ресурсам в центрах сертификации сторонних поставщиков

Чтобы устранить эту проблему, необходимо обновить сертификаты контроллера домена, чтобы субъект сертификата содержал путь к каталогу объекта сервера (различающееся имя). Пример темы: CN=DC1,OU=Domain Controllers,DC=ad,DC=contoso,DC=com

Кроме того, можно задать альтернативное имя субъекта (SAN) сертификата контроллера домена, чтобы он содержал полное доменное имя объекта сервера и netBIOS-имя домена. Пример альтернативного имени субъекта:

dns=dc1.ad.contoso.com
dns=ad.contoso.com
dns=ad

Проверка подлинности с доверием к ключу нарушена для Windows Server 2019

Относится к:

  • Windows Server 2019
  • Гибридные развертывания доверия к ключам
  • Локальные развертывания доверия к ключам

Контроллеры домена под управлением ранних версий Windows Server 2019 имеют проблему, которая препятствует правильной работе проверки подлинности с доверием к ключу. KDC_ERR_CLIENT_NAME_MISMATCH отчетов о трассировках сетей.

Выявление проблемы с проверкой подлинности с доверием к ключу Windows Server 2019

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

Эта ошибка отображается на устройствах с гибридным присоединением к Microsoft Entra в развертываниях с доверием к ключу после подготовки Windows Hello для бизнеса, но перед синхронизацией ключа пользователя с идентификатором Microsoft Entra в Active Directory. Если ключ пользователя не синхронизирован с идентификатором Microsoft Entra и msDS-keycredentiallink атрибут объекта пользователя в AD заполнен для NGC, возможно, возникнет ошибка.

Другой индикатор сбоя можно определить с помощью трассировок сети. При записи трассировки сети для события входа с доверием к ключу трассировки отображаются сбои Kerberos с ошибкой KDC_ERR_CLIENT_NAME_MISMATCH.

Устранение проблемы с проверкой подлинности с доверием к ключу Server 2019

Проблема устранена в Windows Server 2019 сборки 17763.316 (KB4487044). Чтобы устранить проблему, обновите все контроллеры домена Windows Server 2019 до сборки 17763.316 или более поздней версии.

Подготовка доверия сертификатов с помощью AD FS нарушена в Windows Server 2019

Относится к:

  • Windows Server 2019
  • Гибридные развертывания доверия сертификатов
  • Локальные развертывания доверия сертификатов

Ad FS, работающий в Windows Server 2019, не завершает проверку подлинности устройства из-за недопустимой проверки входящих областей в запросе. Проверка подлинности устройства в AD FS — это требование для регистрации сертификата с помощью AD FS в Windows Hello для бизнеса. Клиент блокирует подготовку Windows Hello для бизнеса до успешной проверки подлинности.

Определение доверия сертификатов с помощью проблемы с регистрацией AD FS 2019

Процесс подготовки для Windows Hello для бизнеса запускается в случае успешной проверки готовности. Результат проверки подготовкиAdmin доступен в журналах событий в разделе Регистрация устройств Microsoft-Windows-User. Если подготовка заблокирована из-за того, что проверка подлинности устройства не прошла успешно, регистрируется событие с идентификатором 362 , указывающее , что пользователь успешно прошел проверку подлинности в корпоративном stS: Нет.

Log Name:      Microsoft-Windows-User Device Registration/Admin
Source:        Microsoft-Windows-User Device Registration
Date:          <Date and time>
Event ID:      362
Task Category: None
Level:         Warning
Keywords:
User:          <User SID>
Computer:      <Computer name>
Description:
Windows Hello for Business provisioning will not be launched.
Device is Azure Active Directory-joined ( AADJ or DJ++ ): Yes
User has logged on with Azure Active Directory credentials: Yes
Windows Hello for Business policy is enabled: Yes
Windows Hello for Business post-logon provisioning is enabled: Yes
Local computer meets Windows hello for business hardware requirements: Yes
User is not connected to the machine via Remote Desktop: Yes
User certificate for on premise auth policy is enabled: Yes
Enterprise user logon certificate enrollment endpoint is ready: Not Tested
Enterprise user logon certificate template is : No ( 1 : StateNoPolicy )
User has successfully authenticated to the enterprise STS: No
Certificate enrollment method: enrollment authority
See https://go.microsoft.com/fwlink/?linkid=832647 for more details.

Если устройство недавно присоединилось к домену, может возникнуть задержка перед выполнением проверки подлинности устройства. Если состояние сбоя этой проверки готовности сохраняется, это может указывать на проблему с конфигурацией AD FS.

Если возникла проблема с областью AD FS, журналы событий на сервере AD FS указывают на сбой проверки подлинности клиента. Ошибка регистрируется в журналах событий в ad FS/Admin с идентификатором события 1021 , а событие указывает, что клиенту запрещен доступ к ресурсу http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope с областью действия ugs.

Log Name:      AD FS/Admin
Source:        AD FS
Date:          <Date and time>
Event ID:      1021
Task Category: None
Level:         Error
Keywords:      AD FS
User:          <ADFS service Account>
Computer:      <Date and time>
Description:
Encountered error during OAuth token request.
Additional Data
Exception details:
Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthUnauthorizedClientException: MSIS9368: Received invalid OAuth request. The client '38aa3b87-a06d-4817-b275-7a316988d93b' is forbidden to access the resource 'http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope' with scope 'ugs'.
       at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthProtocolContext.ValidateScopes(String scopeParameter, String clientId, String relyingPartyId)
       at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateCore()

Устранение проблемы с доверием к сертификату с помощью AD FS 2019

Эта проблема устранена в Windows Server версии 1903 и более поздних. В Windows Server 2019 эту проблему можно устранить, добавив область ugs вручную.

  1. Запустите консоль управления AD FS. Перейдите к описанию области служб>.

  2. Щелкните правой кнопкой мыши Описание области и выберите Добавить описание области.

  3. В поле имя введите ugs и нажмите кнопку Применить > ОК.

  4. Запустите PowerShell от имени администратора.

  5. Получите ObjectIdentifier разрешения приложения с параметром ClientRoleIdentifier, равным "38aa3b87-a06d-4817-b275-7a316988d93b":

    (Get-AdfsApplicationPermission -ServerRoleIdentifiers 'http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope' | ?{ $_.ClientRoleIdentifier -eq '38aa3b87-a06d-4817-b275-7a316988d93b' }).ObjectIdentifier

  6. Выполните команду Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier from step 5> -AddScope 'ugs'.

  7. Перезапустите службу AD FS.

  8. На клиенте: перезапустите клиент. Пользователю должно быть предложено подготовить Windows Hello для бизнеса.