Fonctionnement de Windows Hello Entreprise

• S’applique à:

  ✅ Windows 11, ✅ Windows 10

Windows Hello Entreprise est un système distribué qui nécessite plusieurs technologies pour fonctionner ensemble. Pour simplifier l’explication du fonctionnement de Windows Hello Entreprise, nous allons la décomposer en cinq phases, qui représentent l’ordre chronologique du processus de déploiement.

Remarque

Deux de ces phases sont nécessaires uniquement pour certains scénarios de déploiement.

Les scénarios de déploiement sont décrits dans l’article Planifier un déploiement Windows Hello Entreprise.

Phase d’inscription de l’appareil

Dans cette phase, l’appareil inscrit son identité auprès du fournisseur d’identité (IdP), afin qu’elle puisse être associée et authentifiée auprès du fournisseur d’identité.

Phase d’approvisionnement

Au cours de cette phase, l’utilisateur s’authentifie à l’aide d’une forme d’authentification (généralement, nom d’utilisateur/mot de passe) pour demander une nouvelle Windows Hello Entreprise informations d’identification. Le flux d’approvisionnement nécessite un deuxième facteur d’authentification avant de pouvoir générer une paire de clés publique/privée. La clé publique est inscrite auprès du fournisseur d’identité, mappée au compte d’utilisateur.

Phase de synchronisation de clé

Dans cette phase, requise par certains déploiements hybrides, la clé publique de l’utilisateur est synchronisée entre Microsoft Entra ID et Active Directory.

Phase d’inscription de certificat

Dans cette phase, requise uniquement par les déploiements utilisant des certificats, un certificat est émis à l’utilisateur à l’aide de l’infrastructure à clé publique (PKI) du organization.

Phase d’authentification

Dans cette dernière phase, l’utilisateur peut se connecter à Windows à l’aide de la biométrie ou d’un code confidentiel. Quel que soit le mouvement utilisé, l’authentification se produit à l’aide de la partie privée des informations d’identification Windows Hello Entreprise. Le fournisseur d’identité valide l’identité de l’utilisateur en mappant le compte d’utilisateur à la clé publique inscrite pendant la phase d’approvisionnement.

Les sections suivantes fournissent des informations plus détaillées sur chacune de ces phases.

Inscription du périphérique

Tous les appareils inclus dans le déploiement Windows Hello Entreprise doivent passer par un processus appelé inscription des appareils. L’inscription d’appareil permet aux appareils d’être associés et de s’authentifier auprès d’un fournisseur d’identité :

• Pour les déploiements cloud et hybrides, le fournisseur d’identité est Microsoft Entra ID et l’appareil s’inscrit auprès du service d’inscription des appareils
• Pour les déploiements locaux, le fournisseur d’identité est Services ADFS (AD FS) et l’appareil s’inscrit auprès du service Enterprise Device Registration Service hébergé sur AD FS

Lorsqu’un appareil est inscrit, le fournisseur d’identité fournit à l’appareil une identité utilisée pour authentifier l’appareil lorsqu’un utilisateur se connecte.

Il existe différents types d’inscription, qui sont identifiés comme type de jointure. Pour plus d’informations, consultez Qu’est-ce qu’une identité d’appareil ?

Pour obtenir des diagrammes de séquence détaillés, consultez le fonctionnement de l’inscription des appareils.

Approvisionnement

Windows Hello’approvisionnement est déclenché une fois l’inscription de l’appareil terminée et une fois que l’appareil reçoit une stratégie qui active Windows Hello. Si toutes les conditions préalables sont remplies, une fenêtre CXH (Cloud eXperience Host) est lancée pour amener l’utilisateur à parcourir le flux d’approvisionnement.

Remarque

Selon le type de déploiement, Windows Hello Entreprise provisionnement est lancé uniquement si :

• L’appareil répond à la configuration matérielle requise Windows Hello
• L’appareil est joint à Active Directory ou Microsoft Entra ID
• L’utilisateur se connecte avec un compte défini dans Active Directory ou Microsoft Entra ID
• La stratégie Windows Hello Entreprise est activée
• L’utilisateur n’est pas connecté à l’ordinateur via le Bureau à distance

