Configurações incorretas de segurança do Active Directory

Quando as equipes perguntam quais são as configurações incorretas de segurança do Active Directory mais comuns, a resposta útil não é uma tabela de frequência. É o conjunto de falhas de controle que reaparece nos guias de hardening da Microsoft, nas recomendações da ANSSI e nas revisões recorrentes de AD, porque ainda deixam caminhos reais de elevação de privilégio, exposição de credenciais ou perda de visibilidade.

Este artigo mostra a visão misconfigurations do Active Directory. Não é uma checklist completa como Auditar a segurança do Active Directory: checklist prática, nem um guia de ordem de rollout como Endurecimento do Active Directory: o que bloquear primeiro e como validar. O objetivo aqui é mais estreito: identificar as configurações incorretas de AD que ainda mais importam, explicar por que importam e mostrar o que validar antes e depois da correção.

O que conta como uma configuração incorreta de segurança do Active Directory?

Uma configuração incorreta de segurança do Active Directory não é apenas um ajuste diferente de um benchmark. Na prática, é uma fraqueza de controle que deixa autenticação, privilégios, replicação de diretório, administração ou gestão de políticas mais ampla do que deveria para o ambiente.

É por isso que as mesmas famílias de problemas continuam voltando: contas privilegiadas em excesso, má separação de caminhos administrativos, direitos de replicação amplos demais, tráfego de diretório sem assinatura, segredos reutilizáveis de admin local, contas de serviço com senhas estáticas, configurações inseguras de delegação e controle permissivo de Group Policy. São problemas de configuração, mas se tornam problemas de caminho de ataque quando ficam em produção.

Quais são as configurações incorretas de segurança do Active Directory mais comuns?

ℹ️ Nota: esta lista não é um ranking estatístico neutro do mercado. É um Top 10 prático das famílias de configurações incorretas que reaparecem nos guias da Microsoft, da ANSSI e em revisões de AD, e que ainda criam exposição material em ambientes reais.

Configuração incorreta	Exposição principal	Deep dive
Contas privilegiadas em excesso	Deriva de privilégios e blast radius maior	Endurecimento do Active Directory
Sem separação de caminhos administrativos	Roubo de credenciais e reutilização de sessões admin	Auditar a segurança do Active Directory
Direitos de replicação amplos demais	Identidades DCSync-capable fora do escopo previsto	Auditar a segurança do Active Directory
LDAP signing não aplicado	Binds sem assinatura e controles de diretório mais fracos	LDAP Signing Disabled
SMB signing não exigido	Exposição a NTLM relay e adulteração de tráfego	SMB signing desativado
Windows LAPS não implantado	Reutilização de senhas de admin local	Windows LAPS não implantado
Controles de senha fracos	Credenciais previsíveis ou muito duradouras	Active Directory Password Security
Contas de serviço com senha estática	Segredos difíceis de girar e maior exposição	Active Directory Password Security
Delegação Kerberos insegura	Caminhos de impersonação mais amplos que o necessário	Caminhos de ataque AD
Permissões GPO perigosas	Tomada de controle de políticas e controle indireto de sistemas privilegiados	GPO Misconfigurations

1. Contas privilegiadas em excesso e grupos sensíveis

Esta é a família de configuração incorreta mais básica em AD: usuários demais, contas de serviço demais ou contas de emergência demais mantêm associação permanente a grupos altamente sensíveis ou a direitos delegados equivalentes. Microsoft e ANSSI empurram o mesmo princípio aqui: minimizar acesso privilegiado permanente e manter o escopo administrativo explícito.

O risco é direto. Cada conta privilegiada adicional aumenta a exposição de credenciais, a superfície de logon interativo, o risco ligado à delegação e o perímetro de recuperação quando uma identidade é comprometida. Na prática, o problema raramente é uma única conta Domain Admin. É a acumulação lenta de contas admin antigas, contas de suporte, contas de emergência que viraram permanentes e caminhos de aninhamento que ninguém mais limpa.

Validar antes da mudança: inventário de grupos privilegiados, aninhamentos, direitos delegados sobre ativos Tier 0 e casos reais de uso administrativo. Remover acesso sem revisar ownership e dependência operacional gera interrupções.

Evidências para guardar depois: export do inventário de grupos privilegiados, registros de remoção de acesso e lista revisada das identidades que ainda precisam de privilégio permanente.

2. Falta de separação de caminhos administrativos ou de hosts administrativos seguros

Muitos ambientes AD ainda permitem que a mesma identidade administre servidores, leia email, abra documentos e faça logon em workstations de menor confiança. O guia da Microsoft sobre secure administrative hosts existe porque acesso privilegiado não é só associação a grupo. Ele também depende de onde as credenciais administrativas ficam expostas.

