Problèmes de déploiement connus de Windows Hello Entreprise
Le contenu de cet article est destiné à résoudre les problèmes de déploiement connus pour Windows Hello Entreprise.
La réinitialisation du code confidentiel sur les appareils de jointure Microsoft Entra échoue avec l’erreur Nous ne pouvons pas ouvrir cette page pour l’instant
La réinitialisation du code confidentiel sur les appareils joints à Microsoft Entra utilise un flux appelé connexion web pour authentifier l’utilisateur au-dessus du verrou. La connexion web autorise uniquement la navigation vers des domaines spécifiques. Si la connexion web tente d’accéder à un domaine qui n’est pas autorisé, elle affiche une page avec le message d’erreur Nous ne pouvons pas ouvrir cette page pour le moment.
Identifier les domaines autorisés de réinitialisation du code confidentiel
L’utilisateur peut lancer le flux de réinitialisation du code confidentiel à partir de l’écran de verrouillage à l’aide du lien J’ai oublié mon code confidentiel dans le fournisseur d’informations d’identification du code confidentiel. La sélection du lien lance une interface utilisateur en plein écran pour l’expérience de code confidentiel sur les appareils de jointure Microsoft Entra. En règle générale, l’interface utilisateur affiche une page d’authentification, où l’utilisateur s’authentifie à l’aide des informations d’identification Microsoft Entra et effectue l’authentification multifacteur.
Dans les environnements fédérés, l’authentification peut être configurée pour acheminer vers AD FS ou un fournisseur d’identité non-Microsoft. Si le flux de réinitialisation du code confidentiel est lancé et tente d’accéder à une page de serveur de fournisseur d’identité fédérée, il échoue et affiche l’erreur Nous ne pouvons pas ouvrir cette page pour le moment , si le domaine de la page serveur n’est pas inclus dans une liste d’autorisation.
Si vous êtes client du cloud Azure US Government , la réinitialisation du code pin tente également d’accéder à un domaine qui n’est pas inclus dans la liste d’autorisation par défaut. Le résultat est le message Nous ne pouvons pas ouvrir cette page pour le moment.
Résoudre le problème de réinitialisation des domaines autorisés avec réinitialisation du code confidentiel
Pour résoudre l’erreur, vous pouvez configurer une liste de domaines autorisés pour la réinitialisation du code confidentiel à l’aide de la stratégie ConfigureWebSignInAllowedUrls . Pour plus d’informations sur la configuration de la stratégie, consultez Configurer des URL autorisées pour les fournisseurs d’identité fédérés sur les appareils joints à Microsoft Entra.
Connexion d’approbation de clé hybride interrompue en raison de la suppression de la clé publique de l’utilisateur
S’applique à :
- Déploiements d’approbation de clé hybride
- Windows Server 2016, builds 14393.3930 à 14393.4048
- Windows Server 2019, builds 17763.1457 à 17763.1613
Dans les déploiements d’approbation de clé hybride avec des contrôleurs de domaine exécutant certaines builds de Windows Server 2016 et Windows Server 2019, la clé Windows Hello Entreprise de l’utilisateur est supprimée après la connexion. Les connexions suivantes échouent jusqu’à ce que la clé de l’utilisateur soit synchronisée pendant le prochain cycle de synchronisation delta de Microsoft Entra Connect.
Identifier le problème de suppression de clé publique de l’utilisateur
Une fois que l’utilisateur a approvisionné des informations d’identification Windows Hello Entreprise dans un environnement d’approbation de clé hybride, la clé doit se synchroniser de l’ID Microsoft Entra vers Active Directory pendant un cycle de synchronisation Microsoft Entra Connect. La clé publique de l’utilisateur est écrite dans l’attribut msDS-KeyCredentialLink de l’objet utilisateur.
Avant la synchronisation de la clé Windows Hello Entreprise de l’utilisateur, les connexions avec Windows Hello Entreprise échouent avec le message d’erreur Cette option est temporairement indisponible. Pour l’instant, utilisez une autre méthode pour vous connecter. Une fois la clé synchronisée, l’utilisateur peut se connecter et le déverrouiller avec son code confidentiel ou la biométrie inscrite.
Dans les environnements présentant le problème, une fois la première connexion avec Windows Hello Entreprise et l’approvisionnement terminés, la tentative de connexion suivante échoue. Dans les environnements où les contrôleurs de domaine exécutent une combinaison de builds, certains utilisateurs peuvent être affectés par le problème et les tentatives de connexion suivantes peuvent être envoyées à différents contrôleurs de domaine. Le résultat est des échecs de connexion intermittents.
Après la tentative de connexion initiale, la clé publique Windows Hello Entreprise de l’utilisateur est supprimée du msDS-KeyCredentialLink attribute. Vous pouvez vérifier la suppression en interrogeant l’attribut d’un msDS-KeyCredentialLink utilisateur avant et après la connexion. Vous pouvez interroger dans AD à l’aide msDS-KeyCredentialLinkde Get-ADUser et en spécifiant msds-keycredentiallink pour le -Properties paramètre .
Résoudre le problème de suppression de clé publique de l’utilisateur
Pour résoudre le problème, mettez à jour les contrôleurs de domaine Windows Server 2016 et 2019 avec les derniers correctifs. Pour Windows Server 2016, le comportement est résolu dans la build 14393.4104 (KB4593226) et les versions ultérieures. Pour Windows Server 2019, le comportement est résolu dans la build 17763.1637 (KB4592440).
Accès d’appareil joint à Microsoft Entra aux ressources locales à l’aide de l’approbation de clé et de l’autorité de certification (CA) non-Microsoft
S’applique à :
- Déploiements d’approbation de clés jointes Microsoft Entra
- Autorité de certification non-Microsoft émettrice de certificats de contrôleur de domaine
Windows Hello Entreprise utilise l’authentification par carte à puce pour de nombreuses opérations. Ce type d’authentification comporte des instructions spéciales lors de l’utilisation d’une autorité de certification non-Microsoft pour l’émission de certificat, dont certaines s’appliquent aux contrôleurs de domaine. Ces configurations ne sont pas nécessaires pour tous les types de déploiement Windows Hello Entreprise. L’accès aux ressources locales à partir d’un appareil joint à Microsoft Entra nécessite une configuration spéciale lors de l’utilisation d’une autorité de certification non-Microsoft pour émettre des certificats de contrôleur de domaine.
Pour plus d’informations, consultez Recommandations pour l’activation de la connexion par carte à puce avec des autorités de certification non-Microsoft.
Identifier les problèmes d’accès aux ressources locales avec les autorités de certification non-Microsoft
Le problème peut être identifié à l’aide des traces réseau ou de la journalisation Kerberos à partir du client. Dans la trace réseau, le client ne parvient pas à placer une TGS_REQ requête lorsqu’un utilisateur tente d’accéder à une ressource. Sur le client, elle peut être observée dans le journal des événements des opérations Kerberos sous Application and Services/Microsoft/Windows/Security-Kerberos/Operational. Les journaux sont désactivés par défaut. L’événement d’échec pour ce cas inclut les informations suivantes :
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
Résoudre le problème d’accès aux ressources locales avec des autorités de certification non-Microsoft
Pour résoudre le problème, les certificats de contrôleur de domaine doivent être mis à jour afin que l’objet du certificat contienne le chemin d’accès au répertoire de l’objet serveur (nom unique).
Exemple d’objet : CN=DC1,OU=Domain Controllers,DC=ad,DC=contoso,DC=com
Vous pouvez également définir l’autre nom d’objet (SAN) du certificat du contrôleur de domaine pour qu’il contienne le nom de domaine complet de l’objet serveur et le nom NETBIOS du domaine. Exemple d’autre nom d’objet :
dns=dc1.ad.contoso.com
dns=ad.contoso.com
dns=ad
Authentification d’approbation de clé rompue pour Windows Server 2019
S’applique à :
- Windows Server 2019
- Déploiements d’approbation de clé hybride
- Déploiements d’approbation de clé locale
Les contrôleurs de domaine exécutant des versions antérieures de Windows Server 2019 rencontrent un problème qui empêche l’authentification d’approbation de clé de fonctionner correctement. Les KDC_ERR_CLIENT_NAME_MISMATCH de rapport de suivi des réseaux.
Identifier le problème d’authentification d’approbation de clé Windows Server 2019
Sur le client, l’authentification avec Windows Hello Entreprise échoue avec le message d’erreur « Cette option est temporairement indisponible ». Pour l’instant, utilisez une autre méthode pour vous connecter.
L’erreur est présentée sur les appareils joints hybrides Microsoft Entra dans les déploiements d’approbation de clé après le provisionnement de Windows Hello Entreprise, mais avant la synchronisation de la clé d’un utilisateur entre l’ID Microsoft Entra et Active Directory. Si la clé d’un utilisateur n’est pas synchronisée à partir de l’ID Microsoft Entra et que l’attribut msDS-keycredentiallink sur l’objet utilisateur dans AD est rempli pour NGC, il est possible que l’erreur se produise.
Un autre indicateur de la défaillance peut être identifié à l’aide de traces réseau. Si vous capturez des traces réseau pour un événement de connexion d’approbation de clé, les traces indiquent l’échec de Kerberos avec l’erreur KDC_ERR_CLIENT_NAME_MISMATCH.
Résoudre le problème d’authentification d’approbation de clé Server 2019
Le problème est résolu dans Windows Server 2019, build 17763.316 (KB4487044). Mettez à niveau tous les contrôleurs de domaine Windows Server 2019 vers la build 17763.316 ou ultérieure pour résoudre le problème.
Provisionnement d’approbation de certificat avec AD FS rompu sur Windows Server 2019
S’applique à :
- Windows Server 2019
- Déploiements d’approbation de certificats hybrides
- Déploiements d’approbation de certificats locaux
AD FS exécuté sur Windows Server 2019 ne parvient pas à terminer l’authentification de l’appareil en raison d’une vérification non valide des étendues entrantes dans la demande. L’authentification de l’appareil auprès d’AD FS est une exigence pour Windows Hello Entreprise pour inscrire un certificat à l’aide d’AD FS. Le client bloque l’approvisionnement de Windows Hello Entreprise jusqu’à ce que l’authentification réussisse.
Identifier l’approbation de certificat avec le problème d’inscription AD FS 2019
L’expérience d’approvisionnement de Windows Hello Entreprise démarre si les vérifications des prérequis sont réussies. Le résultat des vérifications provisioningAdmin est disponible dans les journaux des événements sous Microsoft-Windows-User Device Registration. Si l’approvisionnement est bloqué en raison de l’échec de l’authentification de l’appareil, l’ID d’événement 362 est enregistré, indiquant que l’utilisateur s’est correctement authentifié auprès de l’entreprise STS : Non.
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.
Si un appareil a récemment rejoint un domaine, il peut y avoir un délai avant que l’authentification de l’appareil ne se produise. Si l’état d’échec de cette vérification des prérequis persiste, cela peut indiquer un problème avec la configuration AD FS.
Si le problème d’étendue AD FS est présent, les journaux des événements sur le serveur AD FS indiquent un échec d’authentification du client. L’erreur est enregistrée dans les journaux des événements sous AD FS/Admin en tant qu’ID d’événement 1021 et l’événement spécifie que l’accès à la ressource http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope est interdit au client avec l’étendue 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()
Résoudre le problème d’approbation de certificat avec AD FS 2019
Ce problème est résolu dans Windows Server, version 1903 et ultérieure. Pour Windows Server 2019, le problème peut être résolu en ajoutant manuellement l’étendue ugs.
Lancez la console de gestion AD FS. Accédez à Descriptions de l’étendue des services>.
Sélectionnez Avec le bouton droit Descriptions de l’étendue , puis Ajouter une description d’étendue.
Sous nom, tapez ugs, puis sélectionnez Appliquer > OK.
Lancez PowerShell en tant qu’administrateur.
Obtenez l’ObjectIdentifier de l’autorisation d’application avec le paramètre ClientRoleIdentifier égal à « 38aa3b87-a06d-4817-b275-7a316988d93b » :
(Get-AdfsApplicationPermission -ServerRoleIdentifiers 'http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope' | ?{ $_.ClientRoleIdentifier -eq '38aa3b87-a06d-4817-b275-7a316988d93b' }).ObjectIdentifierExécutez la commande
Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier from step 5> -AddScope 'ugs'.Redémarrez le service AD FS.
Sur le client : redémarrez le client. L’utilisateur doit être invité à provisionner Windows Hello Entreprise.