Le processus lsass.exe n’est pas un intrus : c’est le service qui authentifie les ouvertures de session et applique la stratégie de sécurité locale de Windows. Quand il monte en charge, la cause vient presque toujours de ce qui lui parle, pas de lui : requêtes d’annuaire coûteuses sur un contrôleur de domaine, ou boucle d’authentification sur un poste.
Points clés
- lsass.exe est le Local Security Authority Subsystem Service, décrit par Microsoft comme un processus système protégé qui authentifie et connecte les utilisateurs.
- Il conserve en mémoire chiffrée les identifiants des sessions Windows actives, ce qui explique pourquoi Microsoft l’entoure de protections spécifiques.
- Le fichier légitime se trouve dans C:\Windows\System32 et il n’y a qu’une seule instance dans une session Windows normale.
- Sur un contrôleur de domaine, une forte charge processeur de lsass.exe se diagnostique avec le jeu de collecteurs de données Active Directory de l’Analyseur de performances.
- La protection LSA est activée par défaut sur les nouvelles installations de Windows 11 22H2 et versions ultérieures qui remplissent les critères de Microsoft.
Ce que fait lsass.exe, concrètement
Derrière le sigle LSASS il y a l’autorité de sécurité locale. Microsoft la définit comme un processus système protégé qui authentifie les utilisateurs sur l’ordinateur local, tient à jour la stratégie de sécurité locale, et assure la traduction entre les noms de comptes et les identifiants de sécurité, les fameux SID.
Ce n’est donc pas un utilitaire optionnel. Chaque ouverture de session, chaque accès à un partage réseau, chaque renouvellement de ticket Kerberos passe par lui. Le service charge des modules d’authentification distincts, dont la bibliothèque du serveur LSA, qui choisit entre NTLM et Kerberos selon le contexte.
Deuxième rôle, moins visible : LSASS garde en mémoire les identifiants des sessions ouvertes, pour que vous n’ayez pas à ressaisir votre mot de passe à chaque accès à une boîte Exchange ou à un site SharePoint. Depuis Windows 8.1, cette mémoire est chiffrée et accessible uniquement par lsass.exe, précise la documentation Microsoft. C’est aussi ce qui fait de ce processus une cible de choix, et la raison des mécanismes de durcissement décrits plus bas.
Le bon fichier, et l’imitation
Le processus légitime s’exécute depuis C:\Windows\System32\lsass.exe, sous le compte Système. Un binaire portant un nom voisin ailleurs sur le disque n’est pas le même programme. Dans le Gestionnaire des tâches, onglet Détails, un clic droit puis Ouvrir l’emplacement du fichier tranche la question en deux secondes.
Deux vérifications suffisent ensuite : le chemin, et la signature numérique du fichier dans ses propriétés. Si l’un des deux ne correspond pas, vous ne traitez plus un problème de performance mais un incident de sécurité, à confier à l’équipe qui gère le parc plutôt qu’à un utilitaire de nettoyage. Et non, on ne supprime pas ce fichier : c’est une brique du système, pas un composant à désinstaller.
Pourquoi lsass.exe consomme du processeur
Sur un poste de travail, la charge de lsass.exe est normalement invisible. Une pointe au moment de l’ouverture de session, du déverrouillage ou d’un changement de mot de passe, puis retour au calme. Une charge continue signale un flux d’authentification anormal : script qui boucle, tâche planifiée qui se réauthentifie sans arrêt, application métier qui ouvre et ferme des sessions à la chaîne.
Sur un contrôleur de domaine, le tableau change. Microsoft consacre une page de dépannage à l’utilisation élevée du processeur par Lsass.exe sur les contrôleurs de domaine Active Directory, et liste les symptômes associés : contrôleur lent ou muet face aux demandes d’authentification, clients qui basculent vers un autre contrôleur, compteur de temps processeur du processus durablement haut.
La cause la plus fréquente citée par Microsoft n’est pas un défaut du service mais la charge qui lui arrive : des requêtes LDAP coûteuses, envoyées par des applications distantes, ou un volume de requêtes plus élevé que ce que le serveur peut absorber. La documentation de réglage des performances Active Directory détaille ces requêtes inefficaces et la façon de les tracer.
- Requêtes LDAP non indexées ou trop larges lancées par une application de sauvegarde, de supervision ou de gestion de parc.
- Volume d’authentification qui augmente après la mise hors service d’un autre contrôleur de domaine.
- Poste client pris dans une boucle d’échec d’authentification, souvent après un changement de mot de passe.
- Couche de sécurité tierce qui s’interpose sur les appels d’authentification.
- Charge normale mal dimensionnée : le serveur fait son travail, il manque simplement de ressources.
Diagnostiquer une forte charge, dans l’ordre
Commencez par mesurer plutôt que supposer. Dans le Gestionnaire des tâches, onglet Détails, ajoutez la colonne du temps processeur et observez si la charge est continue ou par pics. Le Moniteur de ressources montre ensuite les connexions réseau associées, ce qui permet de repérer la machine qui interroge le serveur.
Sur un contrôleur de domaine, l’outil prévu est le jeu de collecteurs de données Active Directory de l’Analyseur de performances, à lancer pendant que le problème se produit. Microsoft explique de lire d’abord la partie Résultats des diagnostics du rapport, puis la catégorie Active Directory, qui détaille les requêtes LDAP qui pèsent sur les performances, et la partie Réseau pour identifier les clients à l’origine du trafic.
Complétez avec l’Observateur d’événements, journal Système et journaux de sécurité, pour dater le début du phénomène. Un événement d’échec d’authentification répété toutes les quelques secondes vaut mieux qu’une longue hypothèse. La démarche générale que nous décrivons pour un processeur à 100 % sans raison apparente s’applique aussi ici.
Protection LSA, Credential Guard : pourquoi ce processus est isolé
Parce que LSASS manipule des secrets, Windows l’isole. La protection LSA empêche les processus non protégés de lire sa mémoire et d’y injecter du code. Elle se configure par la valeur RunAsPPL sous la clé de registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa, avec la donnée 1 pour l’activer avec verrou UEFI, ou 2 pour l’activer sans verrou UEFI, cette dernière valeur n’étant appliquée qu’à partir de Windows 11 version 22H2.
Sur les postes clients, Microsoft indique que la protection LSA est activée par défaut à partir de Windows 11 22H2 lorsque trois conditions sont réunies : installation neuve et non mise à niveau, appareil joint à un domaine Active Directory ou à Entra, et compatibilité avec l’intégrité du code protégée par l’hyperviseur.
Credential Guard va plus loin. Avec cette fonctionnalité, le processus LSA du système dialogue avec un processus LSA isolé, LSAIso.exe, qui stocke les secrets dans un espace protégé par la sécurité basée sur la virtualisation, inaccessible au reste du système. Conséquence pratique côté dépannage : voir LSAIso.exe dans la liste des processus n’est pas une anomalie, c’est le signe que Credential Guard est actif.
Un effet de bord existe cependant. Une couche d’authentification tierce non compatible avec la protection LSA peut être bloquée au chargement. Si une application d’entreprise perd l’authentification unique après l’activation de cette protection, le journal des événements du fournisseur d’identité le dira avant tout autre outil.
Ce qu’il ne faut pas faire
- Tenter de terminer le processus depuis le Gestionnaire des tâches : c’est un processus système protégé, pas une application.
- Supprimer ou remplacer le fichier, ou suivre un tutoriel qui propose de le télécharger. Un fichier système ne se télécharge pas.
- Désactiver la protection LSA pour faire disparaître un message d’incompatibilité, sans avoir cherché le composant fautif.
- Conclure à une infection sur la seule base du nom affiché. Le chemin et la signature décident, pas l’intuition.
Quand la charge ne vient pas de lsass.exe
Le Gestionnaire des tâches désigne souvent le mauvais coupable. Sur un poste lent, deux autres processus sortent bien plus fréquemment que LSASS : le moteur d’analyse de Microsoft Defender, dont nous détaillons les cas de charge dans notre article sur Antimalware Service Executable, et le processus des applications modernes, traité dans Runtime Broker et sa consommation processeur.
La chaîne de mise à jour joue le même tour, avec un processus au nom obscur qui travaille en arrière-plan pendant une recherche de mises à jour : c’est le sujet de notre fiche sur MoUsoCoreWorker.exe. Vérifiez donc quel processus consomme réellement, sur plusieurs minutes, avant de partir sur une piste d’authentification.
Sur un serveur de fichiers ou un contrôleur de domaine, l’indexation et l’antivirus restent aussi des suspects sérieux, en particulier quand les exclusions recommandées par l’éditeur n’ont jamais été appliquées.
Questions fréquentes
lsass.exe est-il un virus ?
Non. C’est un composant de Windows situé dans C:\Windows\System32. Des logiciels malveillants ont utilisé des noms proches pour passer inaperçus, d’où l’intérêt de vérifier le chemin et la signature numérique du fichier plutôt que le nom affiché.
Peut-on désactiver le service pour économiser des ressources ?
Non, et le gain serait nul. Sans autorité de sécurité locale, plus d’ouverture de session ni d’application de la stratégie de sécurité. Si la charge est réelle, elle vient de ce qui sollicite le service, pas du service lui-même.
Pourquoi lsass.exe occupe-t-il autant de mémoire sur un contrôleur de domaine ?
Sur un contrôleur de domaine, le service travaille avec la base d’annuaire et met en cache une partie des données consultées. Une occupation mémoire élevée y est donc courante. Le signal à surveiller est le temps processeur soutenu et la lenteur des réponses aux clients, pas la mémoire seule.
Deux processus lsass.exe, est-ce normal ?
Dans une session Windows classique, non. En revanche, une machine qui héberge des conteneurs ou des machines virtuelles affiche les processus de ces environnements, ce qui n’a rien d’anormal. Le chemin de chaque instance permet de trancher.
Faut-il activer la protection LSA sur un poste isolé ?
Microsoft l’active par défaut sur les nouvelles installations de Windows 11 22H2 et ultérieures répondant à ses critères, notamment la jonction à un domaine. Sur un poste autonome, l’activation manuelle par le registre reste possible, en vérifiant d’abord la compatibilité des outils d’authentification tiers installés.
Photo d’en-tete : capture du Gestionnaire des taches de Windows par PantheraLeo1359531, Wikimedia Commons, domaine public. La capture illustre le suivi de charge processeur en general, pas le processus lsass.exe en particulier.
Sources : Microsoft Learn, processus d’identification dans l’authentification Windows ; Microsoft Learn, configurer la protection LSA supplémentaire ; Microsoft Learn, fonctionnement de Credential Guard ; Microsoft, résoudre l’utilisation élevée du processeur par Lsass.exe ; Microsoft Learn, considérations LDAP pour Active Directory. Consultées le 13 septembre 2026.
Michel, dirigeant d’une PME informatique et formateur, expert en logiciels professionnels tels que CRM et ERP. Sa connaissance approfondie des outils de gestion d’entreprise lui permettant de conseiller et former efficacement d’autres sociétés à leur utilisation.
