Windows Hello for Business¶

WHfB : pourquoi remplacer les mots de passe¶

Le vrai problème n'est pas "le mot de passe faible"¶

Le problème n'est pas uniquement la longueur du mot de passe.

Le problème, c'est qu'un mot de passe est un secret partagé.

Dès qu'il est connu par l'utilisateur, il peut être :

• saisi sur un faux portail
• intercepté sur un poste compromis
• rejoué sur plusieurs services
• transformé en hash réutilisable dans une attaque latérale

Autrement dit :

vous ne défendez pas seulement une chaîne de caractères.

Vous défendez une matière première d'attaque.

Le modèle de menace à garder en tête¶

Trois familles d'attaque expliquent à elles seules pourquoi WHfB existe.

WHfB, en une phrase opérationnelle¶

WHfB repose sur deux éléments.

Le premier :

une clé privée créée sur l'appareil et idéalement protégée par le TPM.

Le second :

un geste local qui autorise l'usage de cette clé.

Ce geste peut être :

• un PIN
• une empreinte
• une reconnaissance faciale

Le point critique :

le geste n'est pas le secret de réseau.

Le PIN ne "voyage" pas.

L'empreinte ne "voyage" pas.

Le visage ne "voyage" pas.

L'authentification réseau s'appuie sur la clé et sur le modèle de confiance choisi.

Ce que le TPM apporte vraiment¶

Le TPM ne rend pas une architecture magique.

Il rend l'extraction du matériel cryptographique beaucoup plus difficile.

En pratique :

• la clé privée est liée au matériel
• les protections anti-bruteforce sont locales
• la copie simple du secret sur un autre poste devient non triviale

Sur un parc moderne Windows 11, c'est la ligne de base attendue.

Si vous autorisez WHfB sans TPM, vous perdez précisément une partie de la promesse de sécurité qui justifie le projet.

Le PIN n'est pas un mini mot de passe¶

C'est une confusion classique.

Le mot de passe AD et le PIN WHfB ne protègent pas la même chose.

Le mot de passe sert à authentifier un utilisateur contre une identité.

Le PIN sert à déverrouiller localement l'usage d'une clé déjà liée à l'appareil.

Conséquence pratique :

• un mot de passe faible met potentiellement en danger plusieurs services
• un PIN compromis ne suffit pas sans l'appareil
• un PIN de 6 chiffres peut être acceptable là où un mot de passe de 6 caractères ne l'est pas

Ce n'est pas parce que le PIN est "court".

C'est parce que son périmètre d'abus n'est pas le même.

Password, NTLM, Kerberos, WHfB : ne mélangez pas tout¶

Ces termes se croisent souvent dans les discussions de migration.

Ils ne sont pourtant pas équivalents.

Ce que vous gagnez côté exploitation¶

Avec WHfB bien déployé :

• moins de tickets liés aux oublis de mot de passe
• moins de dépendance aux portails de reset d'urgence
• moins de surface pour le phishing classique
• un meilleur alignement avec Conditional Access et les scénarios passwordless

Ce que vous ne gagnez pas automatiquement¶

WHfB n'efface pas d'un coup :

• les applications legacy en NTLM
• les comptes privilégiés mal gérés
• les postes sans TPM
• les workflows RDP/VDI qui attendent encore un certificat ou un autre mécanisme

WHfB n'est pas une baguette magique.

C'est un changement de primitive d'authentification.

Décision simple pour un admin¶

Si votre priorité est :

• réduire le phishing utilisateur
• diminuer la dépendance au mot de passe
• rester compatible avec un AD hybride moderne

alors WHfB mérite d'être traité comme un chantier de sécurité, pas comme une simple option de confort Windows 11.

Les trois modèles de déploiement¶

Première règle : choisissez le modèle avant la GPO¶

Beaucoup d'échecs WHfB viennent d'un ordre inversé.

L'équipe active la GPO.

Puis elle se demande comment le poste doit authentifier l'utilisateur on-prem.

