Active Directory: O que é, Como Configurar e Monitorar?

Autor: Pedro Tebaldi PM do KeepGreen| Revisão técnica: Ednilson Correa SRE

Publicado jun/2026Atualizado set/2026

O Active Directory sustenta o acesso de milhares de empresas todos os dias. Quando um colaborador faz login, abre um arquivo compartilhado ou acessa o e-mail corporativo, há grande chance de o Active Directory estar por trás dessa autorização. Por isso, entender esse serviço deixou de ser tarefa apenas do administrador de domínio.

Apesar de onipresente, o diretório costuma ser tratado como caixa-preta até o dia em que para. Uma indisponibilidade derruba logins, e-mail e sistemas internos de uma só vez. Dessa forma, garantir alta disponibilidade do ambiente exige conhecer como ele funciona por dentro.

Neste guia, você vai entender o que é o Active Directory, para que serve, como funciona e quais são seus componentes e serviços. Além disso, mostramos os comandos que respondem se o diretório está saudável, com a saída real de um laboratório de dois controladores.

O que é Active Directory

O Active Directory (AD) é o serviço de diretório da Microsoft para redes Windows. Em termos simples, ele funciona como um banco de dados central que armazena informações sobre usuários, computadores, grupos, impressoras e outros recursos da rede. Junto desse banco, roda um conjunto de serviços que conecta cada pessoa aos recursos que ela tem permissão de usar.

A Microsoft lançou o Active Directory com o Windows 2000 Server. Desde então, ele se tornou o padrão de fato para gestão de identidade em ambientes corporativos. Hoje, a maioria das grandes empresas usa o AD como espinha dorsal de autenticação e controle de acesso.

O serviço resolve dois problemas centrais. Primeiro, a autenticação: confirmar que o usuário é quem diz ser, normalmente por usuário e senha. Segundo, a autorização: liberar apenas os dados e sistemas que aquele usuário tem direito de acessar.

Sem um diretório central, cada servidor manteria a própria lista de usuários e senhas. Em uma empresa com centenas de máquinas, esse modelo vira um caos de credenciais duplicadas. O Active Directory elimina o problema ao centralizar identidade e política em um único lugar.

Para que serve o Active Directory na prática

Na prática, o Active Directory serve para centralizar o controle de quem acessa o quê dentro da empresa. Ele entrega quatro funções principais que sustentam a operação diária de TI.

• Autenticação centralizada: o usuário faz login uma vez e o domínio valida sua identidade para todos os recursos autorizados.
• Autorização e controle de acesso: permissões definem quais pastas, aplicações e sistemas cada perfil pode usar.
• Gestão centralizada via Group Policy: o administrador aplica políticas de senha, segurança e configuração a milhares de máquinas de uma só vez.
• Single Sign-On (SSO): uma única autenticação libera o acesso a vários sistemas integrados, sem novo login a cada serviço.

Esse modelo também simplifica o ciclo de vida do colaborador. Quando o RH admite alguém, o time de TI cria uma conta e a vincula aos grupos certos. Na saída, basta desativar essa conta para revogar todos os acessos. Esse controle conversa diretamente com o controle de ativos de TI, já que cada dispositivo também vira um objeto gerenciável no diretório.

Como o Active Directory funciona

O coração do Active Directory é o Active Directory Domain Services (AD DS), papel do Windows Server que executa o diretório. Os servidores que rodam o AD DS recebem o nome de controladores de domínio (Domain Controllers, ou DCs). Cada DC guarda uma cópia completa do diretório do domínio.

Quando um administrador altera uma senha ou exclui uma conta em um DC, essa mudança precisa chegar aos demais. É aqui que entra a replicação: os controladores sincronizam suas cópias entre si para manter o diretório consistente. Por isso, a latência de replicação vira uma métrica crítica de saúde.

Os protocolos por trás da autenticação

Três protocolos sustentam o funcionamento do AD. O LDAP consulta e grava objetos no diretório. O Kerberos cuida da autenticação por tickets, sem trafegar a senha pela rede, conforme a especificação do protocolo de tickets. Já a resolução de nomes via DNS permite que clientes localizem os controladores disponíveis.

O fluxo é mais simples do que parece. Primeiro, o usuário envia as credenciais ao fazer login. Em seguida, o Kerberos emite um ticket que comprova a identidade. A partir daí, esse ticket libera o acesso aos recursos autorizados sem pedir a senha de novo. Como resultado, o usuário transita entre sistemas com uma única autenticação.

Como gerenciar e verificar a saúde do Active Directory

