Si al intentar abrir la pestaña Auditoría de un archivo, carpeta o volumen NTFS en Windows Server 2016/2019 recibes el mensaje “No tiene permiso para ver o editar la configuración de auditoría de este objeto” aun siendo administrador, esta guía práctica y exhaustiva te mostrará por qué ocurre y cómo solucionarlo paso a paso.

Descripción del problema

En el Explorador de archivos o en la consola fsutil, la ruta Propiedades → Seguridad → Opciones avanzadas → Auditoría debería mostrar la lista de entradas SACL (System Access Control List) que definen qué operaciones sobre el objeto se registran en el Visor de eventos (Security log). Sin embargo, en algunos servidores aparece la alerta:

No tiene permiso para ver o editar la configuración de auditoría de este objeto.

Como consecuencia:

• No es posible agregar ni modificar entradas SACL desde la interfaz gráfica.
• Los administradores pierden visibilidad de eventos de seguridad críticos.
• Scripts de cumplimiento normativo que dependen de la GUI fallan.

Entendiendo la pestaña Auditoría

La pestaña Auditoría presenta las SACL almacenadas en el descriptor de seguridad del objeto. Verlas o editarlas requiere el derecho SeSecurityPrivilege (Manage auditing and security log), independiente de los permisos DACL (lectura, escritura, control total). Por diseño, este privilegio está limitado a:

• SYSTEM
• Integrantes del grupo local Administrators (salvo que una GPO lo retire)

Sin dicho privilegio, Windows filtra la SACL y la GUI arroja el error descrito.

Causas habituales

1. SeSecurityPrivilege ausente en la cuenta actual.
2. Directivas (GPO) que reescriben la asignación de privilegios en cada actualización de directivas.
3. Herencia de permisos deshabilitada en el objeto, lo que impide que la SACL del contenedor padre se aplique.
4. UAC: ejecutar el Explorador sin elevación causa que el token carezca de privilegios incluso si la cuenta los posee.

Comprobaciones preliminares

Antes de hacer cambios, verifica:

• ¿Estás usando una sesión Elevated? Abre un símbolo del sistema con Run as administrator.
• ¿El objeto hereda permisos? Si herencia está desactivada, habilítala temporalmente.
• ¿Puedes habilitar auditoría mediante CLI? Ejecuta:

whoami /priv | findstr /i SeSecurityPrivilege
auditpol /get /subcategory:"File System"

Guía paso a paso para restaurar el acceso

Paso	Acción	Detalles
1	Conceder SeSecurityPrivilege	En la consola gpedit.msc o en una GPO de dominio: Equipo → Configuración de Windows → Configuración de seguridad → Directivas locales → Asignación de derechos de usuario → Administrar registro y directiva de auditoría. Añade tu usuario o un grupo (p. ej. Administrators, Auditors).
2	Aplicar y reiniciar sesión	Los derechos de usuario se cargan al iniciar sesión; cierra sesión (o reinicia el servidor) para que el nuevo token incluya SeSecurityPrivilege.
3	Verificar herencia	En Seguridad → Opciones avanzadas marca «Incluir los permisos heredables»; esto replica las SACL desde el contenedor padre.
4	Elevar con UAC	Abre el Explorador o mmc.exe como administrador. Si el problema persiste, vuelve al Paso 1: la cuenta todavía carece del privilegio.
5	Revisar GPO de dominio	Usa gpresult /r o el RSOP para detectar GPO que quitan SeSecurityPrivilege. Corrige la directiva o crea una que se aplique al OU del servidor.

Procedimiento detallado

1. Otorgar el privilegio SeSecurityPrivilege

La forma más fiable es mediante GPO porque evita que futuras actualizaciones lo deshagan:

1. Abre gpmc.msc, crea o edita una directiva vinculada al contenedor del servidor.
2. Navega a Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → User Rights Assignment.
3. Haz doble clic en Manage auditing and security log, pulsa Add User or Group… y selecciona la cuenta o grupo.
4. Haz OK y actualiza la política con gpupdate /force.

