Microsoft AZ-801: Segurança do Active Directory Domain Services — Guia de estudos

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Faz parte do Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

O Active Directory Domain Services (AD DS) é a base da identidade e do acesso em redes Windows. Proteger o AD DS significa controlar como as credenciais são criadas, armazenadas e usadas; restringir onde identidades privilegiadas podem se autenticar; fortalecer os protocolos de autenticação; auditar ações de alto valor; e garantir uma recuperação confiável. Esta seção aborda políticas de senha e de conta refinadas, proteções de identidade privilegiada, fortalecimento e delegação de autenticação, auditoria e SACLs, a Lixeira (Recycle Bin), assinatura e vinculação de canal LDAP (LDAP signing and channel binding), o comportamento do AdminSDHolder, backup e restaurações autoritativas, incluindo a recuperação do SYSVOL, e o modelo de camadas (tiering) do AD.

Políticas de Credenciais e Controles de Identidade Privilegiada

Políticas de senha refinadas (PSOs) permitem múltiplas políticas de senha/bloqueio em um único domínio sem a necessidade de domínios extras. As PSOs são objetos msDS-PasswordSettings armazenados em CN=Password Settings Container,CN=System,<domain DN> (o msDS-PasswordSettingsContainer). Uma PSO se aplica a usuários e grupos de segurança globais através do atributo msDS-PSOAppliesTo. Quando um usuário tem múltiplas PSOs aplicáveis (diretamente ou via grupos), a PSO resultante é aquela com o menor valor de msDS-PasswordSettingsPrecedence; se houver um empate, a PSO com o menor GUID prevalece. A PSO efetiva do usuário é registrada em msDS-ResultantPSO. Projete as PSOs de forma que números de precedência mais baixos correspondam às políticas mais restritivas que você deseja que prevaleçam e valide as políticas efetivas lendo o msDS-ResultantPSO.

O grupo de segurança Protected Users fortalece contas de alto valor removendo comportamentos de autenticação legados e arriscados. Os membros:

Não podem usar NTLM, Digest ou CredSSP
Têm o uso de RC4 e DES negado para o Kerberos
Não podem ser delegados via Kerberos (de forma irrestrita ou restrita)
Recebem TGTs não renováveis com um tempo de vida curto e fixo (padrão de 4 horas)
Não armazenam em cache credenciais em texto plano ou segredos de longo prazo na estação de trabalho (impede o fallback do WDigest e que o material de credencial permaneça no LSASS) Use este grupo para identidades privilegiadas operadas por humanos e proprietários de serviços de alto risco após validar a compatibilidade das aplicações. Os domain controllers devem executar o Windows Server 2012 R2 ou posterior para impor essas proteções.

Políticas de autenticação e silos de política de autenticação restringem onde e como as contas podem se autenticar. Uma política de autenticação pode definir restrições de Kerberos por conta, como o tempo de vida do TGT e os dispositivos permitidos (por SPN/FQDN do host). Um silo de política de autenticação agrupa usuários, computadores e contas de serviço para que apenas as combinações permitidas possam se autenticar usando Kerberos, restringido por essa política. Isso impõe controles do tipo “station-to-admin”: por exemplo, administradores da Camada 0 (Tier 0) só podem fazer logon em domain controllers e em estações de trabalho de acesso privilegiado (PAWs) designadas, mas não em servidores membros ou estações de trabalho. Combine com o grupo Protected Users para obter o máximo efeito. Esses recursos exigem DCs com Windows Server 2012 R2 e KDC armoring.

O AdminSDHolder e o SDProp protegem as ACLs de identidades privilegiadas. Membros de grupos de administradores internos (por exemplo, Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Server Operators, Backup Operators, Print Operators e outros) são “protegidos”. O SDProp é executado a cada hora no PDC Emulator, copiando a ACL de CN=AdminSDHolder,CN=System para os objetos protegidos e desabilita a herança de ACL neles (AdminCount=1). Para conceder direitos de helpdesk sobre objetos protegidos, altere a ACL no AdminSDHolder — nunca diretamente nos objetos protegidos individuais — caso contrário, a alteração será revertida. Quando uma conta é removida de todos os grupos protegidos, reabilite a herança de ACL e limpe o AdminCount para que as ACLs e GPOs no nível da OU voltem a ser aplicadas.

