LDAP Channel Binding, Domain Controller, NTLM Relay, LDAPS: A Metade do Aviso de 2020 que Ninguém Terminou

LDAP Channel Binding, Domain Controller, NTLM Relay, LDAPS — os quatro termos pertencem à mesma frase, porque o channel binding é a única configuração de domain controller que impede um relay NTLM de aterrissar dentro de uma sessão LDAPS na porta 636. A maioria das equipes de Active Directory leu a orientação de hardening da Microsoft de 2020 como um único item, ativou a assinatura LDAP e seguiu em frente. A metade do channel binding é um valor de registro separado que, no Windows Server 2022 e versões anteriores, não existe até que um administrador o crie — e o Windows Server 2025 só mudou isso para implantações totalmente novas.

LDAP Channel Binding, Domain Controller, NTLM Relay, LDAPS: Como as Peças se Encaixam

O LDAP channel binding usa um Channel Binding Token (CBT) para vincular a autenticação que ocorre dentro de uma sessão TLS ao canal TLS que a transporta. A Microsoft descreve isso como o uso de CBTs "para vincular criptograficamente a segurança da camada de aplicação (como uma sessão SSL/TLS) à conexão de rede subjacente", de modo que um atacante que intercepte a sessão criptografada não consiga sequestrá-la ou fazer downgrade dela.

O token só existe em um lugar. A referência de política do Windows para Domain controller: LDAP server channel binding token requirements é explícita: "CBT ou EPA é usado com sessões TLS quando um método de autenticação SASL é usado para autenticar o usuário. SASL significa que você usa NTLM ou Kerberos para autenticação do usuário. LDAP Simple Bind sobre TLS não oferece proteção de channel binding token e, portanto, não é recomendado."

Duas portas importam aqui. O LDAP simples escuta na porta 389 — a porta onde vivem problemas de enumeração não autenticada como o acesso LDAP anônimo via dsHeuristics. O LDAPS usa a porta 636 e estabelece SSL/TLS assim que um cliente se conecta. O channel binding é um controle para a segunda.

A capacidade em si não é nova. Segundo o KB4520412, "o suporte a LDAP channel binding foi adicionado pelo CVE-2017-8563 no Windows Server 2008 e versões posteriores", e os channel binding tokens são suportados a partir do Windows 10 versão 1709. O que o CVE-2017-8563 realmente entregou foi o suporte ao Extended Protection for Authentication (EPA) mais uma entrada de registro que um administrador precisa criar — não uma mudança no valor padrão.

Por Que a Assinatura LDAP Não Cobre Seu Tráfego LDAPS

Esta é a parte que costuma ser ignorada, e o próprio texto de vulnerabilidade da Microsoft diz isso claramente. A descrição do MSRC para CVE-2017-8563 afirma:

Existe uma vulnerabilidade de elevação de privilégio no Microsoft Windows quando um atacante man-in-the-middle consegue encaminhar com sucesso uma solicitação de autenticação para um servidor LDAP do Windows, como um sistema executando Active Directory Domain Services (AD DS) ou Active Directory Lightweight Directory Services (AD LDS), que foi configurado para exigir assinatura ou sealing em conexões de entrada.

Leia essa última oração duas vezes. O domain controller nessa frase já exige assinatura. Ainda assim é possível fazer relay. A correção que a Microsoft lançou foi o EPA, e o FAQ do mesmo aviso diz aos administradores que instalar a atualização não é suficiente — eles também precisam criar a configuração de registro LdapEnforceChannelBinding.

O escopo do controle de assinatura explica o motivo. Quando a assinatura LDAP é imposta, um domain controller "rejeita binds simples LDAP em conexões não SSL/TLS e binds SASL que não solicitam assinatura". As duas metades dessa regra tratam de tráfego que ainda não está dentro do TLS. Um bind simples realizado sobre LDAPS não é o que o controle de assinatura rejeita, e, segundo a referência de política citada acima, ele também não recebe proteção de channel binding token: o CBT se aplica quando um método SASL — NTLM ou Kerberos — faz a autenticação, motivo pelo qual a Microsoft sinaliza o LDAP Simple Bind sobre TLS como "não recomendado", em vez de algo que o channel binding corrige.

Se você ainda está trabalhando no lado da assinatura, esse controle é tratado separadamente em Assinatura LDAP desativada: como binds sem assinatura expõem o Active Directory. Este artigo trata do outro valor, na outra porta.

O Padrão Que Nunca Mudou

O aviso ADV190023 da Microsoft, Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing, é incomumente direto sobre a posição inicial: "Existe um conjunto de configurações padrão inseguras para LDAP channel binding e assinatura LDAP em domain controllers do Active Directory que permitem que clientes LDAP se comuniquem com eles sem impor LDAP channel binding e assinatura LDAP."