Gerenciar o Active Directory no dia a dia significa responder três perguntas com comando, não com suposição. A primeira pergunta é quem detém cada papel FSMO. A segunda é se a replicação entre os controladores está em dia. Por fim, vem o tempo que o diretório leva para responder a uma autenticação. Assim, as três checagens cabem em menos de um minuto.

Todos os blocos desta seção saíram de um laboratório próprio, montado na noite de 1º de setembro de 2026. São dois controladores de domínio Samba AD DC 4.24.6 em contêiner, no domínio empresa.local, com nível funcional Windows 2008 R2. Além disso, as saídas trazem carimbo UTC, três horas à frente de Brasília.

Esses controladores falam os mesmos protocolos do AD DS, ou seja, LDAP, Kerberos e replicação DRS. Já os comandos mudam de nome entre as duas implementações. Por isso, a tabela traduz cada verificação para o Windows Server.

Promova o segundo controlador antes de qualquer outra coisa

Quem roda um único controlador não tem replicação para acompanhar. Pior: a queda desse servidor derruba a autenticação inteira e leva junto o DNS do domínio. Por isso, o segundo DC vem antes de qualquer rotina de verificação. No laboratório, a promoção terminou em 7,1 segundos.

# no segundo servidor, com o DNS ja apontando para o primeiro controlador
samba-tool domain join empresa.local DC -U 'EMPRESA\Administrator' --dns-backend=SAMBA_INTERNAL

Adding CN=DC2,OU=Domain Controllers,DC=empresa,DC=local
Adding CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=empresa,DC=local
Adding SPNs to CN=DC2,OU=Domain Controllers,DC=empresa,DC=local
Setting account password for DC2$
Enabling account
Calling bare provision
Provision OK for domain DN DC=empresa,DC=local
Replicating critical objects from the base DN of the domain
Done with always replicated NC (base, config, schema)
Replicating DC=DomainDnsZones,DC=empresa,DC=local
Replicating DC=ForestDnsZones,DC=empresa,DC=local

O comando exige que o futuro controlador já resolva o domínio pelo DC existente. Sem esse ajuste de DNS antes do join, ele não encontra o parceiro e a promoção falha. No Windows Server, o caminho equivalente começa com a instalação do papel AD DS. Em seguida, o Install-ADDSDomainController do módulo ADDSDeployment faz a promoção.

Quem responde por cada papel FSMO

Cada papel FSMO fica em um controlador por vez. Quando o dono some, o domínio recusa certas operações: trocar o esquema, criar domínio novo, alocar faixa de RID e alterar senha dependem deles. Logo, a primeira checagem do dia é descobrir quem responde por cada um.

# o sed so encurta o DN para caber na tela
samba-tool fsmo show | sed 's/,CN=Servers.*//'

SchemaMasterRole owner: CN=NTDS Settings,CN=DC
InfrastructureMasterRole owner: CN=NTDS Settings,CN=DC
RidAllocationMasterRole owner: CN=NTDS Settings,CN=DC
PdcEmulationMasterRole owner: CN=NTDS Settings,CN=DC
DomainNamingMasterRole owner: CN=NTDS Settings,CN=DC
DomainDnsZonesMasterRole owner: CN=NTDS Settings,CN=DC
ForestDnsZonesMasterRole owner: CN=NTDS Settings,CN=DC

No laboratório, por exemplo, todos os papéis estão no mesmo controlador. Aparecem sete porque o Samba também lista os donos das partições de DNS. Em contrapartida, o netdom query fsmo do Windows mostra os cinco papéis clássicos.

Ler a saída é metade do trabalho; decidir é a outra metade. Portanto, com o dono no ar, mova o papel por transferência. Se o dono morreu, resta a tomada, que exige nunca mais religar aquele servidor, conforme a documentação de papéis FSMO da Microsoft.

A replicação está em dia?

Cada partição replica por conta própria, então a leitura é por contexto de nomes, não por servidor. O mesmo comando devolve uma linha para cada uma. Dessa forma, o par de saídas abaixo mostra o antes e o depois de derrubar o primeiro controlador.

# com os dois controladores no ar
samba-tool drs showrepl

DC=empresa,DC=local
    Default-First-Site-Name\DC via RPC
        DSA object GUID: 9f04f862-27ba-46bb-a5bc-c04a24646842
        Last attempt @ Wed Sep  2 00:54:45 2026 UTC was successful
        0 consecutive failure(s).
        Last success @ Wed Sep  2 00:54:45 2026 UTC