Les prérequis supplémentaires pour des types de déploiement spécifiques sont décrits dans l’article Planifier un déploiement Windows Hello Entreprise.

Pendant la phase d’approvisionnement, un conteneur Windows Hello est créé. Un conteneur Windows Hello est un regroupement logique de données ou de matériaux clés. Le conteneur contient les informations d’identification de organization uniquement sur les appareils inscrits auprès du fournisseur d’identité du organization.

Remarque

Il n’existe aucun conteneur physique sur le disque, dans le Registre ou ailleurs. Les conteneurs sont des unités logiques utilisées pour regrouper des éléments associés. Les clés, certificats et informations d’identification que Windows Hello stocke sont protégés sans la création de conteneurs ou de dossiers réels.

Voici les étapes impliquées dans la phase d’approvisionnement :

1. Dans la fenêtre CXH, l’utilisateur est invité à s’authentifier auprès du fournisseur d’identité avec l’authentification multifacteur
2. Une fois l’authentification multifacteur réussie, l’utilisateur doit fournir un mouvement de bio (si disponible) et un code confidentiel
3. Après la confirmation du code confidentiel, le conteneur Windows Hello est créé
4. Une paire de clés publique/privée est générée. La paire de clés est liée au module de plateforme sécurisée (TPM), le cas échéant, ou dans le logiciel
5. La clé privée est stockée localement et protégée par le module de plateforme sécurisée et ne peut pas être exportée
6. La clé publique est inscrite auprès du fournisseur d’identité, mappée au compte d’utilisateur
   1. Le service d’inscription d’appareil écrit la clé dans l’objet utilisateur dans Microsoft Entra ID
   2. Pour les scénarios locaux, AD FS écrit la clé dans Active Directory

La vidéo suivante montre les étapes d’inscription Windows Hello Entreprise après la connexion avec un mot de passe :

Pour plus d’informations et des diagrammes de séquence détaillés, consultez fonctionnement de l’approvisionnement.

Windows Hello détails du conteneur

Pendant la phase d’approvisionnement, Windows Hello génère une nouvelle paire de clés publique/privée sur l’appareil. Le module de plateforme sécurisée génère et protège la clé privée. Si l’appareil n’a pas de TPM, la clé privée est chiffrée et stockée dans un logiciel. Cette clé initiale est appelée clé de protection. La clé de protection est associée à un seul mouvement : si un utilisateur inscrit un code confidentiel, une empreinte digitale et un visage sur le même appareil, chacun de ces mouvements a une clé de protection unique.

La clé de protection encapsule de manière sécurisée la clé d’authentification. La clé d’authentification est utilisée pour déverrouiller les clés d’ID utilisateur. Le conteneur n’a qu’une seule clé d’authentification, mais il se peut que plusieurs copies de cette clé soient renvoyées avec des clés de protecteur unique différentes.

Chaque logiciel de protection chiffre sa propre copie de la clé d’authentification. La façon dont le chiffrement est effectué appartient au logiciel de protection lui-même. Par exemple, le protecteur de code confidentiel effectue une opération de scellement du module de plateforme sécurisée (TPM) en utilisant le code confidentiel comme entropie, ou, lorsqu’aucun module de plateforme sécurisée n’est disponible, effectue un chiffrement symétrique de la clé d’authentification à l’aide d’une clé dérivée du code pin lui-même.

Important

Les clés peuvent être générées dans du matériel (TPM 1.2 ou 2.0) ou des logiciels, en fonction du paramètre de stratégie configuré. Pour garantir que les clés sont générées dans le matériel, vous devez configurer un paramètre de stratégie. Pour plus d’informations, consultez Utiliser un appareil de sécurité matériel.

Les comptes personnels (compte Microsoft) et professionnels ou scolaires (Active Directory ou Microsoft Entra ID) utilisent un seul conteneur pour les clés. Toutes les clés sont séparées par les domaines des fournisseurs d’identité pour assurer la confidentialité des utilisateurs.

Windows Hello génère également une clé d’administration. La clé d’administration peut être utilisée pour réinitialiser les informations d’identification si nécessaire. Par exemple, lors de l’utilisation du service de réinitialisation du code confidentiel. En plus de la clé de protecteur, les appareils avec un module de plateforme sécurisée (TPM) génèrent un bloc de données contenant des attestations du module de plateforme sécurisée.

