Windows Hello for Business: lire l’état NGC avec dsregcmd

Sur notre maquette, nous allons ouvrir une session de domaine sur un poste Windows 11 joint hybride, laisser Windows déclencher l’inscription Windows Hello for Business, puis relire avec dsregcmd et quelques commandes ce que le poste et l’annuaire ont réellement conservé: une paire de clés, un conteneur NGC (Next Generation Credential) et une clé publique attachée au compte.

Nom du domaine: test.local (TESTLOCAL), synchronisé vers un tenant Entra ID par Entra Connect

Poste client: pc01, Windows 11, joint hybride, TPM 2.0

Utilisateur: user01@test.local

Modèle de confiance: cloud Kerberos trust (l’objet AzureADKerberos existe déjà dans le domaine)

Windows Hello ou Windows Hello for Business?

C’est le premier point que je tiens à bien différencier, car les deux affichent le même écran de saisie du PIN alors que le mécanisme n’a rien à voir.

Windows Hello, dans sa version grand public ou sous la forme du « PIN de commodité » (convenience PIN) sur un compte de domaine, ne fait que remplacer la saisie: le PIN déverrouille un mot de passe conservé localement, et c’est ce mot de passe qui part ensuite vers le contrôleur de domaine. Le secret partagé reste en place, avec tout ce que cela implique (NTLM, hash, réutilisation du mot de passe…). Windows Hello for Business crée lui une paire de clés asymétriques propre à l’appareil, dont seule la clé publique est enregistrée auprès du fournisseur d’identité. Nous retrouvons dans la FAQ de Microsoft ce qui s’ajoute à Windows Hello: l’appareil est attesté par le TPM, l’authentification repose sur une clé ou un certificat, et l’accès conditionnel peut en tenir compte.

Depuis Windows 10 1607, les deux ne cohabitent plus: quand les stratégies « Use Windows Hello for Business » et « Turn on convenience PIN sign-in » sont activées ensemble, l’utilisateur ne peut plus créer de PIN de commodité sur un poste qui n’est pas joint à Entra ID, comme le décrit cet article de support. Microsoft y justifie ce blocage: le PIN de commodité protège un mot de passe, alors que le PIN Windows Hello for Business protège une clé liée au TPM.

Avec WHfB, le PIN n’est jamais transmis: il sert uniquement à débloquer localement la clé privée protégée par le TPM. Nous sommes donc face à une authentification à deux facteurs, comme le rappelle la présentation officielle: la clé (ce que l’on possède) et le PIN (ce que l’on sait). La biométrie débloque la même clé que le PIN.

L’inscription vue par dsregcmd

Avant toute inscription, ouvrons une session avec user01 sur pc01 et lançons dsregcmd /status dans le contexte de l’utilisateur, sans élévation. Le paragraphe qui nous intéresse est « Ngc Prerequisite Check »:

C:\>dsregcmd /status
+----------------------------------------------------------------------+
| Ngc Prerequisite Check                                               |
+----------------------------------------------------------------------+
            IsDeviceJoined : YES
             IsUserAzureAD : YES
             PolicyEnabled : YES
          PostLogonEnabled : YES
            DeviceEligible : YES
        SessionIsNotRemote : YES
            CertEnrollment : none
              PreReqResult : WillProvision

Nous lisons chaque ligne comme une condition, toutes décrites dans la documentation de dsregcmd:

• IsDeviceJoined et IsUserAzureAD: l’appareil est joint à Entra ID et l’utilisateur y existe, ce qui suppose une synchronisation Entra Connect fonctionnelle,
• PolicyEnabled: la stratégie WHfB est reçue par le poste,
• PostLogonEnabled: l’inscription est déclenchée nativement à l’ouverture de session (NO signifie qu’un mécanisme maison s’en charge),
• DeviceEligible: le matériel répond aux exigences,
• SessionIsNotRemote: la session est locale et non RDP,
• CertEnrollment: « none » en cloud Kerberos trust ou en clé, une autorité d’inscription en modèle certificat.

