Firma LDAP disabilitata: come i bind non firmati espongono Active Directory

What Is firma LDAP disabilitata?

Firma LDAP disabilitata significa che un domain controller Active Directory accetta ancora traffico LDAP senza protezione di integrità sul percorso di bind usato dal client. La documentazione Microsoft è chiara: i bind LDAP SASL non firmati e i bind LDAP semplici su una connessione non protetta da SSL/TLS dovrebbero essere rifiutati, perché espongono il servizio di directory a replay e a manipolazioni man-in-the-middle. Nel caso di un bind semplice in chiaro, possono anche esporre direttamente le credenziali sulla rete.

In pratica, la debolezza compare quando il team lascia la policy del domain controller in uno stato permissivo perché una vecchia applicazione, uno script, un appliance o un’integrazione di directory dipende ancora da un comportamento LDAP debole. La directory resta disponibile, ma la fiducia che il domain controller ripone in quel traffico è eccessiva. LDAP non è un canale secondario in Active Directory. È uno dei principali piani di controllo per interrogare utenti, gruppi, computer e oggetti privilegiati.

La firma LDAP disabilitata emerge spesso durante una revisione più ampia come Come auditare la sicurezza di Active Directory: checklist pratica per i team interni, ma merita un proprio percorso di remediation, perché la correzione spesso coinvolge i proprietari delle applicazioni tanto quanto gli amministratori della directory.

How firma LDAP disabilitata Works

Microsoft documenta due modelli rischiosi che la firma LDAP dovrebbe impedire sui domain controller:

1. bind LDAP SASL che non richiedono la firma
2. bind LDAP semplici eseguiti in chiaro invece che su SSL/TLS

Quando la firma è obbligatoria, client e server firmano crittograficamente la sessione LDAP per impedire che un intermediario modifichi il traffico senza essere rilevato. Quando i bind semplici restano necessari, Microsoft raccomanda di proteggerli con SSL/TLS invece di consentirli in chiaro.

È importante anche non confondere firma LDAP e LDAP channel binding. La firma protegge l’integrità della sessione LDAP. Il channel binding è una misura distinta per le sessioni LDAP protette da TLS e segue un diverso flusso di eventi e policy. Nei contesti reali i due temi vengono spesso corretti insieme, ma non coincidono.

Microsoft evidenzia anche un cambiamento importante: Windows Server 2025 abilita la firma LDAP per impostazione predefinita nelle nuove distribuzioni Active Directory. Questo conferma che non si tratta più di un hardening opzionale, ma di una baseline attesa.

The Attack Chain

Passo 1 - Trovare il percorso legacy che usa ancora LDAP debole

Gli attaccanti non devono partire da un account Domain Admin. Il primo obiettivo è spesso il sistema, lo script, il jump host o l’applicazione che esegue ancora bind LDAP deboli verso un domain controller. Negli audit interni questo percorso emerge spesso con lo stesso lavoro usato in Monitoraggio sicurezza AD: Event ID e SIEM: capire quali client eseguono ancora bind SASL non firmati o bind semplici in chiaro e chi ne è il proprietario operativo.

# Esempio di bind LDAP semplice in chiaro
ldapsearch -x -H ldap://dc01.corp.local -D 'CORP\svc_legacyapp' -W -b 'DC=corp,DC=local' '(objectClass=user)'

Se un flusso applicativo dipende ancora da un bind semplice in chiaro, il problema reale non è solo il comando. È il fatto che il domain controller sia rimasto sufficientemente permissivo da accettarlo.

Passo 2 - Intercettare o manipolare traffico LDAP debole

La guida Microsoft sulla firma LDAP richiama esplicitamente il rischio di replay e man-in-the-middle sul traffico non firmato. Se il percorso di bind non è protetto in integrità, un attaccante ben posizionato in rete può alterare richieste LDAP o riutilizzare materiale di autenticazione in modi che l’ambiente non dovrebbe più consentire.

Per questo motivo la firma LDAP disabilitata si sovrappone spesso, dal punto di vista operativo, a Attacchi NTLM Relay: dirottare l’autenticazione in AD. I problemi non sono identici, ma entrambi riducono la fiducia nel traffico di autenticazione e directory che attraversa la rete.

Passo 3 - Trasformare l’accesso alla directory in più privilegio

Una volta che l’attaccante può fare affidamento su questo percorso LDAP debole, il passo successivo non è sempre la compromissione immediata del dominio. Più spesso inizia una fase di ricognizione e mappatura dei privilegi:

• enumerare gruppi privilegiati e deleghe
• individuare account di servizio sensibili e oggetti applicativi critici
• identificare percorsi che favoriranno in seguito abuso di ACL, GPO o account troppo esposti

La stessa logica compare in Percorsi di attacco AD verso Domain Admin: una debolezza nel piano di controllo della directory diventa più pericolosa quando aiuta l’attaccante a trovare il percorso più breve verso oggetti privilegiati.

Detection

Il percorso di rilevazione più pulito si basa sugli eventi Directory Service documentati da Microsoft per la firma LDAP.

Per la prima priorità conviene partire dall’Event 2887 e verificare se il problema è ancora attivo. Se lo è, aumentate i LDAP Interface Events per fare in modo che l’Event 2889 fornisca IP e identità del client. Questo permette di assegnare la remediation al vero owner dell’applicazione.

# Leggere gli eventi principali collegati alla firma LDAP su un DC
Get-WinEvent -LogName 'Directory Service' |
  Where-Object { $_.Id -in 2886,2887,2888,2889,3039,3040,3041,3074,3075 } |
  Select-Object TimeCreated, Id, LevelDisplayName, Message

Durante la remediation è utile mettere questi eventi in relazione con una revisione più ampia come Compliance AD e Azure: NIS2, ISO 27001 e CIS Controls. La firma LDAP è uno di quei controlli che spesso esistono da tempo nelle policy, ma restano applicati male in produzione.

Remediation

💡 Quick Win: usate prima gli Event 2887 e 2889. Identificate tutti i client che dipendono ancora da bind SASL non firmati o da bind semplici LDAP in chiaro prima di forzare i DC a rifiutarli.

Una sequenza di remediation solida segue in genere questo ordine:

1. Inventariare i client deboli. Analizzate i dati di 2887 e abilitate eventi più dettagliati così che 2889 identifichi i sistemi sorgente.
2. Correggere il comportamento del client. Aggiornate applicazione, driver, appliance o script in modo che richiedano firma per SASL o usino SSL/TLS per i bind semplici.
3. Richiedere la firma sui domain controller. Nella policy, impostate Domain controller: LDAP server signing requirements su Require signing.
4. Rivedere la policy lato client. Usate Network security: LDAP client signing requirements per evitare che i client Windows gestiti aprano ancora sessioni LDAP deboli.
5. Ritestare le applicazioni dipendenti. Validate il comportamento di bind in percorsi realmente usati in produzione.
6. Monitorare i tentativi residui. Dopo l’enforcement, osservate 2888 e 2889 per trovare sistemi che richiedono ancora intervento.

# Esempio di validazione della policy su un host Windows
secedit /export /cfg C:\Temp\secpol.cfg
Select-String -Path C:\Temp\secpol.cfg -Pattern 'LDAP'

La trappola operativa più comune è forzare l’impostazione senza coordinarsi con i proprietari delle applicazioni. La firma LDAP va imposta, ma il percorso più sicuro passa da inventario, migrazione e test. Questo è ancora più importante quando l’ambiente presenta già Malfunzionamenti GPO come vettore di attacco o altre carenze di igiene che complicano il cambiamento.

Validate Before You Close the Finding

La validazione finale deve dimostrare più di una policy modificata. Eseguite di nuovo lo stesso test che aveva identificato il client debole, confermate che ora usa firma o LDAPS come previsto e fate approvare il flusso reale dal proprietario dell’applicazione. I problemi di firma LDAP spesso sopravvivono sotto forma di eccezioni dimenticate, account di servizio mai rivisti o appliance mai ritestate dopo l’aggiornamento della GPO.

Se l’ambiente mostra anche esposizione a relay su servizi vicini, documentatelo in modo esplicito. In molti audit, lo stesso sistema che usa ancora LDAP debole mostra anche condizioni compatibili con NTLM_RELAY_OPPORTUNITY. Registrare questa relazione aiuta a rimuovere la dipendenza in modo definitivo invece di prorogare un’eccezione.

How EtcSec Detects This

EtcSec collega questo tema direttamente a LDAP_SIGNING_DISABLED, e spesso ha senso rivederlo insieme a NTLM_RELAY_OPPORTUNITY quando traffico di directory debole e percorsi di rete relay-friendly compaiono nello stesso ambiente. Il punto utile non è solo sapere che l’impostazione è debole, ma verificare se la policy del DC resta permissiva, se i client deboli sono ancora attivi e se la correzione appartiene all’ingegneria AD o a un team applicativo.

ℹ️ Note: EtcSec controlla automaticamente le debolezze di firma LDAP durante ogni audit Active Directory, aiutando a distinguere una regola scritta da un controllo realmente applicato sui domain controller in produzione.

Official References

• Microsoft Learn: LDAP signing for Active Directory Domain Services on Windows Server
• Microsoft Learn: Manage LDAP signing using Group Policy for Active Directory Domain Service
• Microsoft Learn: How to enable LDAP signing in Windows Server
• Microsoft Support KB4520412: LDAP channel binding and LDAP signing requirements for Windows

Related Reading

Se state correggendo la firma LDAP, rivedetela insieme a Attacchi NTLM Relay: dirottare l’autenticazione in AD, Monitoraggio sicurezza AD: Event ID e SIEM, Percorsi di attacco AD verso Domain Admin, Malfunzionamenti GPO come vettore di attacco e Sicurezza password AD: configurazioni errate che contano. L’hardening LDAP è più forte quando fiducia di rete, fiducia di directory e percorsi di privilegio vengono esaminati insieme.