Quali sono le configurazioni di sicurezza errate di Active Directory più comuni? 10 problemi da correggere per primi

Quando i team chiedono quali sono le configurazioni di sicurezza errate di Active Directory più comuni, la risposta utile non è una tabella di frequenza. È l’insieme dei failure di controllo che ricompaiono nelle guide di hardening Microsoft, nelle raccomandazioni ANSSI e nelle revisioni AD ricorrenti, perché continuano a lasciare veri percorsi di escalation di privilegio, esposizione di credenziali o perdita di visibilità.

Questo articolo presenta la vista misconfigurations di Active Directory. Non è una checklist di audit completa come Auditare la sicurezza di Active Directory: checklist pratica, e non è nemmeno una guida all’ordine di rollout come Messa in sicurezza di Active Directory: cosa bloccare prima e come validarlo. L’obiettivo è più stretto: identificare le configurazioni errate di AD che contano ancora di più, spiegare perché contano e mostrare che cosa validare prima e dopo la correzione.

Che cosa conta come configurazione di sicurezza errata in Active Directory?

Una configurazione di sicurezza errata in Active Directory non è semplicemente un’impostazione diversa da un benchmark. In pratica, è una debolezza di controllo che lascia autenticazione, privilegi, replica di directory, amministrazione o gestione delle policy più ampia del necessario per l’ambiente.

È per questo che le stesse famiglie di problemi tornano sempre: troppi account privilegiati, scarsa separazione dei percorsi amministrativi, diritti di replica troppo ampi, traffico di directory non firmato, segreti di amministratore locale riutilizzabili, account di servizio con password statiche, impostazioni di delega insicure e controllo troppo permissivo di Group Policy. Sono problemi di configurazione, ma diventano problemi di attack path quando restano in produzione.

Quali sono le configurazioni di sicurezza errate di Active Directory più comuni?

ℹ️ Nota: questa lista non è una classifica statistica neutrale del mercato. È una Top 10 pratica delle famiglie di configurazioni errate che ricompaiono nelle guide Microsoft, ANSSI e nelle review AD, e che continuano a creare esposizione materiale in ambienti reali.

1. Troppi account privilegiati e gruppi sensibili

Questa è la famiglia di configurazioni errate più basilare in AD: troppi utenti, account di servizio o account di emergenza mantengono appartenenze permanenti a gruppi altamente sensibili o a diritti delegati equivalenti. Microsoft e ANSSI spingono qui lo stesso principio: ridurre l’accesso privilegiato permanente e mantenere esplicito lo scope amministrativo.

Il rischio è diretto. Ogni account privilegiato aggiuntivo aumenta l’esposizione di credenziali, la superficie di accesso interattivo, il rischio legato alla delega e il perimetro di recupero quando un’identità viene compromessa. In pratica, il problema raramente è un solo account Domain Admin. È l’accumulo lento di vecchi account admin, account di supporto, account di emergenza diventati permanenti e percorsi di annidamento che nessuno ripulisce più.

Da validare prima del cambiamento: inventario dei gruppi privilegiati, annidamenti, diritti delegati sugli asset Tier 0 e casi d’uso amministrativi reali. Rimuovere accessi senza controllare ownership e dipendenze operative crea disservizi.

Prove da conservare dopo il rollout: export dell’inventario dei gruppi privilegiati, record di rimozione degli accessi e lista rivista delle identità che richiedono ancora privilegi permanenti.

2. Mancanza di separazione dei percorsi amministrativi o di host amministrativi sicuri

Molti ambienti AD permettono ancora alla stessa identità di amministrare server, leggere email, aprire documenti e accedere a workstation a minore livello di fiducia. La guida Microsoft sui secure administrative hosts esiste perché l’accesso privilegiato non riguarda solo l’appartenenza ai gruppi. Dipende anche da dove le credenziali amministrative vengono esposte.

Se gli utenti privilegiati amministrano da endpoint generalisti, credenziali e token admin hanno più probabilità di essere catturati, riutilizzati o sfruttati nel movimento laterale. Per questo workstation amministrative dedicate, account separati e un percorso amministrativo pulito restano importanti, anche quando l’appartenenza ai gruppi sensibili sembra già ragionevole.

Da validare prima del cambiamento: quali amministratori usano già account separati, quali sistemi vengono usati per amministrare e quali workflow dipendono ancora da endpoint di uso misto. Molti team scoprono di avere separazione sulla carta, ma non nell’uso quotidiano.