# o mesmo comando depois de derrubar o primeiro controlador
DC=empresa,DC=local
    Default-First-Site-Name\DC via RPC
        DSA object GUID: 9f04f862-27ba-46bb-a5bc-c04a24646842
        Last attempt @ Wed Sep  2 00:55:12 2026 UTC failed, result 64 (WERR_NETNAME_DELETED)
        1 consecutive failure(s).
        Last success @ Wed Sep  2 00:54:45 2026 UTC

Entre criar uma conta no primeiro DC e vê-la no segundo, o laboratório mediu 1,2 s, 3,3 s e 3,6 s em três tentativas. Além disso, ninguém forçou sincronização. No Windows Server, o padrão intra-site é notificar o primeiro parceiro 15 segundos após a mudança. Depois disso, cada parceiro recebe o aviso três segundos após o anterior.

Repare no detalhe que a saída esconde. Com o primeiro DC fora do ar, apenas a partição que sofreu tentativa de sincronia acusou falha. No entanto, as outras quatro seguiram exibindo 0 consecutive failure(s), porque ninguém tentou replicar nelas. Portanto, leia o campo Last success contra o relógio: contador zerado não significa saúde.

Quanto tempo o diretório leva para responder

O tempo de resposta de LDAP e de Kerberos antecede a reclamação do usuário. Ou seja, quando o login demora, o diretório já vinha demorando antes. Assim, esta sonda mede o bind autenticado e a busca por contas, sem depender do RSAT, que não existe nas edições Home do Windows.

# Mede o tempo de resposta do controlador de dominio sem RSAT.
# System.DirectoryServices.Protocols vem no .NET, entao roda em qualquer Windows.
#   $env:AD_SENHA = 'senha'; .\medir-ad.ps1

$servidor = "127.0.0.1"      # no seu ambiente: o FQDN do controlador
$porta    = 3389             # no seu ambiente: 389, ou 636 com TLS
$baseDN   = "DC=empresa,DC=local"
$usuario  = "Administrator"
$dominio  = "EMPRESA.LOCAL"

Add-Type -AssemblyName System.DirectoryServices.Protocols

$id   = New-Object System.DirectoryServices.Protocols.LdapDirectoryIdentifier($servidor, $porta)
$cred = New-Object System.Net.NetworkCredential($usuario, $env:AD_SENHA, $dominio)
$con  = New-Object System.DirectoryServices.Protocols.LdapConnection($id, $cred)
$con.AuthType = [System.DirectoryServices.Protocols.AuthType]::Negotiate
$con.SessionOptions.ProtocolVersion = 3
$con.SessionOptions.ReferralChasing = "None"   # sem isto voce mede o timeout do cliente

"bind : {0} ms" -f [int](Measure-Command { $con.Bind() }).TotalMilliseconds

$req = New-Object System.DirectoryServices.Protocols.SearchRequest(
    $baseDN, "(&(objectCategory=person)(objectClass=user))", "Subtree", @("sAMAccountName"))
$t = Measure-Command { $res = $con.SendRequest($req) }
"busca: {0} ms / {1} contas" -f [int]$t.TotalMilliseconds, $res.Entries.Count

$env:AD_SENHA = 'a senha da conta de servico'
.\medir-ad.ps1

bind : 22 ms
busca: 2 ms / 18 contas

Na primeira versão, o script mediu 12.576 ms para a mesma busca. O controlador não era o culpado: o .NET persegue as referências de outras partições por padrão. Cada referência inalcançável espera o próprio tempo limite. Desligar o ReferralChasing derrubou a medição para 2 ms, ou seja, um fator de seis mil.

Kerberos entrou na mesma bateria: o ticket saiu em 57 a 73 ms, com validade de dez horas. Esse é o valor padrão da Default Domain Policy, segundo a referência de política do Kerberos. Anote o número que o seu ambiente entrega em dia normal, porque é ele que vira limiar de alerta depois.

Guarde a última lição do laboratório. Enquanto o DNS do segundo DC apontava para o primeiro, derrubar o primeiro travou até o comando de diagnóstico. Ele ficou pendurado mais de 100 segundos sem imprimir nada. Em resumo, diagnóstico rodado de dentro do domínio morre junto com o domínio.

Monitoramento do Active Directory

Essas checagens valem para o instante em que você as roda. O diretório, no entanto, falha de madrugada. Quando um controlador para sem ninguém perceber, a empresa só descobre no dia seguinte, com os logins falhando em massa.

Por isso, o monitoramento de servidores que hospedam o diretório precisa ser proativo. A meta é detectar a degradação antes que ela vire indisponibilidade. Um serviço de monitoramento em tempo real acompanha os sinais de saúde 24×7 e dispara alertas no primeiro desvio.

O que monitorar no Active Directory

