Credential Guard désactivé après mise à niveau : vérifier et corriger

Que signifie Credential Guard désactivé après mise à niveau ?

Credential Guard désactivé après mise à niveau peut être une configuration héritée, même sur une version de Windows qui active la fonction par défaut. Une mise à niveau éligible n'efface pas une décision explicite antérieure de la désactiver. Avant de considérer un système d'exploitation récent comme une preuve de protection des identifiants, vérifiez l'édition de la machine, son historique de déploiement, sa stratégie et les services en cours d'exécution. Les instructions de configuration de Microsoft documentent cette exception persistante.

Credential Guard isole certains secrets du domaine à l'aide de la sécurité basée sur la virtualisation (VBS). Il s'agit concrètement d'établir si cette isolation fonctionne sur les appareils où les utilisateurs du domaine ouvrent une session. Une stratégie de déploiement et une mise à niveau réussie du système d'exploitation répondent à des questions différentes de celles d'un contrôle à l'exécution.

Ce guide reflète les pages Microsoft Learn consultées le 3 octobre 2026. Il couvre les appareils Windows 11 éligibles à partir de la version 22H2 et les membres du domaine Windows Server 2025 éligibles. Les commandes ci-dessous sont reprises de la documentation ; elles n'ont pas été exécutées sur un parc Windows pour cet article. Aucune fréquence des exceptions héritées n'est avancée.

Fonctionnement de l'activation par défaut

La présentation de Credential Guard par Microsoft décrit l'activation par défaut à partir de Windows 11 22H2 et Windows Server 2025. Son introduction situe cette activation sur les systèmes éligibles joints au domaine qui ne sont pas contrôleurs de domaine ; ses conditions propres à Windows énumèrent les exigences de licence, d'éligibilité matérielle et logicielle et d'absence de désactivation explicite. Conservez ces réserves lors de l'examen d'un parc AD.

Pour le cas historique de Pro, Microsoft identifie HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\IsolatedCredentialsRootSecret comme l'indicateur de registre à examiner. Il identifie cet historique ; ce n'est pas une mesure de l'isolation en cours d'exécution. Le tableau des licences n'accorde pas à Pro, Pro Education ou SE les mêmes droits qu'à Enterprise et Education. Présentation Microsoft

L'éligibilité matérielle doit également être examinée. La présentation cite VBS et Secure Boot pour la protection et recommande TPM, sans en faire une exigence générale de Credential Guard. Elle précise séparément que VBS peut atteindre un état d'exécution sans Secure Boot. Préservez cette distinction : un service VBS en cours d'exécution ne certifie pas à lui seul les protections de plateforme recherchées. La documentation de la plateforme VBS détaille les extensions de virtualisation, SLAT et les exigences de firmware et de DMA.

Pourquoi une désactivation explicite survit à la mise à niveau

Microsoft indique que les valeurs configurées explicitement prévalent sur l'activation par défaut après redémarrage. Un appareil explicitement désactivé avant une mise à niveau reste désactivé ensuite. La mise à niveau constitue donc un point de contrôle utile pour l'audit, pas une remédiation d'une ancienne exception. Configurer Credential Guard

Examinez LsaCfgFlags dans HKLM\SYSTEM\CurrentControlSet\Control\Lsa et dans HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard. Microsoft documente 0 pour la désactivation explicite, 1 pour l'activation avec verrouillage UEFI et 2 pour l'activation sans verrouillage. Dans les GPO, examinez Computer Configuration → Administrative Templates → System → Device Guard → Turn On Virtualization Based Security, y compris la configuration de Credential Guard qu'elle contient. Procédures Microsoft de configuration et de désactivation

Une exception peut avoir été introduite pour une dépendance applicative réelle. Les problèmes connus de Microsoft abordent l'authentification unique MS-CHAPv2/NTLMv1, les identifiants CredSSP enregistrés et la migration dynamique Hyper-V reposant sur CredSSP. Établissez quel processus nécessitait initialement l'exception, s'il en a toujours besoin et qui est responsable de la décision. Ne supposez ni que l'exception reste nécessaire, ni qu'elle peut être supprimée sans tests.

