Windows Server 2012 : corriger l’enflure de lsass.log (LSASS/NTLM, Registre, GPO)

Sur un contrôleur de domaine Windows Server 2012, le fichier C:\Windows\System32\lsass.log peut croître de plusieurs Mo/s et saturer le disque en quelques jours. Ce guide explique comment diagnostiquer la cause, arrêter immédiatement la croissance et empêcher sa réapparition.

Sommaire

Contexte et symptômes

Vous observez une inflation spectaculaire du fichier lsass.log sur un contrôleur de domaine Windows Server 2012. Un redémarrage réinitialise la taille du fichier, mais la croissance reprend aussitôt. La machine reste fonctionnelle mais le risque de panne est réel : volumes système saturés, sauvegardes qui échouent et services Active Directory dégradés.

Processus associé : lsass.exe (Local Security Authority Subsystem Service), cœur de l’authentification Windows (NTLM, Kerberos, politique de sécurité locale).
Fichier concerné : C:\Windows\System32\lsass.log.
Symptômes : I/O disque soutenus, montée CPU transitoire sur lsass.exe, LSASS monopolise des handles de fichiers, l’espace libre diminue en continu.

Pourquoi `lsass.log` enfle-t-il ?

Dans la majorité des cas, l’inflation provient d’une journalisation de débogage LSASS activée involontairement (souvent après le déploiement d’un correctif de sécurité ou d’une GPO de diagnostic). Cette journalisation, destinée à résoudre des problèmes d’authentification NTLM, écrit des traces extrêmement bavardes vers lsass.log. Tant qu’elle reste active, le fichier croît rapidement.

Trois valeurs du Registre contrôlent ce comportement :

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LogToFile (DWORD) : active l’écriture vers le fichier.
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LspDbgTraceOptions (DWORD) : options de trace NTLM.
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LspDbgInfoLevel (DWORD) : niveau de détail des traces NTLM.

Objectif : remettre ces trois valeurs à 0 pour couper l’écriture et supprimer le verbiage NTLM.

Vue d’ensemble de la résolution

Approche	Détails	Remarques
Vérifier qu’il s’agit d’un journal de débogage LSASS	Ouvrir `lsass.log` : des traces NTLM et des piles d’appels confirment le diagnostic.	Entrées très verbeuses et répétitives.
Désactiver la journalisation via le Registre	Dans `HKLM\SYSTEM\CurrentControlSet\Control\Lsa` : • `LogToFile` (DWORD) → `0` • `LspDbgTraceOptions` (DWORD) → `0` • `LspDbgInfoLevel` (DWORD) → `0`	Créer les valeurs si elles n’existent pas.
Supprimer ou vider le fichier après modification	Arrêter le service NTDS (ou redémarrer), supprimer `lsass.log`, relancer le service.	Ne pas supprimer pendant que LSASS écrit dedans.
Contrôler l’absence de journaux résiduels	Surveiller pendant 24 h : la taille doit rester nulle ou très faible (< 1 Mo).	Si la croissance reprend, vérifier GPO/scripts qui réécrivent les clés.
Mettre le serveur à niveau	Windows Server 2012 est fin de support (10 octobre 2023). Un passage à 2019/2022 élimine des risques de réactivation accidentelle et assure les mises à jour de sécurité.	Si contrainte de rester en 2012 : documenter la modification et la rejouer après restauration.

Checklist de diagnostic rapide

Confirmer le chemin et la taille : C:\Windows\System32\lsass.log gagne plusieurs Mo/s.
Consulter quelques lignes du fichier : présence de messages de trace NTLM et de contextes de sécurité.
Vérifier l’existence des clés LogToFile, LspDbgTraceOptions, LspDbgInfoLevel dans le Registre.
Contrôler qu’aucune GPO « Préférences → Registre » ne pousse ces valeurs.
Observer PerfMon : Process(lsass) → IO Data Bytes/sec, Working Set; LogicalDisk → % Free Space.

Procédure détaillée et sécurisée

Avant de commencer

Planifier un créneau de maintenance (idéalement hors production).
Disposer d’un compte avec privilèges d’Administrateur du domaine.
Effectuer une sauvegarde du Registre : reg export HKLM\SYSTEM backup_system.reg.
Vérifier la santé AD (réplication OK) pour éviter de cumuler les incidents.

Désactiver la journalisation via PowerShell

Exécutez sur le contrôleur affecté :

# 1) Désactiver/normaliser les clés de trace LSASS/NTLM
$lsaPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa'
$props = @('LogToFile','LspDbgTraceOptions','LspDbgInfoLevel')
foreach ($p in $props) {
  if (-not (Get-ItemProperty -Path $lsaPath -Name $p -ErrorAction SilentlyContinue)) {
    New-ItemProperty -Path $lsaPath -Name $p -PropertyType DWord -Value 0 | Out-Null
  } else {
    Set-ItemProperty -Path $lsaPath -Name $p -Value 0
  }
}