L’accès au matériel de clé stocké dans le conteneur est activé uniquement par le code confidentiel ou le mouvement biométrique. La vérification en deux étapes qui a lieu lors de l’approvisionnement crée une relation approuvée entre le fournisseur d’identité et l’utilisateur. Cela se produit lorsque la partie publique de la paire de clés publique/privée est envoyée à un fournisseur d’identité et associée au compte d’utilisateur. Lorsqu’un utilisateur entre le mouvement sur l’appareil, le fournisseur d’identité sait qu’il s’agit d’une identité vérifiée, en raison de la combinaison de touches Windows Hello et de mouvements. Il fournit ensuite un jeton d’authentification qui permet à Windows d’accéder aux ressources et services.

Un conteneur peut contenir plusieurs types de matériaux clés :

• Une clé d’authentification, qui est toujours une paire de clés publique-privée asymétrique. Cette paire de clés est générée au moment de l’inscription. Il doit être déverrouillé chaque fois qu’il est accessible, à l’aide du code confidentiel de l’utilisateur ou d’un geste biométrique. La clé d’authentification existe jusqu’à ce que l’utilisateur réinitialise le code confidentiel, au moment où une nouvelle clé est générée. Lorsque la nouvelle clé est générée, tous les éléments de clé que l’ancienne clé précédemment protégée doivent être déchiffrés et rechiffrés à l’aide de la nouvelle clé
• Une ou plusieurs clés d’ID utilisateur. Ces clés peuvent être symétriques ou asymétriques, selon le fournisseur d’identité que vous utilisez. Pour les Windows Hello for Work basées sur un certificat, lorsque le conteneur est déverrouillé, les applications qui nécessitent l’accès à la clé d’ID utilisateur ou à la paire de clés peuvent demander l’accès. Les clés d’ID utilisateur sont utilisées pour signer ou chiffrer les demandes d’authentification ou les jetons envoyés de cet appareil au fournisseur d’identité. Les clés d’ID utilisateur sont généralement de longue durée, mais peuvent avoir une durée de vie plus courte que la clé d’authentification. Les comptes Microsoft, les comptes Active Directory et les comptes Microsoft Entra nécessitent tous l’utilisation de paires de clés asymétriques. L’appareil génère des clés publiques et privées, inscrit la clé publique auprès du fournisseur d’identité (qui la stocke pour une vérification ultérieure) et stocke la clé privée en toute sécurité. Pour les organisations, les clés d’ID utilisateur peuvent être générées de deux manières :
  • La paire de clés d’ID utilisateur peut être associée à l’autorité de certification d’une organization. Cette option vous permet aux organisations disposant déjà d’une infrastructure à clé publique (PKI) de continuer à l’utiliser si nécessaire. Étant donné que de nombreuses applications, telles que les solutions VPN, nécessitent l’utilisation de certificats, lorsque vous déployez Windows Hello dans ce mode, cela permet une transition plus rapide des mots de passe utilisateur tout en préservant les fonctionnalités basées sur les certificats. Cette option permet également au organization de stocker d’autres certificats dans le conteneur protégé. Par exemple, les certificats qui permettent à l’utilisateur de s’authentifier via RDP
  • Le fournisseur d’identité peut générer directement la paire de clés d’ID utilisateur, ce qui permet un déploiement rapide et à moindre charge de Windows Hello dans des environnements qui n’ont pas ou n’ont pas besoin d’une infrastructure à clé publique

Les clés d’ID utilisateur sont utilisées pour authentifier l’utilisateur auprès d’un service. Par exemple, en signant un nonce pour prouver la possession de la clé privée, qui correspond à une clé publique inscrite. Les utilisateurs disposant d’un compte Active Directory, Microsoft Entra ID ou Microsoft ont une clé associée à leur compte. La clé peut être utilisée pour se connecter à leur appareil Windows en s’authentifiant auprès d’un contrôleur de domaine (scénario Active Directory) ou dans le cloud (scénarios Microsoft Entra ID et MSA).

