Aller au contenu

Configurer Windows Hello for Business sans mot de passe

Configurer Windows Hello for Business sans mot de passe

Section intitulée « Configurer Windows Hello for Business sans mot de passe »

Windows Hello for Business remplace le mot de passe quotidien par une clé cryptographique protégée par le poste et déverrouillée localement. Le gain est net contre le phishing et le rejeu, mais le prix est une dépendance forte à la gestion des terminaux, à Active Directory et aux procédures de récupération.

→ Lire l’explication complète de la marmotte

Windows Hello for Business, souvent abrégé WHfB, ne signifie pas « supprimer le mot de passe d’Active Directory ». Il crée une paire de clés par utilisateur et par terminal. La clé privée reste liée au matériel, idéalement à un TPM (Trusted Platform Module), et Active Directory valide l’identité via Kerberos, le protocole d’authentification à tickets de Microsoft.

Trois modèles existent :

  • Key trust : Active Directory stocke la clé publique dans l’attribut msDS-KeyCredentialLink de l’utilisateur. C’est le choix à retenir pour un annuaire local ou hybride qui n’a pas besoin d’authentification par certificat.
  • Certificate trust : le terminal obtient un certificat utilisateur auprès d’une PKI (Public Key Infrastructure), puis s’authentifie avec ce certificat. Ce modèle reste nécessaire si des applications historiques exigent une carte à puce virtuelle ou un certificat utilisateur précis.
  • Cloud Kerberos trust : Microsoft Entra ID délivre un ticket Kerberos utilisable contre Active Directory local. Ce modèle convient à un environnement hybride géré depuis le cloud, avec une dépendance supplémentaire au plan de contrôle Entra.

La recommandation est tranchée : déployer key trust pour un Active Directory majoritairement local, et réserver certificate trust aux dépendances applicatives démontrées. Introduire une PKI uniquement pour WHfB transforme une authentification moderne en chantier de certificats, de modèles, de listes de révocation et de serveurs oubliés derrière une baie. La PKI est un excellent outil, pas un rite initiatique.

Le compromis central est le suivant : WHfB élimine la transmission répétée d’un secret réutilisable, mais déplace la confiance vers le terminal enrôlé et son matériel. Une identité compromise via un poste administré de travers reste compromise. Le phishing recule, le poste douteux ne devient pas vertueux par magie.

Pour réduire les chemins d’attaque historiques, combiner ce déploiement avec le durcissement de NTLM. Tant que NTLM (NT LAN Manager) demeure une voie normale d’authentification, un environnement conserve une surface de rejeu et de relais qui contourne une part du bénéfice attendu.

Le modèle key trust exige des contrôleurs de domaine Windows Server 2016 ou plus récents, entièrement corrigés, ainsi qu’un schéma Active Directory compatible avec l’attribut msDS-KeyCredentialLink. Un contrôleur de domaine est le serveur qui valide les identités et délivre les tickets Kerberos. Vérifier ce point avant toute stratégie de groupe : une interface de configuration ne corrige pas un annuaire trop ancien.

Les postes doivent utiliser Windows 10 version 22H2 ou Windows 11, édition Pro, Enterprise ou Education, joints au domaine et gérés par stratégie de groupe ou par une plateforme de gestion des appareils. Le TPM 2.0 doit être activé dans le micrologiciel, prêt dans Windows et détenu par le système d’exploitation. Un TPM désactivé est un coffre-fort très économique : il ne contient rien.

Prévoir également :

  • DNS (Domain Name System) interne fonctionnel vers les contrôleurs de domaine ;
  • synchronisation horaire correcte, car Kerberos refuse les écarts de temps significatifs ;
  • accès réseau aux contrôleurs de domaine lors du premier provisionnement et des ouvertures de session hors cache ;
  • un compte administrateur de récupération distinct de l’identité quotidienne ;
  • un groupe pilote contenant des utilisateurs et terminaux représentatifs, y compris les profils nomades et les opérateurs d’infrastructure.

Ne pas viser immédiatement les comptes à privilèges. Les administrateurs de domaine, les comptes d’exploitation et les comptes de secours suivent des règles propres : bastions dédiés, authentificateurs matériels lorsque requis, séparation des rôles. WHfB améliore l’ouverture de session interactive, il ne remplace pas une architecture d’administration.