# 2) Arrêter AD DS pour libérer le fichier (ou prévoir un redémarrage immédiat)

Stop-Service -Name NTDS -Force

# 3) Purger le fichier de log

\$log = 'C:\Windows\System32\lsass.log'
if (Test-Path \$log) { Remove-Item \$log -Force }

# 4) Redémarrer AD DS

Start-Service -Name NTDS

Remarques importantes :

Sur un contrôleur de domaine, Stop-Service NTDS interrompt temporairement l’authentification locale (prévoir un DC voisin disponible).
Si l’arrêt du service n’est pas possible, planifiez un redémarrage juste après la modification du Registre, puis supprimez le fichier à la remontée (il ne se régénérera plus).

Équivalent via l’Éditeur du Registre

Ouvrez regedit.exe.
Accédez à HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.
Pour chaque valeur :
- LogToFile : type REG_DWORD, données : 0.
- LspDbgTraceOptions : REG_DWORD = 0.
- LspDbgInfoLevel : REG_DWORD = 0.
Redémarrez ou arrêtez/relancez NTDS, puis supprimez lsass.log.

Déploiement à l’échelle via GPO

Pour éviter les régressions et appliquer la correction à tous les contrôleurs :

Ouvrez Gestion des stratégies de groupe.
Créez ou éditez une GPO liée à l’OU des contrôleurs de domaine.
Parcourez : Configuration ordinateur → Préférences → Paramètres Windows → Registre.
Ajoutez trois éléments Registre en Création (ou Mise à jour) :
- Clé : HKLM\SYSTEM\CurrentControlSet\Control\Lsa, Valeur : LogToFile, Type : REG_DWORD, Données : 0.
- Valeur : LspDbgTraceOptions, Type : REG_DWORD, Données : 0.
- Valeur : LspDbgInfoLevel, Type : REG_DWORD, Données : 0.
Forcer l’application : gpupdate /force puis redémarrer les DC concernés lors d’un créneau prévu.

Validation post‑remédiation

Vérifier que lsass.log n’est plus recréé (ou reste < 1 Mo).
Surveiller pendant 24 h l’espace disque ; aucun pic anormal ne doit apparaître.
Contrôler les journaux Applications and Services Logs → Microsoft → Windows → NTLM et Security : l’audit standard continue, seule la trace de débogage a été coupée.
Confirmer que l’authentification (Kerberos/NTLM) fonctionne côté clients, serveurs applicatifs et comptes de service.

Automatisation et durcissement

Script PowerShell idempotent (runbook)

# Désactivation durable de la trace LSASS & nettoyage du log
$lsa = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa'
$kv = @{
  'LogToFile'          = 0
  'LspDbgTraceOptions' = 0
  'LspDbgInfoLevel'    = 0
}
foreach ($k in $kv.Keys) {
  New-ItemProperty -Path $lsa -Name $k -Value $kv[$k] -PropertyType DWord -Force | Out-Null
}

# Optionnel: arrêt AD DS si environnement tolère l'interruption (sinon planifier reboot)

try {
Stop-Service NTDS -ErrorAction Stop -Force
} catch {}

# Suppression sécurisée

\$path = 'C:\Windows\System32\lsass.log'
if (Test-Path \$path) { Remove-Item \$path -Force }

# Relance

try { Start-Service NTDS } catch {}

# Affichage de l'état

Get-ItemProperty -Path \$lsa -Name LogToFile, LspDbgTraceOptions, LspDbgInfoLevel | Format-List

Surveillance proactive

Alerte taille de fichier : tâche planifiée exécutant toutes les 5 min : $f='C:\Windows\System32\lsass.log' if (Test-Path $f) { $size = (Get-Item $f).Length/1MB if ($size -gt 50) { Write-EventLog -LogName Application -Source 'LSASSMonitor' -EntryType Warning -EventId 3001 -Message "lsass.log atteint $([int]$size) Mo" } } Astuce : créez au préalable la source d’événements LSASSMonitor.
PerfMon : journal de collecte sur Process(lsass)\IO Data Bytes/sec et LogicalDisk\% Free Space avec seuils d’alerte.
Intégration SIEM : alerte sur la réapparition des clés non nulles.

Considérations de sécurité

La désactivation des traces de débogage n’impacte pas l’audit standard de sécurité ni Kerberos.
Ne confondez pas avec la Protection LSA (RunAsPPL) : ne la désactivez pas.
Conservez un runbook décrivant la procédure, pour réappliquer rapidement après restauration d’image ancienne.

Cas particuliers et bonnes pratiques

Environnement avec plusieurs DC : traitez par vagues (site par site) pour maintenir la résilience. Vérifiez dcdiag et la réplication après chaque vague.
RODC : la procédure s’applique de la même manière.
Serveur membre non‑DC : la problématique est plus rare, mais les clés et la méthode restent valables.
Serveurs critiques : coordonnez avec sauvegardes, monitoring et fenêtres de maintenance applicatives.

