Dans un environnement d’entreprise, la sécurité des identifiants stockés localement sur les postes Windows est un point critique souvent négligé.
Le cache LSA (Local Security Authority), composant clé du système d’authentification Windows, conserve temporairement des informations sensibles telles que les hashs de mots de passe et les tickets d’authentification.
Une mauvaise configuration du cache LSA peut exposer le réseau à des attaques comme le credential dumping ou le pass-the-hash.
Cet article vous explique comment sécuriser le cache LSA, quelle stratégie appliquer sur les postes et serveurs, et comment automatiser le tout via une clé de registre déployée par GPO.
Qu’est-ce que le cache LSA ?
Le Local Security Authority Subsystem Service (LSASS) est un processus Windows responsable de la gestion :
des connexions locales et réseau,
de la validation des utilisateurs,
et du stockage temporaire des informations d’authentification.
Pour permettre une reconnexion plus rapide (notamment en cas de déconnexion du contrôleur de domaine), Windows garde en mémoire les derniers identifiants utilisés.
Ces données sont stockées dans le cache LSA, chiffré, mais néanmoins exploitable par un attaquant disposant de privilèges élevés.
Risques liés à une mauvaise configuration du cache LSA
Laisser le cache LSA actif sur tous les postes peut représenter une faille de sécurité sérieuse :
Un malware ou un pirate avec des droits administratifs locaux peut extraire les hashs NTLM du cache.
Ces hashs peuvent être utilisés dans une attaque pass-the-hash pour accéder à d’autres systèmes.
En environnement Active Directory, cela peut faciliter la compromission latérale entre postes et serveurs.
Ainsi, limiter ou désactiver le cache LSA sur les machines non critiques est une bonne pratique en cybersécurité.
Configuration recommandée du cache LSA
Le paramètre de configuration du cache LSA est contrôlé par la clé de registre suivante :
Le nombre de comptes mis en cache est défini par la valeur DWORD :
Valeurs possibles :
| Valeur | Signification |
|---|---|
| 0 | Aucun identifiant n’est mis en cache (recommandé pour serveurs) |
| 1 à 10 | Nombre d’identifiants stockés localement (par défaut : 10) |
Bonnes pratiques :
Postes utilisateurs :
CachedLogonsCount = 1→ permet la reconnexion en cas de panne réseau tout en limitant l’exposition.Serveurs sensibles (DC, SQL, File Server, etc.) :
CachedLogonsCount = 0→ aucun cache local, sécurité maximale.Postes nomades (laptops) :
CachedLogonsCount = 2 ou 3→ compromis entre mobilité et sécurité.
Automatiser la configuration via GPO
Pour uniformiser cette configuration dans tout le parc informatique, le plus simple est de pousser la clé de registre via une stratégie de groupe (GPO).
Étapes de déploiement :
Ouvrez la console “Gestion des stratégies de groupe” (GPMC.msc).
Créez ou éditez une GPO dédiée (ex : “Sécurité LSA – CachedLogonsCount”).
Allez dans :
Ajoutez une nouvelle clé :
Action : Mettre à jour
Clé :
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinlogonNom de la valeur :
CachedLogonsCountType : REG_SZ
Donnée :
1(ou0selon le profil de la machine)
Liez la GPO aux OU correspondantes (postes, serveurs, laptops).
Cette méthode garantit une configuration homogène, sans intervention manuelle, et surtout centralisée et traçable.
Renforcer la protection du processus LSASS
Au-delà du cache, Microsoft recommande d’activer la protection du processus LSASS en mode isolé pour bloquer toute extraction mémoire.
👉 Clé de registre :
Cette mesure empêche tout outil non signé (comme Mimikatz) d’accéder à la mémoire LSASS.
Elle est hautement recommandée sur les serveurs et postes administrateurs.
Conclusion
Le cache LSA joue un rôle utile mais potentiellement risqué dans la gestion des identifiants sous Windows.
En adaptant sa configuration selon le type de machine, et en centralisant le paramétrage via GPO, vous renforcez significativement la cybersécurité de votre parc.
L’ajout d’une protection LSASS vient compléter cette approche “defense in depth”, garantissant une sécurité robuste contre les menaces modernes.
