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

Outre le déploiement de Credential Guard, il est recommandé aux organisations de passer 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 au Wi-Fi et au VPN

Lorsque vous activez Credential Guard, vous ne pouvez plus utiliser l’authentification classique NTLM pour l’authentification unique. 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 à Kerberos

Lorsque vous activez Credential Guard, vous ne pouvez plus utiliser la délégation Kerberos sans contraintes ou le chiffrement DES. La délégation sans contraintes peut permettre aux personnes malveillantes d’extraire les clés Kerberos du processus LSA isolé.
Utilisez plutôt la délégation Kerberos avec contraintes ou basée sur les ressources.

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 à la mise à niveau

À mesure que la profondeur et l’étendue des protections fournies par Credential Guard sont accrues, les nouvelles versions de Windows avec Credential Guard en cours d’exécution peuvent affecter les scénarios qui fonctionnaient dans le passé. Par exemple, Credential Guard peut bloquer l’utilisation d’un type particulier d’informations d’identification ou d’un composant particulier pour empêcher les programmes malveillants de tirer parti des vulnérabilités.

Les scénarios de test requis pour les opérations dans un organization avant la mise à niveau d’un appareil à l’aide de Credential Guard.

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. Il se peut que l'utilisateur ne puisse pas utiliser un VPN pour se connecter à des 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.

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

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 s’authentifier manuellement à nouveau dans chaque nouvelle session Windows lorsque Credential Guard est en cours d’exécution.

Appareils affectés

Tout appareil sur lequel Credential Guard est activé peut rencontrer le problème. Dans le cadre de la mise à jour Windows 11 version 22H2, les appareils éligibles qui n’ont pas désactivé Credential Guard sont activés par défaut. Cela affectait 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 ultérieurement rétrogradés vers Pro, et qui répondent toujours à la configuration matérielle minimale requise, recevront l’activation par défaut.

Astuce

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, 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.

Vous pouvez désactiver Credential Guard après la mise à niveau en suivant les instructions de désactivation.

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 quand 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.

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"
/>

Comment résoudre le problème

Nous vous recommandons de passer des connexions basées sur MSCHAPv2, telles que PEAP-MSCHAPv2 et EAP-MSCHAPv2, à l’authentification basée sur les certificats, comme 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 Windows 11 version 22H2. 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.

Problèmes liés aux applications non-Microsoft

Le problème suivant affecte MSCHAPv2 :

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

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 :

Important

Cette liste n’est pas complète. Vérifiez si votre fournisseur de produit, votre version de produit ou votre système informatique prend en charge Credential Guard sur les systèmes qui exécutent une version spécifique de Windows. Des modèles de système informatique spécifiques peuvent être incompatibles avec Credential Guard.