La désactivation du LDAP (Lightweight Directory Access Protocol) anonyme et des liaisons simples en clair reste une mesure connexe obligatoire. Une identité sans mot de passe ne justifie pas un annuaire bavard. Voir désactiver les binds LDAP faibles.

Créer d’abord une unité d’organisation réservée aux postes pilotes et une unité d’organisation pour les utilisateurs pilotes. Lier la stratégie aux postes : le composant WHfB s’exécute dans le contexte du terminal, pas dans celui du contrôleur de domaine.

La stratégie à activer est Use Windows Hello for Business dans Computer Configuration > Administrative Templates > Windows Components > Windows Hello for Business. Pour un modèle key trust, laisser désactivée l’option imposant un certificat. Configurer aussi une longueur minimale de code confidentiel d’au moins six caractères, exiger les chiffres et éviter les politiques absurdes qui forcent une réinitialisation fréquente.

Le code confidentiel, ou PIN (Personal Identification Number), n’est pas un mot de passe Active Directory réduit à quatre chiffres. Il déverrouille localement la clé privée. Le voler sans le terminal et sans la clé matérielle ne suffit pas. En revanche, autoriser 123456 parce que « le TPM protège tout » reste une idée de présentation vendeur, pas une politique de sécurité.

Voici un exemple PowerShell reproductible pour créer et lier une stratégie de pilote. L’exécution requiert le module GroupPolicy et des droits de création de stratégie de groupe.

Fenêtre de terminal
# Créer la stratégie WHfB réservée au groupe pilote.
$gpo = New-GPO -Name "WHfB-KeyTrust-Pilot"
# Activer Windows Hello for Business sur les ordinateurs ciblés.
Set-GPRegistryValue -Name $gpo.DisplayName `
-Key "HKLM\SOFTWARE\Policies\Microsoft\PassportForWork" `
-ValueName "Enabled" -Type DWord -Value 1
# Lier la stratégie à l'unité d'organisation des postes pilotes.
New-GPLink -Name $gpo.DisplayName `
-Target "OU=Postes-Pilotes,DC=exemple,DC=local"
# Limiter l'application aux membres du groupe de sécurité pilote.
Set-GPPermission -Name $gpo.DisplayName `
-TargetName "GG-WHfB-Pilote" -TargetType Group -PermissionLevel GpoApply

Après application de stratégie et ouverture de session avec le mot de passe existant, Windows demande l’enrôlement. Tester ensuite une fermeture complète de session, un redémarrage, une connexion réseau indisponible et une connexion à une ressource de fichiers. Tester uniquement la fenêtre d’enrôlement ne valide rien d’autre que la fenêtre d’enrôlement. Elle est généralement excellente à ce métier.

Pour le modèle certificate trust, ne pas improviser les modèles de certificats. Il faut une autorité de certification d’entreprise, un modèle destiné à WHfB, l’auto-enrôlement, la publication des points de révocation et une continuité de service de la PKI. La page PKI et TLS couvre les dépendances d’infrastructure qui deviennent alors non négociables.

Surface d’attaque et limites de l’authentification sans mot de passe

Section intitulée « Surface d’attaque et limites de l’authentification sans mot de passe »

WHfB réduit le phishing de mot de passe, le bourrage d’identifiants et le rejeu d’un secret statique. La clé privée ne doit pas quitter le TPM, et Kerberos utilise une preuve cryptographique plutôt que le mot de passe de l’utilisateur.

Le mécanisme ne garantit pas :

  • la sécurité d’un poste déjà compromis avec des privilèges administrateur ;
  • la protection contre une approbation frauduleuse pendant l’enrôlement initial ;
  • la sécurité des applications qui continuent à demander un mot de passe ou utilisent NTLM ;
  • la révocation instantanée des sessions déjà ouvertes ;
  • la résistance à un attaquant ayant le terminal, le code confidentiel et une capacité à contourner les protections matérielles.

Un code confidentiel local limite le vol à distance, mais une attaque physique reste possible. Activer BitLocker avec chiffrement de disque lié au TPM, imposer Secure Boot, protéger l’accès au micrologiciel par mot de passe administrateur et interdire le démarrage sur média externe. Sans ces contrôles, le terminal devient le maillon qui traîne derrière le cadenas.

