La promesse : ouvrir la session sans mot de passe, conserver le SSO local

Windows Hello for Business (WHfB) remplace le geste quotidien du mot de passe par une clé asymétrique liée à l’appareil, déverrouillée par NIP ou biométrie. Cloud Kerberos Trust permet ensuite à un utilisateur hybride d’accéder aux ressources Active Directory intégrées à Kerberos sans déployer de certificats de connexion pour les utilisateurs et les contrôleurs de domaine. Ce n’est pas une suppression automatique du mot de passe du compte AD : conservez une méthode de récupération, protégez le mot de passe sous-jacent et mesurez les usages résiduels.

Le scénario : une employée sur un poste joint à Microsoft Entra ouvre Windows avec son NIP WHfB, puis accède à un partage de fichiers local par VPN. Microsoft Entra ID émet un ticket Kerberos partiel avec le PRT; le poste contacte un contrôleur de domaine inscriptible pour obtenir un TGT complet et des tickets de service. Sans connectivité vers AD, ce SSO local ne fonctionne pas, même si l’ouverture de session Windows hors ligne peut fonctionner selon l’état du poste.

Cloud trust, key trust et certificate trust : choisir le bon modèle

« Sans PKI complexe » ne veut pas dire « aucun certificat dans l’entreprise ». Un VPN ou Wi-Fi EAP-TLS, S/MIME ou une application exigeant un certificat utilisateur peut toujours nécessiter une PKI ou une autre solution de distribution de certificats. La stratégie « Use certificate for on-premises authentication » prévaut sur cloud trust si les deux sont configurées; ne superposez pas les modèles au hasard.

Modèle	Authentification AD	Certificats pour WHfB	À retenir
Cloud Kerberos trust	Ticket partiel Entra, TGT complet émis par le DC	Aucun certificat de connexion WHfB	Préféré en hybride sans besoin de certificat d’authentification
Key trust	Clé publique utilisateur et authentification par certificat du DC	PKI nécessaire pour les DC	Modèle existant; transition cloud trust possible
Certificate trust	Certificat utilisateur	PKI, certificats utilisateurs et composants associés	Nécessaire si l’authentification par certificat est requise

Avant de commencer : liste de prérequis et cas d’exclusion

WHfB cloud trust n’exige pas en lui-même une licence Entra ID P1/P2; Intune, l’inscription automatique MDM ou certaines politiques Conditional Access ont leurs propres licences. Évitez de promettre un coût nul sans examiner les dépendances. La compatibilité des clients et des contrôleurs dépend des versions et des mises à jour minimales indiquées par Microsoft.

Identités AD synchronisées vers Microsoft Entra ID : contrôler notamment onPremisesSamAccountName, onPremisesDomainName et onPremisesSecurityIdentifier. Valider les domaines et forêts contenant les utilisateurs pilotes.
Postes Microsoft Entra joined ou hybrid joined, Windows 10 21H2 avec KB5010415 ou version ultérieure prise en charge, ou Windows 11 21H2 avec KB5010414 ou version ultérieure; garder les postes à jour. Un appareil joint seulement à AD n’entre pas dans ce scénario hybride.
Contrôleurs de domaine Windows Server 2016 ou 2019 avec correctifs requis, ou Windows Server 2022/2025; prévoir des DC inscriptibles en nombre suffisant dans les sites concernés. Si une GPO limite les chiffrements Kerberos, inclure AES256_HMAC_SHA1.
Microsoft Entra Connect, accès aux DC, DNS et réseau pour les ressources locales; authentification forte pour l’inscription WHfB, TPM pour lier les clés et méthode de secours documentée.
Recenser comptes privilégiés, usages RDP/VDI, Run as, cartes à puce, VPN pré-ouverture de session, Wi-Fi EAP-TLS et applications qui demandent explicitement des certificats : tester séparément chaque parcours.

Microsoft — exigences Windows, DC, synchronisation et licences ↗

Étape 1 — Créer Microsoft Entra Kerberos pour les domaines visés

Si Microsoft Entra Kerberos est déjà déployé pour l’authentification locale par clés FIDO2, réutilisez l’objet existant. Sinon, l’équipe AD et l’équipe identité doivent créer un objet AzureADKerberos par domaine et forêt concernés. Il ressemble à un objet RODC, mais aucun serveur physique supplémentaire n’est installé. Réalisez l’opération depuis le serveur Entra Connect ou un serveur disposant de la dépendance Microsoft.Online.PasswordSynchronization.Rpc.dll et de la connectivité DC. Utilisez un compte Domain Admin/Enterprise Admin local et un Hybrid Identity Administrator Entra, selon la procédure Microsoft; retirez ensuite les droits temporaires.

