Windows Hello Entreprise, clés matérielles et authentification unique (SSO)

Si vous gérez des identités dans des environnements Microsoft, vous avez probablement déjà entendu parler de Windows Hello, Windows Hello Entreprise, clés matériel et SSOMais il est facile de s'y perdre parmi tous ces acronymes, types de confiance et exigences. De plus, dans les déploiements hybrides avec un Active Directory existant, comprendre ce que WHfB apporte réellement par rapport à un simple code PIN ou une authentification biométrique peut faire toute la différence entre un projet réussi et un véritable casse-tête.

Dans cet article, nous allons expliquer en détail comment cela fonctionne. Windows Hello Entreprise (WHfB), quel rôle jouent les clés matérielles, comment fonctionne l'authentification unique (SSO) ? Nous verrons en quoi il diffère de Windows Hello « classique » pour les particuliers. Nous examinerons les phases internes (enregistrement de l’appareil, provisionnement, synchronisation des clés, certificats et authentification), les modèles de déploiement (cloud uniquement, hybride et sur site), les types de confiance, les exigences en matière d’infrastructure à clés publiques (PKI), les licences, les défis concrets du déploiement et comment tout cela s’intègre aux approches modernes telles que FIDO2 et la sécurité sans mot de passe.

Windows Hello vs Windows Hello Entreprise : quelles sont les véritables différences ?

Windows Hello (en termes simples) est l'interface utilisateur permettant de se connecter avec un code PIN ou des données biométriques. Sur un appareil Windows, conçu pour les environnements personnels et professionnels. Windows Hello Entreprise (WHfB), quant à lui, est l'extension pour entreprises qui ajoute des fonctionnalités d'identité robustes, intégrées à Active Directory et à Microsoft Entra ID.

Vous pouvez utiliser les deux méthodes Reconnaissance par code PIN, empreinte digitale ou faciale prise en charge par le TPM pour se connecter à l'ordinateur. Vous pouvez même vous authentifier auprès d'un domaine local classique. La grande différence est que WHfB crée et gère identifiants cryptographiques de niveau entreprisePaires de clés ou certificats liés à l'utilisateur et à l'appareil, gérés par des politiques et utilisables pour l'authentification unique (SSO) sur les ressources locales et cloud.

Alors que Windows Hello « normal » est essentiellement limité à remplacer le mot de passe par un geste pratique sur cet appareilWHfB génère une authentification forte que le fournisseur d'identité (AD, Microsoft Entra ID ou AD FS) reconnaît, stocke et utilise pour émettre des jetons d'accès et appliquer la sécurité. Accès conditionnel, validation KDC stricte, PRT, Kerberos dans le cloud et d'autres commandes avancées.

La question logique est la suivante : si je dispose déjà d’appareils joints à un domaine, gérés avec Intune, avec TPM et biométrie, et SSO vers le cloud via la synchronisation du hachage du mot de passe, Qu'est-ce que j'y gagne exactement en ajoutant WHfB ? La réponse réside dans la manière dont les clés sont construites et validées, dans la façon dont l'appareil est connecté et dans la capacité d'étendre cette sécurité à l'ensemble de l'écosystème, et pas seulement à la connexion locale.

Architecture de base : phases de Windows Hello Entreprise

WHfB est un système distribué qui repose sur plusieurs composants : périphérique, TPM, fournisseur d'identité, PKI, synchronisation d'annuaires et mécanismes SSOPour bien comprendre son fonctionnement sans s'y perdre, il est utile de le diviser en cinq phases chronologiques de mise en œuvre.

1. Enregistrement de l'appareil

La première pièce du puzzle est la enregistrement de l'appareil auprès du fournisseur d'identité (IdP)Cette étape vous permet d'associer l'appareil à une identité dans l'annuaire et de lui permettre de s'authentifier automatiquement lorsqu'un utilisateur se connecte.

Dans les environnements exclusivement cloud ou hybrides, Le fournisseur d'identité est Microsoft. Entrez votre identifiant. et l'appareil s'enregistre auprès de son service d'enregistrement (connecté à Microsoft Entra, connecté de manière hybride ou enregistré). Dans les scénarios purement locaux, le fournisseur d'identité est généralement AD FS avec son service d'enregistrement des appareils d'entreprise.

Une fois cette inscription terminée, le fournisseur d'identité attribue l'équipe une identité unique qui sera utilisée pour établir la confiance entre l'appareil et le répertoire Lors des authentifications successives, cet enregistrement est classé selon le « type de connexion de l’appareil », qui détermine si l’appareil est connecté à un domaine local, à Entra ID, à un compte hybride ou simplement enregistré comme appareil personnel.

2. Provisionnement : création du conteneur Windows Hello

Une fois l'appareil enregistré, la phase commence. Fourniture d'identifiants Windows Hello pour les entreprisesC’est ici que se crée le conteneur Windows Hello, qui regroupe logiquement tous les éléments cryptographiques de l’utilisateur sur cet ordinateur.

Le processus d'approvisionnement typique suit ces principales étapes, toujours selon un authentification initiale avec des identifiants faibles (nom d'utilisateur et mot de passe) :

• L'utilisateur s'authentifie via l'authentification multifacteur auprès du fournisseur d'identité. (Microsoft Enter MFA ou une autre méthode compatible, ou un adaptateur MFA dans AD FS dans les environnements locaux).
• Après avoir surmonté ce deuxième obstacle, il vous est demandé de configurer un un code PIN et, si le matériel compatible est disponible, un geste biométrique (empreinte, visage, iris).
• Après confirmation du code PIN, Windows génère le Conteneur Windows Hello pour ce compte dans cette équipe.
• À l'intérieur de ce conteneur, un paire de clés cryptographiques (publique et privée), lié au TPM lorsqu'il existe ou, à défaut, protégé par logiciel.
• La La clé privée reste sur l'appareil et ne peut pas être exportée., restant protégés par le TPM et par les protections PIN/biométriques.
• La La clé publique est enregistrée auprès du fournisseur d'identité. et il est lié à l'objet utilisateur : dans l'identifiant de connexion Microsoft, il est inscrit dans l'utilisateur, et dans les scénarios locaux fédérés, AD FS le transfère à Active Directory.

Le conteneur comprend également un clé administrativeCeci est utile dans des cas comme la réinitialisation du code PIN ; sur les appareils dotés d’un module TPM, un bloc de données contenant les certificats TPM est également stocké. L’accès à l’ensemble des données n’est déverrouillé que lorsque l’utilisateur effectue le geste (code PIN ou données biométriques), et cette authentification multifacteur initiale établit une relation de confiance entre l’utilisateur, l’appareil et le fournisseur d’identité.

3. Clés dans le conteneur : authentification et identifiant utilisateur

Dans le conteneur Windows Hello, on trouve plusieurs types de clés, avec des rôles différents, toutes chiffré avec protection par code PIN ou biométrique:

• Clé d'authentificationUne paire de clés asymétriques générées lors de l'enregistrement, qui doivent toujours être déverrouillées par un code PIN ou un geste biométrique. Elles servent de base au recyclage d'autres matériaux lors du changement de code PIN.
• Clés d'identification de l'utilisateurLes clés d'identité peuvent être symétriques ou asymétriques selon le fournisseur d'identité (IdP) et le modèle (clé ou certificat). Elles servent à signer ou à chiffrer les requêtes et les jetons adressés au fournisseur d'identité. En entreprise, elles sont généralement générées sous forme de paires de clés asymétriques, la clé publique étant enregistrée auprès de l'IdP.

Ces clés d'identification utilisateur peuvent être obtenues de deux manières principales : associé à l'infrastructure à clés publiques (PKI) de l'entreprise pour émettre des certificats (par exemple, pour VPN, RDP ou authentification Kerberos basée sur un certificat) ou générée directement par l'IdP dans les scénarios sans PKI (modèle de clé pure).

La même infrastructure permet l'utilisation de Windows Hello en tant qu'authentificateur FIDO2/WebAuthn Dans les applications et sites web compatibles, les sites peuvent créer une authentification FIDO au sein du conteneur Windows Hello ; lors des visites suivantes, l’utilisateur s’authentifie avec son code PIN ou ses données biométriques sans divulguer son mot de passe.

4. Synchronisation clé dans les environnements hybrides

