Domain Controller LDAPS TLS Fraco, Print Spooler, Sincronização Horário Audit: Checklist de Higiene de Rede

Este é um domain controller ldaps tls fraco print spooler sincronizacao horario audit: um checklist prático para três configurações voltadas à rede que as revisões de Active Directory construídas em torno de ACLs e aninhamento de grupos costumam ignorar. Cada uma é rápida de verificar, e cada uma quebra silenciosamente uma garantia de segurança diferente assim que um domain controller se afasta de sua baseline.

Domain Controller LDAPS TLS Fraco, Spooler de Impressão, Sincronização de Horário no Audit

A maioria das revisões de hardening de Active Directory persegue ACLs, aninhamento de grupos e caminhos de delegação — e ignora a própria superfície de rede do domain controller. Se você está trabalhando a partir de uma lista de prioridades mais ampla, Endurecimento do Active Directory: prioridades mostra onde esse tipo de hardening de protocolo se encaixa em relação ao acesso privilegiado e a segredos reutilizáveis. Os três achados abaixo raramente aparecem em um relatório de permissões, mas cada um é barato de verificar e barato de corrigir uma vez que você sabe onde olhar:

Nenhum desses três é novo. O que torna válido agrupá-los em uma única rodada de revisão é que eles falham silenciosamente — um DC com um listener LDAPS rebaixado, um spooler ativo, ou alguns minutos de desvio de relógio parece completamente saudável em uma checagem de saúde padrão até que algo force a questão.

TLS Fraco no LDAPS

Instalar um certificado válido no armazenamento "Computador Local\Pessoal" do DC habilita automaticamente o LDAPS na porta 636 (e 3269 para o Global Catalog) — a própria orientação da Microsoft sobre configurar certificados de LDAP sobre SSL confirma que nenhuma configuração adicional de serviço é necessária assim que o certificado é confiável tanto para o DC quanto para seus clientes. O problema é que "o LDAPS está ativo" não diz nada sobre quais versões de TLS e conjuntos de cifras ele ainda vai aceitar. Um DC cujo Schannel nunca foi endurecido vai negociar TLS 1.0 ou 1.1, e conjuntos de cifras CBC/SHA1 fracos, com qualquer cliente disposto a oferecê-los — como detalhado no guia da DSInternals sobre forçar TLS 1.2+ para LDAPS em domain controllers. Isso importa porque binds simples de LDAP carregam material de credenciais na rede; uma cifra rebaixada no canal criptografado que deveria protegê-las anula todo o propósito de rodar LDAPS.

Detecção

Habilite o log de diagnóstico do Schannel antes de mexer em qualquer coisa — você quer evidência do que realmente está se conectando antes de desativar uma versão de protocolo:

# Log de eventos Schannel detalhado (detalhe de protocolo/cifra por conexão via Event ID 36880)
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL" `
  -Name "EventLogging" -Value 7 -PropertyType DWord -Force

# Enumerar os conjuntos de cifras atualmente habilitados para TLS neste DC
Get-TlsCipherSuite | Select-Object Name, Certificate, Exchange, Cipher, Hash

Get-TlsCipherSuite retorna a lista ordenada de conjuntos de cifras que o Windows vai negociar — a Microsoft documenta a referência completa do cmdlet em Get-TlsCipherSuite (TLS). Com EventLogging configurado, todo handshake Schannel de e para o DC cai no log do Sistema sob o Event ID 36880, com a versão de protocolo e o conjunto de cifras negociados detalhados — essa é sua evidência de quais clientes ou ferramentas ainda estão forçando um downgrade antes de você desativar qualquer coisa.

Remediação

1. Confirme que nenhum cliente legítimo ainda precisa de TLS 1.0/1.1 usando a evidência do Event ID 36880 acima.
2. Desative TLS 1.0 e TLS 1.1 no lado do servidor via as chaves de registro Protocols do Schannel, ou use Disable-TlsCipherSuite para remover os conjuntos CBC/SHA1 fracos mantendo habilitados os conjuntos da classe TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.
3. Reinicie o DC — mudanças de protocolo do Schannel só têm efeito após a reinicialização.
4. Execute Get-TlsCipherSuite novamente e reverifique o Event ID 36880 para confirmar que apenas conjuntos fortes estão sendo negociados.