Chaîne d'attaque : ce que change l'absence d'isolation

Sans l'isolation de Credential Guard, une compromission locale disposant de privilèges suffisants peut rendre les secrets du domaine présents sur l'hôte plus accessibles au vol depuis LSASS. Lorsque Credential Guard fonctionne, les secrets protégés sont au contraire traités par un composant LSA isolé. Le vol et la réutilisation dépendent toujours des secrets présents, des privilèges de l'attaquant et d'un chemin d'authentification disponible ; un contrôle désactivé n'équivaut pas automatiquement à une compromission du domaine. Fonctionnement de Credential Guard

Notre article sur le Pass-the-Hash dans Active Directory explique comment des données NTLM volées peuvent permettre un déplacement latéral lorsque la destination accepte NTLM et que le compte possède des droits utiles. Il présente déjà Credential Guard comme une mesure de réduction du risque. Ce guide ajoute l'investigation des désactivations héritées et la vérification à l'exécution nécessaires pour établir si cette mesure est effectivement en place.

Credential Guard a des limites même lorsqu'il est actif : les comptes locaux/Microsoft, les tickets de service Kerberos, les identifiants NTLM saisis manuellement, les enregistreurs de frappe et l'abus des privilèges d'une session existante restent des risques pertinents. Les vérificateurs de connexion au domaine mis en cache ne sont pas non plus des hachages NTLM que l'on peut simplement présenter à une autre machine. Limites de protection selon Microsoft

Détection : mesurer le service en cours d'exécution

Sur l'appareil Windows cible, utilisez une session PowerShell élevée et la commande exacte fournie par Microsoft dans Vérifier si Credential Guard est activé :