Adote um modelo de camadas (tiering) do AD para minimizar a exposição de credenciais. A Camada 0 (Tier 0) contém domain controllers, sistemas de identidade (PKI, federação, PAM) e as contas de administrador que os gerenciam. A Camada 1 (Tier 1) contém cargas de trabalho de servidor e seus administradores. A Camada 2 (Tier 2) contém estações de trabalho e seus administradores. Impeça o logon entre as camadas, use PAWs para a administração das Camadas 0 e 1 e isole as credenciais usando recursos como Protected Users, silos de autenticação, Remote Credential Guard, Just-Enough Administration (JEA) e Windows LAPS para rotação de senha do administrador local.

Reforço de Segurança da Autenticação e Delegação

A assinatura (signing) e a vinculação de canal (channel binding) do LDAP protegem contra ataques de retransmissão (relay) e man-in-the-middle. Configure os controladores de domínio para exigir assinatura via Group Policy: Configuração do Computador\Configurações do Windows\Configurações de Segurança\Políticas Locais\Opções de Segurança\“Controlador de domínio: requisitos de assinatura do servidor LDAP” = Exigir assinatura. Exija a assinatura do cliente sempre que possível: “Segurança de rede: requisitos de assinatura do cliente LDAP” = Exigir assinatura. Para LDAPS, habilite a vinculação de canal nos DCs definindo LDAPEnforceChannelBinding em HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters como 1 (Habilitado, recomendado) ou 2 (Sempre). Faça um inventário de dispositivos e aplicações legadas; habilitar a assinatura ou a vinculação de canal pode quebrar associações (binds) anônimas/simples ou pilhas LDAP antigas. Monitore o log de eventos do Directory Service: 2886 (assinatura não exigida), 2887 (resumo de associações simples não assinadas), 2888 (assinatura ainda desabilitada), 2889 (IPs de clientes realizando associações simples não assinadas quando o log de diagnóstico está habilitado). Implemente as alterações em modo de “Aviso” (channel binding=1) antes de forçar o modo “Sempre” (2).

A delegação Kerberos controla como os serviços agem em nome dos usuários:

A delegação irrestrita (“Confiar neste computador para delegação a qualquer serviço (somente Kerberos)”) permite que um serviço receba um TGT encaminhável e personifique usuários para qualquer serviço. Isso é de alto risco; evite em favor de modelos restritos.
A delegação restrita (KCD) (“Confiar neste computador para delegação apenas a serviços especificados”) limita para onde um serviço pode delegar (lista de SPNs de destino). Com “Usar qualquer protocolo de autenticação”, o serviço pode usar a transição de protocolo (S4U2Self) e, em seguida, o S4U2Proxy para alcançar os back-ends especificados.
A delegação restrita baseada em recursos (RBCD) transfere o controle para o recurso, definindo msDS-AllowedToActOnBehalfOfOtherIdentity na conta de serviço de destino. O proprietário do recurso concede quais entidades principais (principals) de front-end podem delegar a ele, simplificando cenários entre domínios e minimizando a superfície de ataque. Prefira a RBCD para designs modernos; audite e verifique periodicamente os SPNs e as configurações de delegação.

Auditoria e Resiliência

A auditoria do AD DS deve ser deliberada e específica. Use a Configuração Avançada de Política de Auditoria (Advanced Audit Policy Configuration) para habilitar subcategorias em vez de categorias legadas e defina “Auditoria: forçar que as configurações da subcategoria de política de auditoria substituam as configurações da categoria de política de auditoria” para garantir a consistência. As subcategorias recomendadas incluem Gerenciamento de Contas (Account Management), Logon/Logoff (Logon, Logoff, Logon Especial), Logon de Conta (Serviço de Autenticação Kerberos/Operações de Tíquete de Serviço) e Alterações/Acesso ao Serviço de Diretório. IDs de eventos chave:

4720 (Uma conta de usuário foi criada) de Gerenciamento de Contas
4740 (Uma conta de usuário foi bloqueada) de Gerenciamento de Contas
4625 (Falha no logon de uma conta) de Logon/Logoff
4648 (Foi tentado um logon usando credenciais explícitas) de Logon/Logoff Complemente com Alterações no Serviço de Diretório para capturar os valores de quem/o quê/antigo/novo para atributos críticos (eventos 5136/5137/5139). Para auditar alterações específicas (por exemplo, associação a grupos, SPNs, ACLs), configure SACLs em objetos ou OUs alvo (habilite os Recursos Avançados no ADUC, abra a guia Segurança do objeto > Avançado > Auditoria). Adicione entradas para auditar “Gravar todas as propriedades” ou propriedades específicas (member, servicePrincipalName) e “Modificar permissões/proprietário” conforme necessário. Valide se os logs chegam a um SIEM central e se os logs de Segurança dos DCs têm retenção suficiente.

