Windows Hello Entreprise : Guide complet de l’authentification unique et de la sécurité matérielle

Windows Hello Entreprise est devenu la pierre angulaire de la stratégie sans mot de passe de Microsoft : il combine codes PIN, biométrie et clés cryptographiques pour permettre aux utilisateurs de se connecter sans saisir de mot de passe, tout en bénéficiant d’un niveau de sécurité nettement supérieur. Cette solution repose sur la sécurité matérielle, le module TPM et les modèles d’authentification unique (SSO) modernes, dans les environnements cloud, hybrides et sur site.

Bien plus qu'un simple code PIN Windows, Windows Hello Entreprise (WHfB) est un système distribué qui intègre Microsoft Entra ID (anciennement Azure AD), Active Directory, l'infrastructure à clés publiques (PKI), Kerberos, FIDO2 et des stratégies avancées pour les appareils et les utilisateurs. Si vous êtes administrateur Windows ou responsable des identités, il est essentiel de comprendre comment tous ces éléments s'articulent (inscription, provisionnement, synchronisation des clés, certificats et authentification) pour un déploiement réussi et une authentification unique robuste et résistante au phishing.

Qu’est-ce que Windows Hello Entreprise exactement et comment modifie-t-il l’authentification ?

Windows Hello Entreprise est la version gérée de Windows Hello destinée aux entreprises. Elle remplace le mot de passe par une authentification à clé publique associée à l'appareil, protégée par un module TPM et déverrouillée par un code PIN ou un geste biométrique. Cette authentification permet de se connecter à Microsoft Entra ID, Active Directory, AD FS et d'autres services qui en dépendent.

Au lieu de s'appuyer sur des secrets partagés (mots de passe, codes OTP, codes SMS), WHfB génère une paire de clés publique/privée pour chaque utilisateur et appareil. La clé publique est enregistrée auprès du fournisseur d'identité (IdP), tandis que la clé privée reste stockée en toute sécurité sur l'appareil et ne peut être exportée. L'utilisateur ne fournit de l'« entropie » (son code PIN ou ses données biométriques) pour libérer cette clé privée qu'au moment de l'authentification.

Le résultat est une expérience d'authentification résistante au phishing, au vol d'identifiants et aux attaques par force brute , maintenant l'authentification unique (SSO) à la fois dans le cloud (Microsoft 365, applications modernes) et les services sur site (Kerberos, applications existantes, VPN basés sur des certificats, etc.).

Phases internes de Windows Hello Entreprise : De zéro à l’authentification unique

Pour bien comprendre WHfB, il est utile de diviser son fonctionnement en plusieurs phases chronologiques : enregistrement de l’appareil, provisionnement, synchronisation des clés (le cas échéant), inscription du certificat (le cas échéant) et enfin, authentification quotidienne.

1. Enregistrement de l'appareil

Tout d'abord, l'appareil doit être enregistré . Cette étape associe l'appareil à un fournisseur d'identité spécifique et lui attribue sa propre identité.

Déploiements cloud ou hybridesLe fournisseur d'identité est Microsoft Enter ID et l'appareil est enregistré auprès du service d'enregistrement des appareils.
Implémentations purement localesLe fournisseur d'identité est AD FS et l'enregistrement est effectué auprès du service d'enregistrement des appareils d'entreprise exposé par AD FS.

Après l'enregistrement, l'appareil dispose d'une identité de confiance lui permettant de s'authentifier auprès du fournisseur d'identité (IdP) lors de la connexion d'un utilisateur. Il existe différents types d'enregistrement (jonction à un domaine, jonction à Microsoft Entra, enregistrement personnel, etc.), appelés types de jonction , qui déterminent le comportement ultérieur de WHfB et de l'authentification unique (SSO).

2. Phase d'approvisionnement

Lors de la configuration initiale, l'utilisateur cesse d'être un « utilisateur avec mot de passe » et dispose désormais de son propre conteneur Windows Hello sur l'appareil. Ce conteneur regroupe les données cryptographiques associées à ses comptes (professionnels, scolaires, personnels) de manière isolée par fournisseur d'identité.

Le processus d'approvisionnement typique suit les étapes suivantes :