Vérifiez le domaine retourné, l’objet AD et sa publication Entra; pour plusieurs domaines, répétez sur chacun où résident les utilisateurs. Ne placez pas les identifiants administratifs dans une tâche planifiée ou dans un fichier de configuration.

Exemple PowerShell — création contrôlée; comptes interactifs, aucun secret dans le script

# Sur un serveur autorisé, après validation du domaine et de la fenêtre de changement.
Install-Module AzureADHybridAuthenticationManagement -Scope CurrentUser
Import-Module AzureADHybridAuthenticationManagement
$domain = 'ad.exemple.ca' # Remplacer par le vrai domaine AD de l'utilisateur
$cloudUpn = 'hybrid-admin@exemple.onmicrosoft.com'
$domainCred = Get-Credential -Message 'Compte AD avec droits requis (UPN)'
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $cloudUpn -DomainCredential $domainCred
Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $cloudUpn -DomainCredential $domainCred

Microsoft — module, création et vérification de l’objet Kerberos ↗

Étape 2 — Déployer Intune sur un groupe pilote

Dans Microsoft Intune, créez une stratégie Windows du catalogue des paramètres, catégorie Windows Hello for Business, ciblée vers un petit groupe de postes pilotes représentatifs. Configurez « Use Windows Hello For Business » sur true, « Use Cloud Trust For On Prem Auth » sur Enabled et « Require Security Device » sur true lorsque le TPM est présent. Si la stratégie WHfB à l’échelle du locataire existe déjà et convient, Microsoft précise qu’il peut suffire d’ajouter le paramètre cloud trust. Vérifiez l’état d’application sur les appareils; ne mélangez pas inutilement politiques héritées et nouvelles politiques pour le même réglage.

Paramètre du catalogue	Valeur pilote	Pourquoi
Use Windows Hello For Business	true	Autorise l’inscription
Use Cloud Trust For On Prem Auth	Enabled	Active la confiance Kerberos hybride
Require Security Device	true	Lie la clé au TPM; contrôler la capacité des appareils

Option GPO pour les appareils hybrides gérés par Active Directory

Avec les modèles Passport.admx/Passport.adml à jour dans le magasin central, ciblez la GPO par filtrage de sécurité sur un groupe pilote. Sous Configuration ordinateur > Modèles d’administration > Composants Windows > Windows Hello for Business, activez « Use Windows Hello for Business », « Use cloud Kerberos trust for on-premises authentication » et, selon le parc, « Use a hardware security device ». Le premier paramètre WHfB existe aussi en Configuration utilisateur, mais la stratégie cloud trust n’existe qu’en Configuration ordinateur. Si les deux scopes WHfB sont définis, la stratégie utilisateur prévaut pour ce paramètre.

Les GPO priment sur les paramètres Intune WHfB en cas de conflit selon le guide Microsoft : attribuez un propriétaire à chaque paramètre et retirez les doublons avant l’élargissement. Ne configurez pas « Use certificate for on-premises authentication » sur ces postes, car il prendrait le dessus sur cloud trust.

Sur un poste pilote — vérifier l’application et l’état de jonction

gpupdate /force
gpresult /h C:\Temp\whfb-gpo.html  # Créer C:\Temp au préalable
dsregcmd /status

Étape 3 — Inscrire les utilisateurs et valider un parcours réel

Après une ouverture de session admissible, l’utilisateur effectue son défi MFA, crée un NIP et peut éventuellement enregistrer une biométrie. La paire de clés reste liée à l’appareil, de préférence au TPM. Sur un poste hybrid joined, le premier accès avec le NIP exige une ligne de vue vers un DC; pour les employés à distance, validez le VPN préconnexion ou réalisez cette étape sur le réseau de l’entreprise. Ensuite seulement, testez la reconnexion hors ligne, puis la reconnexion au partage local quand le VPN et le DC sont accessibles.

OnPremTgt=YES indique la présence d’un ticket cloud Kerberos local, pas à lui seul la réussite de chaque application. Les noms des champs diagnostics varient selon les versions Windows. Vérifiez la connexion à une ressource représentative avec le nom DNS normal, son ticket et les autorisations; le journal User Device Registration/Admin explique les prérequis d’inscription. Ne publiez pas les sorties dsregcmd complètes dans un billet de soutien : elles peuvent contenir des identifiants du locataire ou de l’utilisateur.

Contrôles en contexte utilisateur sur le poste de test

dsregcmd /status
# Vérifier AzureAdJoined, DomainJoined, AzureAdPrt, NgcSet et OnPremTgt selon la version.
klist
# Ouvrir \serveur.ad.exemple.ca\partage, puis relancer klist pour observer le ticket de service.

Comptes privilégiés : ne pas assouplir la protection RODC

