Capitolo #2 – Una questione di fiducia
Oltre il limite del perimetro
English version available here → [EN]
Primavera 1993, chi scrive sta ancora ultimando gli studi.
Una domenica di aprile si corre il GP di F1 a Donington, UK. Per il leggendario Ayrton Senna è un anno difficile, la sua McLaren è inferiore alla concorrenza ed in griglia parte quinto, ma c’è un dettaglio che gioca a suo favore: piove! E quando piove la sua fiducia nel mezzo diventa totale.
Semaforo verde, scatta come una furia e nel primo giro si porta già in testa per un dominio assoluto, nessun altro ha la sua confidenza con la pista bagnata.
Nel resto del mondo, in quegli stessi mesi, qualcosa di altrettanto straordinario sta prendendo forma, cambiando radicalmente il modo in cui le persone si fidano dei sistemi informatici.
Con la diffusione del World Wide Web e la distribuzione del browser NCSA Mosaic, Internet smette di essere un ambiente riservato a pochi addetti ai lavori e diventa improvvisamente accessibile.
Chiunque può collegarsi, esplorare risorse remote, interagire con sistemi che non conosce e che non controlla.
Fino a quel momento, i modelli di sicurezza erano stati costruiti attorno a confini chiari: reti aziendali, sistemi locali, domini ben definiti.
Con il Web, invece, ci si affida a servizi lontani, identità remote, infrastrutture che vivono fuori dal proprio controllo diretto.
È una rivoluzione culturale prima ancora che tecnologica.
Nei sistemi Enterprise il tema della fiducia si gioca su due fronti contrapposti.
Da un lato, l’universo Windows si diffonde basandosi su un modello di fiducia chiuso e perimetrale, che coincide con i primi domini.
È qui che viene introdotto per la prima volta un concetto esplicito di Trust, fondato su un protocollo proprietario: NTLM.
Un meccanismo pensato per ambienti controllati, dove la fiducia è una configurazione statica e dichiarata.
Dall’altro, il mondo Unix e accademico utilizza da tempo modelli di autenticazione distribuita, che raggiungono una maturità significativa con Kerberos V5.
Qui la fiducia non è solo un collegamento tra sistemi, ma un elemento progettato per ambienti aperti, interconnessi e potenzialmente eterogenei.
Sono due visioni della fiducia profondamente diverse, nate per rispondere a esigenze diverse.
Con l’introduzione di Active Directory, Microsoft compie però una scelta fondamentale: accoglie i valori dell’altro modello e adotta Kerberos come base fondante del nuovo sistema di autenticazione, avviando un percorso di convergenza tra questi due mondi.
Inizialmente i modelli convivono, affiancati più che integrati, come compromesso necessario per garantire compatibilità con il passato.
È solo con Windows Server 2003 che arriva una convergenza più matura, segnando il passaggio verso un approccio Kerberos-first, in cui la fiducia diventa parte dell’architettura, e non solo un collegamento tra perimetri separati.
Eppure, nonostante questa convergenza sia avvenuta da oltre vent’anni, non sempre è stata compresa fino in fondo.
Come se, paradossalmente, fosse mancata proprio la fiducia in quel processo che voleva riunire scuole di pensiero inizialmente molto distanti.
Questo capitolo parte da qui.
Da una fiducia che si è evoluta tecnicamente, ma non sempre concettualmente, e dalle conseguenze di non aver davvero compreso quel cambiamento fino in fondo.
Cos’è e come funziona
Abbiamo capito che il concetto di “Trust” arriva da lontano, proviamo adesso di declinarlo in maniera pratica nel contesto Active Directory.
Meccanismi di base di una Trust
Partiamo da un concetto principio che viene molto spesso dato per scontato: il Dominio di autenticazione.
Un Dominio è un perimetro entro il quale è presente una “fiducia” implicita tra gli oggetti che ne fanno parte, mediata da opportuni permessi che definiscono chi accede a cosa e con che modalità (ACL, ne abbiamo parlato nel capitolo 1). Tra perimetri differenti (Domini) non c’è fiducia implicita e di conseguenza l’accesso non è consentito.
L’elemento che contraddistingue tutti gli oggetti facenti parte dello stesso Dominio è il Security Identifier (SID).
Si tratta di un attributo fondamentale del modello di sicurezza di Windows: una stringa immutabile che identifica in modo univoco un’entità (utente, gruppo, computer…) indipendentemente dal nome che le viene assegnato.
Un SID ha una struttura ben precisa e può essere rappresentato in forma leggibile come segue:
S-1-5-21-<DomainIdentifier>-<RelativeIdentifier>
La prima parte del SID identifica l’autorità che lo ha emesso e il contesto di sicurezza in cui l’oggetto è stato creato.
In particolare, la sequenza S-1-5-21 indica che il SID appartiene a un contesto di dominio Windows, mentre il valore <DomainIdentifier> rappresenta l’identità del dominio stesso.
Questo significa che tutti gli oggetti appartenenti allo stesso dominio condividono esattamente la stessa porzione iniziale del SID.
L’ultima parte, chiamata Relative Identifier (RID), è invece ciò che rende l’oggetto univoco all’interno di quel dominio.
Il RID viene assegnato dal Domain Controller al momento della creazione dell’oggetto e distingue un utente, un gruppo o un computer da tutti gli altri che condividono lo stesso Domain SID.
In altre parole, il SID racconta sempre due verità:
da dove proviene l’oggetto (il dominio che lo ha emesso)
chi è l’oggetto all’interno di quel dominio
Questa separazione è uno dei pilastri del modello di sicurezza di Active Directory, se volete approfondire l’argomento vi lascio il riferimento all’articolo ufficiale.
Grazie a questo meccanismo, sin dalla prima versione dei Domini NT, è stato reso disponibile il meccanismo di Domain Trust, inizialmente basato su protocollo NTLM.
È bene ricordare che, anche concettualmente, la fiducia ha una direzione precisa., lLa stessa cosa vale per la Domain Trust, dove chi offre le risorse (es: un File Server in un Dominio di risorse) concede fiducia a chi offre le identità (Dominio delle utenze). Questa direzione viene rappresentata con una freccia che va dalle risorse alle identità.
Quando viene attivata una Trust, il dominio di risorse non importa utenti né replica oggetti dal dominio trusted.
Nel momento in cui un oggetto esterno viene utilizzato per la prima volta — ad esempio aggiungendolo a un gruppo locale o assegnandogli un permesso — Active Directory crea automaticamente un Foreign Security Principal.
Un Foreign Security Principal non è un vero account locale, ma un puntatore: un oggetto minimale che contiene esclusivamente il SID dell’entità remota.
Serve a consentire al dominio di risorse di includere identità esterne nei propri meccanismi di autorizzazione, senza doverne conoscere la struttura o replicarne gli attributi.
Ancora una volta, tutto ruota attorno alla fiducia: il dominio di risorse non sa chi sia quell’oggetto, ma si fida del fatto che il suo SID sia stato emesso da un’autorità considerata attendibile.
L’evoluzione delle trust: da collegamenti puntuali a fiducia architetturale
Nel primo modello di domini Windows, la fiducia è un concetto semplice e molto concreto: due domini si conoscono, si parlano, si fidano l’uno dell’altro.
Nulla di più. Ogni trust è un collegamento esplicito, costruito a mano, che vale solo tra due estremi ben definiti. Se serve altro, si crea un’altra trust. E poi un’altra ancora.
È un modello coerente con l’epoca: ambienti piccoli, perimetri chiari, poche interazioni.
Ma è anche un modello che non scala. Ogni nuova relazione aumenta la complessità e, soprattutto, rende la fiducia fragile: basta dimenticare un collegamento perché qualcosa smetta di funzionare.
Con l’arrivo di Active Directory e la nascita del concetto di forest, Microsoft cambia approccio.
I domini non sono più isole indipendenti, ma parti di una struttura più ampia, pensata per condividere uno spazio di fiducia comune. A supportare un modello gerarchico di Domini nascono le trust intra-forest, che diventano automatiche, bidirezionali e transitive: la fiducia non è più una decisione puntuale, ma una proprietà della struttura.
È un passaggio fondamentale: per la prima volta la fiducia smette di essere un insieme di eccezioni e diventa una regola portante.
Quando però serve uscire da questo perimetro (collaborare con domini esterni, ambienti legacy o foreste completamente separate) si torna temporaneamente al passato.
Come eredità delle Domain Trust nascono le External Trust: collegamenti espliciti, non transitivi, volutamente limitati. Un compromesso necessario, pensato per contenere il rischio e ridurre l’esposizione.
Il problema è che, nel frattempo, il mondo è andato avanti.
Con Windows Server 2003 arriva il tentativo di sintesi definitiva: la Forest Trust.
Non più una fiducia tra singoli domini, ma tra insiemi di domini. Non più un’eccezione, ma un’estensione coerente del modello Kerberos-first introdotto con Active Directory. La fiducia diventa finalmente parte anche delle architetture estese: transitiva, strutturata, progettata per scenari complessi come migrazioni, consolidamenti e coesistenza di ambienti.
Da quel momento, le trust non sono più solo un mezzo per “far funzionare le cose”, ma uno strumento di design da considerare con attenzione.
Abbiamo fin qui parlato di tanti tipi di trust, fare confusione è un attimo, mettiamo le cose un po’ in ordine:
In fase di design architetturale la “vera” scelta riguarda le trust di tipo esterno (non intra-forest), dove dobbiamo capire “quanta” fiducia concedere, ma soprattutto con che modalità.
Ed è qui che nasce il gap che vediamo ancora oggi, perché, mentre il modello di fiducia è evoluto, il modo di pensarlo spesso è rimasto fermo.
Applicare un modello di Trust sbagliato rispetto al contesto molto spesso non è un errore di configurazione.
È un’eredità concettuale.
Quali “danni” si possono fare
Come per il primo capitolo ho ritenuto interessante ed efficace calare gli aspetti teorici in un contesto pratico, partendo sempre da quanto ho potuto osservare sul campo.
Caso reale #1 – La trust che non ti aspetti
Torniamo al Caso reale #1 del capitolo #1, il progetto di migrazione è complesso e prosegue il lavoro da “equilibrista”. Se pensavate di aver già visto e risolto tutti i problemi vi sbagliate, è una situazione che riserva ancora qualche sorpresa.
I permessi sulle utenze sono stati sistemati e si passa ai test di migrazione. Per capire bene tutto quello che include lo scenario credo però che valga la pena fare uno schema di riepilogo:
Anche solo contando il numero di frecce che sono servite a tracciare lo schema ci si rende conto del significato della parola “complesso”, gli elementi in campo sono diversi, soffermiamoci su quelli più significativi:
· Tra l’ambiente Active Directory sorgente e destinazione è presente una Trust
· Il motore di sincronizzazione Entra Connect è in target ed ha un connettore anche verso il source
· Gli utenti da migrare fanno uso di uno specifico suffisso nello UserPrincipalName (UPN), ovvero quell’attributo di logon simile alla mail
· Il metodo di login per quel suffisso UPN sul tenant Entra ID è di tipo federato e punta ad una Farm ADFS in source
Si tratta di uno scenario dove è già attiva una “collaborazione tra le parti” di cui la Trust è la colonna portante, la migrazione delle identità è solo una parte del disegno complessivo.
Ma rimanendo sulle identità mi preme sottolineare un paio di dettagli:
· I nomi Netbios ed FQDN tra i due ambienti Active Directory sono differenti, requisito per poter attivare una trust
· Il suffisso UPN degli utenti, che è di fatto un FQDN aggiuntivo, può essere registrato solo in una delle due Active Directory alla volta, pena la generazione di “UPN suffix collision”. Questo obbliga ad una migrazione di tipo cut-over, dove le utenze ed il relativo FQDN vengono spostate in blocco.
Torniamo ai nostri test, viene individuato un FQDN separato con cui svolgere tutto il processo, la procedura va avanti, si arriva al momento del cut-over, le utenze diventano attive in target e si passa al test di logon.
Pagina di logon di Microsoft 365, si inserisce lo UserPrincipalName di un utente di test, il sistema di federazione ci rimanda alla farm ADFS, si inserisce la password e… otteniamo un KO: Incorrect username or password.
Uhm… errore molto generico, inizia la trafila delle verifiche:
· L’utente è attivo in target? > Sì
· Reset della password in target > ancora KO
· Tentativo di logon su ADFS con SamaccountName (DOMAIN\username) > stesso errore
· La risoluzione DNS funziona? > Sì
· I requisiti per gli scenari multi-forest di ADFS sono soddisfatti? > OK
· La Trust è configurata correttamente? > …
Ecco, questo è il momento in cui salta fuori il dettaglio che cambia tutto.
Andando ad analizzare la configurazione della Trust tra i due ambienti Active Directory ci si rende conto che è stata attivata (o meglio ereditata) una External Trust e non una più sofisticata Forest Trust.
Altro dettaglio importante, visto in precedenza, è che le utenze oggetto di migrazione fanno uso di suffissi UPN aggiuntivi, es: <username>@UPNsuffix.xyz
Questi ultimi sono definiti a livello di foresta e fanno parte dei metadati condivisi tramite la Configuration Partition.
Il meccanismo di Name / UPN Suffix Routing utilizza queste informazioni ed è disponibile solo nel contesto di una forest trust.
“Name suffix routing is a mechanism used to manage how authentication requests are routed across Windows Server 2003 forests that are joined together by forest trusts.”
Le External Trust, operando esclusivamente a livello di dominio, non hanno visibilità dei metadati di foresta e non possono quindi instradare suffissi UPN aggiuntivi.
Per questo motivo un tentativo di logon con il suffisso UPN aggiuntivo, effettuato nella farm ADFS dell’ambiente source, non permette il corretto instradamento della richiesta verso i Domain Controller dell’ambiente Active Directory target.
Siamo quindi alle prese con una configurazione ereditata, sicuramente funzionale allo scopo originale, ma incompatibile con lo scenario presente.
La domanda a questo punto è inevitabile: come risolvere?
La soluzione tecnica più ovvia sarebbe quella di sostituire l’External Trust con una Forest Trust. Logico no?
Peccato che nei progetti reali le soluzioni ovvie non siano sempre praticabili e si scontrano con le politiche aziendali.
In questo caso il cliente aveva le idee chiare: nessuna modifica architetturale poteva essere approvata senza una verifica formale degli impatti, condotta in un ambiente controllato che riproducesse fedelmente la produzione. E con un vincolo ulteriore, non negoziabile: l’esperienza utente non doveva cambiare.
Requisiti comprensibili, anzi corretti e tutelativi, ma che nella pratica significavano una cosa sola: la strada più semplice era sbarrata.
È uno di quei momenti in cui il lavoro da equilibrista si fa sentire davvero. Hai la diagnosi, conosci la cura, ma non puoi somministrarla. Devi trovare un percorso alternativo che rispetti i vincoli, non comprometta l’esperienza utente e non faccia saltare la timeline del progetto.
La soluzione individuata è stata quella di aggirare il limite senza ignorarlo: introdurre una nuova farm ADFS nell’ambiente target, validare l’architettura e l’esperienza utente con un suffisso UPN dedicato, raccogliere le evidenze necessarie per portare al tavolo una proposta formale di cambio architetturale in un secondo momento.
Non la risposta ideale. Ma la risposta possibile in quello specifico contesto.
Questo il diagramma di arrivo:
Anche in questo caso siamo di fronte ad uno sforzo extra che difficilmente può essere preventivato durante la normale fase di assessment.
La Trust era attiva e stava facendo quello per cui era stata progettata, peccato che non fosse sufficiente a supportare lo scenario di migrazione.
Supponendo che la messa in opera della Trust sia stata fatta dopo il 2003, viene naturale aprire una riflessione sulla lungimiranza della scelta che ha portato all’uso della External Trust e dei vincoli che nel tempo si porta dietro.
Cosa ci ha insegnato la fiducia
La fiducia, nei sistemi informatici, è uno di quei concetti che diamo per scontati fino a quando non smette di funzionare.
È una compagna invisibile, silenziosa, che ci abitua alla sua presenza senza farsi sentire. Eppure, quando viene progettata o ereditata senza piena consapevolezza, è in grado di determinare il successo o il fallimento di intere architetture.
Il caso visto in questo capitolo mostra chiaramente un punto spesso trascurato: una trust non è solo un collegamento tecnico, è una scelta di design.
Una scelta che nasce in un contesto preciso, per risolvere un problema specifico, e che può restare perfettamente valida per anni… fino a quando il contesto cambia.
Nel momento in cui entrano in gioco identità ibride, federazioni, suffissi UPN aggiuntivi e requisiti di continuità verso il cloud, quella stessa fiducia può diventare un vincolo invisibile.
Non perché sia “sbagliata”, ma perché è stata pensata per un mondo diverso, con confini più semplici e percorsi di autenticazione meno articolati.
La lezione più importante è che la fiducia non scala automaticamente con la complessità.
Aggiungere nuovi componenti (Entra ID, ADFS, sincronizzazioni multi‑forest) senza rimettere in discussione il modello di trust significa spesso costruire sopra fondamenta che non sono state progettate per sostenere quel peso.
C’è poi una seconda lezione, ancora più sottile: i problemi legati alla fiducia raramente si manifestano in modo esplicito.
Non producono errori chiari, non indicano una causa precisa. Si presentano come comportamenti ambigui, autenticazioni che falliscono “senza motivo”, configurazioni che sembrano corrette ma non funzionano. Ed è proprio questa ambiguità a renderli costosi da diagnosticare e risolvere.
Come nel caso del guardiano visto nel Capitolo 1, anche qui il problema non sono le trust.
Esse continuano a fare esattamente ciò per cui sono state progettate: delimitare perimetri, stabilire confini, definire chi può fidarsi di chi.
Il problema nasce quando il design moderno ignora quei confini, assumendo che la fiducia sia implicita, transitiva o adattabile per default.
Negli ambienti ibridi, la fiducia non è un dettaglio operativo, ma una decisione architetturale di primo livello.
Trattarla come un’eredità da subire, invece che come un elemento da comprendere e ridisegnare, significa spostare i problemi più avanti nel tempo, dove saranno inevitabilmente più complessi e più costosi, soprattutto quando si inseriscono nell’equazione i vincoli “politici”.
Ed è proprio da qui che Legacy Things continua il suo percorso: riportare alla luce quei meccanismi silenziosi che, pur nati decenni fa, continuano a determinare il comportamento delle infrastrutture moderne.
Perché ignorare il passato non lo rende innocuo. Lo rende solo più difficile da riconoscere quando torna a farsi sentire.