Prove da conservare dopo il rollout: inventario degli host amministrativi sicuri o equivalenti, restrizioni di logon o assegnazioni di admin host e prova che l’amministrazione sensibile non parta più da sistemi non gestiti o di uso generale.

3. Diritti di replica concessi troppo ampiamente

DCSync non è solo un’etichetta offensiva. Operativamente, è un problema di permessi: identità che non hanno bisogno dei diritti di replica li possiedono comunque. Microsoft Defender for Identity lo evidenzia tramite la valutazione sugli account non amministrativi con permessi DCSync proprio perché l’impatto di fondo è molto alto.

Quando Replicating Directory Changes, Replicating Directory Changes All o diritti correlati vengono concessi troppo ampiamente, un’identità può richiedere dati di directory altamente sensibili che dovrebbero restare strettamente controllati. La corretta mentalità di remediation non è bloccare DCSync, ma ridurre al minimo previsto i principal capaci di replicare.

Da validare prima del cambiamento: review delle ACL sulla radice del dominio e sugli oggetti rilevanti, identificazione degli attuali detentori dei diritti di replica e conferma che ogni detentore sia realmente necessario per backup, sincronizzazione o tooling di sicurezza.

Prove da conservare dopo il rollout: snapshot della review ACL, lista finale approvata delle identità capaci di replicare e traccia che dimostri che i principal rimossi non possiedono più tali diritti.

4. LDAP signing e channel binding applicati male

LDAP non firmato resta uno degli esempi più chiari di un controllo AD vecchio ma ancora operativamente rilevante. La guida Microsoft su LDAP signing per AD DS esiste perché i bind SASL non firmati e i simple bind possono indebolire l’integrità del traffico di directory, e i vincoli di compatibilità lasciano spesso gli ambienti a metà deployment.

La configurazione errata raramente è un solo valore di registro. Più spesso è un’applicazione incoerente tra domain controller, applicazioni che dipendono ancora da comportamenti di bind più deboli o una validazione incompleta dell’impatto reale sui client quando i requisiti diventano più severi.

Da validare prima del cambiamento: inventario dei client LDAP, identificazione dell’uso di bind non firmati, conferma che LDAPS, signing o channel binding non rompano applicazioni legacy e rollout graduale prima dell’enforcement.

Prove da conservare dopo il rollout: impostazioni di policy dei domain controller, risultati dei test sulle applicazioni critiche e telemetria che mostri che i client attesi usano un comportamento conforme.

Per il meccanismo completo e i caveat di validazione, vedere LDAP Signing Disabled: How Unsigned Binds Expose Active Directory.

5. SMB signing non richiesto dove conta ancora

SMB signing è un altro controllo che i team conoscono, ma rinviano per assunzioni sulle performance, timori di compatibilità o baseline ereditate su client e server. La guida Microsoft è diventata più netta qui perché SMB non firmato lascia ancora spazio alla manomissione del traffico e supporta condizioni di NTLM relay in ambienti che non hanno ridotto i percorsi di fiducia legacy.

La configurazione errata non è SMB esiste. È il fatto che l’integrità non venga richiesta dove dovrebbe esserlo, soprattutto su sistemi che accettano ancora flussi di autenticazione sensibili o che si trovano su percorsi amministrativi.

Da validare prima del cambiamento: dispositivi legacy, sistemi embedded, server più vecchi o percorsi applicativi che dipendono ancora da un comportamento SMB più debole. Verificare lo stato reale di signing su client e server invece di assumere che un lato lo imponga ovunque.

Prove da conservare dopo il rollout: stato effettivo della policy di SMB signing, registro delle eccezioni per i sistemi non ancora conformi e risultati di validazione che dimostrino che i sistemi sensibili richiedono ora la firma.

Per l’esposizione di protocollo dettagliata, vedere Firma SMB disabilitata: perché consente ancora NTLM relay.

6. Windows LAPS non distribuito

Un gran numero di ambienti AD protegge ancora meglio le credenziali di dominio delle password di amministratore locale. Questo mantiene in vita uno dei più vecchi pattern di esposizione Windows: segreti di admin locale statici o riutilizzati tra endpoint e, in alcuni ambienti, gestione debole delle password DSRM sui domain controller.

La guida Microsoft su Windows LAPS è importante perché non si tratta solo di igiene delle workstation. Password di admin locale riutilizzabili favoriscono il movimento laterale, complicano il contenimento dopo una divulgazione di password e riducono il valore di altre misure di hardening.