Le phishing se déplace aussi vers l’enrôlement : un attaquant qui obtient une session initiale avec mot de passe peut inscrire son propre terminal ou sa propre clé. Exiger une authentification multifacteur pour l’enrôlement hybride, surveiller les modifications de msDS-KeyCredentialLink et alerter sur l’ajout inattendu de clés. Les attributs d’identité méritent la même attention que les groupes privilégiés.

Conserver le mot de passe Active Directory pendant la transition, mais retirer les usages interactifs ordinaires par politique et par communication opérationnelle. Le mot de passe demeure souvent nécessaire pour la récupération, certaines tâches hors ligne et des dépendances anciennes. Le supprimer trop tôt ne crée pas du passwordless, il crée un ticket d’incident.

En cas de perte ou de vol d’un terminal, désactiver l’objet ordinateur, révoquer l’accès de l’utilisateur si nécessaire et supprimer la clé enregistrée pour ce terminal. Dans le modèle certificate trust, révoquer également le certificat et publier une liste de révocation accessible. La révocation d’un certificat ne ferme pas les sessions déjà établies : il faut aussi invalider les tickets et couper les accès exposés.

Superviser au minimum :

  • les échecs et succès Kerberos sur les contrôleurs de domaine ;
  • les événements d’enrôlement WHfB sur les postes ;
  • les changements d’attributs de clé des utilisateurs ;
  • l’état du TPM, BitLocker et Secure Boot dans l’outil de gestion de parc ;
  • les exceptions NTLM restantes, avec propriétaire et date de suppression.

Sauvegarder l’état Active Directory, la PKI si elle existe, les stratégies de groupe et les procédures de récupération. Une restauration autoritaire d’Active Directory peut restaurer des attributs de clés obsolètes ; valider la cohérence des identités après reprise. La sauvegarde n’est pas une décoration de conformité, même si certains tableurs la traitent avec une profondeur philosophique impressionnante.

Sans Windows Hello for Business, l’ouverture de session repose sur un secret que l’utilisateur saisit au clavier chaque jour. Un enregistreur de frappe ou un faux écran de verrouillage suffit alors à le capturer, et ce secret reste valable depuis n’importe quel poste, puisqu’il n’est lié à aucun TPM ni à aucun terminal enrôlé. Un mot de passe réutilisé sur un service externe puis divulgué ouvre également le compte Active Directory. Les contrôleurs de domaine restent exposés à la pulvérisation de mots de passe courants sur de nombreux comptes, une attaque qui reste sous le seuil de verrouillage de chaque compte. Côté détection, une connexion avec un mot de passe volé ne se distingue pas d’une connexion légitime : aucune clé liée à un appareil ne permet de repérer un terminal inconnu.

Windows Hello for Business permet d’ouvrir une session sur un ordinateur sans retaper le mot de passe du compte d’entreprise. Au départ, l’utilisateur ouvre encore sa session avec son mot de passe. L’ordinateur crée alors deux clés liées entre elles. La première reste dans une puce de sécurité de l’ordinateur et ne doit pas en sortir. La seconde est enregistrée dans l’annuaire de l’entreprise, qui contient les comptes et les droits.

Pour utiliser la clé cachée dans l’ordinateur, l’utilisateur prouve sa présence avec un code personnel, une empreinte ou la reconnaissance du visage. Cette vérification reste locale à l’ordinateur : le code personnel n’est pas envoyé sur le réseau. L’ordinateur demande ensuite à l’annuaire de confirmer l’identité. L’annuaire vérifie la preuve produite avec la clé publique enregistrée, puis autorise l’accès aux services.

Si l’ordinateur est perdu, son accès doit être retiré de l’annuaire et le compte peut être bloqué. Si la puce de sécurité est absente ou inactive, la protection est moins bonne et le déploiement doit être arrêté. Si le réseau, l’heure ou les serveurs d’identité sont indisponibles, certaines connexions peuvent échouer. Enfin, cette méthode ne protège pas un ordinateur déjà contrôlé par un attaquant : elle évite surtout de transmettre et de réutiliser le mot de passe chaque jour.

À lire aussi

Pages voisines

: les deux pages se citent l’une l’autre.