Windows Hello peut également être utilisé comme authentificateur FIDO2 pour s’authentifier auprès de n’importe quel site web prenant en charge WebAuthn. Les sites web ou les applications peuvent créer une clé d’ID utilisateur FIDO dans le conteneur Windows Hello de l’utilisateur à l’aide d’API. Lors des visites suivantes, l’utilisateur peut s’authentifier sur le site web ou l’application à l’aide de son code confidentiel Windows Hello ou d’un geste biométrique.

Pour en savoir plus sur la façon dont Windows utilise le module de plateforme sécurisée (TPM) pour prendre en charge Windows Hello Entreprise, consultez Comment Windows utilise le module de plateforme sécurisée.

Stockage de données biométriques

Les données biométriques utilisées pour prendre en charge Windows Hello sont stockées uniquement sur l’appareil local. Il n’est pas itinérant et n’est jamais envoyé à des appareils ou serveurs externes. Cette séparation permet d’empêcher des attaques potentielles en ne fournissant aucun point de collecte qu’une personne malveillante pourrait compromettre pour voler les données biométriques. Même si un attaquant pouvait obtenir les données biométriques d’un appareil, elles ne pouvaient pas être reconvertis en échantillon biométrique brut reconnaissable par le capteur biométrique.

Chaque capteur a son propre fichier de base de données biométrique où sont stockées les données du modèle (chemin d’accès C:\WINDOWS\System32\WinBioDatabase). Chaque fichier de base de données a une clé unique générée de manière aléatoire qui est chiffrée pour le système. Les données du modèle pour le capteur sont chiffrées avec la clé par base de données à l’aide d’AES avec le mode de chaînage CBC. Le hachage est SHA256.

Remarque

Certains capteurs d’empreintes digitales peuvent effectuer une correspondance sur le module de capteur d’empreintes digitales plutôt que sur le système d’exploitation. Ces capteurs stockent les données biométriques sur le module d’empreinte digitale plutôt que dans le fichier de base de données. Pour plus d’informations, consultez Windows Hello connexion à la sécurité renforcée (ESS).

Synchronisation de clé

La synchronisation des clés est requise dans les environnements hybrides. Une fois que l’utilisateur a approvisionné une Windows Hello Entreprise informations d’identification, la clé doit être synchronisée entre Microsoft Entra ID et Active Directory.

La clé publique de l’utilisateur est écrite dans l’attribut msDS-KeyCredentialLink de l’objet utilisateur dans Active Directory. La synchronisation est gérée par Microsoft Entra Connect Sync.

Inscription de certificat

Pour les déploiements de certificats, après avoir inscrit la clé, le client génère une demande de certificat. La demande est envoyée à l’autorité d’enregistrement des certificats (CRA). L’ARC se trouve sur le serveur Services ADFS (AD FS), qui valide la demande de certificat et la répond à l’aide de l’infrastructure à clé publique d’entreprise.

Un certificat est inscrit sur le conteneur Hello de l’utilisateur, qui est utilisé pour s’authentifier auprès des ressources locales.

Authentication

Les informations d’identification Windows Hello sont basées sur un certificat ou une paire de clés asymétriques. Windows Hello informations d’identification et le jeton obtenu à l’aide de ces informations d’identification sont liés à l’appareil.

L’authentification est l’authentification à deux facteurs avec la combinaison des éléments suivants :

• Une clé, ou certificat, lié à un appareil et
  • quelque chose que la personne connaît (un code confidentiel) ou
  • quelque chose que la personne est (biométrie)

L’entrée de code confidentiel et le mouvement biométrique déclenchent tous deux l’utilisation de la clé privée pour signer par chiffrement les données envoyées au fournisseur d’identité. Le fournisseur d’identité vérifie l’identité de l’utilisateur et authentifie l’utilisateur.

Le code confidentiel ou la partie privée des informations d’identification n’est jamais envoyé au fournisseur d’identité, et le code confidentiel n’est pas stocké sur l’appareil. Les mouvements de code confidentiel et de bio sont une entropie fournie par l’utilisateur lors de l’exécution d’opérations qui utilisent la partie privée des informations d’identification.