A Lixeira do AD DS (Recycle Bin) protege contra exclusões acidentais, preservando todos os atributos e backlinks de objetos excluídos. Habilite-a uma vez por floresta (irreversível) via ADAC ou PowerShell (Enable-ADOptionalFeature -Identity ‘Recycle Bin Feature’ -Scope ForestOrConfigurationSet -Target <forest>). Após a habilitação, um objeto excluído permanece em um estado de “objeto excluído” durante o tempo de vida definido em msDS-DeletedObjectLifetime (se não definido, o padrão é tombstoneLifetime), período no qual ele pode ser totalmente restaurado com os atributos intactos. Depois disso, ele se torna um objeto reciclado e não pode mais ser restaurado com seus atributos, sendo posteriormente coletado pelo processo de “garbage collection”. Florestas modernas geralmente têm um tombstoneLifetime padrão de 180 dias; florestas mais antigas podem ter 60. Restaure com o ADAC, LDP ou PowerShell (Restore-ADObject) e prefira a recuperação autoritativa de associação a grupos via Lixeira em vez de readições manuais para evitar o desvio de privilégios (privilege drift).

Backups e restauração autoritativa são as últimas linhas de proteção. Faça backups frequentes do Estado do Sistema (System State) de cada controlador de domínio usando o Windows Server Backup ou o wbadmin (wbadmin start systemstatebackup). Para reversões em nível de objeto que vão além da Lixeira, execute uma restauração não autoritativa do Estado do Sistema e, em seguida, use o ntdsutil para marcar objetos ou OUs específicos como autoritativos (aumentando sua versão para que a replicação os reaplique). Entenda a diferença: a restauração não autoritativa traz o DC de volta e aplica a replicação atual; a autoritativa marca um objeto para que a versão restaurada sobrescreva réplicas mais recentes. Para o SYSVOL usando a Replicação DFS (DFSR), execute a recuperação não autoritativa ou autoritativa:

Não autoritativa: Pare o serviço DFSR, defina a assinatura do SYSVOL do membro afetado como não autoritativa (msDFSR-Options=0), inicie o DFSR para que ele se reidrate a partir de um parceiro upstream.
Autoritativa: No DC bom escolhido, defina a assinatura do SYSVOL como autoritativa (msDFSR-Options=1), inicie o DFSR e, em seguida, force os parceiros a ressincronizar (DFSRDIAG PollAD). Valide a saúde com o dfsrdiag backlog e os logs de eventos. Para o FRS legado (sem suporte), migre para o DFSR e evite os procedimentos com BurFlags.

Juntando Tudo: Operações, Prioridades de Fortalecimento e Acesso em Camadas

Priorize a Camada 0 (Tier 0) primeiro: imponha a assinatura/vinculação de canal do LDAP, remova a delegação irrestrita, mude para KCD/RBCD, coloque identidades privilegiadas no grupo Protected Users e vincule políticas/silos de autenticação para restringir os endpoints de logon, e exija PAWs para administradores das Camadas 0 e 1. Estabeleça PSOs para contas privilegiadas com bloqueio e rotação rigorosos. Ative a auditoria avançada com SACLs nos contêineres da Camada 0. Garanta backups diários do Estado do Sistema (System State) dos DCs e runbooks documentados para restauração autoritativa e recuperação do SYSVOL. Nas Camadas 1 e 2, bloqueie o logon de administradores em camadas inferiores, elimine a reutilização de administradores locais com o Windows LAPS e monitore picos nos eventos 4625/4740 e o uso indevido do 4648 para tentativas de movimento lateral.

Cenário de Problema Prático

A Adobe precisa proteger uma floresta do AD DS on-premises rapidamente após adquirir uma subsidiária cujos aplicativos de negócios (line-of-business) dependem de protocolos legados. Os objetivos são reduzir o sucesso de ataques de pulverização de senhas (password spraying), impedir a retransmissão de credenciais (credential relay) para os DCs, restringir logons privilegiados a PAWs, modernizar a delegação para uma camada web e garantir a recuperação rápida de exclusões acidentais.