Dans l'assistant d'expérience utilisateur (CXH), l'utilisateur s'authentifie auprès du fournisseur d'identité (IdP) à l'aide de MFA (généralement nom d'utilisateur/mot de passe plus un deuxième facteur).
Après avoir réussi l'authentification multifacteur, le système invite l'utilisateur à configurer un PIN et, si du matériel compatible est disponible, un ou plusieurs gestes biométriques (visage, empreinte).
Le conteneur Windows Hello est créé. sur l'appareil.
L'équipe génère un paire de clés d'authentification publique/privée, de préférence lié à un module TPM ; s’il n’y a pas de module TPM, il est protégé par un chiffrement logiciel.
La clé privée est stockée localement, scellée par le TPM lorsqu'il existe, et marquée comme non exportable.
La clé publique est enregistrée auprès du fournisseur d'identité associé au compte de l'utilisateur :
- Dans les environnements cloud, le service d'enregistrement des appareils l'inscrit dans l'objet utilisateur Microsoft Enter ID.
- Dans les scénarios locaux, AD FS stocke la clé dans Active Directory.

À partir de ce moment, lorsque l'utilisateur déverrouille l'appareil avec un code PIN ou par biométrie, il « déclenche » en réalité l'utilisation de cette clé privée Hello pour prouver son identité au fournisseur d'identité.

3. Détails du conteneur Windows Hello et types de clés

Le conteneur Windows Hello ne stocke pas une seule clé : il peut contenir différents types de données cryptographiques , chacune ayant sa propre fonction et son propre « protecteur ». Chaque protecteur chiffre sa copie de la clé d’authentification à l’aide d’une technique différente (par exemple, en scellant un TPM à l’aide du code PIN comme entropie, ou en utilisant un chiffrement symétrique dérivé du code PIN s’il n’y a pas de TPM).

À l'intérieur du conteneur, on trouve :

Une clé d'authentification principaleIl s'agit toujours d'une paire asymétrique (publique/privée) créée lors de l'inscription. C'est celle qui doit être déverrouillée à chaque fois à l'aide d'un code PIN ou de données biométriques. Si l'utilisateur réinitialise son code PIN, un Nouveau mot de passe et tout le contenu protégé par le précédent chiffrement est réencrypté avec le nouveau.
Un ou plusieurs clés d'identification de l'utilisateur Clés d'identification utilisateur : Elles peuvent être symétriques ou asymétriques selon le fournisseur d'identité et le modèle de confiance. Dans les implémentations basées sur des certificats, ces clés servent à générer des requêtes auprès de l'autorité de certification ou pour les protocoles RDP, VPN, etc.
En option, un clé administrative, conçu pour les scénarios de réinitialisation (par exemple, la récupération du code PIN) et les données associées au TPM de l'appareil.

Les clés d'identification utilisateur servent à prouver la propriété de la clé privée auprès du service (par exemple, en signant un nonce). Active Directory, Microsoft Entra ID et les comptes Microsoft personnels nécessitent des paires de clés asymétriques ; l'appareil génère la paire, enregistre la partie publique et protège la partie privée, qui ne quitte jamais l'appareil.

Si votre organisation dispose d'une infrastructure à clés publiques (PKI) d'entreprise, vous pouvez associer des clés d'identification utilisateur à des certificats émis par votre autorité de certification , permettant ainsi à WHfB de s'intégrer aux applications nécessitant des certificats (VPN classiques, RDP avec cartes à puce, etc.). Si vous n'avez pas besoin de PKI, le fournisseur d'identité (IdP) peut générer et gérer lui-même ces éléments d'identification afin de simplifier le processus.

4. Synchronisation clé dans les environnements hybrides

Dans les déploiements hybrides , où Microsoft Entra ID et Active Directory coexistent, une étape supplémentaire est nécessaire : la synchronisation de la clé publique Hello du cloud vers l’annuaire local afin que les contrôleurs de domaine puissent authentifier les utilisateurs.

La clé publique est stockée dans l'attribut msDS-KeyCredentialLink de l'objet utilisateur dans Active Directory, et la synchronisation est gérée par Microsoft Connect SyncSans cette réplication, il serait impossible pour un domaine local de vérifier l'authentification basée sur WHfB à partir d'un appareil connecté à Microsoft Entra.

5. Enregistrement du certificat (lors de l'utilisation d'un organisme de confiance de certificats)

Dans les modèles où WHfB s'appuie sur des certificats pour l'authentification Kerberos ou les applications locales , une phase supplémentaire apparaît : l'enregistrement des certificats.

Une fois la clé enregistrée, le client génère une demande de certificat et l'envoie à l' autorité de certification (CRA) , généralement hébergée sur le serveur AD FS, qui orchestre la demande avec l'infrastructure à clés publiques (PKI) de l'entreprise. L'autorité de certification émet le certificat, lequel est stocké dans le conteneur Hello de l'utilisateur sur son appareil et utilisé pour l'authentification auprès des ressources locales exigeant un certificat de carte à puce ou un dispositif similaire.

Authentification quotidienne, SSO et rôle de la sécurité matérielle

Au quotidien , lorsque l'utilisateur allume ou déverrouille son ordinateur, l'authentification repose toujours sur la partie privée de l'identifiant Windows Hello (clé ou certificat), ainsi que sur le geste de l'utilisateur (code PIN ou données biométriques). Ce geste n'est jamais transmis au fournisseur d'identité ni stocké tel quel dans le système.

L'authentification est en réalité à deux facteurs :

Un élément que possède l'utilisateur : la clé ou le certificat associé à l'appareil.
Un élément que l'utilisateur connaît ou qui est : un code PIN local ou des données biométriques.

Lorsque l’utilisateur saisit son code PIN ou utilise son empreinte digitale/reconnaissance faciale, Windows libère la clé d’authentification et l’utilise pour signer cryptographiquement les données envoyées au fournisseur d’identité (IdP) . Ce dernier vérifie cette signature par rapport à la clé publique stockée et, si tout correspond, délivre les jetons nécessaires à l’accès aux ressources (Microsoft 365, applications SaaS, ressources locales, etc.).

Ni le code PIN ni le modèle biométrique ne quittent l'appareil . Le code PIN n'est même pas stocké sous forme de texte : il sert d'entropie pour les opérations cryptographiques et pour le déverrouillage des données protégées par le TPM. Le fournisseur d'identité (IdP) ne voit que la preuve cryptographique que l'utilisateur contrôle la clé privée enregistrée.

Jeton d'actualisation principal (PRT) et SSO moderne

L'authentification unique (SSO ) dans l'environnement Microsoft moderne repose sur un jeton clé : le jeton d'actualisation principal (PRT) . Il s'agit d'un jeton Web JSON contenant des informations sur l'utilisateur et l'appareil, et permettant l'authentification unique aux applications protégées par Microsoft Entra ID ou AD FS.

Le PRT est obtenu en se connectant ou en déverrouillant l'appareil avec des informations d'identification de confiance (WHfB ou informations d'identification traditionnelles), de la même manière que le TGT Kerberos était obtenu auparavant dans un environnement sur site uniquement. Sur les appareils :

Rejoignez Microsoft. ou hybrides liés à Microsoft : le PRT est émis lors de la connexion elle-même.
appareils personnels enregistrés (BYOD) : Le PRT est généré lorsqu'un compte professionnel ou scolaire est ajouté à l'appareil.

Sans PRT, les utilisateurs devraient saisir leurs identifiants en permanence, et les politiques d'accès conditionnel basées sur l'état de l'appareil ne pourraient pas être évaluées . Avec WHfB et un PRT valide, l'authentification unique (SSO) est transparente et conditionnelle, en fonction de l'état de l'appareil, de la conformité, des risques et d'autres facteurs.

Paramètres clés de stratégie : SSO et sécurité matérielle

WHfB propose un ensemble complet de configurations de stratégie via CSP (pour les solutions MDM comme Intune) et GPO. Nombre d'entre elles visent à renforcer l'authentification unique (SSO) et à garantir l'utilisation systématique du matériel de sécurité disponible sur l'appareil.

Utilisation obligatoire des dispositifs de sécurité matériels (TPM)

L'une des règles les plus importantes exige que le déploiement de Windows Hello Entreprise soit effectué uniquement sur des appareils dotés d'un module TPM fonctionnel (1.2 ou 2.0) . Le module TPM offre une protection supplémentaire car la clé privée est liée à ce composant physique ; même si un attaquant copie le disque, il ne pourra pas utiliser la clé sur un autre ordinateur.

Cette configuration est contrôlée par CSP :

./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/RequireSecurityDevice
Et, en option, l'exclusion de certains TPM 1.2 avec :
./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/ExcludeSecurityDevices/TPM12

De plus, une stratégie de groupe équivalente est disponible dans les modèles d'administration Windows Hello Entreprise au niveau de l'ordinateur. Son activation empêchera le provisionnement de Windows Hello Entreprise sur les ordinateurs dépourvus d'un module TPM valide , renforçant ainsi considérablement la sécurité de l'environnement.

Configurer l'authentification unique locale : certificat ou confiance du cloud

Pour l'authentification unique (SSO) avec les ressources locales (contrôleurs de domaine, applications sur site), WHfB peut utiliser trois principaux modèles de confiance : basé sur les certificats, basé sur les clés (Key Trust) et, plus récemment, Cloud Kerberos Trust.

Il existe deux politiques fondamentales :

Utilisation d'un certificat pour l'authentification locale:
./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UseCertificateForOnPremAuth
Si cette option est activée, WHfB enregistre un certificat de connexion dans le conteneur et l'utilise pour l'authentification locale.
Utilisation de la confiance du cloud pour l'authentification locale:
./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UseCloudTrustForOnPremAuth
Si cette option est activée, WHfB utilise un ticket Kerberos dérivé de l'authentification dans Microsoft Entra ID pour s'authentifier auprès des ressources locales, sans qu'il soit nécessaire d'émettre des certificats supplémentaires.

La désactivation ou l'absence de configuration de ces stratégies entraîne l'utilisation d'une clé ou d'un certificat par le système , selon les autres options actives. Dans la stratégie de groupe, ces options se trouvent dans les sections Ordinateur et Utilisateur, sous Composants Windows > Windows Hello Entreprise.

Contrôle principal : activer ou désactiver Windows Hello Entreprise

Il existe une politique globale pour déterminer si un appareil utilise WHfB et si l'assistant de configuration est lancé après la connexion :

./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UsePassportForWork
./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/DisablePostLogonProvisioning

Grâce à eux, vous pouvez :

Exiger que tous les utilisateurs configurent WHfB sur l'appareil.
Empêcher complètement l'utilisation de WHfB.
Laisser chaque utilisateur décider s'il souhaite configurer Hello.
Empêcher le lancement automatique de l'assistant après la première connexion, ce qui est utile lorsque Vous utilisez une solution tierce pour fournir WHfB.

Politiques relatives aux codes PIN, à la récupération et aux contrôles de complexité

Le code PIN Windows Hello est l'un des piliers de la solution. Bien que beaucoup le confondent avec un mot de passe « court », il s'agit en réalité d'un facteur local lié à l'appareil, protégé par le module TPM et bien moins réutilisable qu'un mot de passe traditionnel.

Expiration, historique et durée du code PIN

Les politiques de code PIN vous permettent d'ajuster leur cycle de vie et leur complexité de manière similaire, mais plus granulaire, aux mots de passe traditionnels :

ExpirationVous pouvez paramétrer la durée de validité du code PIN pour qu'elle expire entre 1 et 730 jours. Si la valeur est 0, le code PIN n'expire jamais (valeur par défaut).
record: définit le nombre de codes PIN précédents qui ne peuvent pas être réutilisés, entre 0 et 50. Une valeur de 0 signifie qu'aucun historique n'est stocké.
Longueur minimale et maximale: minimum configurable à partir de 4 caractères ; maximum jusqu'à 127, en respectant toujours que le minimum est inférieur au maximum et que par défaut, si non configuré, un minimum de 6 caractères est requis.

Si ces politiques ne sont pas définies, le comportement par défaut autorise jusqu'à 127 caractères et exige un code PIN d'au moins 6 caractères, sans autre mesure d'application que les règles de complexité que vous définissez.

exigences de composition du code PIN

Vous pouvez choisir les types de caractères pris en charge et ceux requis dans le code PIN Windows Hello :

ChiffresSi vous activez l'option exigeant des chiffres, le code PIN doit contenir au moins un chiffre. Si vous la désactivez, les chiffres sont interdits. Sans ce paramètre, les chiffres sont autorisés, mais non obligatoires.
Lettres minuscules: vous permet d'en exiger au moins un, de les interdire complètement ou de les laisser facultatifs.
Letras mayúsculas: même schéma que pour les lettres minuscules.
Caractères spéciaux: au moins un peut être requis, ils peuvent être interdits ou ils peuvent être autorisés. Il s'agit d'un large ensemble de symboles (! " # $ % & ' ( ) + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~).

Ces règles permettent d'ajuster l'équilibre entre facilité d'utilisation et robustesse . Cependant, une complexité excessive augmente le risque d'oubli de codes PIN et de demandes d'assistance, un écueil que de nombreuses organisations cherchent précisément à éviter lors de l'adoption du WHfB.

Récupération du code PIN

La récupération du code PIN permet à un utilisateur de réinitialiser un code PIN oublié sans perdre les informations d'identification ni les certificats associés (y compris les clés liées aux comptes personnels sur cet ordinateur). Pour ce faire, Windows Hello chiffre un secret de récupération stocké localement, de sorte que seuls le service de récupération et l'appareil lui-même peuvent le déchiffrer.

Cette fonctionnalité exige que l'utilisateur effectue une authentification multifacteurs avec Microsoft Entra ID pour récupérer son code PIN. Si vous activez la stratégie correspondante (via CSP ou GPO), Windows générera et stockera ce secret de récupération. Si vous la désactivez ou ne la configurez pas, l'appareil ne créera ni ne stockera ce secret. En cas d'oubli du code PIN, l'utilisateur devra le supprimer et en créer un nouveau, puis se réinscrire aux services utilisés avec l'ancien code PIN.

Biométrie, protection anti-usurpation et ESS

Les données biométriques (visage, empreintes digitales, iris) utilisées dans WHfB complètent le code PIN et ne le remplacent pas. Un code PIN de secours est toujours disponible en cas de défaillance du capteur ou si le contexte ne permet pas son utilisation.

Protection anti-usurpation d'identité renforcée

Une politique spécifique exige une protection renforcée contre l'usurpation d'identité pour la reconnaissance faciale. Lorsqu'elle est activée, Windows n'autorise l'authentification faciale que si le capteur et la pile logicielle répondent à ces exigences avancées de détection des attaques (par exemple, en empêchant les connexions utilisant des photos, des vidéos ou des deepfakes simples).

S'il est désactivé ou non configuré, Windows ne nécessitera pas cette protection renforcée et l'authentification faciale sera moins restrictive. La route CSP associée est ./Device/Vendor/MSFT/PassportForWork/Biometrics/FacialFeaturesUseEnhancedAntiSpoofing, et l'équivalent se trouve également dans la stratégie de groupe (GPO) sous les options biométriques Windows Hello Entreprise.

ESS : Sécurité de connexion renforcée avec les périphériques

Enhanced Sign-in Security (ESS) est une couche supplémentaire qui combine VBS (Virtualization Based Security), TPM 2.0 et des composants spécifiques pour isoler les modèles biométriques et les opérations de comparaison par matériel.

Avec ESS, les données biométriques (visage, empreintes digitales) et les comparaisons sont effectuées dans des zones de mémoire isolées et protégées , auxquelles le reste du système d'exploitation n'a pas d'accès direct. Le canal entre les capteurs et l'algorithme est également protégé, empêchant ainsi les logiciels malveillants ou les attaquants d'injecter ou de reproduire de fausses données biométriques pour simuler des connexions ou bloquer l'accès des utilisateurs.

La politique EnableESSwithSupportedPeripherals permettre deux valeurs principales:

0L'ESS est activé même en présence de capteurs périphériques ou intégrés non compatibles. L'authentification est possible avec ces appareils, sous certaines conditions. Cette option est déconseillée.
1ESS activé sans Il accepte les capteurs périphériques ou intégrés non compatibles ESS. Autrement dit, les opérations biométriques provenant de tout appareil ne prenant pas en charge ESS sont bloquées pour Windows Hello. Voici la configuration avec plus de sécurité.

Si les appareils ESS sont désactivés ou non configurés, ils bloqueront les capteurs non compatibles ESS, maintenant ainsi une approche prudente en matière de sécurité.

Utilisation de la biométrie en général

La stratégie UseBiometrics détermine si Windows Hello Entreprise autorise l'utilisation des gestes biométriques ou s'il prend uniquement en charge les codes PIN. Si elle est activée ou non configurée, la biométrie est autorisée ; si elle est désactivée, son utilisation est interdite et les utilisateurs doivent toujours s'authentifier à l'aide d' un code PIN ou d'autres facteurs.

Dans tous les cas , les données biométriques :

Ils sont stockés uniquement sur l'appareil local (base de données dans C:\Windows\System32\WinBioDatabase).
Chaque capteur possède son propre fichier et une clé unique générée aléatoirement, chiffrée avec AES en mode CBC et hachage SHA-256.
Elles ne sont ni envoyées à des serveurs externes ni synchronisées entre ordinateurs, ce qui empêche les attaquants de collecter un point de convergence unique.

Intégration avec les cartes à puce et les applications existantes

De nombreuses organisations utilisent encore des cartes à puce et des applications qui requièrent des certificats similaires . WHfB propose des options permettant d'émuler ou de s'intégrer à ces environnements sans compromettre les avantages de l'authentification moderne.

Émulation et énumération des cartes à puce

Par défaut , Windows empêche les utilisateurs d'un même ordinateur de voir les informations d'identification Windows Hello fournies pour d'autres utilisateurs. Une stratégie permet de désactiver cette fonctionnalité dans les cas suivants :

Un même utilisateur peut posséder des comptes avec et sans privilèges sur le même ordinateur.
Il souhaite se connecter avec son compte « normal », mais obtenir des privilèges supérieurs avant de se déconnecter, en utilisant ses propres identifiants Hello.

Il est également possible de désactiver l'émulation de carte à puce . Si cette option est activée, les identifiants WHfB ne seront plus compatibles avec les applications nécessitant une carte à puce. Si elle est désactivée ou non configurée, Windows continuera d'assurer cette émulation automatiquement.

Utiliser les certificats Hello comme certificats de carte à puce

Une autre politique importante es UseHelloCertificatesAsSmartCardCertificatesSi cette option est activée, les applications peuvent gérer Certificats Windows Hello pour les entreprises, tels que les certificats de cartes à puce.Toutefois, dans ce contexte, les facteurs biométriques Ne sont pas disponibles lorsqu'une autorisation est demandée pour utiliser la clé privée du certificat.

Si ce paramètre n'est pas configuré ou est désactivé , les applications n'utiliseront pas les certificats Hello de cette manière et l'authentification biométrique restera disponible pour l'utilisateur. Il est impossible d'activer cette option simultanément avec la stratégie désactivant l'émulation de carte à puce.

Exigences en matière de PKI, de CRL et de certificats de contrôleur de domaine

Dans les déploiements où WHfB doit fournir une authentification unique (SSO) aux ressources sur site à l'aide de certificats et de Kerberos , l'infrastructure PKI et de certificats doit être bien paramétrée, en particulier s'il existe des appareils uniquement connectés à Microsoft Entra qui s'authentifieront auprès d'Active Directory.

Point de distribution CRL accessible par les appareils connectés à Entra

Un élément essentiel est la liste de révocation des certificats (CRL) . Lorsqu'une autorité de certification révoque un certificat, elle ajoute des informations à cette liste, et Windows la consulte pour vérifier si le certificat est toujours valide.

Dans de nombreux environnements sur site, le point de distribution des listes de révocation de certificats ( CDP ) est publié sous forme de chemin LDAP dans Active Directory . Cela fonctionne correctement pour les machines jointes au domaine, mais pas pour celles jointes uniquement à Microsoft Entra, qui ne peut pas accéder à Active Directory sans authentification préalable. Il en résulte une dépendance circulaire : pour valider le certificat du contrôleur de domaine, il est nécessaire d’accéder à Active Directory, or l’accès à Active Directory est impossible sans authentification préalable.

La solution consiste à publier le CDP sur un serveur web accessible via HTTP (et non HTTPS) , ce qui ne nécessite pas d'authentification préalable. La procédure habituelle comprend les étapes suivantes :

Installez IIS ou un autre serveur web sur un serveur interne.
Créez un répertoire virtuel (par exemple, cdp) qui pointe vers un dossier partagé où l'autorité de certification peut publier les listes de révocation de certificats (CRL).
Ajustez les autorisations NTFS et de partage afin que l'autorité de certification puisse écrire dans ce dossier.
Créez un enregistrement DNS (par exemple, crl.midominio.com) pointant vers ce serveur.
Configurez le contrôleur d'accès de diffusion pour inclure un CDP HTTP dans les extensions des certificats émis, et de publier la CRL et la CRL delta à cet emplacement.

Après Vous devez forcer la publication d'une nouvelle CRL et vérifier qu'elle est accessible depuis un navigateur. http://crl.tudominio.com/cdp et consulter les fichiers .crl généré.

Réémission des certificats de contrôleur de domaine et validation stricte du KDC

Les certificats existants ne sont pas automatiquement mis à jour avec le nouveau CDP ; ils doivent être renouvelés . Cela est particulièrement vrai pour les certificats de contrôleur de domaine utilisés pour l’authentification Kerberos. WHfB applique la fonctionnalité de « validation stricte du KDC » lorsqu’un appareil joint à Microsoft Entra s’authentifie auprès d’un domaine local ; le certificat du contrôleur de domaine doit donc répondre à plusieurs exigences :

Le contrôleur de domaine doit posséder la clé privée du certificat présenté.
L'autorité de certification racine qui a émis le certificat du contrôleur de domaine doit se trouver dans le racines de confiance appareil.
Vous devez utiliser le Modèle de certificat d'authentification KerberosPas de vieux modèles.
Le certificat doit inclure l'EKU de Authentification KDC.
Le nom alternatif du sujet doit contenir un nom DNS qui faire correspondre le nom de domaine.
L'algorithme de signature doit être au moins SHA256.
La clé publique doit être RSA 2048 bits.

Après avoir configuré l'autorité de certification et renouvelé les certificats des contrôleurs de domaine, vous devez vérifier dans l'onglet Détails de chaque certificat que le point de distribution de certificats HTTP (CDP) correct est présent. Ceci est essentiel pour que les périphériques joints à Entra puissent faire confiance aux contrôleurs de domaine lors de l'authentification auprès de WHfB.

Implémenter le certificat racine de l'autorité de certification sur les appareils connectés à Entra

Enfin, les appareils connectés à Microsoft Entra doivent faire confiance à l' autorité de certification racine de l'entreprise. Pour ce faire, il faut exporter le certificat racine de la chaîne de confiance du contrôleur de domaine et le distribuer aux ordinateurs, par exemple à l'aide de :

Une politique de certificat de confiance des équipements dans Microsoft Intune, pointant vers le magasin racine approuvé de l'équipe.
Ou des méthodes équivalentes dans d'autres solutions MDM/gérées.

Si cette étape est omise, même si tous les autres éléments sont correctement configurés, les appareils ne feront pas confiance aux DC et les authentifications WHfB échoueront au niveau de la couche TLS/certificat.

Windows Hello Entreprise représente une avancée majeure en matière de sécurité et d'expérience de connexion : il remplace les mots de passe par des identifiants matériels gérés de manière centralisée, offrant une authentification unique (SSO) moderne et résistante au phishing, aussi bien dans le cloud que sur site. Toutefois, pour un fonctionnement optimal, il est essentiel de prendre au sérieux l'infrastructure d'identité et d'infrastructure à clés publiques (PKI), de définir des politiques appropriées pour les codes PIN, la biométrie et l'utilisation obligatoire du module TPM, et de mettre en œuvre un déploiement progressif accompagné d'une communication claire avec les utilisateurs. Ainsi, le changement sera perçu comme une amélioration et non comme une contrainte informatique supplémentaire.