Fonctionnement de Windows Hello Entreprise
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 de nouvelles informations d’identification Windows Hello Entreprise. 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 l’ID Microsoft Entra 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) de l’organisation.
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 geste 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 de Windows Hello Entreprise doivent passer par un processus appelé inscription de l’appareil. 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 l’ID Microsoft Entra, et l’appareil s’inscrit auprès du service d’inscription d’appareil
- Pour les déploiements locaux, le fournisseur d’identité est Active Directory Federation Services (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
L’approvisionnement Windows Hello 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, l’approvisionnement de Windows Hello Entreprise est lancé uniquement si :
- L’appareil répond à la configuration matérielle requise pour Windows Hello
- L’appareil est joint à Active Directory ou à l’ID Microsoft Entra
- L’utilisateur se connecte avec un compte défini dans Active Directory ou l’ID Microsoft Entra
- 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 documents clés ou de données. Le conteneur contient les informations d’identification de l’organisation uniquement sur les appareils inscrits auprès du fournisseur d’identité de l’organisation.
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 stockés par Windows Hello 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 :
- Dans la fenêtre CXH, l’utilisateur est invité à s’authentifier auprès du fournisseur d’identité avec l’authentification multifacteur
- Une fois l’authentification multifacteur réussie, l’utilisateur doit fournir un mouvement bio (si disponible) et un code confidentiel
- Après la confirmation du code confidentiel, le conteneur Windows Hello est créé
- 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
- 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
- La clé publique est inscrite auprès du fournisseur d’identité, mappée au compte d’utilisateur
- Le service d’inscription d’appareil écrit la clé dans l’objet utilisateur dans l’ID Microsoft Entra
- 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.
Détails du conteneur Windows Hello
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 (Id Active Directory ou Microsoft Entra) 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 et de mouvements Windows Hello. 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 Windows Hello for Work basé 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 organisation. 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 à l’organisation 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 moins important 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. Une clé est associée aux utilisateurs disposant d’un compte Active Directory, d’un ID Microsoft Entra ou d’un compte Microsoft. 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 au cloud (scénarios ID Microsoft Entra et MSA).
Windows Hello peut également être utilisé comme authentificateur FIDO2 pour s’authentifier auprès de n’importe quel site web qui prend en charge WebAuthn. Les sites web ou l’application 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 Connexion à la sécurité renforcée Windows Hello (ESS).
Synchronisation de clé
La synchronisation des clés est requise dans les environnements hybrides. Une fois que l’utilisateur a approvisionné des informations d’identification Windows Hello Entreprise, la clé doit être synchronisée entre l’ID Microsoft Entra 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 AD FS (Active Directory Federation Services), 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. Les informations d’identification Windows Hello 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. Le code confidentiel et les mouvements biologiques 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 ID Microsoft Entra 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 les appareils joints hybrides à Microsoft Entra. Pour les appareils personnels inscrits avec l’ID Microsoft Entra, 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 aux exigences de l’authentification multifacteur (MFA) microsoft Entra 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 modifications 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.
Toutefois, lorsque les utilisateurs doivent modifier leur mot de passe (par exemple, en raison de stratégies d’expiration de mot de passe), ils ne sont pas informés de l’exigence de changement de mot de passe lors de la connexion avec Windows Hello. Cela peut entraîner des échecs de l’authentification auprès des ressources protégées par Active Directory. Pour atténuer le problème, envisagez l’une des options suivantes :
- Désactiver l’expiration du mot de passe pour les comptes d’utilisateur
- Comme alternative aux stratégies d’expiration de mot de passe, envisagez d’adopter des stratégies d’expiration du code confidentiel
- Si l’expiration du mot de passe est obligatoire pour une organisation, demandez aux utilisateurs de modifier leurs mots de passe régulièrement ou lorsqu’ils reçoivent des messages d’échec d’authentification. Les utilisateurs peuvent réinitialiser leur mot de passe en :
- Utilisation de l’option Ctrl + Alt + Suppr>Modifier un mot de passe
- Connectez-vous avec leur mot de passe. Si le mot de passe doit être modifié, Windows invite l’utilisateur à le mettre à jour
Important
Pour modifier le mot de passe d’un utilisateur, l’appareil doit être en mesure de communiquer avec un contrôleur de domaine.
Étapes suivantes
Pour répondre à la multitude de besoins et d’exigences des organisations, Windows Hello Entreprise offre différentes options de déploiement. Pour savoir comment planifier un déploiement Windows Hello Entreprise, consultez :