Attention: une fois WHfB configuré pour l’utilisateur, cette section peut disparaître de la sortie. Si PreReqResult vaut « WillNotProvision », le journal « Applications and Services Logs / Microsoft / Windows / User Device Registration / Admin » et son événement 358 donnent le même diagnostic avec plus de contexte.

Quand toutes les conditions sont réunies, nous pouvons suivre la séquence d’inscription telle que Microsoft la décrit:

1. L’application d’inscription, hébergée dans le Cloud Experience Host (CXH), demande un jeton pour le service d’inscription des appareils (Azure DRS), ce qui impose une MFA.
2. L’utilisateur enregistre éventuellement son doigt ou son visage, puis crée son PIN, qui reste le geste par défaut et de secours.
3. Windows prend une paire de clés dans un réservoir de clés pré-générées, avec les données d’attestation du TPM: c’est la clé utilisateur (ukpub/ukpriv).
4. Le jeton, ukpub, l’attestation et les informations de l’appareil partent vers Azure DRS, qui vérifie que la MFA est toujours valide et écrit la clé sur l’objet utilisateur dans Entra ID.

Relançons maintenant dsregcmd /status. La section « User State » a changé:

+----------------------------------------------------------------------+
| User State                                                           |
+----------------------------------------------------------------------+
                    NgcSet : YES
                  NgcKeyId : {3F2A9C1E-7B44-4D0A-9E61-0C5B8D2F11A7}
                  CanReset : DestructiveAndNonDestructive
           WorkplaceJoined : NO
             WamDefaultSet : YES

Avec NgcSet, nous avons la confirmation qu’une clé Windows Hello existe pour l’utilisateur connecté, NgcKeyId en donne l’identifiant et CanReset indique si le PIN peut être réinitialisé sans détruire le conteneur (réinitialisation non destructive) ou seulement en recréant la clé.

En cloud Kerberos trust, nous regardons ensuite la section « SSO State »: CloudTgt et OnPremTgt doivent passer à YES après une ouverture de session avec le PIN. Le TGT partiel émis par Entra ID voyage avec le PRT, dont nous avions détaillé la structure dans l’article sur l’anatomie du Primary Refresh Token.

Où vit la clé?

Côté poste, les conteneurs NGC sont stockés sous C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc, avec des ACL qui en réservent l’accès au service local. Plutôt que de parcourir ce répertoire, nous interrogeons le fournisseur de stockage de clés dédié avec certutil, dans la session de l’utilisateur:

certutil -csp "Microsoft Passport Key Storage Provider" -key

Nous voyons apparaître une entrée par clé, avec dans son nom le SID de user01 et l’autorité qui l’a enregistrée. Pour repartir de zéro sur un poste de test, nous utilisons certutil -deletehellocontainer, qui supprime le conteneur de l’utilisateur courant, et l’inscription est proposée de nouveau à la session suivante.

Attention: la ligne TpmProtected de la section « Device Details » de dsregcmd concerne la clé de l’appareil utilisée pour la jonction, pas la clé Windows Hello de l’utilisateur. Un poste peut afficher TpmProtected: YES alors que la clé de l’utilisateur est protégée par logiciel.

Reste le cas où le TPM est indisponible. Le comportement dépend de la stratégie « Use a hardware security device » (RequireSecurityDevice en CSP). D’après la liste des paramètres, si elle n’est pas activée, Windows préfère le TPM mais inscrit la clé en logiciel lorsque le TPM est absent ou ne fonctionne pas. L’utilisateur ne voit aucune différence, alors que la clé privée n’est plus liée au matériel et ne bénéficie plus de la protection anti-martèlement du TPM sur le PIN. Si la stratégie est activée, l’inscription n’a lieu que sur les postes équipés d’un TPM 1.2 ou 2.0 utilisable, et Microsoft recommande d’exclure le TPM 1.2, limité à RSA et SHA-1.

Pour les mobiles, Windows Hello for Business n’existe pas sur iOS ou Android: il est réservé à Windows. Sur téléphone, nous utilisons une clé liée à l’appareil, en général une passkey dans Microsoft Authenticator, dont nous avions suivi la cérémonie dans l’article sur les passkeys FIDO2 dans Entra ID.