C'est trop tard.

Le bon ordre est :

1. choisir le modèle de confiance
2. valider les prérequis d'infrastructure
3. déployer la GPO ou la policy MDM

Tableau comparatif¶

1. Key Trust¶

Key Trust est le modèle historique "simple" côté PKI.

Il n'exige pas de certificat utilisateur WHfB.

En revanche, il s'appuie sur :

• la synchronisation de clé publique
• l'attribut msDS-KeyCredentialLink
• des DC compatibles

Ce modèle reste pertinent dans deux cas :

• environnement AD on-prem pur
• besoin de rester hors dépendance cloud pour le plan principal

Mais sur un parc moderne hybride, ce n'est plus le premier choix.

2. Certificate Trust¶

Certificate Trust existe pour les environnements qui doivent rester compatibles avec :

• des applications qui veulent un certificat
• des scénarios de type smart card
• des contraintes historiques autour de la PKI et d'AD FS

Il fonctionne.

Mais il coûte plus cher à opérer.

Pourquoi ?

Parce que vous ajoutez :

• une chaîne PKI
• une logique d'inscription de certificats
• des points de contrôle supplémentaires

Si vous n'avez pas un besoin explicite de certificat, ce modèle complexifie souvent inutilement le projet.

3. Cloud Kerberos Trust¶

Cloud Kerberos Trust est le modèle à regarder en premier pour un environnement hybride moderne.

Microsoft le présente aujourd'hui comme le modèle recommandé face à Key Trust quand vous n'avez pas d'exigence de certificat.

Ce qu'il simplifie :

• pas de PKI à déployer pour WHfB
• pas de synchronisation de clés publiques WHfB vers AD pour l'accès on-prem
• meilleure cohérence avec Microsoft Entra ID et les déploiements Windows 11

Recommandation pratique pour WS2022 + Win11¶

Si votre socle cible est :

• Windows Server 2022
• Windows 11
• Hybrid Join
• Microsoft Entra Connect Sync

alors la recommandation par défaut est :

Cloud Kerberos Trust.

Ne gardez Key Trust qu'avec une raison claire.

Ne partez sur Certificate Trust qu'avec une exigence métier documentée.

Les prérequis DC à ne pas rater¶

Deux idées doivent rester séparées dans votre tête.

msDS-KeyCredentialLink

Cet attribut sert à stocker les informations liées au credential pour les scénarios Key Trust et pour les contrôles d'inventaire d'objets déjà enrôlés.

Il fait partie des éléments que vous devez connaître même si vous ciblez Cloud Kerberos Trust, ne serait-ce que pour comprendre l'existant.

Correctifs DC

La documentation Microsoft actuelle publie des prérequis minimums pour Cloud Kerberos Trust :

• Windows Server 2016 avec le KB publié pour ce scénario
• Windows Server 2019 avec le KB publié pour ce scénario
• Windows Server 2022 ou plus récent

Sur un parc 2026, la bonne lecture opérationnelle est simple :

si vous avez encore des DC 2016 ou 2019, vérifiez explicitement qu'ils portent les correctifs requis par la documentation WHfB en vigueur.

Pourquoi le brief "KB4534307" mérite vérification¶

Vous verrez parfois circuler des numéros de KB légèrement différents selon les billets, les traductions ou les notes de migration.

Ne recopiez pas un KB de mémoire dans votre runbook.

Vérifiez la page Microsoft Learn active au moment du déploiement.

C'est particulièrement vrai si vous opérez un domaine mixte 2016/2019/2022.

Cloud Kerberos Trust n'est pas "pour tout le monde"¶

Deux garde-fous importants :

• il ne répond pas au besoin de certificat on-prem si vous avez des applications qui l'exigent
• il n'est pas le bon modèle pour un pur AD on-prem sans dépendance Entra

Autrement dit :

recommandé ne veut pas dire universel.

Mini aide-mémoire¶