Da validare prima del cambiamento: quali endpoint usano già Windows LAPS, se Legacy LAPS e Windows LAPS convivono, come è delegata la lettura delle password e se la gestione DSRM rientra nello scope per i domain controller.

Prove da conservare dopo il rollout: stato del deployment della policy, copertura dei sistemi gestiti, lettori autorizzati e verifica a campione che le password ruotino e siano recuperabili solo dai ruoli approvati.

I dettagli di deployment e validazione sono coperti in Windows LAPS non distribuito: perché le password locali di amministratore condivise restano un rischio.

7. Controlli password deboli ed eccezioni sui conti privilegiati

Una password policy debole resta comune, ma il vero problema operativo è più ampio di una sola impostazione di dominio. Include spesso minimi troppo deboli, assenza di fine-grained password policies mirate, password privilegiate molto vecchie ed eccezioni che lasciano silenziosamente account critici fuori dalla baseline desiderata.

La guida Microsoft sulle fine-grained password policies esiste proprio perché gli account ad alto valore non si adattano sempre a un unico modello di policy. Allo stesso tempo, ANSSI insiste sul fatto che account privilegiati e usi amministrativi richiedano una gestione più rigorosa rispetto agli utenti generici.

Da validare prima del cambiamento: policy password effettiva del dominio, eventuali fine-grained password policies, account privilegiati con flag di eccezione, uso di Password never expires e account di servizio ancora trattati come utenti umani.

Prove da conservare dopo il rollout: export della policy effettiva, mapping di utenti o gruppi con regole rafforzate e artefatti di review per le eccezioni residue.

Per i problemi di credenziali adiacenti, vedere Active Directory Password Security: Misconfigurations That Matter.

8. Account di servizio legacy con password statiche invece di gMSA dove possibile

Gli account di servizio con password statiche restano comuni perché sopravvivono alle migrazioni, supportano applicazioni vecchie e raramente hanno un ownership chiaro end-to-end. Microsoft promuove gMSA perché riduce il carico operativo della gestione password per i workload compatibili, ma molti ambienti mantengono ancora account di servizio privilegiati o con SPN su password manuali e molto vecchie.

Il rischio non riguarda solo l’età della password. Questi account sono spesso sovraprivilegiati, difficili da inventariare, esclusi dalle review normali del ciclo di vita e complicati da ruotare in modo sicuro. Dove esistono SPN, credenziali di lunga durata degli account di servizio aumentano anche il valore del cracking offline dei ticket, per questo il tema si sovrappone all’esposizione di tipo Kerberoasting.

Da validare prima del cambiamento: inventario degli account di servizio, ownership, uso di SPN, livello di privilegio, processo di rotazione delle password e compatibilità applicativa con gMSA. Non tutti i servizi possono migrare subito, quindi conviene partire dai conti più rischiosi.

Prove da conservare dopo il rollout: inventario degli account di servizio, owner documentati, decisioni di migrazione per i candidati gMSA ed evidenza di rotazione o conversione per gli account che restano con password statiche.

9. Delega Kerberos insicura

La delega Kerberos diventa una configurazione errata quando è più ampia di quanto il design del servizio richieda davvero. Microsoft Defender for Identity evidenzia la delega insicura perché impostazioni troppo aperte ampliano i percorsi di impersonazione e cambiano materialmente fin dove può propagarsi una compromissione.

Questo è un buon esempio del perché configurazione errata comune non significhi correzione semplice. La delega è spesso guidata dall’applicazione. Rimuoverla o convertirla senza validare il comportamento del servizio può rompere l’autenticazione in produzione.

Da validare prima del cambiamento: inventario di delega unconstrained, constrained e resource-based dove presente, identificazione degli owner applicativi e conferma dei sistemi che richiedono ancora davvero delega.

Prove da conservare dopo il rollout: inventario rivisto della delega, impostazioni rimosse o convertite ed evidenza di test che dimostri che i flussi richiesti continuano a funzionare dopo il tightening.

Per l’effetto di catena più ampio, collegare questo tema a Percorsi di attacco AD: come le configurazioni errate si concatenano.

10. Permessi GPO pericolosi e controllo debole dei cambiamenti

Group Policy diventa una configurazione di sicurezza errata quando identità a bassa fiducia o troppo ampie possono modificare GPO ad alto impatto, collegare impostazioni pericolose o cambiare percorsi di policy che interessano sistemi privilegiati. Microsoft e ANSSI trattano l’amministrazione GPO come un tema di control plane, non solo di gestione desktop.

