Condividi tramite

Problemi di distribuzione noti di Windows Hello for Business

Il contenuto di questo articolo consente di risolvere i problemi di distribuzione noti per Windows Hello for Business.

La reimpostazione del PIN nei dispositivi di aggiunta a Microsoft Entra non riesce con l'errore Non è possibile aprire la pagina in questo momento

La reimpostazione del PIN nei dispositivi aggiunti a Microsoft Entra usa un flusso denominato accesso Web per autenticare l'utente sopra il blocco. L'accesso Web consente solo lo spostamento in domini specifici. Se l'accesso Web tenta di passare a un dominio non consentito, viene visualizzata una pagina con il messaggio di errore Non è possibile aprire la pagina in questo momento.

Identificare il problema relativo alla reimpostazione del PIN consentito per i domini

L'utente può avviare il flusso di reimpostazione del PIN dalla schermata di blocco usando il collegamento Ho dimenticato il PIN nel provider di credenziali PIN. Selezionando il collegamento viene avviata un'interfaccia utente a schermo intero per l'esperienza PIN nei dispositivi di aggiunta a Microsoft Entra. In genere, l'interfaccia utente visualizza una pagina di autenticazione, in cui l'utente esegue l'autenticazione usando le credenziali di Microsoft Entra e completa l'autenticazione a più fattori.

Negli ambienti federati, l'autenticazione può essere configurata per il routing ad AD FS o a un provider di identità non Microsoft. Se il flusso di reimpostazione del PIN viene avviato e tenta di passare a una pagina del server del provider di identità federato, ha esito negativo e viene visualizzato l'errore Non è possibile aprire la pagina in questo momento , se il dominio per la pagina del server non è incluso in un elenco di elementi consentiti.

Se si è un cliente del cloud di Azure US Government , la reimpostazione del PIN tenta anche di passare a un dominio non incluso nell'elenco di autorizzazioni predefinito. Il risultato è il messaggio Non è possibile aprire la pagina in questo momento.

Risolvere il problema relativo alla reimpostazione dei domini consentiti per il PIN

Per risolvere l'errore, è possibile configurare un elenco di domini consentiti per la reimpostazione del PIN usando il criterio ConfigureWebSignInAllowedUrls . Per informazioni su come configurare i criteri, vedere Configurare gli URL consentiti per i provider di identità federati nei dispositivi aggiunti a Microsoft Entra.

Accesso trust chiave ibrido interrotto a causa dell'eliminazione della chiave pubblica dell'utente

Si applica a:

  • Distribuzioni di trust chiave ibrida
  • Windows Server 2016, compila da 14393.3930 a 14393.4048
  • Windows Server 2019, compila da 17763.1457 a 17763.1613

Nelle distribuzioni di trust chiave ibrida con controller di dominio che eseguono determinate build di Windows Server 2016 e Windows Server 2019, la chiave Windows Hello for Business dell'utente viene eliminata dopo l'accesso. Gli accessi successivi avranno esito negativo fino a quando la chiave dell'utente non verrà sincronizzata durante il successivo ciclo di sincronizzazione differenziale di Microsoft Entra Connect.

Identificare il problema di eliminazione della chiave pubblica dell'utente

Dopo che l'utente effettua il provisioning di credenziali di Windows Hello for Business in un ambiente di attendibilità della chiave ibrida, la chiave deve essere sincronizzata da Microsoft Entra ID ad Active Directory durante un ciclo di sincronizzazione di Microsoft Entra Connect. La chiave pubblica dell'utente viene scritta nell'attributo msDS-KeyCredentialLink dell'oggetto utente.

Prima della sincronizzazione della chiave di Windows Hello for Business dell'utente, gli accessi con Windows Hello for Business hanno esito negativo con il messaggio di errore L'opzione non è temporaneamente disponibile. Per il momento, usare un metodo diverso per accedere. Dopo la corretta sincronizzazione della chiave, l'utente può accedere e sbloccare con il PIN o la biometria registrata.

