Capitolo #1 - AdminSDholder: il guardiano
Quando un meccanismo di Active Directory di 25 anni fa continua a influenzare sicurezza e identity moderne
English version available here → [EN]
15 dicembre 1999, il mondo vive una strana tensione.
Nelle sale italiane si proietta Il miglio verde, negli Stati Uniti il pubblico discute animatamente di Fight Club e resta spiazzato dal finale de The Sixth Sense.
Le radio passano “Move Your Body” degli Eiffel 65 e in Europa risuona “Mambo No. 5” di Lou Bega.
Ma nei meandri dell’IT, l’attenzione è rivolta su tutt’altro.
Mancano sedici giorni al cambio di millennio e il mondo IT trattiene il fiato per il Millennium Bug. Si teme che allo scoccare del 1° gennaio 2000 i sistemi possano bloccarsi, che i software scritti decenni prima non siano pronti al nuovo secolo.
È in questo clima, tra euforia e inquietudine tecnologica, che Microsoft rilascia Windows 2000 in RTM, un sistema operativo che rompe col passato e sta per far sembrare vecchio tutto quanto c’era prima con l’introduzione di Active Directory.
E il guardiano è già lì: AdminSDHolder è un componente nativo, creato come prima difesa interna dei meccanismi della directory, che non può essere sospeso né fermato, va solamente compreso.
Cos’è e come funziona
Con AdminSDHolder ci si riferisce ad uno dei meccanismi di protezione più importanti e più dimenticati di Active Directory.
L’obiettivo è semplice: proteggere gli account e i gruppi più privilegiati del dominio, impedendo che permessi errati o deleghe troppo permissive possano comprometterli, volontariamente o per errore.
In parole povere: evitare di chiudersi fuori casa con le chiavi dentro o evitare che ci riesca qualche malintenzionato.
Per riuscire nel suo intento, Active Directory utilizza un approccio molto rigido e poco negoziabile, descritto in questo articolo ufficiale.
All’interno di ogni dominio Active Directory esiste un oggetto speciale chiamato AdminSDHolder, che si trova nel container System del dominio.
Questo oggetto non rappresenta un utente o un gruppo, ma è un ramo di Active Directory che contiene un modello di sicurezza, ovvero nel suo “Security Descriptor” (o ACL > Access Control List) sono riportati i permessi standard che devono avere gli oggetti considerati critici e che devono essere preservati.
In altre parole:
· AdminSDHolder è il template
· gli oggetti da proteggere sono il target a cui applicare il template
Ogni volta che Active Directory rileva una discrepanza tra il template e un oggetto target, interviene per ripristinare la situazione corretta. Ma come?
Tutto il meccanismo è mosso da un “motore interno” chiamato SDProp (Security Descriptor Propagator).
SDProp viene innescato sul Domain Controller che detiene il ruolo di PDCE (Primary Domain Controller Emulator), non agisce in tempo reale, effettua un ciclo di controllo con un intervallo base di 60 minuti, personalizzabile tramite chiave di registro.
Durante questo ciclo lavora come un guardiano che, se trova qualcosa fuori posto, lo riporta alla condizione attesa.
Sì, ma quali sono gli oggetti da proteggere?
La discriminante è l’appartenenza ai gruppi built-in che detengono un minimo di privilegi sull’ambiente Active Directory, ecco la lista completa:
· Account Operators
· Administrator
· Administrators
· Backup Operators
· Domain Admins
· Domain Controllers
· Enterprise Admins
· Enterprise Key Admins
· Key Admins
· Krbtgt
· Print Operators
· Read-only Domain Controllers
· Replicator
· Schema Admins
· Server Operators
Tutti i gruppi in questione e i relativi membri “subiscono” il template AdminSDHolder.
NB: per membri si intendono inseriti direttamente o per via indiretta attraverso group-nesting, rendendo a volte difficile individuare gli oggetti in perimetro.
Questo spiega uno dei comportamenti più frustranti per chi non conosce il meccanismo: “Imposto i permessi sugli oggetti, tutto funziona… e dopo un’ora spariscono.”
Ma come avviene l’applicazione del template? In una maniera intenzionalmente aggressiva: Active Directory assume che nessuna delega standard debba mai avere controllo su questi oggetti.
Ad un oggetto in ambito accadono tre cose fondamentali:
1. L’ereditarietà dei permessi viene disabilitata
· L’oggetto smette di ereditare le ACL dalla sua OU di appartenenza.
· Questo significa che le deleghe impostate a livello di OU non hanno più effetto.
2. Vengono applicati i permessi di AdminSDHolder
· L’ACL dell’oggetto viene resa coerente con quella del template, indipendentemente da dove l’oggetto si trovi nella struttura.
3. Viene impostato l’attributo adminCount
· L’attributo adminCount viene impostato a 1, segnalando che l’oggetto è (o è stato) protetto.
· Questo attributo, però, non viene automaticamente ripristinato se l’oggetto esce dai gruppi privilegiati, creando spesso confusione e situazioni paradossali
Ultima cosa da ricordare è che questo meccanismo non può essere disattivato, bisogna quindi avere ben chiare le sue dinamiche per poter progettare in maniera adeguata i processi IT che vanno a toccare Active Directory e soprattutto che fanno leva su specifiche ACL.
Quali “danni” si possono fare
Adesso che abbiamo capito come funzionano le cose, viene la parte a mio avviso più interessante: vedere che “danni” si possono fare rimanendo all’oscuro di questi meccanismi.
Per farlo ho ritenuto efficace portare delle testimonianze prese direttamente sul campo.
Caso reale #1 – Il gruppo che non ti aspetti
Siamo nel pieno di un complesso progetto di migrazione in classico ambiente ibrido: Active Directory + Entra ID.
Un dominio AD sorgente con le utenze source, un dominio AD di destinazione con le utenze target, Entra Connect configurato per lavorare su entrambi e sincronizzare tutto verso Entra ID. Le utenze source sono le uniche in sync.
L’obiettivo è chiaro quanto ambizioso: sganciare le utenze source e riagganciare quelle target, senza impatti sul cloud.
Per chi non si è mai trovato in un progetto del genere, ribadisco il mio punto di vista: migrare risorse in un contesto moderno ed ibrido è un lavoro da “equilibrista”.
Tutti gli aspetti coinvolti devono essere allineati al millimetro, pena il fallimento.
Quando si inizia a preparare la procedura di migrazione emergono subito i primi problemi: più della metà delle utenze presenta attributi incoerenti tra on‑premise e cloud.
Da un rapido sguardo, Entra Connect segnala errori ricorrenti: permission-issue.
Prima verifica: i permessi dell’account di servizio di Entra Connect, coma suggerisce questo articolo ufficiale.
Nulla di anomalo in apparenza.
Andando più a fondo, emerge però un dettaglio curioso, tutte le utenze in errore hanno una cosa in comune: da un certo punto in avanti nel tempo, le nuove utenze vengono create con una membership “inspiegabile” > Print Operators.
Quel dettaglio cambia tutto: Print Operators è uno dei gruppi protetti di Active Directory.
Diventare membro significa finire automaticamente nel perimetro di AdminSDHolder, con ereditarietà disabilitata, permessi riscritti da SDProp e ACL che non seguono più la struttura dell’OU.
Un meccanismo nato 25 anni fa stava bloccando il corretto flusso di dati verso il cloud.
La soluzione da applicare si è rivelata tutt’altro che immediata:
revisione dei meccanismi di provisioning
rimozione delle membership errate
ripristino dei permessi corretti su centinaia di utenze
riallineamento con il cloud
Insomma, uno sforzo extra su molti fronti che si sarebbe potuto evitare all’origine con un po’ di consapevolezza in più nel disegno dei flussi di provisioning.
In questo caso il povero AdminSDHolder non stava ostacolando la migrazione, stava semplicemente facendo il proprio lavoro, proteggendo account che non avrebbero mai dovuto essere trattati come privilegiati.
Caso reale #2 – Quando la sicurezza incontra l’eredità
Altro cliente, altro ambiente ibrido: Active Directory + Entra ID, con Entra Connect regolarmente configurato.
Questa volta però il contesto è diverso: ambiente stabile, nessuna migrazione in corso.
Viene introdotta una soluzione di Manutenzione Utenti, con due obiettivi ben definiti:
notificare agli utenti la scadenza della password, consentendone il cambio da Entra ID con password writeback su Active Directory
disattivare automaticamente le utenze per cui non viene rilevata attività, on‑premise o cloud, da un certo periodo di tempo
Il tutto seguendo rigorosamente il principio del Principle of Least Privilege (POLP).
Vengono creati un Service Principal per Entra ID ed un GMSA per Active Directory. Agli account di servizio vengono assegnati solo i permessi strettamente necessari (POLP). La soluzione viene configurata, testata ed avviata.
Tutto è pensato e realizzato secondo i moderni standard di sicurezza e, inizialmente, tutto sembra funzionare correttamente.
Dopo poco tempo, però, emergono i primi problemi:
alcuni utenti non riescono a cambiare la password
altri non possono essere disattivati automaticamente
A questo punto l’analisi si concentra dove ormai abbiamo intuito che conviene guardare: permessi sugli account impattati, AdminSDHolder ed SDProp.
Quello che emerge è una situazione meno rara di quanto si possa pensare.
Sono presenti utenti che in passato hanno fatto parte di gruppi protetti, ma che successivamente ne sono usciti, lasciando una configurazione incoerente: oggetti che non sono più privilegiati, che continuano ad avere adminCount = 1, eredità dei permessi interrotta, template AdminSDHolder applicato.
In questo caso specifico, la causa principale è stata identificata nell’uso di assegnazioni dinamiche di gruppi privilegiati, basate su Just‑In‑Time Administration, sempre nel rispetto del POLP.
Una scelta corretta dal punto di vista della sicurezza, ma che non ha tenuto conto degli effetti persistenti di AdminSDHolder sugli oggetti in ambito.
La soluzione sulla carta sarebbe potuta sembrare semplice: facciamo una bonifica e siamo a posto. In realtà si è rivelata più complessa del previsto, per alcune implicazioni supplementari.
La prima questione è che, per consentire il corretto funzionamento della Manutenzione Utenti, è stato necessario assegnare all’account di servizio i permessi direttamente sul template AdminSDHolder. Questo per consentire la manipolazione di oggetti rimasti “incastrati” nel limbo dei permessi.
Ancora una volta un dettaglio cambia però completamente lo scenario.
Questo ha infatti un impatto importante in termini di sicurezza: il sistema su cui gira la soluzione diventa a tutti gli effetti un asset critico, che deve essere trattato come Tier 0 secondo l’AD Tier Model, con tutte le implicazioni del caso in termini di hardening, accessi e segregazione. Per questi aspetti vi rimando all’ottimo articolo dell’amico Stefano Nieri.
Infine, serve prendere coscienza che non è sufficiente fare tutto questo per poter risolvere: gli oggetti rimasti nel limbo vengono comunque esclusi dai successivi cicli di SDProp. Questo gli consente di “schivare” il nuovo set di permessi che consentirebbe alla soluzione di funzionare.
Unico modo per risolvere: una bonifica ad-hoc per ricondurre l’ambiente ad una situazione stabile.
Dopo aver rivisto tutto l’impianto:
· una password resettata in cloud riesce ad essere propagata correttamente su Active Directory
· un utente, che non accede in cloud od on-premise da molto tempo, riesce ad essere correttamente disattivato
Ancora una volta, non si tratta di una configurazione sbagliata, si tratta dell’interazione tra meccanismi legacy e requisiti di sicurezza moderni, il cui design se preso con leggerezza porta a risultati ingannevoli.
Gli ambienti ibridi quindi, con gli standard di sicurezza richiesti oggi, sono intrinsecamente più complessi di quelli cloud-only.
Anche in questo caso, una maggiore consapevolezza in fase di design avrebbe permesso di impostare il lavoro fin dall’inizio nella direzione corretta, evitando costose correzioni a posteriori.
Cosa ci ha insegnato il guardiano
AdminSDHolder è un perfetto esempio di come un “ingranaggio” che gira sotto il cofano da più di vent’anni possa venire dimenticato: non richiede manutenzione, non genera alert, non fa rumore.
Eppure, il risultato del suo lavoro è sempre presente, anche – e soprattutto – in contesti moderni e orientati al cloud.
La prima lezione che il guardiano ci lascia è semplice, ma spesso sottovalutata: ignorare un meccanismo non lo rende innocuo.
AdminSDHolder continua a fare ciò per cui è stato progettato, applicando regole di sicurezza pensate per proteggere le fondamenta di Active Directory, anche quando sopra quelle fondamenta costruiamo automazioni, integrazioni cloud e processi “moderni”.
La seconda lezione è che fare le cose correttamente non è sempre sufficiente, se manca la consapevolezza di ciò che accade sotto.
Nei casi visti non c’erano configurazioni improvvisate o ambienti trascurati: c’erano migrazioni pianificate, principi di least privilege, Just‑In‑Time administration e soluzioni pensate secondo gli standard di sicurezza attuali.
Eppure, senza conoscere gli effetti persistenti di AdminSDHolder, anche scelte corrette hanno prodotto risultati inattesi.
Il guardiano ci insegna anche che l’eredità sui sistemi non è sempre visibile, ma prima o poi presenta il conto.
Utenti transitati da gruppi privilegiati, attributi come adminCount mai ripristinati, ereditarietà dei permessi interrotta: elementi che possono restare latenti per anni, fino a quando un nuovo progetto, una nuova integrazione o un nuovo requisito di sicurezza non li porta improvvisamente alla luce.
Quando accade, il problema non si manifesta come un errore chiaro, ma come un comportamento “strano” da decifrare, difficile da diagnosticare e spesso più costoso da correggere di quanto ci si aspetti.
C’è infine una lezione di design più ampia: negli ambienti ibridi la complessità non è un’eccezione, è la norma.
Cloud e on‑premise non sono mondi separati, ma parti dello stesso sistema. Le regole del passato continuano a influenzare il presente, e progettare soluzioni moderne senza conoscerle significa semplicemente spostare i problemi più avanti nel tempo.
È proprio da questa consapevolezza che nasce Legacy Things.
AdminSDHolder non è un caso isolato, ma solo il primo di molti “vecchi ingranaggi” che continuano a vivere sotto la superficie delle infrastrutture attuali. Nei prossimi capitoli esploreremo altri meccanismi legacy, altre scelte progettuali del passato che ancora oggi condizionano il modo in cui costruiamo, proteggiamo e facciamo evolvere i nostri sistemi.
E a te che sei arrivato fino in fondo a questo primo capitolo chiedo:
quali sono i meccanismi nascosti che vorresti vedere portati alla luce nelle prossime puntate?