L’impatto va oltre un semplice valore di policy sbagliato. Permessi GPO pericolosi possono consentire a un attaccante o a un operatore sovraprivilegiato di distribuire esecuzione di codice, indebolire la sicurezza degli host, modificare gruppi locali o alterare la postura di sistemi collocati su percorsi amministrativi.

Da validare prima del cambiamento: verificare chi può modificare, collegare o creare GPO, quali GPO si applicano ai sistemi privilegiati e se il change control distingue i GPO ad alto impatto dai cambiamenti desktop ordinari.

Prove da conservare dopo il rollout: risultati delle review dei permessi GPO, liste ristrette di editor, tracce di approvazione per le policy ad alto impatto e copertura di monitoraggio degli eventi di cambiamento GPO.

Per l’analisi diretta di questo percorso, vedere GPO Misconfigurations: How Group Policy Becomes an Attack Vector.

⚠️ Se AD CS è distribuito: debolezze di template, enrollment e configurazione CA appartengono alla stessa review di primo livello, anche se non fanno parte di questa Top 10 principale. Usare ADCS Attack Paths Explained come deep dive dedicato.

Perché queste configurazioni errate persistono?

Questi problemi persistono perché si trovano all’intersezione tra compatibilità, ownership ed eccezioni accumulate. L’hardening di LDAP e SMB può colpire applicazioni vecchie. Gli account di servizio spesso sopravvivono ai team che li hanno creati. Le impostazioni di delega restano perché nessuno vuole rompere l’autenticazione. I permessi GPO derivano perché l’amministrazione delle policy è distribuita tra più team. Gli account privilegiati restano perché rimuoverli richiede evidenza operativa, non solo un’opinione di sicurezza.

È anche per questo che una review annuale non basta. Se questi controlli vengono verificati solo una volta all’anno, deriva dei privilegi, deriva degli account di servizio ed eccezioni di policy possono tornare più rapidamente di quanto il ciclo di review riesca a intercettare. Un processo ricorrente conta quanto la prima pulizia. Vedere Audit ricorrente di Active Directory: perché le review annuali derivano.

Come validarle senza andare a tentoni?

Una buona correzione non è solo un’impostazione cambiata. È un’impostazione cambiata più la prova che il controllo viene davvero applicato e che i workflow necessari continuano a funzionare.

È qui che logging e visibilità del cambiamento contano. Se si stanno modificando controlli centrali di sicurezza AD, bisogna anche sapere se audit policy e modello di raccolta permettono davvero di vedere cambi di gruppi, ACL di directory, GPO e altri eventi critici di control plane. Usare Monitoraggio sicurezza AD: Event ID e SIEM se la baseline di logging resta debole.

Come EtcSec aiuta a priorizzare le configurazioni errate AD

EtcSec è particolarmente utile qui quando l’obiettivo non è una checklist una tantum, ma una vista ripetibile di quali configurazioni errate AD continuano a creare l’esposizione più significativa. Findings come EXCESSIVE_PRIVILEGED_ACCOUNTS, DCSYNC_CAPABLE, LDAP_SIGNING_DISABLED, SMB_SIGNING_DISABLED, LAPS_NOT_DEPLOYED, PASSWORD_POLICY_WEAK, KERBEROASTING_RISK, UNCONSTRAINED_DELEGATION e GPO_DANGEROUS_PERMISSIONS aiutano a trasformare questa lista in una coda di remediation auditabile.

Il punto importante è la ripetibilità. Dopo aver irrigidito un controllo, bisogna rimisurare se l’esposizione è davvero scomparsa e se la deriva non l’ha reintrodotta più tardi. Questa è la differenza tra leggere una guida di hardening una sola volta e mantenere davvero una postura di sicurezza AD nel tempo.

Riferimenti primari

• Best practices for securing Active Directory
• Implementing Secure Administrative Hosts
• Privileged access strategy
• Security assessment: Remove non-admin accounts with DCSync permissions
• LDAP signing for Active Directory Domain Services
• Control SMB signing behavior
• Windows LAPS overview
• Group Managed Service Accounts overview
• Configure fine-grained password policies for AD DS
• Protected Users security group
• Authentication Policies and Authentication Policy Silos
• Security assessment: Unsecure Kerberos delegation
• Group Policy overview
• Configure Windows Event Forwarding
• Active Directory Certificate Services overview
• Guida ANSSI Active Directory