Print Spooler Rodando em um Domain Controller

Domain controllers não imprimem nada por conta própria, então o serviço Print Spooler não tem motivo operacional para estar rodando em um deles — mesmo assim ele vem habilitado por padrão. O advisory do PrintNightmare da CISA (CVE-2021-34527, CVSS 8.8) transformou esse padrão em um caminho de execução remota de código autenticado e de baixo privilégio — a pontuação do NVD (PR:L) confirma que basta uma conta de domínio padrão, não privilégios de admin — e a Emergency Directive 21-04 da CISA instruiu agências federais a desativar o spooler em todo DC — não apenas aplicar patches.

Aplicar patches também não resolve o problema de design subjacente. Desde 2018, o "Printer Bug" (um abuso da chamada RpcRemoteFindFirstPrinterChangeNotification no MS-RPRN) permite que qualquer usuário autenticado force um DC com o spooler ativo a se autenticar em um host controlado pelo atacante — documentado no artigo de Sean Metcalf Domain Controller Print Server + Unconstrained Kerberos Delegation. Encadeada com uma conta que possui delegação irrestrita, essa coerção entrega o próprio material de credenciais do DC; encadeada com um relay, ela alimenta diretamente um ataque de NTLM relay — a mesma família de exposição coberta em Assinatura SMB desativada: por que ainda permite NTLM relay. O Microsoft Defender for Identity agora traz isso como uma avaliação de segurança permanente recomendando desativar o Print Spooler em DCs.

Detecção

Verifique cada DC do domínio em uma única passada — não confie em checar apenas o DC que você lembra de ter configurado:

$dcs = Get-ADDomainController -Filter * | Sort-Object HostName
foreach ($dc in $dcs) {
    Get-Service -Name Spooler -ComputerName $dc.HostName |
        Select-Object @{N='DC';E={$dc.HostName}}, Status, StartType
}

Confirme também que não há filas de impressão publicadas dependendo de um DC antes de mexer nele:

Get-ADObject -Filter "ObjectCategory -eq 'printQueue'"

Remediação

1. Para cada DC onde Status é Running ou StartType não é Disabled, pare e desative o serviço:

Set-Service -Name Spooler -StartupType Disabled -ComputerName $dc.HostName
Stop-Service -Name Spooler -ComputerName $dc.HostName

2. Aplique isso em todo o domínio com uma GPO vinculada à OU Domain Controllers (Computer Configuration > Preferences > Control Panel Settings > Services, com Spooler definido como Stopped/Disabled), para que uma reinicialização ou restart manual não reative o serviço silenciosamente.
3. Execute o loop de detecção novamente após o próximo ciclo de atualização da GPO para confirmar que a configuração se manteve em todos os DCs, incluindo qualquer um recém-promovido — um DC recém-promovido começa com o serviço Spooler de volta ao estado padrão (em execução).

Desvio de Relógio Que Ninguém Está Monitorando

O Kerberos carimba seus tickets com data/hora para bloquear ataques de replay, o que significa que a autenticação depende do relógio de cada DC permanecer próximo da fonte de tempo do domínio. A tolerância é governada pela política Kerberos Tolerância máxima para sincronização do relógio do computador — 5 minutos por padrão, definida em Default Domain Policy > Computer Configuration > Windows Settings > Security Settings > Account Policies > Kerberos Policy, segundo a referência de política de segurança da Microsoft. Ao ultrapassar essa tolerância, a autenticação Kerberos falha completamente com uma resposta KRB_AP_ERR_SKEW — que é interpretada erroneamente como um problema de aplicação ou de rede com muito mais frequência do que é corretamente diagnosticada como desvio de relógio.