• Disponibilidade dos controladores: cada DC respondendo e acessível na rede.
• Latência de replicação: tempo de sincronização entre DCs, já que atrasos geram inconsistência de senha e acesso.
• Tempo de resposta de autenticação: latência de Kerberos e LDAP, que afeta o login do usuário.
• Papéis FSMO: os cinco papéis de operação única precisam estar sempre ativos em um DC saudável.
• Saúde do banco NTDS.dit: o arquivo do diretório não pode ficar sem espaço em disco.
• Serviços essenciais e DNS: serviços do AD DS e a zona DNS do domínio sempre no ar.

O custo de não monitorar é alto. Sem visibilidade, a equipe vira refém do telefone tocando e age tarde demais. Com monitoramento proativo, ao contrário, o time atua sobre o sintoma cedo e preserva a continuidade do negócio.

Componentes e estrutura do Active Directory

A estrutura do Active Directory segue uma hierarquia lógica. Cada elemento cumpre um papel específico na organização de identidades e políticas. A tabela abaixo resume os componentes essenciais que todo profissional de infraestrutura precisa conhecer.

Principais serviços do Active Directory

O nome Active Directory costuma se referir ao AD DS, mas a família inclui outros serviços. Cada um resolve uma necessidade específica de identidade ou segurança dentro do ambiente corporativo.

• AD DS (Domain Services): o serviço principal de diretório, autenticação e autorização.
• AD FS (Federation Services): federação de identidade para login em aplicações externas e de parceiros.
• AD CS (Certificate Services): emissão e gestão de certificados digitais internos.
• AD LDS (Lightweight Directory Services): diretório LDAP leve para aplicações que não precisam de domínio completo.
• AD RMS (Rights Management Services): proteção de documentos e e-mails por política de uso.

Na maioria dos projetos, o AD DS concentra o uso. Ainda assim, conhecer os demais serviços ajuda a desenhar uma arquitetura de identidade completa, principalmente quando a empresa integra parceiros ou aplicações na nuvem.

Active Directory vs Microsoft Entra ID

Com a migração para a nuvem, surge uma dúvida frequente: o Active Directory tradicional foi aposentado pelo Azure? A resposta é não. O AD on-premises e o Microsoft Entra ID (antigo Azure AD) resolvem problemas diferentes e costumam coexistir.

O AD on-premises gerencia domínios Windows dentro da rede corporativa, com Group Policy e Kerberos. Já o Entra ID, a plataforma de identidade na nuvem da Microsoft, foca em autenticação para aplicações web e SaaS. Em ambientes híbridos, as duas plataformas se conectam e sincronizam identidades.

Dessa forma, o usuário usa a mesma conta no notebook do escritório e no e-mail na nuvem. A tabela compara as duas abordagens lado a lado.

Boas práticas de segurança e operação do Active Directory

O Active Directory é alvo preferencial de ataques porque controla as chaves do reino. Comprometer o diretório significa comprometer toda a rede. Algumas práticas reduzem bastante esse risco.

• Princípio do menor privilégio: conceda apenas o acesso necessário e revise contas administrativas com frequência.
• Contas administrativas separadas: nunca use a conta de administrador de domínio para tarefas do dia a dia.
• Política de senhas forte e MFA: exija complexidade e adicione múltiplo fator onde for possível.
• Backup e recuperação dos DCs: teste a restauração do diretório, não apenas a rotina de backup.
• Auditoria de eventos: registre e revise logins suspeitos e mudanças de privilégio.

Essas medidas funcionam melhor dentro de uma estratégia de segurança cibernética mais ampla. Além disso, a correlação de eventos de autenticação ajuda a flagrar movimento lateral e escalonamento de privilégio cedo. Vale também acompanhar a documentação oficial da Microsoft para versões e correções de segurança.

Conclusão

Em resumo, o Active Directory é muito mais do que uma lista de usuários e senhas. Ele concentra autenticação, autorização e política em um único serviço que sustenta a operação inteira da empresa. Por isso, dominar seus componentes, serviços e protocolos deixou de ser opcional para quem cuida de infraestrutura.

No entanto, conhecer a teoria não basta. O diferencial está em tratar o diretório como serviço crítico e monitorar sua saúde de forma proativa. Disponibilidade dos controladores, latência de replicação e tempo de autenticação contam a história antes de o usuário ligar reclamando.

A OpServices ajuda empresas a enxergar esses sinais e a transformar o Active Directory de caixa-preta em ambiente sob controle. Quer garantir que o seu diretório não seja o próximo ponto cego da operação? Fale com um especialista da OpServices e veja como monitorar sua infraestrutura crítica de ponta a ponta.