Erreur de design fréquente¶

Vouloir faire cohabiter les trois modèles "au cas où".

Mauvaise idée.

Vous devez choisir un modèle principal.

Ensuite :

• documenter les exceptions
• piloter les OU pilotes
• éviter les policies contradictoires

Configuration GPO pour WHfB¶

Le chemin GPMC à retenir¶

Le nœud principal est :

Computer Configuration > Administrative Templates > Windows Components > Windows Hello for Business

Une partie des réglages PIN n'est pas dans ce nœud.

Ils sont sous :

Computer Configuration > Administrative Templates > System > PIN Complexity

Si vous ne séparez pas ces deux zones, vous allez croire qu'il "manque" des paramètres.

Table des paramètres clés¶

Lecture correcte de ce tableau¶

Ne lisez pas ce tableau comme un copier-coller aveugle.

Lisez-le comme une matrice de posture.

Exemple :

si vous ciblez Cloud Kerberos Trust, alors :

• Use cloud Kerberos trust for on-premises authentication = Enabled
• Use certificate for on-premises authentication = Not Configured ou Disabled

Si vous activez les deux à la fois, le comportement ne sera pas celui que vous attendez.

La documentation Microsoft actuelle indique que le mode Certificate Trust prend la priorité sur Cloud Kerberos Trust quand la policy certificat est activée.

Use Windows Hello for Business¶

Cette setting fait plus que "permettre l'option".

En Enabled, vous forcez l'enrôlement dans le périmètre visé.

En Not Configured, vous laissez plus de latitude au poste et à l'utilisateur.

Pour un déploiement d'entreprise, l'ambiguïté n'aide pas.

Si vous voulez industrialiser, activez explicitement.

Use a hardware security device¶

Sur le terrain, c'est la policy qui sépare un vrai déploiement de sécurité d'un déploiement "ça marche sur mon portable".

Activez-la.

Puis vérifiez les TPM.

Ne poussez pas cette GPO à l'échelle si votre parc mélange :

• vieux portables sans TPM utilisable
• TPM désactivés en firmware
• machines virtuelles non alignées avec votre politique

Enable enhanced anti-spoofing¶

Cette policy concerne surtout la biométrie faciale.

Elle durcit le contrôle des capteurs compatibles.

Sur Windows 11, c'est cohérent avec une posture moderne.

Mais gardez en tête l'effet réel :

certains matériels biométriques plus anciens peuvent cesser d'être utilisables.

Use PIN Recovery¶

Sans PIN Recovery, l'expérience oubli de PIN devient plus brutale.

L'utilisateur peut devoir recréer son conteneur selon le contexte et repasser certaines étapes.

Avec PIN Recovery activé, vous améliorez :

• l'autonomie utilisateur
• la continuité opérationnelle
• la réduction des tickets support basiques

Minimum PIN length¶

Le minimum recommandé ici est 6.

Ce n'est pas une concession faible.

C'est une valeur cohérente avec le fait que le PIN ne s'utilise qu'en local sur l'appareil lié.

Si vous montez plus haut, faites-le pour une raison documentée :

• exigences réglementaires
• population privilégiée
• borne partagée avec contrainte spécifique

Politique PIN et politique mot de passe : deux mondes¶

Ne reliez pas mentalement le PIN aux règles du mot de passe AD.

La politique de mot de passe agit sur :

• l'authentification de compte
• la rotation du secret partagé
• la surface d'exposition du compte dans d'autres services

La politique PIN agit sur :

• la déverrouillage local du credential WHfB
• la complexité locale de ce geste
• le comportement de l'expérience utilisateur

Vous pouvez donc avoir :

• mot de passe AD long et complexe
• PIN de 6 caractères

sans incohérence de sécurité.

Où configurer la complexité PIN¶

Le piège le plus fréquent :

les admins cherchent tous les réglages WHfB dans le nœud Windows Hello for Business.

Or la complexité du PIN se gère surtout sous :