As atualizações de 10 de março de 2020, que todo mundo lembra, adicionaram a configuração de Group Policy e os event IDs. Elas não mudaram nada. O KB4520412 repete o aviso quatro vezes — na introdução e uma vez em cada seção de atualização: "As atualizações de 10 de março de 2020, e atualizações no futuro previsível, não vão mudar as políticas padrão de assinatura LDAP ou LDAP channel binding, nem seus equivalentes de registro, em domain controllers do Active Directory novos ou existentes." As atualizações de auditoria de 8 de agosto de 2023 e 10 de outubro de 2023 repetem isso cada uma para seu próprio lançamento.

No lado do registro, o KB4034879 é igualmente direto: "Por padrão, esta configuração está desativada" e "a entrada de registro LdapEnforceChannelBindings precisa ser criada explicitamente."

O Windows Server 2025 é onde a história finalmente muda — parcialmente.

A documentação da Microsoft afirma que o Windows Server 2025 e versões posteriores definem o channel binding como "When supported" por padrão, com a auditoria de channel binding ativada por padrão, e que esses padrões mais fortes se aplicam a novas implantações do Active Directory — enquanto "instalações de upgrade mantêm suas configurações de segurança LDAP atuais para evitar interrupções". Ou seja, um domain controller Windows Server 2025 que entra em um domínio construído em 2016 não é automaticamente o "endurecido" do folheto de marketing. Se uma renovação de domain controller já está no seu radar, essa distinção importa: veja Fim do Suporte do Windows Server 2016: Upgrade de Domain Controller do Active Directory.

E "When supported" também não é a linha de chegada. Pela própria definição da Microsoft, nesse nível "apenas channel bindings incorretos serão bloqueados, e clientes que não suportam channel binding podem continuar se conectando via LDAP sobre TLS". A prática recomendada e documentada é Always.

A Cadeia de Ataque

Etapa 1 - Obter uma autenticação para encaminhar

O atacante precisa de uma máquina Windows ou conta de usuário que se autentique em direção a um host sob seu controle. A mecânica dessa etapa — coerção, envenenamento de resolução de nomes, um caminho de compartilhamento malicioso — são as mesmas cobertas em Ataques NTLM Relay: sequestrando autenticação no AD, e não mudam por nada no domain controller.

Etapa 2 - Fazer relay para o LDAPS na porta 636

Em vez de encerrar a autenticação, o atacante abre sua própria sessão TLS para um domain controller na porta 636 e encaminha as mensagens de autenticação da vítima para dentro dela. Este é exatamente o cenário que o ADV190023 descreve: "um atacante man-in-the-middle consegue encaminhar com sucesso uma solicitação de autenticação para um servidor LDAP do Windows ... que não foi configurado para exigir channel binding, e assinatura ou sealing em conexões de entrada."

Etapa 3 - Fazer bind e agir como o principal repassado

Com LdapEnforceChannelBinding ausente ou definido como 0, o domain controller não tem como perceber que a autenticação foi emitida para um canal TLS diferente daquele pelo qual chegou, e o bind é bem-sucedido. O atacante agora possui uma sessão LDAP autenticada com os direitos de diretório da conta repassada — o que, se o principal repassado for uma conta de computador de domain controller ou um usuário privilegiado, é um caminho muito curto para o resto do domínio. Uma sessão LDAP autenticada também é onde objetos de diretório são escritos, e padrões como a machine account quota determinam o quanto uma conta de baixo privilégio ainda consegue fazer.

Com a aplicação de CBT definida como Always, a mesma autenticação repassada não carrega um binding válido para o canal do atacante, e o domain controller a rejeita.

Detecção

Comece pelo que cada domain controller realmente faz hoje, não pelo que a página do GPO alega.

$dcs = (Get-ADDomainController -Filter *).HostName

Invoke-Command -ComputerName $dcs -ScriptBlock {
    $params = 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters'
    $diag   = 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics'
    [pscustomobject]@{
        DC          = $env:COMPUTERNAME
        OS          = (Get-CimInstance Win32_OperatingSystem).Caption
        CBT         = (Get-ItemProperty $params -Name LdapEnforceChannelBinding -ErrorAction SilentlyContinue).LdapEnforceChannelBinding
        Signing     = (Get-ItemProperty $params -Name LDAPServerIntegrity -ErrorAction SilentlyContinue).LDAPServerIntegrity
        LdapLogging = (Get-ItemProperty $diag -Name '16 LDAP Interface Events' -ErrorAction SilentlyContinue).'16 LDAP Interface Events'
    }
} | Format-Table -AutoSize

Uma coluna CBT vazia significa que o valor nunca foi criado. No Windows Server 2022 e anteriores, isso equivale a 0 — Never.

