Considérations et problèmes connus liés à l’utilisation de Credential Guard

Article
11/01/2024
S’applique à:

✅ Windows 11, ✅ Windows 10, ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

Microsoft recommande qu’en plus de déployer Credential Guard, les organisations passent des mots de passe à d’autres méthodes d’authentification, telles que les Windows Hello Entreprise, les clés de sécurité FIDO 2 ou les cartes à puce.

Considérations relatives à la mise à niveau

À mesure que Credential Guard évolue et améliore ses fonctionnalités de sécurité, les versions plus récentes de Windows exécutant Credential Guard peuvent affecter des scénarios précédemment fonctionnels. Par instance, Credential Guard peut restreindre l’utilisation de certaines informations d’identification ou composants pour empêcher les programmes malveillants exploitant des vulnérabilités.

Il est recommandé de tester minutieusement les scénarios opérationnels au sein d’un organization avant de mettre à jour les appareils qui utilisent Credential Guard.

Les mises à niveau vers Windows 11, version 22H2 et Windows Server 2025 ont Credential Guard activée par défaut, sauf si elle est explicitement désactivée.

Considérations relatives au Wi-Fi et au VPN

Lorsque Credential Guard est activé, vous ne pouvez plus utiliser l’authentification classique NTLM (NTLMv1) pour l’authentification unique (SSO). Vous serez obligé d’entrer vos informations d’identification pour utiliser ces protocoles et ne pourrez pas enregistrer les informations d’identification pour une utilisation ultérieure.

Si vous utilisez des points de terminaison Wi-Fi et VPN basés sur MS-CHAPv2, ils sont sujets à des attaques similaires à celles de NTLMv1.

Pour les connexions Wi-Fi et VPN, il est recommandé de passer des connexions MSCHAPv2 (telles que PEAP-MSCHAPv2 et EAP-MSCHAPv2) à l’authentification basée sur les certificats (par exemple, PEAP-TLS ou EAP-TLS).

Considérations relatives à la délégation

Lorsque Credential Guard est activé, certains types de délégation d’identité ne sont pas utilisables, car leurs schémas d’authentification sous-jacents sont incompatibles avec Credential Guard ou nécessitent des informations d’identification fournies.

Lorsque Credential Guard est activé, le fournisseur de prise en charge de la sécurité des informations d’identification (« CredSSP ») n’est plus en mesure d’utiliser les informations d’identification enregistrées ou SSO, bien que des informations d’identification en texte clair puissent toujours être fournies. La délégation basée sur CredSSP nécessite que des informations d’identification en texte clair soient fournies sur l’ordinateur de destination et ne fonctionne pas avec l’authentification unique une fois que Credential Guard est activé et bloque la divulgation des informations d’identification en texte clair. L’utilisation de CredSSP pour la délégation, et en général, n’est pas recommandée en raison du risque de vol d’informations d’identification.

La délégation Kerberos sans contrainte et DES sont bloquées par Credential Guard. La délégation sans contrainte n’est pas recommandée.

Au lieu de cela , Kerberos ou Negotiate SSP sont recommandés pour l’authentification en général, et pour la délégation, la délégation Kerberos contrainte et la délégation Kerberos contrainte basée sur les ressources sont recommandées. Ces méthodes offrent une plus grande sécurité globale des informations d’identification et sont également compatibles avec Credential Guard.

Considérations relatives aux fournisseurs de support de sécurité non-Microsoft

Certains fournisseurs de support de sécurité non-Microsoft (SSP et APs) peuvent ne pas être compatibles avec Credential Guard, car il n’autorise pas les fournisseurs de services de sécurité non-Microsoft à demander des hachages de mot de passe à partir de LSA. Toutefois, les fournisseurs SSP et les points d’accès reçoivent toujours des notifications du mot de passe lorsqu’un utilisateur se connecte et/ou modifie son mot de passe. Toute utilisation d’API non documentées au sein des fournisseurs de services de sécurité et des adresses IP personnalisés n’est pas prise en charge.