Defina PSOs e atribua-os a grupos privilegiados

Crie um PSO rigoroso (valor de precedência baixo) no msDS-PasswordSettingsContainer com uma idade de senha curta, alta complexidade e bloqueio agressivo.
Aplique via msDS-PSOAppliesTo aos grupos “Domain Admins”, “Server Admins” e a um grupo personalizado “Tier0‑Privs”. Por quê: PSOs granulares (Fine‑grained PSOs) visam apenas contas de alto risco sem afetar todo o domínio, e a precedência garante que a política mais rigorosa prevaleça.

Imponha o uso do grupo Protected Users e de silos de autenticação

Adicione administradores humanos da Camada 0 ao grupo Protected Users.
Crie uma política de autenticação que permita logon Kerberos apenas a partir de SPNs de hosts PAW e de DCs; vincule contas e PAWs em um silo de política de autenticação. Por quê: O grupo Protected Users elimina o NTLM/RC4 e impede a delegação; os silos impõem a regra “somente a partir de PAWs”, reduzindo a exposição de tokens e os caminhos para roubo de credenciais.

Fortaleça o LDAP e monitore por quebras de compatibilidade

Defina “Controlador de domínio: requisitos de assinatura do servidor LDAP” como Exigir; configure LDAPEnforceChannelBinding=1 inicialmente.
Revise os eventos 2886–2889 do Serviço de Diretório para identificar vinculações (binds) legadas; corrija os aplicativos e, em seguida, defina LDAPEnforceChannelBinding=2. Por quê: A assinatura e a vinculação de canal (channel binding) eliminam caminhos comuns de retransmissão (relay) para os DCs, enquanto a aplicação em estágios evita interrupções de serviço.

Migre a delegação para RBCD para a camada web

Converta os servidores web de front-end de delegação irrestrita para RBCD adicionando suas contas de computador ao atributo msDS-AllowedToActOnBehalfOfOtherIdentity da conta de serviço da API de back-end.
Remova os sinalizadores (flags) legados “Confiar neste computador para delegação a qualquer serviço”; defina os SPNs de serviço com precisão. Por quê: A RBCD permite que o recurso dite quem pode delegar a ele e limita a representação (impersonation) aos alvos pretendidos, reduzindo o movimento lateral.

Habilite a auditoria avançada e as SACLs

Configure a Política de Auditoria Avançada para Gerenciamento de Contas, Logon/Logoff, Logon de Conta e Alterações no Serviço de Diretório.
Em OUs da Camada 0 e grupos-chave, adicione SACLs que auditem a Escrita (Write) no atributo member e servicePrincipalName, e alterações de permissão/proprietário.
Encaminhe os logs para um SIEM; crie alertas para anomalias nos eventos 4720, 4740, 4625 e 4648. Por quê: Você não pode defender o que não pode ver; esses eventos expõem a criação de contas, bloqueios, falhas de logon e padrões de uso explícito de credenciais.

Ative a Lixeira do AD DS e finalize os runbooks de recuperação

Habilite a Lixeira no nível da floresta e documente os fluxos de trabalho do Restore-ADObject.
Padronize backups diários do Estado do Sistema (System State) dos DCs com o Windows Server Backup, teste a restauração autoritativa via ntdsutil em um laboratório.
Documente e ensaie a recuperação autoritativa e não autoritativa do SYSVOL do DFSR. Por quê: Uma recuperação rápida e precisa dissuade ações destrutivas de invasores e mitiga erros de administradores sem causar desvio de privilégios (privilege drift).

Implemente o modelo de camadas (tiering) do AD operacionalmente

Defina os ativos das Camadas 0, 1 e 2; restrinja os logons de administrador por camada usando a Política de Grupo (Group Policy) e silos de autenticação.
Implante PAWs para as Camadas 0 e 1, imponha o Remote Credential Guard e rotacione as senhas de administrador local com o Windows LAPS. Por quê: O modelo de camadas garante o isolamento de credenciais e impede a escalada de privilégios de um invasor entre as camadas, alinhando as operações diárias com os limites de segurança.

← Microsoft Sentinel e Monitoramento de Segurança · Todos os domínios · Azure Arc e Gerenciamento de Servidores Híbridos →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →