Aller au contenu
02 · Protection des identifiantsPartie 4 sur 4Intermédiaire

Windows Hello for Business : modèles d'approbation et PIN

Déployer Windows Hello for Business en cloud Kerberos trust ou key trust, exiger des clés TPM, définir la stratégie de PIN et vérifier l'inscription des utilisateurs.

Florian Amette11 min de lecture

Les mots de passe sont les identifiants que les attaquants volent le plus souvent : hameçonnés, pulvérisés, capturés par enregistreur de frappe, extraits de la mémoire ou réutilisés depuis une autre fuite. Windows Hello for Business remplace le mot de passe à l'ouverture de session Windows par une paire de clés asymétriques générée sur l'appareil et protégée par son TPM. L'utilisateur déverrouille la clé avec un PIN ou un geste biométrique ; la clé privée ne quitte jamais l'appareil, et il n'y a rien de réutilisable à hameçonner.

Ce guide couvre les décisions qui comptent pour la sécurité : quel modèle d'approbation utiliser, comment imposer des clés adossées au matériel, comment définir la stratégie de PIN et comment confirmer que les utilisateurs et les administrateurs se connectent réellement avec Hello au lieu de revenir au mot de passe. Il s'appuie sur la série Protection des identifiants, où Credential Guard protège ce qui reste en mémoire.

Le fonctionnement en bref

Lors de l'inscription, Windows crée une paire de clés dans le TPM pour l'utilisateur et enregistre la clé publique auprès de Microsoft Entra ID (et, selon le modèle d'approbation, d'Active Directory). À l'ouverture de session, l'utilisateur déverrouille localement la clé privée et s'en sert pour s'authentifier : auprès d'Entra ID pour obtenir un Primary Refresh Token, et auprès d'Active Directory pour obtenir un ticket Kerberos. Le PIN est un geste de déverrouillage local, pas un secret partagé.

Deux propriétés en font tout l'intérêt :

  • Résistance à l'hameçonnage. Il n'y a aucun mot de passe à saisir dans une fausse page, et la clé ne fonctionne que sur l'appareil où elle a été créée.
  • Aucun secret réutilisable sur le réseau. Un attaquant qui capture le trafic ou relaie l'authentification n'obtient rien d'utilisable ailleurs.

Étape 1 : choisir le modèle d'approbation

Dans les environnements hybrides (AD + Entra ID), le modèle d'approbation détermine comment une ouverture de session Hello obtient un ticket Kerberos auprès de vos contrôleurs de domaine.

ModèleFonctionnement de l'authentification sur sitePrérequisUsage typique
Cloud Kerberos trustEntra ID émet un ticket partiel ; le DC sur site l'échange contre un TGT completObjet serveur Entra Kerberos dans AD, DC et clients pris en chargeRecommandé en hybride
Key trustClé publique synchronisée dans AD (msDS-KeyCredentialLink) ; le DC la valide avec PKINITCertificats sur les DC, synchronisation des clés par Entra ConnectEnvironnements qui ne peuvent pas utiliser cloud Kerberos trust
Certificate trustL'utilisateur reçoit un certificat émis via AD CSPKI d'entreprise, AD FS comme autorité d'inscription de certificats, authentification fédéréeScénarios nécessitant un certificat utilisateur, comme certains usages RDP

Cloud Kerberos trust supprime les deux difficultés habituelles : pas de PKI pour les clés Hello, et pas de délai d'inscription le temps que la clé publique se synchronise dans AD. Ses prérequis sont précis : Windows 10 21H2 avec KB5010415 ou Windows 11 21H2 avec KB5010414 ou ultérieur sur les clients ; contrôleurs de domaine sous Windows Server 2016 avec KB4534307, Server 2019 avec KB4534321, ou Server 2022/2025 ; suffisamment de contrôleurs de domaine accessibles en écriture dans chaque site où les utilisateurs s'authentifient ; et utilisateurs synchronisés dans Entra ID. Les membres des groupes intégrés privilégiés (Domain Admins et similaires) ne peuvent pas l'utiliser, car la stratégie de réplication des mots de passe de l'objet AzureADKerberos les exclut, et Microsoft déconseille de l'assouplir.