Il est recommandé de tester les implémentations personnalisées des fournisseurs de services/fournisseurs d’accès avec Credential Guard. Les fournisseurs SSP/points d’accès qui dépendent d’un comportement non documenté ou non pris en charge échouent. Par exemple, l’utilisation de l’API KerbQuerySupplementalCredentialsMessage n’est pas prise en charge. Vous ne devez pas remplacer les fournisseurs SSP NTLM ou Kerberos par des fournisseurs SSP et des points d’accès personnalisés.

Pour plus d’informations, consultez Restrictions relatives à l’inscription et à l’installation d’un package de sécurité.

Considérations relatives aux informations d’identification Windows enregistrées

Le Gestionnaire d’informations d’identification vous permet de stocker trois types d’informations d’identification :

Informations d’identification Windows
Informations d’identification basées sur les certificats
Informations d’identification génériques

Les informations d’identification de domaine stockées dans le Gestionnaire d’informations d’identification sont protégées par Credential Guard.

Les informations d’identification génériques, telles que les noms d’utilisateur et les mots de passe que vous utilisez pour vous connecter aux sites web, ne sont pas protégées, car les applications nécessitent votre mot de passe en texte clair. Si l’application n’a pas besoin d’une copie du mot de passe, elle peut enregistrer les informations d’identification de domaine en tant qu’informations d’identification Windows protégées. Les informations d’identification Windows sont utilisées pour se connecter à d’autres ordinateurs d'un réseau.

Les considérations suivantes s’appliquent aux protections Credential Guard pour le gestionnaire d’informations d’identification :

Les informations d’identification Windows enregistrées par le client Bureau à distance ne peuvent pas être envoyées à un hôte distant. Les tentatives d’utilisation des informations d’identification Windows enregistrées échouent, affichant le message d’erreur Échec de la tentative d’ouverture de session
Les applications qui extraient les informations d’identification Windows échouent
Lorsque les informations d’identification sont sauvegardées à partir d’un PC sur lequel Credential Guard est activé, les informations d’identification Windows ne peuvent pas être restaurées. Si vous devez sauvegarder vos informations d’identification, vous devez le faire avant d’activer Credential Guard

Considérations relatives à l’effacement du module de plateforme sécurisée (TPM)

La sécurité basée sur la virtualisation (VBS) utilise le module TPM pour protéger sa clé. Lorsque le module de plateforme sécurisée est effacé, la clé protégée par le module de plateforme sécurisée utilisée pour chiffrer les secrets VBS est perdue.

Warning

La désactivation de TPM aboutit à la perte des données protégées pour toutes les fonctionnalités VBS qui utilisent VBS pour protéger les données.

Lorsqu’un module TPM est effacé, toutes les fonctionnalités qui utilisent VBS pour protéger les données ne peuvent plus déchiffrer leurs données protégées.

Par conséquent, Credential Guard ne peut plus déchiffrer les données protégées. VBS crée une nouvelle clé protégée par TPM pour Credential Guard. Credential Guard utilise la nouvelle clé pour protéger les nouvelles données. Toutefois, les données précédemment protégées sont définitivement perdues.

Remarque

Credential Guard obtient la clé pendant l’initialisation. La perte de données affecte uniquement les données persistantes et se produit après le prochain démarrage du système.

Informations d’identification Windows enregistrées dans le Gestionnaire d’informations d’identification

Étant donné que le Gestionnaire d’informations d’identification ne peut pas déchiffrer les informations d’identification Windows enregistrées, elles sont supprimées. Les applications doivent demander les informations d’identification qui ont été précédemment enregistrées. Si elles sont à nouveau enregistrées, les informations d’identification Windows sont protégées par Credential Guard.

Clé publique provisionnée automatiquement d’un appareil joint à un domaine

Les appareils joints à un domaine Active Directory provisionnent automatiquement une clé publique liée. Pour plus d’informations sur l’approvisionnement automatique de clé publique, consultez Authentification par clé publique d’appareil jointe au domaine.