Negli ambienti con il problema, dopo il primo accesso con Windows Hello for Business e il provisioning è stato completato, il tentativo di accesso successivo non riesce. Negli ambienti in cui i controller di dominio eseguono una combinazione di build, alcuni utenti potrebbero essere interessati dal problema e i successivi tentativi di accesso potrebbero essere inviati a controller di dominio diversi. Il risultato sono errori di accesso intermittenti.

Dopo il tentativo di accesso iniziale, la chiave pubblica di Windows Hello for Business dell'utente viene eliminata da msDS-KeyCredentialLink attribute. È possibile verificare l'eliminazione eseguendo una query sull'attributo di msDS-KeyCredentialLink un utente prima e dopo l'accesso. È possibile eseguire query msDS-KeyCredentialLink su in AD usando Get-ADUser e specificando msds-keycredentiallink per il -Properties parametro .

Risolvere il problema di eliminazione della chiave pubblica dell'utente

Per risolvere il problema, aggiornare i controller di dominio di Windows Server 2016 e 2019 con le patch più recenti. Per Windows Server 2016, il comportamento viene corretto nella build 14393.4104 (KB4593226) e versioni successive. Per Windows Server 2019, il comportamento è corretto nella build 17763.1637 (KB4592440).

Accesso del dispositivo aggiunto a Microsoft Entra alle risorse locali usando l'attendibilità delle chiavi e l'autorità di certificazione non Microsoft

Si applica a:

  • Distribuzioni di trust chiave unite a Microsoft Entra
  • Autorità di certificazione (CA) non Microsoft che rilascia certificati del controller di dominio

Windows Hello for Business usa l'autenticazione basata su smart card per molte operazioni. Questo tipo di autenticazione include linee guida speciali quando si usa una CA non Microsoft per il rilascio di certificati, alcune delle quali si applicano ai controller di dominio. Non tutti i tipi di distribuzione di Windows Hello for Business richiedono queste configurazioni. L'accesso alle risorse locali da un dispositivo aggiunto a Microsoft Entra richiede una configurazione speciale quando si usa una CA non Microsoft per rilasciare certificati del controller di dominio.

Per altre informazioni, vedere Linee guida per abilitare l'accesso alle smart card con autorità di certificazione non Microsoft.

Identificare i problemi di accesso alle risorse locali con autorità di certificazione non Microsoft

Il problema può essere identificato usando tracce di rete o la registrazione Kerberos dal client. Nella traccia di rete, il client non riesce a effettuare una TGS_REQ richiesta quando un utente tenta di accedere a una risorsa. Nel client è possibile osservarlo nel registro eventi dell'operazione Kerberos in Application and Services/Microsoft/Windows/Security-Kerberos/Operational. I log sono disabilitati per impostazione predefinita. L'evento di errore per questo caso include le informazioni seguenti:

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

Risolvere il problema di accesso alle risorse locali con autorità di certificazione non Microsoft

Per risolvere il problema, è necessario aggiornare i certificati del controller di dominio in modo che l'oggetto certificato contenga il percorso della directory dell'oggetto server (nome distinto). Oggetto di esempio: CN=DC1,OU=Domain Controllers,DC=ad,DC=contoso,DC=com

In alternativa, è possibile impostare il nome alternativo del soggetto (SAN) del certificato del controller di dominio in modo che contenga il nome di dominio completo dell'oggetto server e il nome NETBIOS del dominio. Nome alternativo soggetto di esempio:

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

Autenticazione trust chiave interrotta per Windows Server 2019

Si applica a:

  • Windows Server 2019
  • Distribuzioni di trust chiave ibrida
  • Distribuzioni di trust delle chiavi locali

I controller di dominio che eseguono versioni precedenti di Windows Server 2019 presentano un problema che impedisce il corretto funzionamento dell'autenticazione dell'attendibilità delle chiavi. Le tracce delle reti segnalano KDC_ERR_CLIENT_NAME_MISMATCH.

Identificare il problema di autenticazione dell'attendibilità chiave di Windows Server 2019