Se usuários privilegiados administram a partir de endpoints de uso geral, credenciais e tokens admin têm mais chance de ser capturados, reutilizados ou explorados em movimentos laterais. Por isso, workstations administrativas dedicadas, contas separadas e um caminho administrativo limpo continuam importantes, mesmo quando a associação a grupos sensíveis já parece razoável.

Validar antes da mudança: quais administradores já usam contas separadas, quais sistemas são usados para administração e quais fluxos ainda dependem de equipamentos de uso misto. Muitas equipes descobrem que têm separação no papel, mas não no uso diário.

Evidências para guardar depois: inventário de hosts administrativos seguros ou equivalentes, restrições de logon ou atribuição de hosts admin e prova de que a administração sensível não parte mais de equipamentos não geridos ou generalistas.

3. Direitos de replicação concedidos de forma ampla demais

DCSync não é apenas um rótulo ofensivo. Operacionalmente, é um problema de permissões: identidades que não precisam de direitos de replicação os possuem assim mesmo. O Microsoft Defender for Identity destaca isso por meio da avaliação sobre contas não administrativas com permissões DCSync, porque o impacto de fundo é muito alto.

Quando Replicating Directory Changes, Replicating Directory Changes All ou direitos relacionados são concedidos de forma ampla demais, uma identidade pode solicitar dados extremamente sensíveis do diretório que deveriam permanecer sob controle estrito. A postura correta de remediação não é bloquear DCSync, mas reduzir ao conjunto mínimo pretendido os principals capazes de replicar.

Validar antes da mudança: revisar ACLs na raiz do domínio e em objetos relevantes, identificar quem hoje detém direitos de replicação e confirmar se cada detentor é realmente necessário para backup, sincronização ou tooling de segurança.

Evidências para guardar depois: snapshot da revisão de ACL, lista final aprovada das identidades com capacidade de replicação e registro mostrando que os principals removidos não mantêm mais esses direitos.

4. LDAP signing e channel binding mal aplicados

LDAP sem assinatura continua sendo um dos exemplos mais claros de um controle AD antigo, mas ainda operacionalmente importante. O guia da Microsoft sobre LDAP signing para AD DS existe porque binds SASL sem assinatura e simple binds podem enfraquecer a integridade do tráfego de diretório, e restrições de compatibilidade frequentemente deixam ambientes em implantação parcial.

A configuração incorreta raramente é um único valor de registro. Mais frequentemente, é aplicação inconsistente entre controladores de domínio, aplicações que ainda dependem de comportamento de bind mais fraco ou validação incompleta do impacto real quando as exigências aumentam.

Validar antes da mudança: inventariar clientes LDAP, identificar uso de binds sem assinatura, confirmar se LDAPS, signing ou channel binding vão afetar aplicações legadas e fazer rollout gradual antes do enforcement.

Evidências para guardar depois: configurações de policy nos controladores de domínio, resultados de teste em aplicações críticas e telemetria mostrando que os clientes esperados usam comportamento compatível.

Para o mecanismo completo e os caveats de validação, consulte LDAP Signing Disabled: How Unsigned Binds Expose Active Directory.

5. SMB signing não exigido onde ainda importa

SMB signing é outro controle que as equipes conhecem, mas adiam por suposições de performance, medo de compatibilidade ou baselines herdadas em clientes e servidores. A orientação da Microsoft ficou mais firme aqui porque SMB sem assinatura ainda deixa espaço para adulteração de tráfego e sustenta condições de NTLM relay em ambientes que não reduziram caminhos de confiança legados.

A configuração incorreta não é SMB existe. É a falta de exigência de integridade onde ela deveria existir, especialmente em sistemas que ainda aceitam fluxos de autenticação sensíveis ou que ficam em caminhos administrativos.

Validar antes da mudança: identificar dispositivos legados, sistemas embarcados, servidores antigos ou caminhos de aplicação que ainda dependam de comportamento SMB mais fraco. Verificar o estado real de signing em cliente e servidor, em vez de assumir que um lado o impõe em toda parte.

Evidências para guardar depois: estado efetivo das policies de SMB signing, registro de exceções para sistemas ainda não conformes e resultados de validação mostrando que sistemas sensíveis agora exigem assinatura.

Para a exposição de protocolo detalhada, consulte SMB signing desativado: por que ele ainda permite NTLM relay.

6. Windows LAPS não implantado

Um grande número de ambientes AD ainda protege melhor as credenciais de domínio do que as senhas de administrador local. Isso mantém um dos padrões mais antigos de exposição Windows: segredos de admin local estáticos ou reutilizados entre endpoints e, em alguns ambientes, manejo fraco das senhas DSRM em controladores de domínio.