Nota: en controladores de dominio, solo Domain Admins y SYSTEM lo tienen de fábrica; si se retira, los registros de auditoría podrían quedar sin gestionar.

2. Aplicar la directiva y renovar el token

Para minimizar interrupciones:

• Reinicia únicamente el explorer.exe del usuario con taskkill /f /im explorer.exe && start explorer.
• Verifica que el privilegio aparezca como Enabled en whoami /priv.

3. Restaurar la herencia en objetos huérfanos

Si el objeto se creó mediante scripts que desactivan la herencia (icacls /inheritance:d), el SACL podría estar vacío. Utiliza PowerShell:

$path = "D:\Datos\Informe"
$acl  = Get-Acl $path
$acl.SetAccessRuleProtection($false,$true) # Activa la herencia, conserva reglas existentes
Set-Acl -Path $path -AclObject $acl

4. Ejecutar con elevación UAC

Aun con el privilegio habilitado, el token linked generado por UAC no lo contiene si la aplicación no solicita elevación. Opciones:

• Shift+click derecho “Abrir ventana de PowerShell aquí como administrador”.
• Crear un acceso directo con Run as administrator predeterminado.
• Deshabilitar UAC para administradores solo en entornos de laboratorio.

5. Inspeccionar y corregir políticas de dominio conflictivas

Ejecuta:

gpresult /S localhost /USER %username% /H C:\gp.html & start C:\gp.html

En la sección User Rights Assignment localiza la línea SeSecurityPrivilege. La última GPO de la lista gana; si allí no aparece tu cuenta, modifícala o cambia la precedencia con enlaces de mayor prioridad.

Automatización con PowerShell DSC

Para garantizar consistencia en granjas de servidores, implementa Desired State Configuration:

Configuration AuditPrivilege {
    param([string[]]$NodeName)
    Import-DscResource -ModuleName SecurityPolicyDsc
    Node $NodeName {
        UserRightsAssignment AuditRight {
            Policy      = 'SeSecurityPrivilege'
            Identity    = 'CONTOSO\Auditors'
            Ensure      = 'Present'
        }
    }
}

Ejecuta Start-DscConfiguration -Path .\AuditPrivilege -Wait -Verbose y olvídate de drift.

Buenas prácticas de hardening

• Principio de mínimo privilegio: delega SeSecurityPrivilege solo a roles que realmente revisen los registros.
• Auditoría limitada: habilita solo las subcategorías necesarias (integridad, acceso a objetos críticos) para evitar llenar el Security log.
• Retención de logs: redirige eventos a un SIEM o actívalos como Forwarded Events para preservar evidencia en caso de saturación del disco.
• Supervisión GPO: usa alertas en Azure Arc, Microsoft Defender for Identity o scripts de comprobación de integridad que disparen un ticket si la asignación de privilegios cambia.

Preguntas frecuentes

¿Puedo acceder a la SACL solo con permisos de propietario?

No. Ser propietario otorga el derecho de modificar la DACL, pero la SACL exige SeSecurityPrivilege, ya que afecta la seguridad global del sistema.

¿Qué ocurre si concedo el privilegio a un usuario estándar?

Podrá borrar incluso eventos de seguridad, lo que rompe la cadena de custodia. Mantén el privilegio restringido a cuentas de auditoría o servicio SIEM con trazabilidad.

¿Por qué en algunos servidores 2016 funciona y en otros no?

Probablemente existen diferencias de GPO. Un servidor en una OU distinta hereda otra directiva que modifica User Rights Assignment.

Conclusión

La imposibilidad de abrir la pestaña Auditoría casi siempre se resume en la ausencia o revocación inadvertida de SeSecurityPrivilege. Otorgarlo mediante GPO, forzar la actualización de directivas y usar sesiones elevadas devuelve el acceso inmediato. Complementa la solución con automatización DSC y una estrategia de auditoría selectiva para proteger registros y mantener la conformidad normativa.