Sur Windows 11 24H2, l’alerte « Local Security Authority (LSA) Protection désactivée » peut s’afficher alors que le commutateur reste sur « Activé ». Voici pourquoi cela arrive, comment vérifier l’état réel et les correctifs éprouvés pour rétablir un affichage cohérent.
Pourquoi l’icône Windows Security signale que « Local Security Authority (LSA) Protection » est désactivée ?
Vue d’ensemble du problème
Sur plusieurs PC mis à jour vers Windows 11 24H2, l’application Windows Security affiche de façon intermittente un avertissement indiquant que « la protection LSA est désactivée ». En parallèle, le bouton reste positionné sur « Activé ». Après un redémarrage, l’alerte peut disparaître… puis revenir sans raison apparente. Dans la grande majorité des cas, il s’agit d’un désalignement entre l’état réel du système (LSASS protégé) et la manière dont la GUI lit certaines clés du Registre et/ou un indicateur UEFI.
Explications principales
| Cause probable | Détails |
|---|---|
| Bug d’interface (le plus courant) | L’application Windows Security peut interpréter de manière erronée l’état des indicateurs Registre/UEFI : la protection est effectivement active, mais la GUI pense le contraire. Ce défaut a été observé sur plusieurs builds, dont 24H2, et corrigé progressivement via Windows Update ainsi que des mises à jour de la plateforme Defender (par ex. KB5007651 et versions ultérieures). |
| Mise à jour Defender ou Windows inachevée | Une mise à jour interrompue (ou en attente de second redémarrage) peut laisser LSA temporairement non protégée ou mal reportée jusqu’à la finalisation du correctif. Un simple redémarrage peut suffire à réappliquer la configuration. |
| Logiciel tiers | Certains antivirus, outils d’optimisation ou modules qui injectent des DLL dans LSASS.exe peuvent perturber la protection LSA ou empêcher la GUI de lire correctement l’état. Le symptôme le plus courant : l’alerte disparaît lorsque ces logiciels sont désactivés ou désinstallés. |
Ce que signifie réellement la protection LSA
LSA (Local Security Authority) est le composant qui gère les identités et les secrets système (hashs, tickets, clés). Il s’exécute au sein du processus LSASS.exe. Lorsque la « protection LSA » est activée, LSASS.exe tourne en Protected Process Light (PPL) : seules des DLL signées de confiance peuvent s’y charger, ce qui complique fortement le vol de mots de passe en mémoire.
Sur les versions récentes de Windows 11 (22H2+ et 24H2), l’activation officielle utilise deux valeurs du Registre situées dans HKLM\SYSTEM\CurrentControlSet\Control\Lsa :
RunAsPPLRunAsPPLBoot
Ces valeurs peuvent prendre 0x0 (désactivé), 0x1 (activé avec verrou UEFI) ou 0x2 (activé sans verrou UEFI). Depuis Windows 11 22H2, 0x2 est parfaitement normal : le processus est protégé sans verrouillage UEFI, ce qui est suffisant pour la plupart des postes et évite des difficultés en cas de dépannage matériel.
| Valeur Registre | Signification | Cas d’usage | Recommandation |
|---|---|---|---|
0 ou absence | LSA non protégée (PPL désactivé) | Débogage avancé, compatibilité exceptionnelle | À éviter en production |
1 | LSA protégée avec verrou UEFI | Environnements très régulés (haute conformité) | À réserver aux postes critiques |
2 | LSA protégée sans verrou UEFI | Par défaut sur Windows 11 (22H2+) | Recommandé pour la majorité des PC |
Comment vérifier si la protection est vraiment active
Avant toute modification, validez l’état réel de LSASS.exe. Trois méthodes complémentaires :
Observateur d’événements
- Ouvrez Observateur d’événements (
eventvwr.msc). - Allez dans Journaux Windows > Système.
- Filtrez sur le fournisseur Microsoft-Windows-Wininit (ou cherchez « LSASS.exe »).
Vous devriez trouver une entrée indiquant : LSASS.exe was started as a protected process with level: 4. Si le message apparaît lors du dernier démarrage, LSA est bel et bien protégée.
PowerShell
Exécutez PowerShell en tant qu’administrateur puis lancez :
Get-WinEvent -LogName System -FilterXPath '*[System[Provider[@Name="Microsoft-Windows-Wininit"]]]' |
Select-String 'LSASS.exe was started as a protected process'
Registre
Vérifiez les clés :
HKLM\SYSTEM\CurrentControlSet\Control\Lsa
- RunAsPPL =
0x1(avec verrou UEFI) ou0x2(sans verrou UEFI) - RunAsPPLBoot =
0x1ou0x2
Astuce : assurez-vous que le type soit DWORD (32 bits), pas REG_SZ. Pour un contrôle rapide en ligne de commande :
reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPL
reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPLBoot
Informations système (optionnel)
Ouvrez msinfo32.exe et consultez les sections liées à la « Sécurité basée sur la virtualisation ». Vous pouvez y vérifier l’état de fonctionnalités telles que Credential Guard et l’intégrité de la mémoire (HVCI). Bien que ce ne soit pas un indicateur direct de LSA, ces éléments vont souvent de pair sur Windows 11.
Solutions recommandées
Appliquer toutes les mises à jour
- Ouvrez Paramètres > Windows Update > Rechercher des mises à jour et installez tout ce qui est proposé, puis redémarrez.
- Vérifiez que la plateforme Defender est à jour (au minimum une version équivalente ou plus récente que KB5007651 v1.0.2303.27001). Cette mise à jour a notamment résolu d’anciens faux positifs LSA.
- Pour afficher les versions Defender via PowerShell :
Get-MpComputerStatus | Select-Object AMProductVersion, AMServiceEnabled, AntispywareSignatureVersion
Redémarrer l’ordinateur
Un simple redémarrage synchronise souvent l’état réel (PPL) et l’interface Windows Security. Après le redémarrage, attendez 1 à 2 minutes que le service de sécurité reporte son statut.
Forcer l’activation via Registre ou GPO
Si l’alerte persiste alors que les événements confirment un PPL actif, vous pouvez forcer explicitement les clés.
Méthode Registre (.reg) :
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"RunAsPPL"=dword:00000002
"RunAsPPLBoot"=dword:00000002 </code></pre>
<p>Redémarrez ensuite le PC.</p>
<p><strong>Méthode PowerShell</strong> :</p>
<pre><code>New-Item -Path HKLM:\SYSTEM\CurrentControlSet\Control\Lsa -Force | Out-Null
New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\Lsa -Name RunAsPPL -PropertyType DWord -Value 2 -Force | Out-Null
New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\Lsa -Name RunAsPPLBoot -PropertyType DWord -Value 2 -Force | Out-Null
Write-Host "Clés appliquées. Redémarrez le système."
</code></pre>
<p><strong>Méthode Stratégie locale (GPO)</strong> :</p>
<ol>
<li>Ouvrez <code>gpedit.msc</code>.</li>
<li>Allez dans <em>Configuration ordinateur > Modèles d’administration > Système > Local Security Authority</em>.</li>
<li>Ouvrez « <strong>Configurer LSASS en processus protégé</strong> » et choisissez « <em>Activé sans verrou UEFI</em> » (ou « Activé avec verrou » si votre politique l’exige).</li>
</ol>
<div style="border:1px solid #e2e8f0;padding:12px;border-radius:6px;background:#f8fafc;">
<strong>Prudence :</strong> la modification du Registre comporte des risques. Créez un point de restauration (<em>sysdm.cpl > Protection du système</em>) avant toute action et évitez les multiples outils « tune‑up » agissant en même temps sur la sécurité.
</div>
<h3>Éliminer les interférences logicielles</h3>
<ul>
<li>Désactivez temporairement les antivirus tiers et utilitaires d’optimisation.</li>
<li>Redémarrez et vérifiez l’Observateur d’événements. Si l’alerte disparaît, mettez à jour ou remplacez le logiciel en cause.</li>
<li>En dernier recours, effectuez un démarrage minimal (<em>msconfig</em>) pour isoler le service fautif.</li>
</ul>
<h3>Surveiller les prochaines mises à jour</h3>
<p>Microsoft a progressivement corrigé la discordance d’affichage dans Windows Security : maintenir le système et Defender à jour suffit <em>généralement</em> à faire disparaître l’alerte fantôme.</p>
<h2>Procédure de diagnostic approfondie</h2>
<ol>
<li><strong>Confirmer l’état réel</strong> : recherchez l’événement <em>Wininit</em> « LSASS.exe was started as a protected process ». Si présent, LSA est active.</li>
<li><strong>Relancer la chaîne sécurité</strong> : un redémarrage complet (pas une mise en veille prolongée) synchronise souvent l’indicateur.</li>
<li><strong>Mettre à jour</strong> : installez toutes les MAJ Windows/Defender, puis redémarrez.</li>
<li><strong>Valider le Registre</strong> : <code>RunAsPPL</code> et <code>RunAsPPLBoot</code> doivent être <code>DWORD</code> avec valeur <code>1</code> ou <code>2</code>.</li>
<li><strong>Tester sans logiciels tiers</strong> : démarrage minimal et vérification de l’alerte.</li>
<li><strong>Forcer l’activation</strong> : appliquer les clés proposées ci‑dessus (valeur <code>2</code> recommandée).</li>
<li><strong>Vérifier la conformité</strong> : si une politique d’entreprise impose le verrou UEFI, passez en <code>1</code> via GPO/MDM.</li>
<li><strong>Réparer le système</strong> (rare) : si les incohérences persistent, exécutez :
<pre><code>sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
Cas entreprise (GPO, MDM, Intune)
Dans un environnement managé, l’état de LSA peut être imposé par stratégie. Quelques bonnes pratiques :
- GPO : utilisez la stratégie « Configurer LSASS en processus protégé ». Préférez « Activé sans verrou UEFI » pour la majorité des PC utilisateurs, et « Activé avec verrou UEFI » sur les postes très sensibles.
- Intune / Endpoint Security : déployez un profil Attack Surface Reduction ciblant « Local Security Authority (LSA) protection » avec la valeur attendue (On ou On with UEFI lock).
- Contrôles de conformité : vérifiez que
RunAsPPL/RunAsPPLBootsont correctement typés (REG_DWORD) et que Secure Boot/HVCI respectent votre matrice de sécurité.
Erreurs fréquentes et signaux d’alerte
- Confondre la valeur 2 avec « désactivé » :
2signifie activé sans verrou UEFI. C’est l’état attendu sur la plupart des installations récentes. - Type de valeur incorrect : si
RunAsPPLest en REG_SZ au lieu de REG_DWORD, la GUI peut se tromper. Recréez la valeur au bon type. - MAJ incomplète : après l’installation de mises à jour de plateforme Defender ou du noyau, un redémarrage supplémentaire peut être requis.
- Logiciels incompatibles : des composants injectant dans
LSASS.exepeuvent empêcher PPL. Identifiez‑les via démarrage minimal.
Questions fréquentes
La valeur 2 indique‑t‑elle une protection réduite ?
Non. Elle signifie « protection LSA active sans verrou UEFI ». Le processus reste en PPL et bénéficie du filtrage de charge des DLL. Le verrou UEFI est utile dans des environnements à exigences élevées, mais n’est pas indispensable pour la majorité des postes.
Quelle différence entre LSA Protection et Credential Guard ?
LSA Protection concerne le durcissement de LSASS.exe (PPL). Credential Guard isole les secrets à l’aide de la sécurité basée sur la virtualisation (VBS) et HVCI. Les deux renforcent la sécurité des identifiants, mais ils sont complémentaires : LSA PPL limite les injections, Credential Guard sépare les secrets dans un environnement virtuel sécurisé.
Dois‑je activer le verrou UEFI ?
Uniquement si votre politique de conformité le demande. Le verrou rend l’option plus difficile à désactiver (protection persistante avec dépendance au firmware). En contrepartie, certains scénarios de dépannage peuvent être plus contraints.
Pourquoi l’alerte revient parfois après démarrage à froid ?
Cela indique souvent un décalage de lecture des indicateurs pendant l’initialisation des services sécurité, ou une interaction avec un logiciel tiers. Assurez‑vous que toutes les mises à jour sont appliquées et testez un démarrage minimal pour exclure une interférence.
Comment savoir si tout est enfin correct ?
Trois critères simples : 1) l’événement Wininit confirme « LSASS.exe was started as a protected process » lors du dernier boot ; 2) RunAsPPL/RunAsPPLBoot valent 1 ou 2 (DWORD) ; 3) l’application Windows Security n’affiche plus d’alerte après un redémarrage complet.
Exemples prêts à l’emploi
Script PowerShell de vérification
# Vérifie l'événement Wininit confirmant PPL pour LSASS
$evt = Get-WinEvent -LogName System -FilterXPath '*[System[Provider[@Name="Microsoft-Windows-Wininit"]]]' |
Where-Object { $_.Message -match "LSASS.exe was started as a protected process" } |
Select-Object -First 1
# Lit les clés Registre
$lsa = Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\Lsa -ErrorAction SilentlyContinue |
Select-Object RunAsPPL, RunAsPPLBoot
[PSCustomObject]@{
LsaProtectedEventFound = [bool]$evt
RunAsPPL = $lsa.RunAsPPL
RunAsPPLBoot = $lsa.RunAsPPLBoot
} Script PowerShell d’activation
# Active LSA en PPL sans verrou UEFI (valeur 2), puis invite à redémarrer
New-Item -Path HKLM:\SYSTEM\CurrentControlSet\Control\Lsa -Force | Out-Null
New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\Lsa -Name RunAsPPL -PropertyType DWord -Value 2 -Force | Out-Null
New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\Lsa -Name RunAsPPLBoot -PropertyType DWord -Value 2 -Force | Out-Null
Write-Host "LSA PPL activée. Redémarrez l'appareil pour appliquer complètement la protection."
Tableau récapitulatif
| Symptôme | Réalité probable | Vérification | Action recommandée |
|---|---|---|---|
| Alerte « LSA désactivée », commutateur « Activé » | Faux positif de la GUI | Événement Wininit confirmé, clés à 1 ou 2 | Mettre à jour, redémarrer, ignorer si vérifications ok |
Valeurs RunAsPPL/RunAsPPLBoot absentes | Configuration non définie | Registre | Forcer l’activation via Registre/GPO |
| Valeurs présentes mais de type REG_SZ | Type incorrect | reg query | Supprimer et recréer en REG_DWORD |
| Alerte après installation logicielle | Interférence tierce | Démarrage minimal | Désinstaller/mettre à jour le logiciel |
Bonnes pratiques
- Garder Windows et Defender à jour : mises à jour cumulatives + plateforme Defender.
- Préférer la valeur 2 (activé sans verrou UEFI) hors exigences de conformité spécifiques.
- Limiter les outils qui touchent à LSASS : évitez les injections non signées et les optimisateurs « magiques ».
- Contrôler régulièrement l’état via l’Observateur d’événements, surtout après de grosses mises à jour.
Résumé
Sur Windows 11 24H2, l’alerte « LSA protection désactivée » est, le plus souvent, un bug d’affichage. Si l’événement Wininit confirme que LSASS.exe démarre en Protected Process Light et que RunAsPPL/RunAsPPLBoot valent 1 ou 2, la protection est bien active. Installez toutes les mises à jour, redémarrez, puis corrigez les clés si nécessaire. La valeur 2 est normale depuis Windows 11 22H2+ et garantit une protection robuste sans verrouillage UEFI.