Étant donné que Credential Guard ne peut pas déchiffrer la clé privée protégée, Windows utilise le mot de passe de l’ordinateur joint au domaine pour l’authentification auprès du domaine. Sauf si d’autres stratégies sont déployées, il ne doit pas y avoir de perte de fonctionnalités. Si un appareil est configuré pour utiliser uniquement la clé publique, il ne peut pas s’authentifier avec un mot de passe tant que cette stratégie n’est pas désactivée. Pour plus d'informations sur la configuration d'appareils pour permettre uniquement l'utilisation d'une clé publique, voir Authentification par clé publique d'un appareil joint à un domaine.

En outre, si des vérifications de contrôle d’accès, y compris des stratégies d’authentification, nécessitent que les appareils aient les KEY TRUST IDENTITY (S-1-18-4) SID connus ou FRESH PUBLIC KEY IDENTITY (S-1-18-3) , ces vérifications d’accès échouent. Pour plus d’informations sur les stratégies d'authentification, consultez Stratégies d'authentification et Silos de stratégies d'authentification. Pour plus d’informations sur les SID connus, consultez Section 2.4.2.4 Structures de SID connues [MS-DTYP].

Interruption de DPAPI sur des appareils joints à un domaine

Sur les appareils joints à un domaine, DPAPI peut récupérer des clés utilisateur à l’aide d’un contrôleur de domaine du domaine de l’utilisateur. Si un appareil joint à un domaine n’a pas de connectivité à un contrôleur de domaine, la récupération n’est pas possible.

Important

Lors de l'effacement d'un module TPM sur un appareil joint à un domaine, il est recommandé de se trouver sur un réseau disposant d'une connectivité à des contrôleurs de domaine. Cela garantit les fonctions DPAPI, et l’utilisateur n'est pas confronté à un comportement étrange.

La configuration VPN automatique est protégée par une DPAPI utilisateur. L’utilisateur peut ne pas être en mesure d’utiliser le VPN pour se connecter aux contrôleurs de domaine, car les configurations VPN sont perdues. Si vous devez désactiver le module TPM sur un appareil joint à un domaine sans connectivité aux contrôleurs de domaine, vous devez envisager les éléments suivants.

Connexion de l’utilisateur de domaine sur un appareil joint à un domaine après l’effacement d’un module de plateforme sécurisée tant qu’il n’existe aucune connectivité à un contrôleur de domaine :

Type d'informations d'identification	Comportement
Certificat (carte à puce ou Windows Hello Entreprise)	Toutes les données protégées par l’utilisateur DPAPI sont inutilisables et dpAPI utilisateur ne fonctionne pas du tout.
Mot de passe	Si l’utilisateur s’est connecté avec un certificat ou un mot de passe avant d’effacer le TPM, il peut se connecter avec un mot de passe et l’utilisateur DPAPI n’est pas affecté.

Une fois que l’appareil dispose d’une connectivité aux contrôleurs de domaine, la DPAPI récupère la clé de l’utilisateur, et les données protégées avant l'effacement du module TPM peuvent être déchiffrées.

Impact d'une défaillance de DPAPI sur la protection des informations Windows

Lorsque des données protégées par une DPAPI utilisateur sont inutilisables, l’utilisateur perd l’accès à toutes les données de travail protégées par la Protection des informations Windows. L’impact inclut : Outlook ne peut pas démarrer et les documents protégés de travail ne peuvent pas être ouverts. Si DPAPI fonctionne, les données de travail nouvellement créées sont protégées et sont accessibles.

Solution de contournement : les utilisateurs peuvent résoudre le problème en connectant leur appareil au domaine puis en le redémarrant, ou en utilisant leur certificat d’agent de récupération de données du système de fichiers EFS. Pour plus d’informations sur le certificat d’agent de récupération de données du système de fichiers EFS, voir Créer et vérifier un certificat d’agent de récupération de données de système de fichiers EFS.

Problèmes connus

Credential Guard bloque certaines fonctionnalités d’authentification. Les applications qui nécessitent de telles fonctionnalités ne fonctionnent pas lorsque Credential Guard est activé.

