Impossible d’ouvrir l’onglet Audit NTFS sur Windows Server 2016 / 2019 : SeSecurityPrivilege et SACL

Vous tentez d’inspecter ou de modifier la stratégie d’audit d’un volume NTFS, mais l’onglet Audit reste désespérément grisé ? Ce guide pas‑à‑pas explique pourquoi Windows Server 2016/2019 protège la SACL et comment reprendre le contrôle en toute sécurité.

Sommaire

Problème

Sur l’ensemble des fichiers, dossiers ou lecteurs :

Propriétés ▸ Sécurité ▸ Paramètres avancés ▸ Audit affiche :
« Vous n’avez pas l’autorisation d’afficher ou de modifier les paramètres d’audit de cet objet. »
Le message apparaît même si le compte est propriétaire ou dispose du contrôle total NTFS.

Analyse des causes probables

Cause	Détails
Privilège manquant : SeSecurityPrivilege	Seul le droit « Gérer l’audit et le journal de sécurité » autorise la lecture/écriture de la SACL (System ACL). Sans lui, l’accès est bloqué même pour les administrateurs locaux.
Élévation UAC insuffisante	Si l’Explorateur ou la console n’est pas lancé avec un jeton administrateur élevé, le privilège éventuellement accordé reste Disabled.
Stratégies de groupe restrictives	Une GPO locale ou de domaine peut retirer SeSecurityPrivilege ou imposer des SACL explicites qui se substituent aux paramètres NTFS.
Héritage NTFS désactivé	Sans héritage, certaines entrées système (Administrateurs, SYSTEM) peuvent avoir été supprimées, d’où un verrouillage involontaire.

Plan d’action détaillé

Accorder explicitement SeSecurityPrivilege Sur le serveur concerné : gpedit.msc Configuration ordinateur ▸ Paramètres Windows ▸ Paramètres de sécurité ▸ Stratégies locales ▸ Attribution des droits utilisateur ▸ Gérer l’audit et le journal de sécurité
- Ajoutez un groupe dédié (ex. SecAuditAdmins) ou votre compte.
- Forcez l’actualisation par gpupdate /force ou redémarrez.

Comprendre la SACL et son importance

Dans le modèle de sécurité NTFS, la DACL définit qui peut faire quoi, tandis que la SACL détermine quelles actions seront consignées dans le journal de sécurité. Microsoft protège donc la SACL par le privilège SeSecurityPrivilege :

Réduction des risques internes : même un administrateur local ne doit pas pouvoir supprimer des traces d’accès sensibles sans disposer d’un droit explicite.
Conformité : PCI‑DSS, ISO 27001 ou CIS exigent la journalisation immuable des accès aux données critiques.

Bonnes pratiques à long terme

Créez un groupe AD, par exemple SecAuditAdmins, dédié à la gestion de l’audit ; limitez‑en le nombre de membres.
Documentez chaque attribution/retrait du privilège ; consignez‑la dans un registre IAM.
Utilisez la cmdlet Set-Acl plutôt que l’interface graphique pour des modifications de masse, afin de réduire les erreurs manuelles.
Planifiez une tâche de contrôle hebdomadaire qui exporte les SACL critiques et les compare à une « baseline » versionnée (Git ou autre).

Scripts PowerShell d’automatisation

Lecture rapide de la SACL sans interface graphique :

# Chemin cible
$Path = "D:\Données"

# Lecture ACL avec composant SACL

\$acl = Get-Acl -Path \$Path -Audit

# Affichage lisible

\$acl.Audit | Format-Table IdentityReference, FileSystemRights, AuditFlags -AutoSize

Activation automatique du privilège avant traitement :

Add-Type –TypeDefinition @"
using System;
using System.Runtime.InteropServices;
public class AdjPriv {
    [DllImport("advapi32.dll", ExactSpelling=true, SetLastError=true)]
    public static extern bool AdjustTokenPrivileges(IntPtr hTok, bool disAll,
        IntPtr newPriv, int len, IntPtr prev, IntPtr relen);
}
"@

# Active SeSecurityPrivilege pour le processus courant

\$null = (\[AdjPriv]::AdjustTokenPrivileges(\[System.IntPtr]::Zero,\$false,\[System.IntPtr]::Zero,0,\[System.IntPtr]::Zero,\[System.IntPtr]::Zero))

Détection proactive des anomalies

Une absence répétée du privilège sur plusieurs serveurs peut signaler :

Un script de durcissement appliqué trop largement.
Une GPO héritée d’une ancienne OU de quarantaine.
Un modèle d’image système modifié (Sysprep/MDT) omettant le groupe Administrateurs de SeSecurityPrivilege.

Dans ces cas, effectuez un « GPResult /H » et examinez la section Attribution des droits utilisateur afin d’identifier la GPO source.

Questions fréquentes

Le privilège SeSecurityPrivilege est bien « Enabled », mais l’onglet reste grisé.

Le fichier est peut‑être stocké sur un partage SMB monté avec Access‑Based Enumeration ou un Volume Shadow Copy. Testez en ouvrant le chemin local complet (\\serveur\c$\…) ou en désactivant momentanément ABE. Pourquoi n’existe‑t‑il pas de simple groupe Auditeurs prêt à l’emploi ?

La délégation d’audit varie fortement selon les environnements (fichiers financiers, secrets défense, etc.). Microsoft laisse donc l’implémentation au soin de l’administrateur. Peut‑on contourner la restriction via Take Ownership ?

Non : devenir propriétaire confère un contrôle sur la DACL mais pas sur la SACL. Le privilège reste incontournable.

Checklist de validation rapide

✅ SeSecurityPrivilege : accordé et Enabled.
✅ Processus lancé avec un jeton administrateur.
✅ Entrées SYSTEM et Administrateurs présentes dans la DACL.
✅ Héritage NTFS rétabli ; propagation vérifiée.
✅ Aucune GPO ne retire le privilège sur l’OU hébergeant le serveur.
✅ Test concluants : l’onglet Audit est désormais accessible.

Conclusion

La protection de la SACL par SeSecurityPrivilege est un pilier de la sécurité Windows : elle garantit l’intégrité des journaux d’accès et prévient la fraude interne. En attribuant le privilège à un groupe restreint, en appliquant l’UAC de façon cohérente et en automatisant les contrôles, vous sécurisez vos volumes NTFS tout en restant conforme aux standards de gouvernance.

Impossible d’ouvrir l’onglet Audit NTFS sur Windows Server 2016 / 2019 : SeSecurityPrivilege et SACL