Windows Server 2016/2019: como corrigir o erro ao acessar a guia Auditing (SACL)

Ao tentar abrir a guia Auditing em servidores Windows Server 2016/2019 você vê “you do not have permission to view or edit this object’s audit settings”? A raiz do problema é privilégio, não NTFS. Veja abaixo a explicação e um passo a passo direto para corrigir.

Índice

Visão geral do problema

Ao acessar Propriedades → Segurança → Avançado → Auditing de um arquivo, pasta ou volume, surge a mensagem:

“you do not have permission to view or edit this object’s audit settings”.

Isso costuma acontecer mesmo quando a conta tem Full control, é membro de Administrators ou até é proprietária do objeto. As demais guias de segurança funcionam normalmente — apenas a guia Auditing falha.

O que está por trás do erro

A guia Auditing lê e escreve a SACL (System Access Control List). Diferentemente da DACL (que rege o “quem pode acessar”), a SACL controla o que será auditado e é protegida por um privilégio do sistema, não por “Full control”.

Conceitos essenciais (sem jargão desnecessário)

Componente	Função	Quem controla	O que preciso para editar
DACL (Discretionary ACL)	Permite/nega acesso (Read/Write/Execute etc.)	Permissões NTFS do objeto	Permissões NTFS (p. ex., Full control)
SACL (System ACL)	Define o que será auditado (sucesso/falha)	Privilégio de conta do sistema	SeSecurityPrivilege (Manage auditing and security log)
UAC / Token	Controla privilégios habilitados no processo	Elevação do processo (Run as administrator)	Janela aberta em contexto elevado para ativar o privilégio

Em muitos ambientes, uma baseline de segurança ou GPO remove o direito Manage auditing and security log dos Administrators. Mesmo quando o direito existe, se a janela foi aberta sem elevação (UAC), o privilégio não está ativo no token do processo e a guia falha.

Diagnóstico rápido

Antes de mudar políticas, confirme o cenário. Execute em um Prompt de Comando ou PowerShell elevado (Executar como administrador):

whoami /priv | findstr /i SeSecurityPrivilege

SeSecurityPrivilege exibido como Enabled: o processo elevado tem o privilégio ativo.
Exibido como Disabled ou não listado: o usuário não possui o direito ou a janela não está elevada.

Confira também a filiação da conta:

whoami /groups

Se suspeitar de GPO removendo o direito, gere um relatório de Resultant Set of Policy:

gpresult /h C:\Temp\gp.html

Abra o relatório e verifique User Rights Assignment → Manage auditing and security log para saber qual GPO está “ganhando”.

Correção passo a passo

Conceda o privilégio SeSecurityPrivilege

O ajuste preferencial é no nível de GPO de domínio aplicada aos servidores. Como alternativa, use a política local do servidor alvo.

Política local (servidor isolado): abra secpol.msc → Políticas Locais → Atribuição de direitos de usuário → Gerenciar auditoria e log de segurança (Manage auditing and security log) → adicione os grupos adequados (p. ex., Administrators, Domain Admins ou um grupo específico de suporte).
GPO de domínio (recomendado): abra gpmc.msc → edite a GPO aplicada aos servidores (ou crie uma dedicada de “Baseline de Servidores”) → Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment → ajuste Manage auditing and security log.
Controladores de domínio: edite uma GPO que se aplique aos DCs (muitos ambientes usam a Default Domain Controllers Policy para esse direito específico); valide cuidadosamente.

Depois de aplicar a mudança, atualize a política e renove o token de logon:

gpupdate /force

Faça logoff/logon da conta administrativa (ou desconecte/reconecte a sessão RDP) para que o novo privilégio seja incorporado ao token.

Abra a interface a partir de um processo elevado

Como o UAC filtra privilégios, você precisa que a janela de Propriedades seja aberta por um processo com elevação:

Abra PowerShell ou Prompt de Comando com Executar como administrador.
A partir dele, abra a ferramenta que você usa para administrar o servidor (p. ex., um MMC como Computer Management iniciado elevado) e acesse as Propriedades do item alvo.
Se ainda assim a guia falhar, retorne ao gpresult para identificar a GPO que está negando/removendo o direito e ajuste a precedência.

Herança e escopo do SACL (opcional, mas importante)

A permissão para ver a guia não depende de herança, porém a herança determina como suas entradas de auditoria se propagam. Ao criar uma entrada, defina o escopo em Aplica-se a (ex.: Essa pasta, subpastas e arquivos) conforme a necessidade.

Ative as políticas de auditoria para gerar eventos

Sem política de auditoria, o SACL não produz eventos. Em uma GPO aplicada aos servidores:

Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Object Access → habilite Audit File System para Success e/ou Failure conforme o seu caso.

Após aplicar, eventos como 4656 (solicitação de handle) e 4663 (tentativa de acesso a objeto) começarão a surgir no log Security, se disparados pelas condições do SACL.

Checklists práticos

Checklist de correção rápida

Verifique o privilégio no token: whoami /priv | findstr /i SeSecurityPrivilege
Garanta o direito via GPO ou política local em Manage auditing and security log.
Execute gpupdate /force e faça logoff/logon.
Abra a janela a partir de um processo elevado.
Se necessário, habilite Audit File System na Advanced Audit Policy.

Comandos úteis

whoami /priv | findstr /i SeSecurityPrivilege   :: Verifica se o privilégio está no token
whoami /groups                                  :: Confirma filiação a Administrators/Domain Admins
gpupdate /force                                 :: Atualiza GPOs
gpresult /h C:\Temp\gp.html                     :: Descobre a GPO efetiva (RSoP)</code></pre>

<h2>Cenários típicos e como resolver</h2>
<h3>Baseline endurecida removeu o direito</h3>
<p>Ambientes com baseline (CIS/STIG/Custom) costumam retirar <em>Manage auditing and security log</em> dos <em>Administrators</em>. Solução: crie um <strong>grupo de suporte</strong> (p. ex., <em>Server Audit Admins</em>) e conceda apenas a esse grupo. Documente a exceção e monitore o uso.</p>

<h3>Conta com “Full control” mas sem privilégio</h3>
<p>“Full control” governa a <strong>DACL</strong>, não a <strong>SACL</strong>. A solução é conceder <em>SeSecurityPrivilege</em> via GPO/política local e abrir a interface elevada.</p>

<h3>Edição remota</h3>
<p>Se você está administrando <em>remotamente</em> (MMC remoto ou PSRemoting), o privilégio deve existir no <strong>servidor de destino</strong>. Garanta a concessão na GPO aplicada ao alvo, não apenas no seu computador.</p>

<h3>Servidor Core sem GUI</h3>
<p>Em edições Server Core, use:
  <ul>
    <li>GPO para conceder o privilégio.</li>
    <li>MMC remoto (<em>Computer Management</em>) aberto elevado a partir de uma estação de administração.</li>
    <li>Ou manipule o SACL via PowerShell (exemplo mais abaixo).</li>
  </ul>
</p>

<h2>Automação e linha de comando (opcional)</h2>
<h3>Aplicação local do direito com secedit</h3>
<p>Para um ajuste pontual (laboratório ou servidor isolado), você pode usar <code>secedit</code>. Preferencialmente use GPO em produção.</p>
<ol>
  <li>Exporte a política local:
    <pre><code>secedit /export /cfg C:\Temp\sec.inf</code></pre>
  </li>
  <li>Edite <code>sec.inf</code> e ajuste a linha do direito. Exemplos de valores:
    <pre><code>SeSecurityPrivilege = *S-1-5-32-544           ; BUILTIN\Administrators
; ou incluindo um grupo de domínio:
SeSecurityPrivilege = *S-1-5-32-544, CONTOSO\Domain Admins

<p>Dica: usar SIDs (*S-1-5-…) evita problemas de idioma/nome.</p>

Reaplique a política:

secedit /configure /db C:\Windows\Security\Local.sdb /cfg C:\Temp\sec.inf /areas USER_RIGHTS