Cet article décrit les problèmes connus liés à l’activation de Credential Guard.

La migration dynamique avec Hyper-V interrompt la mise à niveau vers Windows Server 2025

Les appareils qui utilisent la délégation basée sur CredSSP peuvent ne plus être en mesure d’utiliser la migration dynamique avec Hyper-V après la mise à niveau vers Windows Server 2025. Les applications et services qui s’appuient sur la migration dynamique (comme SCVMM) peuvent également être affectés. La délégation credSSP est la délégation par défaut pour Windows Server 2022 et versions antérieures pour la migration dynamique.

	Description
Appareils affectés	Tout serveur sur lequel Credential Guard est activé peut rencontrer ce problème. À compter de Windows Server 2025, Credential Guard est activé par défaut sur tous les serveurs joints à un domaine qui ne sont pas des contrôleurs de domaine. L’activation par défaut de Credential Guard peut être bloquée de manière préventive avant la mise à niveau.
Cause du problème	La migration dynamique avec Hyper-V et les applications et services qui s’en appuient sont affectées par le problème si l’une ou les deux extrémités d’une connexion donnée tentent d’utiliser CredSSP avec Credential Guard activé. Avec Credential Guard activé, CredSSP peut uniquement utiliser les informations d’identification fournies, et non les informations d’identification enregistrées ou SSO. Si la machine source d’une migration dynamique utilise CredSSP pour la délégation avec Credential Guard activé, la migration dynamique échoue. Dans la plupart des cas, l’état d’activation de Credential Guard sur l’ordinateur de destination n’aura pas d’impact sur la migration dynamique. La migration dynamique échoue également dans les scénarios de cluster (par exemple, SCVMM), car n’importe quel appareil peut agir en tant que machine source.
Résolution	Au lieu de la délégation CredSSP, la délégation Kerberos contrainte et Resource-Based délégation Kerberos contrainte sont recommandées. Ces formes de délégation offrent une meilleure protection des informations d’identification, en plus d’être compatibles avec Credential Guard. Les administrateurs d’Hyper-V peuvent configurer ces types de délégation manuellement ou à l’aide de scripts automatisés.

L’authentification unique pour les services réseau s’interrompt après la mise à niveau vers Windows 11, version 22H2 ou Windows Server 2025

Les appareils qui utilisent un réseau sans fil ou câblé 802.1x, des connexions RDP ou VPN qui s’appuient sur des protocoles non sécurisés avec une authentification par mot de passe ne peuvent pas utiliser l’authentification unique pour se connecter et sont obligés de se réauthentifier manuellement dans chaque nouvelle session Windows lorsque Credential Guard est en cours d’exécution.

	Description
Appareils affectés	Tout appareil sur lequel Credential Guard est activé peut rencontrer le problème. À compter de Windows 11, version 22H2 et Windows Server 2025, les appareils éligibles qui n’ont pas désactivé Credential Guard, sont activés par défaut. Cela affecte tous les appareils sur les licences Entreprise (E3 et E5) et Éducation, ainsi que certaines licences Pro, à condition qu’ils répondent à la configuration matérielle minimale requise. Tous les appareils Windows Pro qui exécutaient Précédemment Credential Guard sur une licence éligible et qui sont ensuite rétrogradés vers Pro, et qui répondent toujours à la configuration matérielle minimale requise, reçoivent l’activation par défaut.
Cause du problème	Les applications et les services sont affectés par le problème lorsqu’ils s’appuient sur des protocoles non sécurisés qui utilisent l’authentification par mot de passe. Ces protocoles sont considérés comme non sécurisés, car ils peuvent entraîner la divulgation du mot de passe sur le client ou le serveur, et Credential Guard les bloque. Les protocoles affectés sont les suivants : - Délégation Kerberos sans contrainte (l’authentification unique et les informations d’identification fournies sont bloquées) - Kerberos lorsque PKINIT utilise le chiffrement RSA au lieu de Diffie-Hellman (l’authentification unique et les informations d’identification fournies sont bloquées) - MS-CHAP (seule l’authentification unique est bloquée) - WDigest (seule l’authentification unique est bloquée) - NTLM v1 (seule l’authentification unique est bloquée) Remarque : Étant donné que seule l’authentification unique est bloquée pour MS-CHAP, WDigest et NTLM v1, ces protocoles peuvent toujours être utilisés en invitant l’utilisateur à fournir des informations d’identification.
Résolution	Microsoft recommande de passer des connexions basées sur MSCHAPv2 (par exemple, PEAP-MSCHAPv2 et EAP-MSCHAPv2) à l’authentification basée sur les certificats (par exemple, PEAP-TLS ou EAP-TLS). Credential Guard ne bloque pas l’authentification basée sur les certificats. Pour un correctif plus immédiat, mais moins sécurisé, désactivez Credential Guard. Credential Guard n’a pas de stratégies par protocole ou par application, et il peut être activé ou désactivé. Si vous désactivez Credential Guard, vous laissez les informations d’identification de domaine stockées vulnérables au vol.