Lorsqu’un utilisateur souhaite accéder au matériel de clé protégée, le processus d’authentification commence par l’entrée d’un code confidentiel ou d’un geste biométrique pour déverrouiller l’appareil, processus parfois appelé libération de la clé. Imaginez que vous utilisez une clé physique pour déverrouiller une porte : avant de pouvoir la déverrouiller, vous devez sortir la clé dans votre poche ou sac. Le code confidentiel de l’utilisateur déverrouille la clé de protecteur du conteneur principal sur l’appareil. Lorsque ce conteneur est déverrouillé, les applications (et donc l’utilisateur) peuvent utiliser les clés d’ID utilisateur qui se trouvent à l’intérieur du conteneur.

Ces clés sont utilisées pour signer les demandes envoyées au fournisseur d’identité, demandant l’accès aux ressources spécifiées.

Important

Bien que les clés soient déverrouillées, les applications ne peuvent pas les utiliser à volonté. Les applications peuvent utiliser des API spécifiques pour demander des opérations dont certaines actions nécessitent un document de clé (pour déchiffrer un courrier électronique ou pour se connecter à un site Web par exemple). L’accès via ces API ne nécessite pas de validation explicite par le biais d’un mouvement de l’utilisateur, et le matériel clé n’est pas exposé à l’application demandeure. L’application demande plutôt une authentification, un chiffrement ou un déchiffrement, et Windows Hello traite la tâche réelle et renvoie les résultats. Le cas échéant, une application peut demander une authentification forcée, et ce même sur un appareil déverrouillé. Windows invite l’utilisateur à entrer à nouveau le code PIN ou à effectuer un mouvement d’authentification, ajoutant ainsi un niveau de protection supplémentaire des données ou actions sensibles. Par exemple, vous pouvez configurer une application pour exiger une nouvelle authentification chaque fois qu’une opération spécifique est effectuée, même si le même compte et le même code confidentiel ou le même mouvement ont déjà été utilisés pour déverrouiller l’appareil.

Pour plus d’informations et des diagrammes de séquence détaillés, consultez fonctionnement de l’authentification.

Jeton d’actualisation principal

L’authentification unique (SSO) s’appuie sur des jetons spéciaux obtenus pour accéder à des applications spécifiques. Dans le cas traditionnel de l’authentification intégrée Windows à l’aide de Kerberos, le jeton est un ticket TGT (ticket d’octroi de ticket) Kerberos. Pour les applications Microsoft Entra ID et AD FS, ce jeton est un jeton d’actualisation principal (PRT). Il s’agit d’un jeton web JSON qui contient des revendications concernant l’utilisateur et l’appareil.

Le PRT est initialement obtenu lors de la connexion ou du déverrouillage de la même façon que le TGT Kerberos est obtenu. Ce comportement est vrai pour les appareils joints Microsoft Entra et Microsoft Entra joints hybrides. Pour les appareils personnels inscrits avec Microsoft Entra ID, le PRT est initialement obtenu lors de l’ajout d’un compte professionnel ou scolaire. Pour un appareil personnel, le compte permettant de déverrouiller l’appareil n’est pas le compte professionnel, mais un compte de consommateur (compte Microsoft).

Le PRT est nécessaire pour l’authentification unique. Sans elle, les utilisateurs seraient invités à fournir des informations d’identification chaque fois qu’ils accèdent aux applications. Le PRT contient également des informations sur l’appareil. Si vous avez des stratégies d’accès conditionnel basées sur l’appareil définies sur une application, l’accès PRT est refusé.

Astuce

La clé Windows Hello Entreprise répond à Microsoft Entra exigences de l’authentification multifacteur (MFA) et réduit le nombre d’invites MFA que les utilisateurs verront lors de l’accès aux ressources.

Pour plus d’informations, consultez Qu’est-ce qu’un jeton d’actualisation principal ?

Windows Hello Entreprise et changements de mot de passe

La modification du mot de passe d’un compte d’utilisateur n’affecte pas la connexion ou le déverrouillage, car Windows Hello Entreprise utilise une clé ou un certificat.

Étapes suivantes

Pour répondre à la multitude de besoins et d’exigences de l’organisation, Windows Hello Entreprise propose différentes options de déploiement. Pour savoir comment planifier un déploiement Windows Hello Entreprise, consultez :

Planifier un déploiement Windows Hello Entreprise