Nel client, l'autenticazione con Windows Hello for Business non riesce con il messaggio di errore, Questa opzione è temporaneamente non disponibile. Per il momento, usare un metodo diverso per accedere.

L'errore viene visualizzato nei dispositivi aggiunti ibridi di Microsoft Entra nelle distribuzioni di trust chiave dopo il provisioning di Windows Hello for Business, ma prima che la chiave di un utente venga sincronizzata da Microsoft Entra ID ad Active Directory. Se la chiave di un utente non è sincronizzata da Microsoft Entra ID e l'attributo msDS-keycredentiallink nell'oggetto utente in AD viene popolato per NGC, è possibile che si verifichi l'errore.

Un altro indicatore dell'errore può essere identificato usando le tracce di rete. Se si acquisiscono tracce di rete per un evento di accesso con attendibilità chiave, le tracce mostrano che Kerberos ha esito negativo con l'errore KDC_ERR_CLIENT_NAME_MISMATCH.

Risolvere il problema di autenticazione dell'attendibilità chiave del server 2019

Il problema viene risolto in Windows Server 2019, build 17763.316 (KB4487044). Aggiornare tutti i controller di dominio Windows Server 2019 alla build 17763.316 o successiva per risolvere il problema.

Provisioning dell'attendibilità dei certificati con AD FS interrotto in Windows Server 2019

Si applica a:

  • Windows Server 2019
  • Distribuzioni di attendibilità dei certificati ibridi
  • Distribuzioni di attendibilità dei certificati locali

AD FS in esecuzione in Windows Server 2019 non riesce a completare l'autenticazione del dispositivo a causa di un controllo non valido degli ambiti in ingresso nella richiesta. L'autenticazione del dispositivo in AD FS è un requisito per Windows Hello for Business per registrare un certificato usando AD FS. Il client blocca il provisioning di Windows Hello for Business fino al completamento dell'autenticazione.

Identificare l'attendibilità del certificato con il problema di registrazione di AD FS 2019

L'esperienza di provisioning per Windows Hello for Business viene avviata se i controlli dei prerequisiti hanno esito positivo. Il risultato dei controlli provisioningAdmin è disponibile nei log eventi in Registrazione dispositivo utente-Microsoft-Windows.The result of the provisioningAdmin checks is available in event logs under Microsoft-Windows-User Device Registration. Se il provisioning è bloccato perché l'autenticazione del dispositivo non ha esito positivo, viene registrato l'ID evento 362 che indica che l'utente ha eseguito correttamente l'autenticazione al servizio token di sicurezza aziendale: No.

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.

Se un dispositivo è stato aggiunto di recente a un dominio, potrebbe verificarsi un ritardo prima che si verifichi l'autenticazione del dispositivo. Se lo stato di errore di questo controllo dei prerequisiti persiste, può indicare un problema con la configurazione di AD FS.

Se è presente il problema di ambito ADFS, i log eventi nel server AD FS indicano un errore di autenticazione dal client. L'errore viene registrato nei log eventi in AD FS/Admin come ID evento 1021 e l'evento specifica che al client non è consentito l'accesso alla risorsa http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope con ambito 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()

Risolvere il problema relativo all'attendibilità dei certificati con AD FS 2019

Questo problema è stato risolto in Windows Server, versione 1903 e successive. Per Windows Server 2019, il problema può essere risolto aggiungendo manualmente l'ambito ugs.

  1. Avviare la console di gestione di AD FS. Passare a Descrizioni ambito servizi>.

  2. Fare clic con il pulsante destro del mouse su Descrizioni ambito e scegliere Aggiungi descrizione ambito.

  3. In nome digitare ugs e selezionare Applica > OK.

  4. Avviare PowerShell come amministratore.

  5. Ottenere l'oggettoIdentifier dell'autorizzazione dell'applicazione con il parametro ClientRoleIdentifier uguale a "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. Eseguire il comando Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier from step 5> -AddScope 'ugs'.

  7. Riavviare il servizio AD FS.

  8. Nel client: riavviare il client. All'utente deve essere richiesto di effettuare il provisioning di Windows Hello for Business.