O guia da Microsoft sobre Windows LAPS importa porque isso não é apenas higiene de workstation. Senhas de admin local reutilizáveis apoiam movimento lateral, dificultam contenção após divulgação de senha e reduzem o valor de outras medidas de hardening.

Validar antes da mudança: quais endpoints já usam Windows LAPS, se LAPS legado e Windows LAPS coexistem, como a leitura de senhas é delegada e se a gestão de DSRM está no escopo dos controladores de domínio.

Evidências para guardar depois: estado do deployment da policy, cobertura de máquinas geridas, leitores autorizados e verificação por amostragem de que as senhas giram e só podem ser recuperadas por papéis aprovados.

Os detalhes de implantação e validação estão cobertos em Windows LAPS não implantado: por que senhas locais de administrador compartilhadas continuam perigosas.

7. Políticas de senha fracas e exceções em contas privilegiadas

Uma política de senha fraca continua comum, mas o problema operacional real é mais amplo do que um único ajuste de domínio. Normalmente inclui mínimos fracos, falta de fine-grained password policies direcionadas, senhas privilegiadas muito antigas e exceções que deixam silenciosamente contas críticas fora da baseline desejada.

O guia da Microsoft sobre fine-grained password policies existe porque contas de alto valor nem sempre cabem em um único modelo de policy. Ao mesmo tempo, a ANSSI insiste que contas privilegiadas e usos administrativos exigem tratamento mais rígido do que contas de usuários gerais.

Validar antes da mudança: revisar a política de senha efetiva do domínio, eventuais fine-grained password policies, contas privilegiadas com flags de exceção, uso de Password never expires e contas de serviço ainda tratadas como contas humanas.

Evidências para guardar depois: export da policy efetiva, mapeamento de usuários ou grupos submetidos a regras reforçadas e artefatos de revisão para exceções remanescentes.

Para problemas adjacentes de credenciais, consulte Active Directory Password Security: Misconfigurations That Matter.

8. Contas de serviço legadas com senhas estáticas em vez de gMSA quando possível

Contas de serviço com senha estática continuam comuns porque sobrevivem a migrações, suportam aplicações antigas e raramente têm ownership claro de ponta a ponta. A Microsoft promove gMSA porque ele reduz a carga operacional de gestão de senha para workloads compatíveis, mas muitos ambientes ainda mantêm contas de serviço privilegiadas ou com SPN em senhas manuais e muito antigas.

O risco não se resume à idade da senha. Essas contas costumam ser superprivilegiadas, difíceis de inventariar, excluídas de revisões normais de ciclo de vida e complicadas de girar com segurança. Onde existem SPNs, credenciais de longa duração de contas de serviço também aumentam o valor de cracking offline de tickets, por isso esse tema se sobrepõe à exposição de tipo Kerberoasting.

Validar antes da mudança: inventário de contas de serviço, ownership, uso de SPN, nível de privilégio, processo de rotação de senha e compatibilidade de aplicações com gMSA. Nem todo serviço pode migrar imediatamente, então faz sentido priorizar primeiro as contas de maior risco.

Evidências para guardar depois: inventário de contas de serviço, owners documentados, decisões de migração para candidatos gMSA e evidência de rotação ou conversão para as contas que permanecerem com senha estática.

9. Delegação Kerberos insegura

A delegação Kerberos se torna uma configuração incorreta quando é mais ampla do que o desenho do serviço realmente exige. O Microsoft Defender for Identity destaca delegação insegura porque ajustes abertos demais ampliam caminhos de impersonação e alteram materialmente até onde um comprometimento pode se propagar.

Este é um bom exemplo de por que configuração incorreta comum não significa correção simples. A delegação costuma ser dirigida por requisitos de aplicação. Removê-la ou convertê-la sem validar o comportamento do serviço pode quebrar autenticação em produção.

Validar antes da mudança: inventariar delegação unconstrained, constrained e resource-based quando existir, identificar owners de aplicação e confirmar quais sistemas ainda realmente precisam de delegação.

Evidências para guardar depois: inventário revisto de delegação, configurações removidas ou convertidas e evidência de teste mostrando que os fluxos requeridos continuam funcionando após o endurecimento.

Para o efeito de cadeia mais amplo, ligue este tema a Caminhos de ataque AD: como más configurações se encadeiam.

10. Permissões GPO perigosas e controle fraco de mudanças

