Capitolo #5 - Illusione
La realtà non cambia, cambia il punto di osservazione
English version available here → [EN]
Aprile 1983, un anno prima gli Imagination suonavano “Just an illusion”, e senza saperlo stavano dando un titolo perfetto a ciò che sarebbe diventato una pietra miliare dell’intrattenimento.
Io non mi ricordo cosa stessi facendo. Avevo sei anni e di sicuro non avevo ancora una tastiera tra le mani. Però quella sensazione me la ricordo bene, perché quando il cervello capisce di essere stato ingannato, poi se lo segna da parte.
Siamo a New York City, a Liberty Island. Lo show è pronto, le luci sono puntate, e migliaia di persone stanno per vedere una cosa impossibile. Il famosissimo David Copperfield ha in programma un numero molto ambizioso: fare sparire in diretta la Statua della Libertà.
Lo show inizia, un crescendo di tensione, cala un grande sipario e la “magia” si compie. Passano pochi minuti, il sipario scivola a terra e… la statua non c’è più!
L’illusione è avvenuta. O almeno lo è per il pubblico. Chi conosce i retroscena sa che la statua è ferma, è il pubblico ad essersi spostato.
La realtà non cambia, cambia il punto da cui la osservi.
Puntando i riflettori sul mondo IT, il 1983 è stato pieno di fermento. Il 1° gennaio Arpanet, che poi diventerà Internet, adotta il protocollo TCP/IP. In casa Microsoft viene rilasciato il MS-DOS 2.0 e a fine anno viene annunciato Windows, molto prima che il mondo lo veda davvero.
Tanti piccoli semi che avrebbero messo radici profonde nell’IT moderno. E che in quel momento davano l’illusione di avere il futuro già tra le mani.
Quarant’anni dopo, le illusioni sono ancora presenti, solo più sofisticate. Il caso di oggi non si manifesta come un errore chiaro, ma come un comportamento “strano” che sembra capovolgere la logica… finché non decidiamo di cambiare prospettiva.
Il caso “strano”
2026. Un cliente, un member server, un’esigenza apparentemente ordinaria.
Su quella macchina deve essere installato un modulo software che, per fare il suo lavoro, richiede due cose:
· essere amministratore locale
· poter eseguire alcune operazioni su Active Directory tramite Remote Server Administration Tools (RSAT)
È una richiesta che, chi lavora in ambito IT, ha visto decine di volte. Nulla che richieda particolare attenzione, se non la definizione della delega precisa su Active Directory.
Si procede rispettando il “Principle of Least Privilege” (POLP):
· si crea un gMSA
· lo si configura per eseguire il servizio
· per le operazioni “locali” lo si aggiunge agli Administrators del member server
Non un Domain Admin, non un account personale, niente soluzioni affrettate. È la classica identità di servizio, a cui si stanno costruendo le deleghe necessarie al proprio funzionamento.
Poi si arriva alla parte operativa più delicata: i permessi minimi su Active Directory.
Sul server vengono installati gli RSAT, si apre la console Active Directory Users and Computers (ADUC) direttamente da lì, e il consulente inizia a configurare le deleghe necessarie.
Fin qui tutto lineare: il gMSA è un normale domain user, è local admin solo su quel server, e l’obiettivo è assegnargli qualche permesso mirato su specifiche OU.
In ambito POLP ogni delega va però certificata sul campo.
Si passa quindi a verificare quali permessi effettivi riceva quell’account sull’alberatura di Active Directory, è a quel punto che succede qualcosa che non dovrebbe succedere: il gMSA sembra avere diritti ben oltre la delega appena impostata.
Si apre una Organizational Unit > Properties > Security > Advanced > Effective Access.
Si osservano i permessi ricevuti dal gMSA, ed è tutto veramente strano: l’interfaccia dice che l’account ha permessi “quasi totali” su tutta l’alberatura!
Si ri-verifica l’account: è membro solamente dei Domain Users.
Al consulente viene una intuizione: e se proviamo di togliere l’account dagli amministratori locali del member server?
Detto, fatto, si procede ad una nuova verifica, ed è lì che la cosa si fa ancora più strana: adesso i permessi sull’alberatura di Active Directory sono corretti.
È a quel punto che la questione arriva sul mio tavolo, il consulente è piuttosto confuso: com’è possibile che una membership locale influenzi i permessi di dominio? È il mondo al contrario!
Ragiono sulle informazioni che ho ricevuto e nella mente inizia a prendere forma un’idea che affonda le radici in quel lontano 1983:
il comportamento non è reale, siamo di fronte ad una illusione!
L’illusione svelata
La logica comune dice che una membership locale non può avere effetti su una directory che vive altrove. Eppure, i controlli sembrano confermarlo.
Il sistema sta dicendo che quell’identità, da quel punto di osservazione, non è più un semplice servizio con privilegi minimi. Tutto il contrario.
Ed è proprio qui che l’illusione diventa interessante, perché se la realtà non è cambiata, allora è cambiato qualcos’altro.
E come con la Statua della Libertà, la domanda giusta non è “cosa è successo”, ma:
“da dove stiamo guardando”?
L’idea nella mia testa si fa sempre più presente e chiedo al consulente: rimetti le cose come prima, facciamo in modo che il problema sia presente, poi cambiamo punto di osservazione.
Rimesso l’utente negli amministratori locali del member server, verifichiamo che l’“effective access” mostri permessi totali.
A quel punto chiedo: apriamo l’ADUC da un Domain Controller e facciamo la stessa verifica da lì?
Come evidente dall’immagine, l’effective access è assolutamente coerente con la delega, non vi è più traccia dei permessi quasi-totali.
Cambiando prospettiva è cambiato il risultato, questo conferma l’illusione.
Ma cos’è allora che sta creando questa illusione?
Guardo il consulente con un sorrisetto accennato gli dico: ho capito cosa è successo, la prova che abbiamo fatto ne è la conferma, è una questione di Security Identifier (SID).
Chiedo di fare queste due operazioni:
· dal member server mostrare il SID del gruppo locale Administrators
· dal Domain Controller mostrare il SID del gruppo locale di dominio Administrators
Ecco spiegata l’illusione: il SID nei due casi è esattamente lo stesso!
Ecco il Legacy Things che viene a galla, siamo ancora una volta davanti ad uno di quei subdoli meccanismi di default che sono lì da decenni e di cui si è persa la memoria: i well-known SID.
Cosa sono e perché sono ancora lì
Il concetto di Security Identifier (SID) lo abbiamo già affrontato nel capitolo 2, quindi non ci torno sopra. Quello che serve qui è una loro categoria molto particolare: i well-known SID.
La stragrande maggioranza dei SID nasce “unica”: viene generata nel momento esatto in cui l’oggetto viene creato, dalla Local Security Authority (LSA) per gli oggetti locali di una macchina o dal Domain Controller per quelli di dominio, e non viene mai più riutilizzata per identificare nessun altro. I well-known SID fanno l’esatto contrario: hanno un valore fisso, identico su qualunque sistema. Non vengono generati: esistono e basta.
C’è anche una data precisa a cui far risalire il loro debutto pratico. I SID non nascono con Active Directory, e nemmeno con qualche versione intermedia di Windows: arrivano già con Windows NT 3.1, la primissima release della famiglia NT, distribuita il 27 luglio 1993.
Erano parte integrante del nuovo modello di sicurezza progettato dal team di Dave Cutler, quello fondato su access token e liste di controllo degli accessi (ACL). In altre parole, quando parliamo di well-known SID non stiamo guardando un dettaglio recente, ma un pezzo di architettura che ci accompagna, sostanzialmente immutato, da oltre trent’anni.
Ma da dove arriva la regola che impone quei valori fissi? Chi lo ha deciso, e dove sta scritto? Non è una convenzione informale, né una scelta lasciata alla singola implementazione: è messa nero su bianco in una specifica ufficiale. I well-known SID sono elencati, uno per uno, nel documento [MS-DTYP] Windows Data Types, nella sezione dedicata alle Well-Known SID Structures, dove si legge esplicitamente che i loro valori “restano costanti su tutti i sistemi operativi”.
È una delle Open Specifications di Microsoft, cioè la documentazione di protocollo pensata perché chiunque possa implementare lo stesso modello in modo interoperabile. In altre parole, non è che “Windows fa così”: è che chiunque voglia parlare la stessa lingua è tenuto a usare esattamente quei numeri.
E qui si arriva a un punto che spesso sorprende: il SID non è un’esclusiva del mondo Windows. La documentazione stessa distingue due famiglie. Da un lato ci sono i well-known SID universali, che hanno senso “su tutti i sistemi sicuri che adottano questo modello di sicurezza, inclusi sistemi operativi diversi da Windows”, come Everyone / World (S-1-1-0) o Creator Owner (S-1-3-0), quest’ultimo usato come segnaposto nelle ACE ereditabili. Dall’altro ci sono quelli specifici di Windows, tra cui i gruppi BUILTIN.
Che non sia solo teoria lo conferma il campo: implementazioni come Samba, che oggi sanno fare da Domain Controller Active Directory su Linux, ragionano esattamente con gli stessi SID. Per loro il gruppo Administrators locale è S-1-5-32-544 identico, e componenti come winbind esistono proprio per mappare quei SID sugli UID/GID del mondo Unix.
Il modello di sicurezza, insomma, ha valicato da tempo i confini di Windows.
Torniamo al nostro caso. Il gruppo Administrators del “built-in domain” ha un well-known SID ben preciso: S-1-5-32-544. Vale la pena interpretarlo pezzo per pezzo: il 5 è l’autorità NT, il 32 identifica proprio il dominio built-in, e il 544 è il RID del gruppo Administrators.
Sempre quello: sul member server, sul Domain Controller, sul portatile del consulente. Identico, e non per caso.
Il dettaglio che genera l’illusione è tutto in quel valore condiviso. Su un member server S-1-5-32-544 è il gruppo degli amministratori locali di quella macchina, e nulla più. Su un Domain Controller, però, il “built-in domain” coincide con il dominio stesso: lo stesso identico SID rappresenta lì gli amministratori del dominio, con tutta l’autorità che ne consegue sulla directory.
Quando l’Effective Access viene calcolato dal member server, lo strumento vede che il gMSA appartiene a S-1-5-32-544 e lo confronta con le ACL di Active Directory, dove quello stesso SID gode di permessi pieni. Il tool non sa, e non può saperlo, che “quel 544, visto da qui, vale solo in locale”. Mette insieme due contesti diversi che condividono la stessa etichetta e restituisce una fotografia gonfiata. Basta spostare il punto di osservazione su un DC perché l’ambiguità sparisca: da lì il contesto è uno solo, e i conti tornano.
E allora perché, dopo decenni, sono ancora lì? Per lo stesso motivo per cui non si cambia lingua a metà di una conversazione. I well-known SID sono uno dei mattoni fondamentali del modello di autorizzazione: ACE ereditate, token di accesso, deleghe, permessi di default, tutto ci si appoggia. Cambiarli significherebbe rompere la compatibilità con qualunque cosa sia stata scritta negli ultimi trent’anni, e non solo lato Windows. Sono stabili by design: è la stessa specifica a vincolarli a restare costanti nel tempo e tra sistemi diversi.
Non sono quindi un errore, né una svista rimasta in giro per pigrizia. Sono esattamente ciò che dovevano essere. Il problema non è il SID: è che noi, davanti a un’interfaccia, tendiamo a leggere un’etichetta dimenticando da dove la stiamo guardando. E il punto di osservazione, come al solito, è tutto.
Cosa ci ha insegnato
La prima lezione che questo caso ci lascia è semplice solo in apparenza: lo strumento non stava mentendo. L’Effective Access ha fatto esattamente il suo mestiere, ha calcolato l’accesso a partire da ciò che vedeva da quel punto, e ha risposto in modo formalmente corretto. Il problema è che noi cercavamo un’altra verità, quella dei permessi reali sulla directory, e lui non aveva mai promesso di dircela. Torno allora a quel motto che ho già usato in queste pagine, perché non c’è sintesi migliore: i sistemi informatici non fanno quello che vuoi, fanno quello che gli dici di fare. A quel tool avevamo di fatto chiesto “dimmi cosa vedi da qui”, e lui, con coerenza implacabile, ci ha risposto proprio questo. L’illusione non era nel software, ma nell’aver scambiato la sua risposta per la domanda che avevamo in testa.
La seconda lezione riguarda il modo in cui reagiamo davanti a un comportamento “impossibile”. L’istinto, quasi sempre, è cercare subito un colpevole: un bug, una configurazione sbagliata, una compromissione, qualcosa che si è “rotto”. Ma in questo caso non si era rotto niente, e nessuna caccia al colpevole avrebbe portato da qualche parte. La svolta è arrivata solo quando abbiamo smesso di chiederci “cosa è successo” e abbiamo iniziato a chiederci “da dove stiamo guardando”. Spostare il punto di osservazione, dal member server al Domain Controller, ha fatto svanire l’anomalia esattamente come la Statua della Libertà tornava al suo posto appena il pubblico si accorgeva di essersi mosso. Il consulente, davanti a quei permessi impossibili, aveva esclamato “è il mondo al contrario!”. Ed è proprio lì la lezione:
Quando il mondo ti sembra assurdamente sottosopra, quasi sempre non è il mondo a essersi capovolto: è il tuo punto di osservazione a essere sbagliato.
Prima di credere che sia la realtà a girare al contrario, conviene verificare da dove la stiamo guardando.
C’è infine una terza lezione, ed è quella che tiene insieme l’intera serie: il legacy non è un difetto, è memoria persa. Il well-known SID non era un errore lasciato lì per pigrizia, era esattamente ciò che doveva essere, stabile by design da oltre trent’anni. Ciò che mancava non era la correttezza del sistema, ma la nostra conoscenza del modello, il sapere che quel 32 significa “built-in domain” e che quel 544 vale lo stesso identico numero su mondi diversi. È lo stesso filo che attraversa tutti questi capitoli. Il guardiano di AdminSDHolder che riscriveva permessi che nessuno gli chiedeva più, le trust nate per dare forma alla fiducia e diventate un vincolo invisibile, il Domain Controller che sembrava mentire mentre diceva la verità. Ogni volta il punto non era che il sistema fosse rotto. Il punto era che il sistema continuava a fare ciò per cui era stato progettato, mentre noi avevamo perso parte della memoria di quel progetto.
Forse è questa la vera illusione dei sistemi legacy: non ci ingannano nascondendosi, ci ingannano restando in piena vista, così ovvi e silenziosi che smettiamo di guardarli davvero. Continuano a rispondere con precisione, ma noi abbiamo dimenticato la domanda a cui rispondevano. E allora, come davanti alla Statua della Libertà, l’unico modo per riconoscere il trucco non è fissare più intensamente lo stesso punto, ma avere l’umiltà di spostarci e chiederci da dove stiamo guardando.
Ed è esattamente da qui che Legacy Things continua il suo cammino: riportare alla luce quei meccanismi silenziosi che, pur nati decenni fa, continuano a governare il comportamento delle infrastrutture moderne. Non per nostalgia, ma perché ignorarli non li rende innocui. Li rende solo più bravi a farci vedere cose che non esistono.