Astuce

Pour empêcher l’activation par défaut, configurez vos appareils pour désactiver Credential Guard avant la mise à jour vers une version qui a reçu l’activation par défaut. Si le paramètre n’est pas configuré (qui est l’état par défaut) et si l’appareil est éligible, l’appareil active automatiquement Credential Guard après la mise à jour.

Si Credential Guard est explicitement désactivé, l’appareil n’active pas automatiquement Credential Guard après la mise à jour.

Remarque

Pour déterminer si un appareil Windows Pro reçoit l’activation par défaut lors de la mise à niveau vers Windows 11, version 22H2 ou Windows Server 2025, case activée si la clé IsolatedCredentialsRootSecret de Registre est présente dans Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0. S’il est présent, l’appareil active Credential Guard après la mise à jour.

Credential Guard peut être désactivé après la mise à niveau en suivant les instructions de désactivation.

Comment confirmer le problème

MS-CHAP et NTLMv1 sont pertinents pour la rupture de l’authentification unique après la mise à jour Windows 11, version 22H2. Pour vérifier si Credential Guard bloque MS-CHAP ou NTLMv1, ouvrez le observateur d'événements (eventvwr.exe) et accédez à Application and Services Logs\Microsoft\Windows\NTLM\Operational. Vérifiez les journaux suivants :

ID d’événement (type)

Description

4013 (Avertissement)

<string
id="NTLMv1BlockedByCredGuard"
value="Attempt to use NTLMv1 failed.
Target server: %1%nSupplied user: %2%nSupplied domain: %3%nPID
of client process: %4%nName
of client process: %5%nLUID
of client process: %6%nUser identity
of client process: %7%nDomain name
of user identity of client process: %8%nMechanism OID: 9%n%n
This device doesn't support NTLMv1.
/>

4014 (erreur)

<string
id="NTLMGetCredentialKeyBlockedByCredGuard"
value="Attempt to get credential key by call package blocked by Credential Guard.%n%n
Calling Process Name: %1%nService Host Tag: %2"
/>

Problèmes liés aux applications non-Microsoft

Le problème suivant affecte MSCHAPv2 :

Credential Guard ne fonctionne pas avec les configurations MSCHAPv2, dont Cisco ISE est une implémentation d’entreprise courante.

Le problème suivant affecte l’API Java GSS. Consultez l’article de la base de données des bogues Oracle suivant :

JDK-8161921 : Credential Guard n’autorise pas le partage de TGT avec Java

Lorsque Credential Guard est activé sur Windows, l’API Java GSS ne s’authentifie pas. Credential Guard bloque des fonctionnalités d’authentification d’application spécifiques et ne fournit pas la clé de session TGT aux applications, quels que soient les paramètres de clé de Registre. Pour plus d’informations, consultez Configuration requise pour l’application.

Prise en charge des fournisseurs

Les produits et services suivants ne prennent pas en charge Credential Guard :