Dans les architectures hybrides où coexistent Identifiant de connexion Microsoft et Active DirectoryL'enregistrement de la clé dans le cloud ne suffit pas. Après la mise en service, la clé publique WHfB doit être synchronisée avec le répertoire local pour être activée. Authentification et SSO auprès des ressources sur site.

Dans ces scénarios, Microsoft Entra Connect Sync prend en charge Copiez la clé publique dans l'attribut msDS-KeyCredentialLink de l'objet utilisateur dans Active Directory. Cette synchronisation est essentielle pour que le contrôleur de domaine puisse valider les signatures générées par le périphérique avec la clé privée stockée dans le TPM.

5. Enregistrement des certificats (uniquement lorsque cela est nécessaire)

Dans certains modèles (tels que le fiducie de certificatOutre les clés, l'organisation doit délivrer des certificats d'authentification aux utilisateurs. Dans ce cas, une phase supplémentaire est activée. enregistrement des certificats.

Après l'enregistrement de la clé publique, le client génère un demande de certificat qui envoie la requête à l'autorité de registre de certificats, généralement intégrée à AD FS dans les déploiements fédérés. Cette autorité de registre valide la requête à l'aide de l'infrastructure à clés publiques (PKI) de l'entreprise et Il émet un certificat qui est stocké dans le conteneur Hello, réutilisable pour l'authentification sur les ressources locales qui reposent encore sur des certificats.

Authentification, clé privée et SSO : comment tout cela s’articule

Une fois les phases d'inscription et de mise en service terminées, le quotidien de l'utilisateur se réduit à quelque chose de très simple : un geste (code PIN ou biométrie) qui « libère » la clé privée sur l'appareilCe qui est intéressant, c'est ce qui se passe en coulisses.

Lorsque l'utilisateur déverrouille l'ordinateur, Windows utilise la partie privée des informations d'identification WHfB pour signer cryptographiquement les données envoyées au fournisseur d'identitéCette méthode vérifie la signature à l'aide de la clé publique stockée dans l'objet utilisateur. Comme le code PIN et la clé privée ne quittent jamais l'appareil, le processus est protégé contre le phishing et le vol d'identifiants classique.

Dans les scénarios Microsoft Enter ID, l'authentification aboutit à un Jeton de rafraîchissement principal (PRT)Un jeton Web JSON contenant des informations sur l'utilisateur et l'appareil. Il constitue la base de l'authentification unique (SSO) pour les applications cloud et, en combinaison avec Microsoft Kerberos ou la synchronisation de clés, également pour les ressources locales.

Sans PRT, même si l'utilisateur possède une accréditation WHfB valide, Je perdrais l'authentification unique. et serait contraint de s'authentifier en permanence dans chaque application. C'est pourquoi les politiques d'accès conditionnel, qu'elles soient basées sur l'appareil ou sur les risques, prennent généralement en compte la présence et la validité de ce PRT.

Pour Active Directory, lors de l'utilisation de la confiance par clé ou certificat, WHfB agit comme un carte à puce virtuelleL'utilisateur signe un nonce ou un défi auprès du KDC, le contrôleur de domaine valide le certificat ou la clé et émet un ticket TGT Kerberos, permettant ainsi l'authentification unique (SSO) aux services locaux intégrés à Kerberos.

Sécurité interne : biométrie, TPM et protection contre les attaques

L'un des piliers de WHfB est que le Les données biométriques ne quittent jamais l'appareilLes modèles générés par les capteurs sont stockés localement dans bases de données chiffrée (par exemple, dans le chemin C:\WINDOWS\System32\WinBioDatabase) à l'aide de clés uniques par base de données, protégée avec AES en mode CBC et SHA-256 comme fonction de hachage.

Cela signifie que même si un attaquant parvenait à accéder à ces fichiers, Je n'ai pas pu reconstituer l'image du visage ni l'empreinte digitale de l'utilisateur.Ils ne peuvent pas non plus être utilisés sur un autre appareil. De plus, chaque capteur dispose de son propre espace de stockage, ce qui réduit le risque de vol centralisé des données biométriques.

Le code PIN de Windows Hello Entreprise offre une meilleure protection qu'un mot de passe traditionnel. Il ne transite pas sur le réseau, sa validation est effectuée localement et le module TPM garantit la sécurité. blocages dus à un trop grand nombre de tentatives incorrectesCela rend les attaques par force brute ou par dictionnaire inefficaces. De plus, si quelqu'un vole le code PIN, celui-ci ne fonctionnera que sur cet appareil précis, car l'identifiant est lié au matériel.

Face aux menaces modernes (Comment savoir si un courriel est une tentative d'hameçonnage ?(réutilisation des mots de passe, vol massif d'identifiants), WHfB s'appuie sur Cryptographie à clé publique liée à un appareilCela évite, de par sa conception, la divulgation de secrets partagés. Ceci est parfaitement conforme aux normes et recommandations de réglementations telles que NIST 800-63B et aux modèles de sécurité « zéro confiance ».

Modèles de déploiement : cloud, hybride et sur site

WHfB offre une grande flexibilité en termes de topologie, mais cette flexibilité engendre une certaine complexité. De manière générale, on peut distinguer trois modèles de déploiement qui se combinent de différentes façons. Microsoft Entra ID, Active Directory, infrastructure à clés publiques (PKI) et fédération.

Modèle exclusivement cloud

Dans les organisations qui vivent presque à 100 % dans Microsoft 365 et autres services SaaS, sans infrastructure locale pertinente, le modèle le plus simple est celui de Accès cloud uniquement, avec des appareils connectés à Microsoft. Se connecterDans ce scénario :

• Tous les utilisateurs et appareils résident dans ID d'entrée Microsoft.
• L'enregistrement des appareils et des clés s'effectue directement dans le cloud.
• Aucune infrastructure à clés publiques (PKI) d'entreprise n'est nécessaire. ni les certificats de contrôleur de domaine.
• L'authentification unique (SSO) repose sur les jetons PRT et Microsoft Entra pour les applications.

C'est l'option la plus directe pour les entreprises privilégiant le cloud, avec faible coût d'infrastructure et déploiement relativement simple, idéal lorsque les ressources sur site ne sont pas disponibles ou sont minimales.

Modèle hybride : le cas le plus courant

La grande majorité des entreprises se situent quelque part entre ces deux extrêmes : Active Directory historique combiné à l'identifiant de connexion Microsoft synchroniséWHfB excelle dans ce domaine, mais c'est aussi là que les problèmes de configuration sont les plus fréquents s'ils ne sont pas bien planifiés.

Dans un environnement hybride, les identités sont synchronisées avec Microsoft Entra Connect Sync, et il existe plusieurs combinaisons possibles de modèle de déploiement (hybride) et type de confiance (cloud Kerberos, clé ou certificat)L'objectif est généralement de proposer :

• SSO aux services cloud (SharePoint Applications en ligne, Teams, OIDC/SAML).
• accès transparent aux ressources locales (actions, applications Kerberos, VPN, RDP).
• Une solution de sortie progressive pour les mots de passe, tout en maintenant les applications existantes.

Les principaux types de confiance dans les scénarios hybrides sont :

• Kerberos dans le cloudMicrosoft Entra Kerberos émet des TGT pour Active Directory sans nécessiter d'infrastructure à clés publiques (PKI) supplémentaire. Il s'agit du modèle hybride le plus moderne et le plus simple, car il exploite l'infrastructure FIDO2 existante et ne requiert pas la synchronisation des clés publiques avec Active Directory.
• Key TrustLes utilisateurs s'authentifient auprès d'Active Directory à l'aide d'une clé liée à leur appareil ; les contrôleurs de domaine requièrent des certificats spécifiques. L'infrastructure à clés publiques (PKI) est requise pour les contrôleurs de domaine, mais pas pour les certificats utilisateur.
• Certificat de confianceLes certificats d'authentification utilisateur sont émis et utilisés pour obtenir des TGT Kerberos. Cela nécessite une infrastructure à clés publiques (PKI) complète, AD FS comme autorité d'authentification client (CRA) et une configuration plus poussée.

Choisir le bon type de confiance est crucial : Aucune n'est intrinsèquement « plus sûre ».Cependant, leur coût, leur complexité et leurs exigences en matière d'infrastructure varient. Pour les nouveaux déploiements, l'utilisation de Kerberos dans le cloud est souvent la meilleure option, à condition que les versions Windows du client et du serveur respectent les exigences minimales.

Modèle local pur

Les organisations soumises à de fortes contraintes réglementaires, ou ayant peu ou pas d'adoption du cloud, peuvent opter pour un déploiement WHfB. 100 % local, pris en charge par Active Directory et AD FSDans ce modèle :

• L'enregistrement des appareils est géré AD FS.
• L'authentification peut être basée sur une clé ou sur un certificat, mais elle est toujours soutenue par une infrastructure à clés publiques (PKI) d'entreprise.
• Les options MFA incluent des adaptateurs pour AD FS ou des solutions comme Azure MFA Server (déjà existantes) intégrées sur site.

Cette approche donne un contrôle total des données d'authentificationCependant, cela nécessite un effort de maintenance considérable (PKI, AD FS, publication de CRL accessibles par des ordinateurs non joints au domaine, etc.), ce que toutes les organisations ne sont pas disposées à assumer à long terme.

Infrastructure à clés publiques (PKI) accessible, certificats de contrôleur de domaine et listes de révocation de certificats (CRL)

Dans les modèles qui reposent sur des certificats (que ce soit pour les utilisateurs, les contrôleurs de domaine ou les deux), l'infrastructure à clés publiques (PKI) devient le pilier de la confiance. WHfB exige validation stricte des KDC lorsqu'un appareil joint à Microsoft Enterprise s'authentifie auprès d'un domaine local.

Concrètement, cela signifie que le certificat du contrôleur de domaine doit satisfaire à un certain nombre de conditions techniques : Émis par une autorité de certification racine de confiance pour le périphérique, basé sur le modèle d'authentification Kerberos, avec l'EKU « authentification KDC », un nom DNS correct, RSA 2048 et SHA-256 comme algorithme de signatureentre autres exigences.

De plus, il est essentiel que l'appareil puisse vérifier la révocation des certificatsC’est là que réside le problème classique des listes de révocation de certificats (CRL) : un appareil connecté uniquement à Microsoft Entra ne peut pas lire les chemins LDAP dans Active Directory s’il ne s’est pas encore authentifié ; il est donc nécessaire de publier le point de distribution de la CRL dans une URL HTTP accessible sans authentification.

Cela implique de préparer un serveur web (IIS, par exemple), de créer un répertoire virtuel (cdp) et d'ajuster les permissions. NTFS et à partir des ressources partagées, désactiver stockage En mode de mise en cache hors ligne, configurez l'autorité de certification pour qu'elle publie la liste de révocation de certificats (CRL) sur cette ressource partagée et l'expose via HTTP. Une fois cette opération effectuée, vous devez : Renouveler les certificats du contrôleur de domaine pour inclure le nouveau CDP et s'assurer que le certificat racine d'entreprise est déployé sur les appareils joints à Microsoft Entra (par exemple, avec Intune et un profil de « certificat approuvé »).

Synchronisation d'annuaire, authentification multifacteur et configuration des périphériques

L'expérience de l'utilisateur final avec Windows Hello Entreprise dépend en grande partie de Comment la synchronisation d'annuaires, l'authentification multifacteur et la configuration des stratégies sont intégrées.

Dans les déploiements hybrides, Microsoft Entra Connect Sync ne se contente pas de synchroniser les comptes ; il peut également synchroniser… attributs critiques tels que msDS-KeyCredentialLinkqui contient la clé publique WHfB requise pour l'authentification dans Active Directory. Dans les environnements locaux avec Azure MFA Server, la synchronisation est utilisée pour importer les utilisateurs sur le serveur MFA, qui interroge ensuite le service cloud pour vérification.

En matière d'authentification multifacteurs, les organisations disposent de plusieurs options : Microsoft Entra MFA pour les scénarios cloud ou hybridesLes méthodes externes intégrées via l'authentification externe dans Entra ID ou via la fédération, ainsi que les adaptateurs MFA tiers pour AD FS dans les environnements sur site, sont pris en charge. L'indicateur FederatedIdpMfaBehavior dans les domaines fédérés détermine si Entra ID accepte, exige ou ignore l'authentification multifacteur (MFA) effectuée par le fournisseur d'identité fédéré. Ce paramètre peut être crucial pour le bon fonctionnement du provisionnement WHfB.

La configuration WHfB sur l'équipement peut être effectuée avec stratégie de groupe (GPO) ou CSP via MDM (Par exemple, Intune). Dans les organisations modernes, il est courant d'activer l'enregistrement automatique WHfB, d'imposer l'authentification multifacteur lors de la première connexion, de définir des politiques de complexité des codes PIN et de contrôler les méthodes biométriques acceptées (uniquement les capteurs certifiés, les caméras infrarouges, etc.).

Parallèlement, il est essentiel de prendre en compte l’expérience du rétablissement : réinitialisation du code PIN en libre-service, méthodes alternatives telles que les clés FIDO2, et Chiffrement BitLocker pour protéger les données au repos en cas de perte ou de vol de l'appareil.

Licences, configurations système requises et limitations pratiques

L'un des mythes les plus répandus est qu'il faut toujours utiliser WHfB. Microsoft Entrez l'ID P1 ou P2En réalité, les fonctionnalités de base de WHfB sont disponibles avec le niveau gratuit Entra ID, et l'authentification multifacteurs requise pour le provisionnement sans mot de passe peut également être activée sans licences premium, bien que des fonctionnalités telles que l'inscription MDM automatique, l'accès conditionnel avancé ou l'écriture différée sur l'appareil nécessitent des niveaux supérieurs.

En termes de système d'exploitation, pratiquement toutes les versions client modernes de Windows prennent en charge WHfB, mais La confiance dans Kerberos dans le cloud exige des minimums concrets. (par exemple, Windows 10 21H2 avec certains correctifs ou certaines versions spécifiques de Windows 11Côté serveur, toute version prise en charge de Windows Server peut généralement faire office de contrôleur de domaine, bien que la partie Kerberos dans le cloud nécessite des versions et des mises à jour spécifiques sur les contrôleurs de domaine.

Au-delà des aspects techniques, il existe des défis très pratiques : le partage d’équipements où WHfB, étant spécifique à l'appareil et à l'utilisateur, s'adapte régulièrement; matériel sans TPM 2.0 ou capteurs biométriques ; ou environnements où le coût du renouvellement des anciennes flottes, du déploiement de l'infrastructure à clés publiques (PKI) et de la mise à niveau des centres de données de 2012 rend l'adoption complète du WHfB peu attrayante à court terme.

Dans certains cas, la voie raisonnable implique combiner WHfB avec d'autres facteurs sans mot de passe (Clés FIDO2, cartes à puce, authentification téléphonique) pour couvrir les postes de travail partagés, les plateformes non-Windows ou les utilisateurs très mobiles, laissant WHfB comme authentificateur principal dans portátiles entreprises liées à Entra ou hybrides.

Dans l'ensemble, Windows Hello Entreprise offre bien plus qu'un simple code PIN : il introduit Des identifiants asymétriques liés au matériel, une vérification KDC stricte, une intégration poussée avec Microsoft Entra ID et Active Directory, et un cadre robuste pour l'authentification unique sécurisée (SSO) Que ce soit dans le cloud ou sur site, sa véritable valeur ajoutée par rapport à Windows Hello de base dépend de votre point de départ : dans les environnements modernes privilégiant le cloud ou hybrides avec une infrastructure à clés publiques (PKI) et un contrôleur de domaine (DC) mis à jour, le gain en matière de sécurité et de gestion justifie largement l’effort ; en revanche, dans les environnements très anciens, avec une infrastructure peu préparée et sans plan de modernisation, il peut être plus judicieux de privilégier d’abord la mise à niveau du matériel, de la PKI et du contrôle d’accès avant d’exploiter pleinement le potentiel de Windows Hello fb.

Article connexe:

Comment savoir quelles applications ont accès à votre caméra, votre microphone ou votre emplacement dans Windows 11

Isaac

Écrivain passionné par le monde des octets et de la technologie en général. J'aime partager mes connaissances à travers l'écriture, et c'est ce que je vais faire dans ce blog, vous montrer toutes les choses les plus intéressantes sur les gadgets, les logiciels, le matériel, les tendances technologiques et plus encore. Mon objectif est de vous aider à naviguer dans le monde numérique de manière simple et divertissante.