(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning

Interprétez le résultat comme un ensemble d'identifiants de services. La présence de 1 signifie que Credential Guard fonctionne ; 2 désigne l'intégrité de la mémoire. Un résultat contenant à la fois 1 et 2 inclut Credential Guard. SecurityServicesConfigured décrit la configuration, tandis que SecurityServicesRunning décrit l'exécution ; VirtualizationBasedSecurityStatus décrit VBS. Ce sont des observations distinctes. Référence Microsoft des propriétés de Win32_DeviceGuard

Vous pouvez aussi ouvrir msinfo32.exe, sélectionner System Summary et rechercher Credential Guard dans Virtualization-based Security Services Running. Microsoft déconseille d'utiliser la présence de LsaIso.exe dans le Gestionnaire des tâches comme méthode de vérification. Instructions de vérification Microsoft

Lorsque configuration et exécution diffèrent, examinez Windows Logs → System, source WinInit. Microsoft documente ces signaux de démarrage sur la même page de configuration :

Ces événements décrivent l'état de protection, pas une preuve de vol d'identifiants. Une collecte échouée donne un état inconnu, pas désactivé. Enregistrez l'hôte, l'heure de collecte et le contexte de redémarrage afin qu'un ancien événement ou un terminal inaccessible ne soit pas confondu avec la couverture actuelle.

Remédiation : remplacer l'exception et vérifier après redémarrage (Remediation)

1. Constituer un inventaire des exceptions

Pour chaque candidat, enregistrez la version, l'édition et les licences, l'éligibilité de la plateforme, le rôle dans le domaine ou de DC, les paramètres explicites locaux et administrés et le résultat à l'exécution. Séparez les appareils dont le service est confirmé comme non exécuté des hôtes qui n'ont pas pu être mesurés. Priorisez l'investigation là où des identifiants du domaine sont utilisés, tout en conservant les exclusions documentées ci-dessus.

2. Tester la dépendance qui justifiait la désactivation

Utilisez des appareils représentatifs et les processus d'authentification réels. Microsoft recommande l'authentification Wi-Fi/VPN par certificat plutôt que MS-CHAPv2, ainsi que Kerberos Constrained Delegation ou Resource-Based Kerberos Constrained Delegation pour les processus de migration Hyper-V concernés. Ces changements traitent la dépendance plutôt que de perpétuer la désactivation. Enregistrez un responsable et une date de réexamen pour les exceptions qui doivent subsister. Instructions de compatibilité Microsoft

3. Définir une configuration explicite prise en charge

Pour les appareils administrés dans le domaine, suivez la procédure GPO de Microsoft : activez Turn On Virtualization Based Security sous Computer Configuration → Administrative Templates → System → Device Guard, puis choisissez Enabled with UEFI lock ou Enabled without lock sous Credential Guard Configuration. Définissez la portée et testez le déploiement avant une généralisation. Redémarrez après l'application de la stratégie. Intune propose aussi ces options de Credential Guard. Instructions de déploiement Microsoft

L'alternative documentée par registre utilise EnableVirtualizationBasedSecurity=1 sous HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard, avec LsaCfgFlags=1 ou 2 sous HKLM\SYSTEM\CurrentControlSet\Control\Lsa. RequirePlatformSecurityFeatures sous le chemin DeviceGuard sélectionne Secure Boot (1) ou Secure Boot avec protection DMA (3). Suivez la procédure documentée complète et résolvez les conflits de configuration administrée. Paramètres de registre Microsoft

Choisissez le verrouillage délibérément. L'activation par défaut se fait sans verrouillage UEFI ; supprimer une configuration verrouillée par UEFI nécessite la procédure de firmware de Microsoft et une confirmation physique. Une modification du registre seule ne supprime pas cet état du firmware. Documentez la capacité de récupération avant de choisir le verrouillage. Procédure Microsoft de verrouillage UEFI

4. Vérifier et conserver les preuves

Après redémarrage, répétez la commande CIM documentée ou le contrôle avec msinfo32.exe et examinez les erreurs WinInit. Clôturez la remédiation lorsque le service attendu fonctionne et que les processus requis passent les tests, pas simplement lorsqu'une GPO existe. Gardez les appareils non résolus dans l'inventaire avec leurs preuves réelles et l'action suivante.

Ce contrôle à l'exécution n'établit pas si les identifiants ont été exposés avant le démarrage de la protection. Microsoft recommande d'activer Credential Guard avant la jonction au domaine ou la première connexion d'un utilisateur du domaine, car les secrets utilisés auparavant peuvent déjà avoir été compromis. Instructions de déploiement Microsoft

Examinez aussi les expositions d'identifiants connexes. Notre article sur WDigest activé explique comment UseLogonCredential et des exceptions obsolètes peuvent augmenter les données d'identification exposées dans LSASS. Il s'agit d'un examen complémentaire du stockage des identifiants, pas d'un substitut à la mesure de l'isolation de Credential Guard.

Comment EtcSec détecte ce problème

L'etc-collector d'EtcSec inclut CREDENTIAL_GUARD_DISABLED, un contrôle de configuration GPO de sévérité moyenne. Sa méthode Detect() lit les stratégies GPO collectées et recherche une valeur VBS de 1 et une valeur LsaCfgFlags de Credential Guard de 1 ou 2. Si l'une des conditions manque, elle enregistre un constat de configuration.

La recherche prend le premier paramètre trouvé dans Default DC Policy, Default Domain Policy, puis les autres GPO ; les deux valeurs peuvent provenir de stratégies différentes. Elle ne calcule pas la stratégie résultante de chaque terminal, n'interroge pas l'état CIM de chaque hôte et n'identifie pas l'activation automatique sur chaque machine. La configuration GPO n'est pas l'état effectif à l'exécution. Une valeur GPO absente peut coexister avec un service activé par défaut en cours d'exécution ; un paramètre présent ne prouve pas l'exécution sur l'ensemble du parc.

Utilisez le constat pour ouvrir l'investigation de configuration, puis joignez les mesures par hôte au dossier de remédiation. La chaîne de preuves utile comprend l'éligibilité, les paramètres explicites, la configuration appliquée, le redémarrage et la vérification à l'exécution. Gardez les résultats inconnus visibles afin que la couverture de configuration ne soit pas présentée comme une protection mesurée.