Computer Configuration > Administrative Templates > System > PIN Complexity

Paramètres typiques à revoir :

• Minimum PIN length
• Maximum PIN length
• Require digits
• Require uppercase letters
• Require lowercase letters
• Require special characters
• History
• Expiration

Recommandation d'exploitation¶

Pour la majorité des parcs bureautiques :

• minimum 6
• chiffres autorisés
• pas d'obligation de caractères spéciaux
• pas d'expiration artificielle du PIN sauf exigence réglementaire forte

Pourquoi ?

Parce qu'un PIN trop "administratif" casse l'adoption sans bénéfice proportionnel.

!!! warning "Conflit MDM"¶

Filtrage et ciblage¶

Le bon déploiement GPO WHfB ne vise pas "tout le domaine" le premier jour.

Utilisez :

• une OU pilote
• ou un filtrage par security group

L'objectif n'est pas uniquement le confort.

L'objectif est de contrôler :

• le volume de TPM non conformes
• les incidents biométriques
• les applications métiers qui tolèrent mal le changement de méthode d'ouverture de session

Petite checklist avant lien GPO¶

Avant de lier la GPO :

• Central Store à jour avec les bons Passport.admx / Passport.adml
• parc pilote identifié
• modèle de confiance documenté
• conflit Intune exclu
• support prêt à répondre au premier enrôlement

Déploiement étape par étape (Cloud Kerberos Trust)¶

Logique générale¶

Le déploiement Cloud Kerberos Trust tient en une idée simple :

vous préparez d'abord le côté identité.

Ensuite seulement vous ouvrez l'enrôlement côté poste.

Si vous inversez l'ordre, les utilisateurs voient l'invite WHfB sans que l'infrastructure ne soit prête.

Résultat :

• enrôlements partiels
• messages peu parlants
• faux diagnostics "TPM" alors que le problème est côté trust

!!! example "Pas à pas"¶

Prerequis infrastructure pour WHfB Cloud Kerberos Trust¶

Le but n'est pas de faire un audit exhaustif du connecteur.

Le but est de répondre à trois questions :

• la synchro identités fonctionne-t-elle ?
• la version est-elle dans une branche supportée ?
• les objets utilisateurs et appareils sont-ils correctement présents côté Entra ?

Le libellé historique "Azure AD Connect" existe encore dans beaucoup de runbooks.

Le produit s'appelle désormais Microsoft Entra Connect Sync.

Gardez cette correspondance en tête quand vous lisez une vieille procédure.

Étape 2 : créer l'objet Microsoft Entra Kerberos¶

Cloud Kerberos Trust s'appuie sur Microsoft Entra Kerberos.

Concrètement, vous devez créer l'objet serveur Kerberos correspondant dans le domaine.

Exemple de séquence :

# Exemple de principe : adaptez les modules et le compte d'administration à votre contexte
Import-Module AzureADHybridAuthenticationManagement

$domain = "corp.contoso.com"
$upn    = "admin-whfb@contoso.com"

Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $upn

Après exécution, vérifiez qu'un objet de type AzureADKerberos existe côté domaine.

Étape 3 : créer la GPO dédiée¶

N'ajoutez pas WHfB dans une énorme GPO de sécurité générique.

Créez une GPO dédiée, par exemple :

WHFB-CloudKerberosTrust-Pilot

Pourquoi ?

Parce que vous voulez pouvoir :

• la lier ou la délier vite
• la filtrer proprement
• lire gpresult sans pollution

Étape 4 : vérifier les TPM¶

Un pilote WHfB sans contrôle TPM est une perte de temps.

Sur chaque poste pilote :

Get-Tpm

Lecture minimale :

• TpmPresent = True
• TpmReady = True
• ManagedAuthLevel cohérent avec votre configuration

Si le TPM n'est pas prêt, n'accusez pas la GPO.

Le problème est plus bas dans la pile.

Étape 5 : appliquer la policy¶

Sur le poste cible :