Alternative : redémarrage contrôlé

Si l’arrêt de NTDS n’est pas possible, procédez ainsi :

Positionner les trois valeurs du Registre à 0.
Planifier et exécuter un redémarrage court.
Vérifier que lsass.log n’est pas recréé ; sinon, supprimer manuellement le fichier.

Mise à niveau recommandée

Windows Server 2012 est en fin de support depuis le 10 octobre 2023. Rester sur cette version augmente les risques opérationnels et de sécurité (correctifs indisponibles, comportements de compatibilité hérités). Une migration vers Windows Server 2019 ou 2022 est conseillée ; vous bénéficierez d’une pile d’authentification plus récente, d’un durcissement par défaut et d’un cycle de support actif.

Foire aux questions

La taille repart à la hausse après quelques jours. Pourquoi ?
Une GPO, un script de conformité ou une image de restauration réécrit probablement les clés du Registre. Inspectez les Préférences → Registre des GPO liées aux DC et corrigez‑les.

Est‑ce dangereux de supprimer lsass.log ?
Non, c’est un fichier de trace de débogage. Assurez‑vous simplement que NTDS est arrêté (ou que vous redémarrez), afin que le handle ne soit plus ouvert.

La désactivation impacte‑t‑elle l’audit sécurité ?
Non. Vous coupez la trace de débogage NTLM, pas les journaux d’audit classiques du canal Sécurité.

Comment vérifier qu’aucune application ne dépend de ces traces ?
En production, aucune application ne doit exiger des traces de débogage LSASS. Ces traces ne sont activées que pour un diagnostic ponctuel.

Guide opératoire (récapitulatif)

Diagnostiquer : confirmer que lsass.log grossit et contient des traces NTLM.
Désactiver : positionner LogToFile, LspDbgTraceOptions, LspDbgInfoLevel à 0.
Nettoyer : arrêter NTDS (ou redémarrer), supprimer lsass.log.
Valider : surveiller 24 h, aucune croissance anormale (< 1 Mo).
Prévenir : appliquer la GPO, mettre en place un monitoring et planifier la mise à niveau.

Exemple de rapport de clôture d’incident

Incident : inflation de lsass.log (> 30 Go en 72 h) sur DC‑PAR‑01.
Cause racine : trace de débogage LSASS active (clés non nulles).
Action : désactivation via GPO + purge du fichier après arrêt de NTDS.
Résultat : taille stable (< 1 Mo) après 48 h de monitoring. Aucun impact utilisateur.

Points clés à retenir

Ce n’est pas normal qu’un lsass.log vive et enfle en production : c’est presque toujours un mode debug laissé activé.
La correction tient en trois valeurs du Registre à mettre à 0 et un nettoyage contrôlé du fichier.
Stabilisez la solution via GPO et monitoring pour éviter toute régression.
Anticipez une mise à niveau : Windows Server 2012 n’est plus supporté.

Annexes

Commande rapide de vérification

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' `
  -Name LogToFile, LspDbgTraceOptions, LspDbgInfoLevel 2>$null |
  Format-List

Get-ChildItem 'C:\Windows\System32\lsass.log' -ErrorAction SilentlyContinue |
Select-Object FullName, @{n='Taille(Mo)';e={\[math]::Round($\_.Length/1MB,2)}}

Détection de réapparition des clés

# A exécuter périodiquement par tâche planifiée
$lsa = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa'
$v = Get-ItemProperty -Path $lsa -Name LogToFile,LspDbgTraceOptions,LspDbgInfoLevel -ErrorAction SilentlyContinue
if ($v.LogToFile  -ne 0 -or
    $v.LspDbgTraceOptions -ne 0 -or
    $v.LspDbgInfoLevel -ne 0) {
  Write-EventLog -LogName Application -Source 'LSASSMonitor' -EntryType Error -EventId 3002 -Message 'Trace LSASS réactivée.'
}

Procédure de suppression manuelle sûre

Vérifier que LogToFile=0, LspDbgTraceOptions=0, LspDbgInfoLevel=0.
Arrêter NTDS ou planifier un redémarrage.
Supprimer C:\Windows\System32\lsass.log.
Relancer NTDS (si applicable) et valider le comportement pendant 24 h.

Conclusion

La croissance fulgurante de lsass.log sur Windows Server 2012 est un signal de débogage laissé actif, pas une fatalité. En neutralisant la journalisation LSASS via le Registre, en purgeant le fichier de log de manière contrôlée, puis en verrouillant la configuration par GPO et monitoring, vous éliminez durablement le risque de saturation disque — tout en préservant l’audit de sécurité standard. Si votre feuille de route le permet, profitez de l’incident pour programmer la migration vers une version de Windows Server encore supportée.

En appliquant la désactivation des trois valeurs du Registre puis en supprimant le fichier, de nombreux administrateurs constatent que lsass.log ne se régénère plus après redémarrage et que la taille reste stable dans la durée.