Les déploiements exclusivement cloud (joints à Entra, sans AD sur site) n'ont besoin d'aucun modèle d'approbation.

Étape 2 : créer l'objet Entra Kerberos (cloud Kerberos trust)

Cloud Kerberos trust repose sur un objet semblable à un contrôleur de domaine en lecture seule dans chaque domaine, qui permet à Entra ID d'émettre des tickets Kerberos partiels auxquels vos DC font confiance. Créez-le depuis une machine disposant du module AzureADHybridAuthenticationManagement, en tant que membre de Domain Admins (et d'Enterprise Admins pour la forêt), avec un compte Entra détenant le rôle Hybrid Identity Administrator :

PowerShell
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber
$domain = $env:USERDNSDOMAIN
$upn    = "admin@contoso.com"
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $upn
Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $upn

Cette opération crée un objet ordinateur AzureADKerberos dans l'UO Domain Controllers et un compte krbtgt_AzureAD. Traitez-les tous deux comme des actifs Tier 0 : la clé de krbtgt_AzureAD permet à qui la contrôle d'influer sur l'émission des tickets. Renouvelez-la périodiquement avec le même module (Set-AzureADKerberosServer -RotateServerKey) et intégrez les comptes Entra capables de la gérer dans votre modèle d'administration Tier 0.

Étape 3 : configurer la stratégie

Par stratégie de groupe, les paramètres se trouvent sous Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Hello for Business :