A hierarquia de tempo do domínio tem apenas uma raiz autoritativa: o emulador de PDC. Todo outro DC sincroniza a partir de um peer na hierarquia do domínio, e as estações de trabalho sincronizam a partir do DC que as autentica. Se o próprio emulador de PDC não estiver apontado para uma fonte externa confiável, o domínio inteiro pode derivar junto sem nada para discordar — o modo de falha que a orientação da Microsoft sobre configurar o PDC raiz com uma fonte de tempo autoritativa foi escrita para prevenir. Um DC que foi silenciosamente apontado para sua própria fonte NTP independente em vez da hierarquia do domínio é igualmente problemático: ele se torna uma segunda autoridade de tempo concorrente, que os outros DCs não têm motivo para confiar mais do que no emulador de PDC, e resolver as falhas intermitentes de Kerberos resultantes sem esse contexto pode consumir horas antes que alguém sequer pense em checar o w32tm.

Detecção

# Status e fonte de sincronização atuais neste DC
w32tm /query /status

# Comparar offsets em todos os DCs do domínio em uma única passada
w32tm /monitor

Monitore o log do Sistema em busca do Event ID 4713 (política Kerberos alterada — apenas em DC, vale um alerta se inesperado) junto com falhas de autenticação que referenciam KRB_AP_ERR_SKEW; correlacionados, eles apontam diretamente para sincronização de tempo em vez de um trust quebrado ou credencial expirada.

Remediação

1. Identifique qual DC detém a função de emulador de PDC e confirme que ele — não um DC par — está configurado contra uma fonte NTP externa e confiável, e não contra o relógio de hardware interno.
2. Se o emulador de PDC estiver desviando ou mal configurado, o guia de remediação de grandes desvios de horário da Microsoft explica como corrigir grandes offsets com segurança — um salto de tempo ingênuo em um DC pode, por si só, quebrar tickets Kerberos em andamento.
3. Confirme que todo outro DC herda o tempo da hierarquia do domínio (NT5DS) em vez de uma fonte independente própria.
4. Execute w32tm /monitor novamente após a convergência e confirme que todos os offsets estão confortavelmente abaixo da tolerância Kerberos de 5 minutos, não apenas logo abaixo dela.

Transformando Isso em uma Verificação Repetível, Não uma Correção Única

Todos os três achados acima têm o hábito de regredir silenciosamente: um DC recém-promovido restaura o serviço Spooler ao seu padrão (em execução), um certificado substituído pode reintroduzir silenciosamente um fallback para cifra fraca, e um appliance NTP desativado pode deixar o emulador de PDC sem aviso. Nada disso é capturado a menos que as categorias de auditoria que registrariam isso estejam de fato habilitadas — veja Lacunas na Configuração da Política de Auditoria do Active Directory se eventos de política do Schannel ou do Kerberos não estiverem aparecendo onde você espera.

Trate este checklist da mesma forma que trataria qualquer outro controle propenso a desvio: execute-o em um cronograma, não apenas depois da primeira correção. Uma passada trimestral pelas três verificações — conjuntos de cifras, status do spooler e offsets de tempo — captura a regressão antes que ela vire um incidente, e é uma fração do esforço da remediação original. Os três trechos de PowerShell acima são curtos o suficiente para empacotar em uma tarefa agendada ou job de CI em vez de rodar manualmente toda vez. Ele também se encaixa bem ao lado de uma revisão mais ampla, como Auditar a Segurança do Active Directory: checklist prática.

Como a EtcSec Detecta Isso

A categoria Network da EtcSec verifica os três achados em toda auditoria de AD: DC_LDAPS_WEAK_TLS sinaliza domain controllers cujo listener LDAPS ainda negocia uma versão fraca de TLS, DC_SPOOLER_ACCESSIBLE sinaliza qualquer domain controller com o serviço Print Spooler acessível, e DC_TIME_SYNC_ISSUE (junto com NTP_NOT_CONFIGURED) sinaliza DCs que estão desviando da fonte de tempo autoritativa do domínio ou sem nenhum peer NTP configurado.