Pour la configuration, je préconise les éléments suivants:

• « Use a hardware security device » activé, TPM 1.2 exclu, pour qu’aucune clé ne soit inscrite en logiciel sans que nous le sachions,
• un PIN de 6 chiffres minimum, réglé dans « Configuration ordinateur / Modèles d’administration / Système / PIN Complexity » ou par Intune,
• la protection renforcée de la connexion (Enhanced Sign-in Security), qui isole le traitement biométrique avec la sécurité basée sur la virtualisation.

Attention: la protection renforcée demande des caméras et capteurs d’empreinte compatibles, il faut donc vérifier le parc matériel avant de l’imposer.

Clé, certificat ou cloud Kerberos trust?

En environnement uniquement cloud, le poste s’authentifie auprès d’Entra ID avec la clé, sans autre composant. Dès que nous avons besoin d’un TGT pour les ressources de test.local, nous devons choisir un modèle de confiance. La documentation de planification les décrit ainsi:

1. Certificate trust: un certificat utilisateur est délivré à partir de la clé Hello, puis le poste fait du PKINIT avec ce certificat. Il faut une PKI complète, pour les contrôleurs de domaine et pour les utilisateurs.
2. Key trust: la clé publique est rapatriée dans l’AD et le contrôleur de domaine l’accepte directement en PKINIT. Il faut toujours un certificat sur les contrôleurs de domaine.
3. Cloud Kerberos trust: Entra ID émet un TGT partiel signé avec la clé de l’objet AzureADKerberos, que le contrôleur de domaine échange contre un TGT complet. Aucun certificat n’est nécessaire, ni sur les contrôleurs de domaine ni pour les utilisateurs, et Microsoft le recommande désormais à la place du modèle clé.

En modèle clé, c’est Entra Connect qui écrit la clé publique dans l’attribut msDS-KeyCredentialLink de l’utilisateur, comme l’explique le guide de déploiement hybride en modèle clé. Lisons-le:

PS C:\> (Get-ADUser user01 -Properties msDS-KeyCredentialLink).'msDS-KeyCredentialLink'
B:828:000200002000016B...0100:CN=user01,OU=Utilisateurs,DC=test,DC=local

Nous avons affaire à une valeur de type DN-Binary: un préfixe B, la longueur en caractères hexadécimaux, le blob puis le DN de l’objet. Le blob suit la structure KEYCREDENTIALLINK_BLOB décrite dans [MS-ADTS]: une suite d’entrées qui portent l’identifiant de la clé, la clé publique elle-même, son usage (NGC pour Windows Hello), sa source, l’identifiant de l’appareil, les dates de création et de dernière ouverture de session, etc… Une valeur par appareil inscrit: un utilisateur avec deux postes aura deux entrées.

En cloud Kerberos trust, le contrôleur de domaine n’a pas besoin de cet attribut pour délivrer le TGT. Sur pc01, après une ouverture de session avec le PIN, nous lançons klist, qui doit montrer le ticket krbtgt/TEST.LOCAL obtenu sans mot de passe, et la lecture des tickets suit la démarche détaillée dans l’article sur la lecture d’un ticket de service avec klist et Wireshark.

Quel que soit le modèle retenu, nous devons surveiller un point de sécurité: un compte qui peut écrire dans msDS-KeyCredentialLink peut y déposer sa propre clé et s’authentifier ensuite en PKINIT à la place de l’utilisateur, sans connaître son mot de passe. C’est l’attaque connue sous le nom de « shadow credentials », et l’audit des droits d’écriture sur cet attribut, comptes à privilèges en tête, mérite sa place dans toute revue de l’annuaire au même titre que les délégations.

Rémi Vernier

Responsable des opérations cybersécurité dans un grand groupe international. Identité, Active Directory, Entra ID, cloud hybride, et désormais SAP, IA et modèles en local.

Tous les articles → LinkedIn →