gpupdate /force
shutdown /r /t 0

L'oubli du redémarrage fausse beaucoup de validations.

Vous croyez tester l'état final.

En réalité, vous testez un état intermédiaire.

Étape 6 : vérifier le join et le prérequis cloud trust¶

Avant même de regarder HelloForBusiness, vérifiez le statut d'inscription :

dsregcmd /status

Cherchez au minimum :

• AzureAdJoined ou DomainJoined selon le scénario attendu
• DeviceAuthStatus
• SSO State
• MdmUrl si vous mélangez avec Intune

Sur un poste Hybrid Join, l'absence de prérequis côté Entra Kerberos se voit souvent ici avant même que l'utilisateur ne vous remonte "le PIN ne marche pas".

Étape 7 : laisser l'utilisateur s'enrôler¶

L'enrôlement WHfB démarre après ouverture de session si les prérequis sont bons.

Expliquez à l'utilisateur pilote ce qu'il va voir :

• proposition de configurer un PIN
• éventuellement proposition biométrique
• demande de MFA selon le flux

Si vous ne préparez pas l'utilisateur, il annule l'assistant.

Puis vous diagnostiquez un "échec technique" qui est en fait un refus humain.

Vérification AD côté parc¶

Pour repérer les objets qui portent déjà des données d'enrôlement :

Get-ADComputer -Filter * -Properties msDS-KeyCredentialLink |
    Where-Object { $_.'msDS-KeyCredentialLink' } |
    Select-Object Name, DistinguishedName

Ce script est surtout utile pour :

• inventorier un existant Key Trust
• repérer des objets déjà passés par un enrôlement
• préparer une migration ou un nettoyage

Pour Cloud Kerberos Trust, ne tirez pas de conclusion abusive :

l'absence de msDS-KeyCredentialLink n'est pas, à elle seule, une preuve d'échec du modèle.

Ce que vous devez valider côté poste¶

Validation minimale :

Séquence de déploiement recommandée¶

Ne ciblez pas 500 postes d'un coup.

Découpez en anneaux :

1. IT / admins non privilégiés
2. support de proximité
3. population bureautique standard
4. portables VIP
5. comptes sensibles avec exigences spécifiques

Cas à sortir du premier pilote¶

Excluez du premier anneau :

• comptes admin Tier 0
• VDI/RDS avec exigences RDP particulières
• postes sans biométrie mais avec contraintes métiers de smart card
• utilisateurs qui changent de poste en permanence sans modèle clair

Point d'attention RDP / VDI¶

Cloud Kerberos Trust ne couvre pas tous les scénarios RDP/VDI fournis comme credential.

Si votre besoin principal est le RDP avec credential fourni au serveur distant, vérifiez le design cible avant généralisation.

Ce n'est pas un bug.

C'est une limite de scénario à traiter en amont.

Après le pilote¶

Quand le pilote est stable :

• conservez la GPO dédiée
• élargissez le groupe de sécurité
• gardez les comptes à contraintes fortes dans une phase séparée

Diagnostic et event IDs¶

Commencez par le journal correct¶

Pour WHfB, ne cherchez pas au hasard dans le journal Système.

Allez directement dans :

Applications and Services Logs > Microsoft > Windows > HelloForBusiness > Operational

La source visible est généralement :

Microsoft-Windows-HelloForBusiness

Table des event IDs utiles¶

Comment lire ces événements¶

358

Bonne nouvelle.

Le poste a réussi l'enrôlement.

Votre travail n'est pas fini pour autant.

Vérifiez encore :

• que l'utilisateur arrive bien à se reconnecter
• que l'accès aux ressources on-prem fonctionne
• que le support sait distinguer oubli de PIN et problème d'enrôlement

360

Ne concluez pas trop vite à un problème "Hello".

Commencez par les fondamentaux :

• TPM absent ou non prêt
• GPO non appliquée
• mauvais modèle de trust
• poste pas correctement Hybrid Join

362