ParamètreValeurPourquoi
Use Windows Hello for BusinessEnabledActive l'inscription
Use cloud Kerberos trust for on-premises authenticationEnabledCloud Kerberos trust (à laisser non défini pour key trust ; Use certificate for on-premises authentication doit rester non configuré, sinon certificate trust l'emporte)
Use a hardware security deviceEnabled, en cochant Do not allow TPM 1.2Refuse les clés logicielles ; voir l'étape 4
Use biometricsEnabled ou Disabled selon votre politiqueReconnaissance faciale et empreinte digitale comme gestes de déverrouillage

Dans Intune, vous pouvez définir une valeur par défaut à l'échelle du locataire sous Devices > Enrollment > Windows Hello for Business, mais pour le contrôle et le ciblage, utilisez une stratégie Endpoint security > Account protection ou le catalogue de paramètres. Les deux utilisent le CSP PassportForWork, avec des paramètres comme Use Windows Hello For Business, Use Cloud Trust For On Prem Auth et Require Security Device. Évitez de configurer le même appareil à la fois par la valeur par défaut du locataire et par une stratégie ciblée, ce qui complique le dépannage. Si un appareil reçoit des paramètres Windows Hello for Business à la fois par stratégie de groupe et par Intune, la stratégie de groupe l'emporte et les paramètres Intune sont ignorés.

Étape 4 : exiger des clés adossées au TPM

Si un appareil n'a pas de TPM utilisable, Windows peut se rabattre sur une clé logicielle, bien plus facile à cibler pour un malware s'exécutant sous l'identité de l'utilisateur ou pour un attaquant en possession du disque. Use a hardware security device (Intune : Require Security Device) empêche ce repli : les appareils sans TPM adéquat n'inscrivent pas du tout Hello.

Vérifiez l'état du TPM avant de l'imposer, en particulier sur les anciens postes fixes et les VM :

PowerShell
Get-Tpm | Select-Object TpmPresent, TpmReady, TpmEnabled, ManufacturerVersion

Refuser le TPM 1.2 écarte des puces plus anciennes aux algorithmes plus faibles et aux antécédents de problèmes de micrologiciel. Le même TPM protège les clés BitLocker : un inventaire des TPM sert donc les deux projets.

Sur le matériel Windows 11 compatible, Enhanced Sign-in Security ajoute une isolation VBS pour les données biométriques et le chemin d'ouverture de session. Cette fonctionnalité dépend de capteurs et de micrologiciels précis : vérifiez la prise en charge des appareils avant d'en faire une exigence.

Étape 5 : définir la stratégie de PIN

La complexité du PIN se configure sous Computer Configuration > Policies > Administrative Templates > System > PIN Complexity (Intune : paramètres PIN Complexity dans le même profil de protection des comptes).

ParamètreRecommandéRemarques
Minimum PIN length6Valeur par défaut : 6. Allonger apporte peu, car le TPM limite les tentatives
Maximum PIN length127 (par défaut)Ne bridez pas les utilisateurs qui veulent un PIN plus long
Require digits / lowercase / uppercase / special charactersChiffres autorisés ; le reste facultatifLa complexité ajoute de la friction sans grand gain de sécurité sur une clé liée au TPM
ExpirationNot configuredLes changements de PIN forcés poussent les utilisateurs vers des motifs prévisibles
History0 sauf exigence d'auditPertinent uniquement si l'expiration est utilisée

La véritable protection contre les tentatives est l'anti-martèlement du TPM, qui verrouille après plusieurs PIN erronés. Conservez les valeurs par défaut sauf raison précise.

Activez la récupération du PIN (Use PIN Recovery dans la stratégie, EnablePinRecovery dans le CSP) pour que les utilisateurs puissent réinitialiser un PIN oublié via le service de réinitialisation de PIN de Microsoft, sans détruire ni réinscrire leur clé. Cela évite qu'un « j'ai oublié mon PIN » se transforme en réinitialisation de mot de passe par le support.

Étape 6 : les administrateurs et le mot de passe qui subsiste

Windows Hello ne supprime pas le mot de passe de l'utilisateur ; il lui évite de le saisir. Pour en tirer tout le bénéfice :

  • Activez l'expérience sans mot de passe, qui masque le fournisseur d'informations d'identification par mot de passe pour le dernier utilisateur connecté avec Hello ou une clé FIDO2 (Authentication/EnablePasswordlessExperience dans le Policy CSP). Elle nécessite Windows 11 22H2 avec KB5030310 ou ultérieur, la jonction Microsoft Entra et une gestion MDM ; les appareils en jonction hybride et joints à AD ne sont pas concernés.
  • Pour les administrateurs, inscrivez Hello pour le compte d'administration du tier sur le PAW, et utilisez l'accès conditionnel pour exiger une authentification résistante à l'hameçonnage pour les rôles d'administration dans Entra ID. Avec cloud Kerberos trust, les comptes Tier 0 membres des groupes intégrés privilégiés ne peuvent pas obtenir de TGT sur site par ce biais : prévoyez pour eux une autre méthode d'ouverture de session, comme les cartes à puce.
  • N'oubliez pas qu'une connexion RDP à un serveur exige généralement toujours un identifiant accepté par le serveur. Remote Credential Guard peut utiliser votre ouverture de session Hello, car les requêtes Kerberos restent sur le client ; testez votre combinaison précise.

Ce qui casse

  • Les appareils sans TPM utilisable ne s'inscrivent plus une fois les clés matérielles exigées.
  • Les utilisateurs qui ne se sont jamais connectés sur le réseau de l'entreprise, en key trust, peuvent devoir attendre la synchronisation des clés avant que les ressources sur site fonctionnent. Cloud Kerberos trust évite ce délai.
  • Les appareils partagés utilisés par de nombreuses personnes : chaque utilisateur inscrit sa propre clé, et le nombre d'inscriptions Hello par appareil est limité.
  • Les applications qui demandent directement le mot de passe Windows (anciens clients VPN, certaines applications métier) au lieu d'utiliser l'authentification intégrée.

Vérifier

  1. État de l'inscription. Exécutez dsregcmd /status en tant qu'utilisateur. Sous User State, NgcSet : YES signifie qu'une clé Hello existe. En cloud Kerberos trust, OnPremTgt : YES (sous SSO State) montre que l'utilisateur a reçu un ticket sur site via Entra ID.
  2. Événements d'inscription. Applications and Services Logs > Microsoft > Windows > User Device Registration > Admin indique si l'inscription a été lancée : événement 358 lorsque les prérequis sont satisfaits et 360 lorsqu'ils ne le sont pas, avec le prérequis en échec.
  3. Méthode d'ouverture de session. Dans les journaux de connexion Entra, filtrez les connexions Windows et vérifiez que la méthode d'authentification indique Windows Hello for Business. Une forte proportion de connexions par mot de passe sur des appareils inscrits signifie que les utilisateurs contournent Hello.
  4. Couverture matérielle. Avec la stratégie de périphérique de sécurité matériel activée, les appareils sans TPM prêt ne s'inscrivent pas du tout. Comparez la couverture NgcSet avec l'inventaire Get-Tpm de l'étape 4 pour repérer les appareils qui ne se sont jamais inscrits, sans bruit.

Liste de contrôle

  • Modèle d'approbation choisi ; cloud Kerberos trust en hybride sauf exception documentée
  • Objet AzureADKerberos créé dans chaque domaine et traité comme Tier 0, rotation de la clé planifiée
  • Hello activé par une seule source de stratégie, périphérique de sécurité matériel exigé, TPM 1.2 refusé
  • PIN de 6 minimum, sans expiration, récupération du PIN activée
  • Administrateurs inscrits sur les PAW ; authentification résistante à l'hameçonnage exigée pour les rôles d'administration
  • Expérience sans mot de passe activée là où elle est prise en charge
  • dsregcmd et événements 358/360 utilisés pour suivre la couverture des inscriptions

Windows Hello for Business retire de l'usage quotidien l'identifiant le plus volé sous Windows. Pour une définition à partager avec les parties prenantes, voir Windows Hello for Business dans le glossaire.

Questions fréquentes

Un code PIN Windows Hello est-il plus faible qu'un mot de passe ?

Non. Le PIN ne fait que déverrouiller une clé privée conservée dans le TPM de l'appareil ; il n'est jamais envoyé sur le réseau et ne sert à rien sur un autre appareil. La protection anti-martèlement du TPM limite les tentatives. Un mot de passe volé fonctionne depuis n'importe où, alors qu'un PIN volé ne fonctionne que sur cet appareil précis, entre les mains de l'attaquant. C'est pourquoi un PIN à six chiffres adossé à un TPM est plus robuste que la plupart des mots de passe.

Quel modèle d'approbation une organisation hybride doit-elle choisir ?

Cloud Kerberos trust, dans la plupart des cas. Il ne nécessite ni PKI pour les clés Hello, ni certificats sur les contrôleurs de domaine pour l'ouverture de session Hello, ni attente de synchronisation des clés, et Microsoft le recommande pour les déploiements hybrides. Key trust ou certificate trust restent pertinents dans des cas précis, comme les environnements exclusivement sur site ou les scénarios que cloud Kerberos trust ne prend pas en charge. Consultez la comparaison actuelle de Microsoft avant de décider.

Les administrateurs doivent-ils utiliser Windows Hello for Business ?

C'est un bon choix pour les administrateurs qui se connectent à leur propre poste d'administration sécurisé, car cela supprime les mots de passe saisis et les identifiants hameçonnables du travail d'administration quotidien. Inscrivez le compte d'administration du tier sur le PAW lui-même, pas sur un portable utilisateur. Pour les comptes d'administration qui doivent fonctionner sur de nombreux systèmes partagés, une clé de sécurité FIDO2 ou une carte à puce est souvent plus simple, car les clés Hello sont liées à un seul appareil.

Windows Hello for Business : modèles d'approbation et PIN

Guides associés