Dans cette note d’information, je souhaite vous partager un sujet d’actualité qui peut avoir un impact à court terme sur les infrastructures Wi-Fi et filaires 802.1x.
Qu’est-ce que Credential Guard ?
Windows Defender Credential Guard est une fonctionnalité de sécurité introduit par Microsoft pour la première fois sur Windows 10 et Windows 2016 Server. Elle permet de protéger les informations d’identification de domaine. Avant Credential Guard, les identifiants de connexion d’un ordinateur Windows étaient stockées dans la RAM directement. De ce fait, ils étaient accessibles par n’importe quel utilisateur du poste, qu’il soit administrateur du poste ou non. Avec Credential Guard, ces identifiants sont désormais stockés dans un conteneur virtuel sécurisé auquel le système d’exploitation ne peut pas directement accéder. L’intérêt de cette fonctionnalité est de sécuriser l’accès à ces données critiques qui pouvaient auparavant être obtenues facilement par un attaquant (via l’utilisation d’outil comme Mimikatz par exemple). Le schéma ci-dessous illustre le fonctionnement de Credentials Guard et on y voit le conteneur sécurisé dans lequel les identifiants « single sign-on » (les identifiants d’ouverture de session) sont désormais stockés :
Microsoft a accéléré l’adoption de cette fonctionnalité. Ainsi, à partir de la version Windows 11 22H2 (20 septembre 2022), Credential Guard est désormais activé par défaut.
Quels problèmes Credential Guard pose-t-il pour nos infrastructures 802.1x Wi-Fi et filaire ?
Cette fonctionnalité a pour effet de « casser » la connexion automatique des machines Windows en 802.1x lorsqu’elles utilisent une authentification par utilisateur et mot de passe. Plus précisément, on parle dans ce cas des authentifications en EAP-PEAP MS-CHAPv2 (ou protocoles de sécurité inférieures) qui utilisent le compte utilisateur ou le compte machine. Après l’ouverture de session, Credential Guard empêche Windows d’accéder aux identifiants « single sign-on » stockés désormais dans le conteneur virtualisé, forçant ainsi l’utilisateur à saisir manuellement son identifiant et mot de passe lorsqu’il souhaite se connecter au réseau Wi-Fi (ou filaire) sécurisé par 802.1x.
Même si EAP-PEAP MS-CHAPv2 n’est pas l’authentification la plus sécurisée qui existe, elle est encore largement utilisée dans de nombreux réseaux. La généralisation de Credential Guard va donc entrainer des problèmes de connexion pour les utilisateurs sur ces réseaux.
Notons que les authentifications plus sécurisées comme EAP-TLS (authentification par certificat) ne sont pas affectées par l’activation de Credential Guard.
Comment prévenir et corriger ce problème ?
Avec l’activation par défaut de Credential Device à partir de la version Windows 11 22H2, la vision de Microsoft est claire : il souhaite voir disparaitre les méthodes d’authentification moins sécurisées au profit des méthodes plus sécurisées comme l’authentification par certificat avec EAP-TLS. D’un point de vue sécurité, la vision de Microsoft est la bonne car EAP-TLS a plusieurs avantages :
- L’authentification par certificat utilisateur est bien plus robuste qu’une authentification par utilisateur/mot de passe.
- Grâce à l’utilisation de certificats, les équipements autorisés à se connecter sur un réseau sont bien mieux maitrisés par les administrateurs. En effet, pour les utilisateurs finaux, il est beaucoup plus complexe de partager un certificat plutôt qu’un couple identifiant/mot de passe. L’intérêt est donc d’éviter que les utilisateurs puissent connecter n’importe quel type de terminal sur le réseau.
- EAP-TLS est une méthode d’authentification sûre alors que MS-CHAPv2 est connu pour être vulnérable à certaines attaques.
La vision court/moyen terme est donc de migrer les authentifications EAP-PEAP MS-CHAPv2 vers EAP-TLS. Précisons que ce type d’authentification nécessite l’utilisation d’une PKI (pour générer et gérer les certificats utilisés lors de l’authentification) et d’un système de configuration centralisé (pour pousser ces certificats sur les terminaux ; une GPO ou un MDM par exemple). Sur une infrastructure Microsoft, une PKI AD CS (Active Directory Certificate Services) est généralement préconisée pour permettre un déploiement plutôt facile et rapide d’EAP-TLS. Il existe également d’autres solutions de CA (Certification Authority) hébergées dans le cloud comme SCEPman ou Microsoft Cloud PKI.
Existe-t-il tout de même une solution temporaire pour contourner Credential Guard lorsque l’infrastructure n’est pas prête à migrer vers EAP-TLS ?
Oui, Microsoft a publié un article pour désactiver Credential Guard sur les machines Windows, via deux solutions : soit par GPO soit en modifiant quelques clés de registre.
Néanmoins, la solution à court/moyen terme est de migrer l’authentification EAP-PEAP MS-CHAPv2 des postes Windows vers EAP-TLS.
Conclusion
L’activation par défaut de Credential Guard sur les dernières versions de Windows 11 nous montre clairement la vision de Microsoft sur ce sujet. Plutôt que de subir les problèmes engendrés par la dépréciation de l’authentification par utilisateur/mot de passe, nous devons anticiper et migrer les environnements utilisateurs Windows vers de l’authentification EAP-TLS. Ces projets sont également l’occasion d’accroitre la sécurité de nos infrastructures Wi-Fi et filaires, tout en profitant du déploiement d’une PKI pour étendre ces bonnes pratiques de sécurité au-delà des seuls terminaux Windows.
Références sur le même sujet
- Documentation officielle Windows sur Credential Guard : https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard-how-it-works
- Post sur communauté Cisco : https://community.cisco.com/t5/network-access-control/windows-11-22h2-credential-guard-enforcement/td-p/4695655
- Article Extreme Networks : https://extremeportal.force.com/ExtrArticleDetail?an=000100238
- Post sur communauté Reddit : https://www.reddit.com/r/sysadmin/comments/xju508/windows_11_22h2_credential_guard_default/