Ambas as configurações ficam em HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters, e o KB4520412 mapeia essas configurações para os nomes de política da seguinte forma.

Em seguida, os eventos. Todos aparecem no log Directory Service com a fonte Microsoft-Windows-ActiveDirectory_DomainService.

🚨 Perigo: Há uma armadilha nessa tabela. O KB4520412 afirma que "os eventos 3039, 3074 e 3075 só podem ser gerados quando o Channel Binding está definido como When Supported ou Always". Um domain controller no padrão, portanto, produz zero inventário de clientes — os eventos de auditoria que mostram quais clientes falhariam não existem até você já ter saído de Never. O instinto usual de "auditar primeiro, depois ativar" funciona ao contrário aqui: mudar para 1 é a etapa de auditoria.

Os eventos 3040 e 3041 são a exceção, e são seu oráculo de linha de base. Eles são gerados no nível de log 0 sem nenhuma configuração, mas somente quando a política é Never. Se um domain controller estiver registrando 3041, o channel binding está desativado nesse domain controller — independentemente do que a página de propriedades dizia.

Get-WinEvent -FilterHashtable @{
    LogName   = 'Directory Service'
    Id        = 3039, 3040, 3041, 3074, 3075
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue |
    Group-Object Id |
    Select-Object Name, Count |
    Sort-Object Name

Para coletar o detalhe do cliente, aumente o nível de diagnóstico do LDAP. O KB4520412 fornece o comando literalmente:

Reg Add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2

No nível 2, os eventos 3074 e 3075 trazem os campos necessários para rastrear um cliente: o endereço IP e a porta do cliente, a identidade que o cliente tentou usar para autenticar, se o cliente suporta channel binding, se foi permitido no modo when-supported, e um valor de flag de resultado de auditoria.

Get-WinEvent -FilterHashtable @{ LogName = 'Directory Service'; Id = 3074, 3075 } -ErrorAction SilentlyContinue |
    ForEach-Object {
        if ($_.Message -match 'Client IP address:\s*(\d{1,3}(?:\.\d{1,3}){3}):\d+') { $Matches[1] }
    } |
    Group-Object |
    Sort-Object Count -Descending |
    Select-Object Count, Name

Ajuste o padrão se algum dos seus clientes alcançar o domain controller via IPv6.

As flags de resultado de auditoria são decodificadas da seguinte forma, segundo o KB4520412.

Bits dentro de 0x30 indicam um CBT válido; bits dentro de 0x0C indicam um CBT com falha.

Os eventos de auditoria também exigem o patch mínimo correto: segundo o ADV190023, os eventos de auditoria de channel binding 3074 e 3075 ficaram disponíveis sem uma etapa manual de ativação com as atualizações de 14 de novembro de 2023 no Windows Server 2022 e as atualizações de 9 de janeiro de 2024 no Windows Server 2019.

Remediation

1. Primeiro, corrija a infraestrutura básica. Channel binding é um controle sobre LDAPS, então o LDAPS precisa estar saudável antes de você impor qualquer coisa: um certificado válido em cada domain controller e uma configuração TLS moderna. Se isso ainda não foi verificado, comece por Domain Controller LDAPS: TLS Fraco, Print Spooler, Auditoria de Sincronização de Horário.

2. Mudar para When Supported (valor 1).

$params = 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters'
New-ItemProperty -Path $params -Name 'LdapEnforceChannelBinding' -PropertyType DWord -Value 1 -Force

O KB4034879 confirma que o custo operacional é praticamente zero: "O servidor LDAP responde dinamicamente a alterações nesta entrada de registro. Portanto, não é necessário reiniciar o computador depois de aplicar a alteração de registro." A Microsoft também recomenda especificamente o valor 1 para maximizar a compatibilidade com sistemas operacionais mais antigos.

3. Ler o inventário por um ciclo de negócio completo. Com o log de diagnóstico no nível 2, colete os eventos 3074 e 3075 em todos os domain controllers por tempo suficiente para capturar tarefas mensais e trimestrais. A orientação do KB4520412 é classificar cada IP de origem em três categorias: appliance ou roteador (contatar o fornecedor), dispositivo não Windows (confirmar com o fornecedor do sistema operacional e da aplicação se tanto a assinatura quanto o channel binding são suportados) e dispositivo Windows (verificar se a aplicação realmente usa channel binding).

4. Esperar classes específicas de quebra. O FAQ de LDAP da Microsoft destaca que clientes conectando via SSL/TLS sem um CBT falharão assim que o servidor exigir isso, e que "conexões SSL/TLS que são encerradas por um servidor intermediário que, por sua vez, abre uma nova conexão com um domain controller do Active Directory, falharão" — um load balancer que faz a terminação TLS na frente dos seus domain controllers é uma vítima garantida. O mesmo FAQ observa que "o suporte a channel binding pode ser menos comum em sistemas operacionais e aplicações de terceiros do que é para a assinatura LDAP", o que explica exatamente por que tantos ambientes terminaram a assinatura e travaram aqui. O KB4520412 acrescenta mais dois modos de falha. O Windows XP "não suporta LDAP channel binding e falharia quando o LDAP channel binding estiver configurado com o valor Always, mas funcionaria com DCs configurados para usar a definição mais permissiva de LDAP channel binding, When supported" — ele sobrevive à etapa 2 e quebra na etapa 5. E um cliente pode ter o EPA desativado localmente através da configuração de registro SuppressExtendedProtection; como o KB4520412 define um cliente capaz de channel binding como aquele em que o EPA está "instalado ou disponível no sistema operacional e não desativado através da configuração de registro SuppressExtendedProtection", esse tipo de cliente também nunca aparece no seu inventário de 3075.

5. Impor com Always (valor 2), via política. Assim que o inventário estiver limpo, defina a Group Policy Domain controller: LDAP server channel binding token requirements como Always em Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options na Default Domain Controllers Policy, para que novos domain controllers herdem essa configuração em vez de depender de alguém lembrar de definir o valor de registro. A prática recomendada declarada pela Microsoft para essa configuração é Always; o efeito colateral documentado é que clientes que não suportam channel binding não conseguem mais executar consultas LDAP contra os domain controllers.

6. Verificar pela ausência. O evento 3041 só é gerado enquanto a política é Never. Quando um domain controller para de registrar 3040 e 3041, e passa a registrar 3039 para falhas genuínas, a imposição está ativa nesse host. Execute novamente o inventário de registro da seção de Detection em todos os domain controllers — incluindo qualquer um promovido depois da mudança.

7. Fechar os caminhos de relay vizinhos. O channel binding fecha um destino de relay. As credenciais repassadas geralmente se originam de algum lugar com SMB sem assinatura, então combine este trabalho com Assinatura SMB Desativada: Por Que Ainda Permite NTLM Relay — e os endpoints de registro de certificado são um destino separado que vale a pena auditar na mesma campanha, abordado em Caminhos de Ataque do ADCS Explicados.

Como o EtcSec Detecta Isso

A EtcSec lê a configuração LDAP efetiva de cada domain controller durante uma auditoria do Active Directory. LDAP_CHANNEL_BINDING_DISABLED sinaliza domain controllers que não exigem channel binding tokens, e LDAP_SIGNING_DISABLED sinaliza a metade de assinatura do mesmo aviso — deliberadamente como dois findings separados, porque fechar um não fecha o outro. NTLM_RELAY_OPPORTUNITY reporta a exposição a relay que esses padrões criam, e DC_LDAPS_WEAK_TLS verifica se a camada TLS da qual o channel binding depende é, em si, sólida.

Referências Oficiais

• KB4520412: 2020, 2023, and 2024 LDAP channel binding and LDAP signing requirements for Windows — mapeamentos de registro, tabelas completas de eventos e gatilhos, flags de resultado de auditoria
• KB4034879: Use the LdapEnforceChannelBinding registry entry to make LDAP authentication over SSL/TLS more secure — semântica dos valores, estado padrão, sem necessidade de reinício
• ADV190023: Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing — a declaração sobre padrões inseguros e o cronograma de atualizações
• CVE-2017-8563 — Windows Elevation of Privilege Vulnerability — o relay contra um servidor LDAP com assinatura obrigatória, CVSS 3.0 base score 7.5
• Domain controller: LDAP server channel binding token requirements — definições de valor, padrões efetivos por versão do Windows, prática recomendada
• LDAP signing for Active Directory Domain Services on Windows Server — padrões do Windows Server 2025 e comportamento de upgrade
• Manage LDAP signing using Group Policy — a política de imposição de assinatura do Server 2025 e etapas de log de diagnóstico
• KB4546509: Frequently asked questions about changes to Lightweight Directory Access Protocol — modos de falha de compatibilidade

Leituras Relacionadas

• Assinatura LDAP desativada: como binds sem assinatura expõem o Active Directory
• Ataques NTLM Relay: sequestrando autenticação no AD
• Assinatura SMB Desativada: Por Que Ainda Permite NTLM Relay
• Domain Controller LDAPS: TLS Fraco, Print Spooler, Auditoria de Sincronização de Horário — uma Checklist de Higiene de Rede
• Acesso LDAP Anônimo via dsHeuristics: Enumeração do Active Directory
• Active Directory Machine Account Quota (ms-DS-MachineAccountQuota)
• Caminhos de Ataque do ADCS Explicados: Como Configurações Incorretas de Certificado se Tornam Caminhos de Escalonamento no Active Directory
• Fim do Suporte do Windows Server 2016: Upgrade de Domain Controller do Active Directory