C'est un signal utile en exploitation.

Il confirme qu'un scénario de récupération de PIN a fonctionné.

Si vous voyez beaucoup de 362 après déploiement, cela peut aussi indiquer :

• une mauvaise préparation utilisateur
• une politique PIN trop exigeante
• une mauvaise compréhension du geste attendu

100

Celui-ci oriente directement vers la gouvernance de policy.

Posez-vous tout de suite la question :

qui pilote réellement WHfB sur ce poste ?

Commandes utiles de diagnostic¶

Get-WinEvent -LogName "Microsoft-Windows-HelloForBusiness/Operational" -MaxEvents 20 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message

gpresult /r /scope computer

Get-Tpm

dsregcmd /status

Ordre de diagnostic recommandé¶

Quand un poste échoue :

1. Get-Tpm
2. gpresult
3. dsregcmd /status
4. Get-WinEvent

Cet ordre évite de passer vingt minutes dans l'Event Viewer pour découvrir ensuite que le TPM est désactivé dans l'UEFI.

Symptômes classiques et lecture rapide¶

N'oubliez pas la partie humaine¶

Un ticket "WHfB ne marche pas" couvre souvent des réalités différentes :

• l'utilisateur a annulé l'enrôlement
• il a oublié son PIN
• la webcam n'est pas compatible anti-spoofing
• il est hors ligne de vue DC lors du premier usage en Hybrid Join

Votre runbook support doit distinguer ces cas.

Sinon tout finit en "bug WHfB".

!!! check "Point de contrôle"¶

Décision d'exploitation après incident¶

Si vous devez interrompre un pilote :

• retirez le groupe de sécurité cible
• laissez la GPO intacte pour analyse
• documentez le motif exact

Ne "réparez" pas en empilant plus de paramètres.

WHfB se corrige rarement par ajout de complexité.

Il se corrige en retirant l'ambiguïté :

• modèle clair
• prérequis clairs
• policy claire

FIDO2, Passkeys et l'avenir du passwordless¶

WHfB n'est pas le seul mécanisme passwordless à piloter. Les clés FIDO2, les passkeys device-bound et les passkeys synchronisées couvrent des besoins différents. La bonne question n'est pas "FIDO2 ou WHfB ?", mais : quel facteur, quel appareil et quel niveau de contrôle entreprise ?

FIDO2 Security Keys vs WHfB¶

Activer FIDO2 pour le sign-in Windows¶

HKLM\SOFTWARE\Policies\Microsoft\FIDO

Chemin GPO : Configuration ordinateur > Modèles d'administration > Système > Ouverture de session > Activer la connexion par clé de sécurité

Prérequis à valider :

• Windows 10 1903+ ou Windows 11 ;
• Microsoft Entra ID hybrid ou cloud-only selon le scénario ;
• clé FIDO2 certifiée, FIPS si votre référentiel sécurité l'exige ;
• méthode FIDO2 activée dans Entra ID ;
• provisioning par l'utilisateur dans My Security Info, pas par GPO.

Passkeys : device-bound vs synced¶

Une device-bound passkey est proche du modèle FIDO2 : le secret reste lié à l'appareil. Une synced passkey est synchronisée par un provider comme iCloud Keychain, Google Password Manager ou 1Password. Les deux sont résistants au phishing, mais ils n'ont pas le même niveau de contrôle entreprise.

Windows 11 23H2+ expose un support passkey natif dans Windows Hello. Le contrôle entreprise passe surtout par Entra ID, Intune, les navigateurs et les providers autorisés.

HKLM\SOFTWARE\Policies\Microsoft\Passkeys

Recommandation entreprise¶

Pour une entreprise, privilégiez :

1. WHfB Cloud Kerberos Trust pour le poste principal ;
2. FIDO2 Security Keys pour les comptes sensibles, le break glass et les scénarios sans biométrie ;
3. passkeys synchronisées uniquement après validation du provider, du stockage et de la récupération.