Atualize e faça logoff/logon:

gpupdate /force

PowerShell para criar uma regra de auditoria

Depois de ter o privilégio e com a janela elevada, você pode também manipular SACL por script (útil em Server Core):

$path = 'C:\Dados'
$acl  = Get-Acl -Path $path
$rule = New-Object System.Security.AccessControl.FileSystemAuditRule(
    'CONTOSO\AuditedUsers',          # Identidade
    'ReadData, WriteData, Delete',   # Direitos
    'ContainerInherit, ObjectInherit',
    'None',
    'Success, Failure'               # Disparos
)
$acl.AddAuditRule($rule)
Set-Acl -Path $path -AclObject $acl

Se surgir erro de acesso, confirme novamente o SeSecurityPrivilege no token do processo (whoami /priv) e a elevação do PowerShell.

Boas práticas de segurança

Princípio do menor privilégio: conceda Manage auditing and security log apenas a grupos operacionais que realmente precisem editar SACL ou limpar o log de segurança.
Controle de acesso de emergência: considere um grupo “break glass” monitorado e com MFA obrigatório para operações sensíveis como auditoria.
Monitoramento: acompanhe eventos de alteração de política de auditoria (ex.: 4719) e uso do log de segurança.
Processos sempre elevados para tarefas de auditoria: padronize atalhos que abram PowerShell/MMC com “Executar como administrador”.

Erros comuns a evitar

Reduzir o UAC para contornar o problema. Não é necessário nem recomendado. Use processos elevados quando precisar.
Confiar em “Full control” achando que cobre SACL. “Full control” cobre DACL, não SACL.
Alterar diretamente a guia sem GPO em ambientes gerenciados. A GPO pode “reverter” na próxima atualização.

Validação pós-correção

Confirme o privilégio ativo: whoami /priv | findstr /i SeSecurityPrivilege
Abra a guia Auditing a partir de uma janela elevada. A mensagem de erro deve desaparecer; você conseguirá ver e editar a SACL.
Se políticas de auditoria foram habilitadas, force um acesso ao objeto e verifique o log Security (IDs como 4663).

Perguntas frequentes

Sou proprietário do arquivo. Por que não consigo ver a SACL?
Porque a SACL é protegida por privilégio de sistema (SeSecurityPrivilege). Ser proprietário ajuda na DACL, mas não autoriza leitura/edição da SACL.

Adicionar “Domain Admins” resolve?
A depender da baseline, sim. Porém, melhor prática é um grupo de suporte dedicado ao tema (auditoria) em vez de incluir grandes grupos administrativos.

É obrigatório desabilitar o UAC?
Não. O necessário é abrir a interface a partir de um processo elevado. Desabilitar UAC reduz a segurança do servidor.

Preciso reiniciar o servidor?
Não. Em geral, gpupdate /force e logoff/logon são suficientes para o token incorporar o novo privilégio.

Funciona com compartilhamentos SMB?
A edição da SACL é feita no sistema de arquivos do servidor que hospeda os dados. Tenha o privilégio concedido naquele servidor.

Resumo executivo

Se a guia Auditing não abre em Windows Server 2016/2019, o problema não é permissão NTFS, e sim privilégio. Conceda SeSecurityPrivilege (Manage auditing and security log) via GPO ou política local, atualize as políticas e abra a janela a partir de um processo elevado. Se necessário, habilite as políticas de auditoria para gerar eventos. Com isso, a mensagem desaparece e a guia passa a ser exibida e editável de forma consistente em todos os servidores.

Verificações rápidas

whoami /priv | findstr /i SeSecurityPrivilege   :: Verifica se o privilégio existe no token
whoami /groups                                  :: Confirma filiação a Administrators/Domain Admins

Resultado esperado
Com o privilégio Manage auditing and security log concedido e a janela aberta de forma elevada, a mensagem some e a guia Auditing passa a ser exibida e editável em todos os servidores Windows Server 2016/2019 sob sua administração.