L’objet AzureADKerberos applique des restrictions comparables à celles d’un RODC. Les utilisateurs membres, directement ou indirectement, des groupes privilégiés intégrés ne peuvent normalement pas utiliser cloud trust pour accéder aux ressources AD locales. Ce comportement protège la frontière entre Entra et Active Directory. Microsoft déconseille explicitement de modifier la Password Replication Policy de CN=AzureADKerberos pour autoriser ces comptes.

Tester un compte utilisateur standard pour les ressources métiers; traiter les comptes d’administration comme un parcours distinct.
Conserver des identités d’administration séparées, un poste d’administration dédié et une méthode de secours documentée.
Ne pas retirer un administrateur d’un groupe protégé, ni modifier la politique RODC uniquement pour faire passer un test WHfB.

Applications et scénarios particuliers : la preuve par les tests

La documentation Microsoft sur les clés de sécurité FIDO2 liste des scénarios RDP, VDI, Citrix et Run as non pris en charge avec ces clés; cela ne prouve pas que tous les scénarios WHfB sont identiques. Chaque méthode, client et application doit être testée. Un nom de partage par adresse IP peut provoquer un mécanisme d’authentification différent d’un FQDN Kerberos.

Scénario	Test recommandé
Partages SMB et intranet Kerberos	NIP, VPN, nom FQDN, klist, accès effectif et droits
Connexion hors réseau	Première connexion hybride avec DC, puis déverrouillage en cache et retour VPN
RDP, VDI, Citrix	Tester le scénario précis et l’authentification prise en charge; ne pas extrapoler des limitations FIDO2 à tous les usages WHfB
Wi-Fi/VPN EAP-TLS, S/MIME	Confirmer le mécanisme de certificats séparé et sa distribution
Applications héritées NTLM ou Run as	Valider les flux exacts; conserver un repli et planifier la modernisation

Microsoft — scénarios FIDO2 pris en charge et exclus ↗

Dépannage : isoler la bonne couche avant de changer la stratégie

Pas d’invite WHfB : vérifier jonction du poste, portée Intune/GPO, TPM, MFA d’inscription et User Device Registration/Admin.
NIP fonctionnel mais aucun accès au partage : vérifier objet Entra Kerberos pour le bon domaine, attributs synchronisés, OnPremTgt, DNS, VPN, heure et DC inscriptible.
Échec limité aux administrateurs : vérifier les groupes privilégiés et les restrictions RODC; ne pas modifier la politique de réplication.
Cloud trust ignoré : rechercher une stratégie certificate trust encore active ou un conflit GPO/Intune.
Échec seulement à distance lors du premier NIP hybride : refaire le test avec visibilité vers un DC avant d’incriminer le TPM.

Collecte non destructive (poste utilisateur)

dsregcmd /status
klist
gpresult /r
Get-WinEvent -LogName 'Microsoft-Windows-User Device Registration/Admin' -MaxEvents 20 | Select-Object TimeCreated,Id,Message

Microsoft — guide de déploiement et diagnostic WHfB ↗

Déploiement par anneaux, retour arrière et critères d’acceptation

Commencez par quelques appareils Entra joined et hybrid joined, avec profils applicatifs, sites et VPN représentatifs. Documentez pour chaque anneau : taux d’inscription, réussite de l’ouverture de session, accès au partage et à l’intranet, besoin réel de certificats, demandes au soutien et temps de résolution. Étendez seulement lorsque les parcours critiques sont validés. Maintenez temporairement le mode d’authentification existant comme repli contrôlé et informez le soutien et les utilisateurs avant de changer les politiques.

Une migration depuis key trust est documentée; depuis certificate trust, il n’existe pas de conversion directe : Microsoft demande de redéployer WHfB après suppression du conteneur Hello dans le contexte utilisateur. Réservez cette opération destructive à un projet séparé, testé avec sauvegarde des méthodes d’accès. La réussite du projet n’est pas « 100 % de NIP créés », mais l’accès soutenu aux ressources nécessaires sans multiplication des mots de passe ou baisse de sécurité.

Semaine 1 : confirmer identité synchronisée, DC et réseau; créer/vérifier l’objet Kerberos avec une fenêtre de changement.
Pilote : assigner Intune ou GPO à un petit groupe; inscrire WHfB puis tester sur site, hors site et après reconnexion VPN.
Élargissement : ajouter des groupes par vagues; surveiller échecs, tickets, applications et support; traiter séparément administrateurs et certificats.
Retour arrière : retirer ou désactiver la politique WHfB ciblée, conserver l’ancienne méthode de connexion et le compte de récupération; ne supprimez pas de conteneur Hello ni l’objet Kerberos en production sans plan de migration et analyse des autres usages FIDO2.

À propos de l’auteur

Marc-Antoine Lambert

Consultant TI senior et Team Lead basé à Montréal, spécialisé en architecture, cybersécurité, infrastructures Microsoft, réseaux et continuité des opérations.

Discuter de votre environnement →