Group Policy se torna uma configuração incorreta de segurança quando identidades de baixa confiança ou amplas demais podem modificar GPOs de alto impacto, vincular ajustes perigosos ou alterar caminhos de policy que afetam sistemas privilegiados. Microsoft e ANSSI tratam a administração de GPO como tema de control plane, e não apenas como gestão de desktop.

O impacto vai além de um valor de policy errado. Permissões GPO perigosas podem permitir que um atacante ou operador superprivilegiado empurre execução de código, enfraqueça a segurança do host, altere grupos locais ou mude a postura de sistemas colocados em caminhos administrativos.

Validar antes da mudança: revisar quem pode editar, vincular ou criar GPOs, quais GPOs se aplicam a sistemas privilegiados e se o controle de mudanças distingue GPOs de alto impacto de alterações rotineiras de desktop.

Evidências para guardar depois: resultados de revisão de permissões GPO, listas restritas de editores, trilhas de aprovação para policies de alto impacto e cobertura de monitoramento para eventos de mudança de GPO.

Para a análise direta desse caminho, consulte GPO Misconfigurations: How Group Policy Becomes an Attack Vector.

⚠️ Se AD CS estiver implantado: fraquezas de template, enrollment e configuração de CA pertencem à mesma revisão de primeira linha, mesmo que não façam parte deste Top 10 principal. Use ADCS Attack Paths Explained como deep dive dedicado.

Por que essas configurações incorretas persistem?

Esses problemas persistem porque ficam na interseção entre compatibilidade, ownership e exceções acumuladas. Hardening de LDAP e SMB pode afetar aplicações antigas. Contas de serviço muitas vezes sobrevivem às equipes que as criaram. Ajustes de delegação permanecem porque ninguém quer quebrar autenticação. Permissões GPO derivam porque a administração de policy fica distribuída entre várias equipes. Contas privilegiadas permanecem porque removê-las exige evidência operacional, não apenas uma opinião de segurança.

É também por isso que uma revisão anual não basta. Se você verifica esses controles apenas uma vez por ano, deriva de privilégios, deriva de contas de serviço e exceções de policy podem voltar mais rápido do que o ciclo de revisão consegue detectar. Um processo recorrente importa tanto quanto a primeira limpeza. Veja Auditoria recorrente de Active Directory: por que auditorias anuais derivam.

Como validar sem adivinhar?

Uma boa correção não é apenas uma configuração alterada. É uma configuração alterada mais prova de que o controle agora é realmente aplicado e de que os fluxos necessários continuam funcionando.

Família de controle	Validar antes do enforcement	Evidências para guardar depois
Acesso privilegiado	Grupos, direitos delegados, workflows admin	Inventário revisto de privilégios e acesso permanente aprovado
Hardening LDAP e SMB	Compatibilidade de clientes, sistemas legados, testes graduais	Estado efetivo da policy e validação bem-sucedida de aplicações
LAPS e senhas	Cobertura, leitores, exceções, classes de conta	Export de policy, cobertura gerida, registro de exceções
Contas de serviço e delegação	Owners, SPNs, nível de privilégio, dependências	Inventário atualizado, decisões de migração, testes de serviço
GPO e control plane	Listas de editores, escopo de links, owners sensíveis	Revisão de permissões, trilha de aprovação, monitoramento

É aqui que logs e visibilidade de mudanças importam. Se você está alterando controles centrais de segurança de AD, também precisa saber se sua audit policy e seu modelo de coleta permitem realmente ver mudanças de grupos, ACLs de diretório, GPOs e outros eventos críticos de control plane. Use Monitoramento de segurança AD: eventos que importam se sua baseline de logs ainda for fraca.

Como a EtcSec ajuda a priorizar configurações incorretas de AD

A EtcSec é mais útil aqui quando o objetivo não é uma checklist pontual, mas uma visão repetível de quais configurações incorretas de AD ainda criam a exposição mais significativa. Findings como EXCESSIVE_PRIVILEGED_ACCOUNTS, DCSYNC_CAPABLE, LDAP_SIGNING_DISABLED, SMB_SIGNING_DISABLED, LAPS_NOT_DEPLOYED, PASSWORD_POLICY_WEAK, KERBEROASTING_RISK, UNCONSTRAINED_DELEGATION e GPO_DANGEROUS_PERMISSIONS ajudam a transformar essa lista em uma fila auditável de remediação.

O ponto importante é a repetibilidade. Depois de endurecer um controle, é preciso medir novamente se a exposição realmente desapareceu e se a deriva não a reintroduziu mais tarde. Essa é a diferença entre ler um guia de hardening uma vez e manter de fato uma postura de segurança AD ao longo do tempo.

Quais são as configurações incorretas de segurança do Active Directory mais comuns? 10 problemas para corrigir primeiro