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.
Accetta invece una cosa molto più semplice e molto più potente: i Security Identifier emessi dall’altro lato.

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.

Spring 1993, the writer is still completing studies.
One April Sunday the F1 Grand Prix takes place at Donington, UK. For the legendary Ayrton Senna it is a difficult year: his McLaren is inferior to the competition, and he starts fifth on the grid, but there is one detail that plays in his favour: it is raining! And when it rains, his trust in the car becomes absolute.
Green light, he launches forward like fury and by the end of the first lap he is already in the lead, in total domination. No one else has his confidence on a wet track.

In the rest of the world, in those same months, something equally extraordinary was taking shape, radically changing the way people trusted computer systems.
With the spread of the World Wide Web and the distribution of the NCSA Mosaic browser, the Internet stops being an environment reserved for a handful of specialists and suddenly becomes accessible.
Anyone can connect, explore remote resources, interact with systems they do not know and do not control.

Until that moment, security models had been built around clear boundaries: corporate networks, local systems, well‑defined domains.
With the Web, instead, people begin relying on distant services, remote identities, infrastructures that live outside their direct control.

It is a cultural revolution even before a technological one.

In Enterprise systems the subject of trust is played out across two opposing fronts.
On one side, the Windows universe was spreading based on a closed, perimeter-based trust model that coincided with the first domains.
This is where the first explicit concept of trust was introduced, built on a proprietary protocol: NTLM.
A mechanism designed for controlled environments, where trust is a static, declared configuration.

On the other side, the Unix and academic world had long used distributed authentication models, reaching significant maturity with Kerberos V5.
Here, trust is not merely a connection between systems, but an element designed for open, interconnected, and potentially heterogeneous environments.

Two profoundly different visions of trust, created to respond to different needs.

With the introduction of Active Directory, however, Microsoft made a fundamental choice: it embraced the values of the other model and adopted Kerberos as the foundational basis of the new authentication system, initiating a path of convergence between these two worlds.
Initially the models coexisted, side by side more than integrated, as a necessary compromise to guarantee backward compatibility.

Only with Windows Server 2003 did a more mature form of convergence arrive, marking the transition towards a Kerberos‑first approach, in which trust became part of the architecture rather than merely a connection between separate perimeters.

And yet, despite this convergence having happened more than twenty years ago, it has not always been fully understood.
As if, paradoxically, trust itself had been lacking in the process that intended to unite schools of thought that were originally far apart.

This chapter starts from here.
From a kind of trust that has evolved technically, but not always conceptually, and from the consequences of not having truly understood that change all the way through.

What it is and how it works

We have understood that the concept of “Trust” has deep roots; let us now try to frame it into practical terms within the context of Active Directory.

Basic mechanics of a Trust

Let us start from a principle that is very often taken for granted: the Authentication Domain.

A Domain is a perimeter within which an implicit “trust” exists among the objects that belong to it, mediated by appropriate permissions that define who can access what and in which mode (we discussed ACLs in Chapter 1).
Between different perimeters (Domains) there is no implicit trust, and consequently access is not allowed.

The element that distinguishes all objects belonging to the same Domain is the Security Identifier (SID).
This is a fundamental attribute of the Windows security model: an immutable string that uniquely identifies an entity (user, group, computer…) regardless of the name assigned to it.

A SID has a precise structure and can be represented in readable form as follows:
S‑1‑5‑21‑<DomainIdentifier>‑<RelativeIdentifier>

The first part of the SID identifies the authority that issued it and the security context in which the object was created.
In particular, the sequence S‑1‑5‑21 indicates that the SID belongs to a Windows domain context, while the value <DomainIdentifier> represents the identity of the domain itself.

This means that all objects belonging to the same domain share exactly the same initial portion of the SID.

The final part, called the Relative Identifier (RID), is what makes the object unique within that domain.
The RID is assigned by the Domain Controller at the time the object is created and distinguishes a user, group or computer from all others that share the same Domain SID.

In other words, the SID always tells two different truths:

· where the object comes from (the domain that issued it)

· who the object is within that domain

This separation is one of the cornerstones of the Active Directory security model; if you want to explore the topic further, here is the link to the official article.

Thanks to this mechanism, ever since the very first NT Domains, the Domain Trust mechanism has been available, initially based on the NTLM protocol.

It is important to remember that, even conceptually, trust has a precise direction, the same is true for Domain Trusts, where those who provide the resources (for example, a File Server in a resource Domain) extend trust to those who provide the identities (the user Domain).
This direction is represented with an arrow going from resources to identities.

When a Trust is activated, the resource domain does not import users nor replicate objects from the trusted domain.
Instead, it accepts something much simpler and far more powerful: the Security Identifiers issued on the other side.

When an external object is used for the first time (for example, by adding it to a local group or assigning it a permission) Active Directory automatically creates a Foreign Security Principal.

A Foreign Security Principal is not a real local account, but a pointer: a minimal object containing only the SID of the remote entity.
It allows the resource domain to include external identities in its authorisation mechanisms without needing to know their structure or replicate their attributes.

Once again, everything revolves around trust: the resource domain does not know who that object is, but trusts that its SID was issued by an authority considered reliable.

The evolution of trusts: from point-to-point connections to architectural trust

In the first Windows domain model, trust was a simple and very concrete concept: two domains know each other, speak to each other, trust each other.
Nothing more. Every trust is an explicit, manually created connection that applies only between two well defined endpoints.
If you need something else, you create another trust, and then another.

It is a model coherent with its era: small environments, clear perimeters, few interactions.
But it is also a model that does not scale.
Every new relationship increases complexity and, more importantly, makes trust fragile: forgetting a single link is enough for something to stop working.

With the arrival of Active Directory and the birth of the forest concept, Microsoft changed approach.
Domains were no longer independent islands, but parts of a broader structure designed to share a common trust space.
To support a hierarchical domain model, intra‑forest trusts were introduced: automatic, bidirectional, transitive.
Trust was no longer an exception but a structural property.

It was a fundamental shift: for the first time, trust stopped being a set of exceptions and became a foundational rule.

However, when it becomes necessary to leave this perimeter (to collaborate with external domains, legacy environments or completely separate forests) one temporarily returns to the past.
As a legacy of Domain Trusts, External Trusts were introduced: explicit, non‑transitive links, deliberately limited.
A necessary compromise, designed to contain risk and reduce exposure.

The problem is that, in the meantime, the world moved on.

With Windows Server 2003, the attempt at a definitive synthesis arrived: the Forest Trust.
No longer trust between individual domains, but between entire sets of domains.
No longer an exception, but a coherent extension of the Kerberos‑first model introduced with Active Directory.
Trust finally became part of extended architectures as well: transitive, structured, designed for complex scenarios such as migrations, consolidations and coexistence.

From that moment onwards, trusts were no longer just a way to “make things work”, but a design tool that must be considered carefully.

So far we have mentioned many different types of trusts; confusion is easy, so let’s put things in order:

In architectural design, the real decision concerns external-type trusts (not intra-forest), where we must decide “how much” trust to grant and, above all, in what way.

And this is where the gap we still see today is born, because while the trust model has evolved, the way people think about it has often remained still.
Applying the wrong trust model to the wrong context is very often not a configuration error.
It is a conceptual legacy.

What can go wrong

As with the first chapter, I felt it would be both interesting and effective to place the theoretical aspects into a practical context, always starting from what I have been able to observe in the field.

Real case #1 – The trust you do not expect

Let us return to Real Case #1 of Chapter #1. The migration project is complex and the work of the “tightrope walker” goes on. If you thought you had already seen and solved every problem, you were mistaken: this is a situation that still has a few surprises in store.

Permissions on the user accounts have been fixed, and the migration tests begin. To fully understand everything that this scenario includes, I believe it is worth laying it out in a summary diagram:

Even just by counting the number of arrows needed to draw the diagram, you immediately understand the meaning of the word “complex”. There are several elements in play, so let us focus on the most significant ones:

• There is a Trust between the source and target Active Directory environments

• The Entra Connect synchronisation engine is in the target and has a connector to the source

• The users to be migrated use a specific suffix in their UserPrincipalName (UPN), that logon attribute that resembles an email address

• The login method for that UPN suffix in the Entra ID tenant is federated and points to an ADFS Farm in the source

This is a scenario where a “collaboration between the parties” is already active, and the Trust is its main pillar. Identity migration is only one part of the overall design.

Staying on the topic of identities, however, I would like to highlight a couple of details:

• The NetBIOS names and FQDNs of the two Active Directory environments are different, which is a requirement for enabling a trust

• The users’ UPN suffix, which is effectively an additional FQDN, can be registered only in one of the two Active Directory environments at a time, otherwise an “UPN suffix collision” is generated. This forces a cut over migration approach, where the user accounts and the related FQDN are moved in one block.

Back to our tests: a separate FQDN is identified with which to carry out the whole process, the procedure continues, cut over time arrives, the users become active in the target and the logon test begins.

Microsoft 365 logon page, the UserPrincipalName of a test user is entered, the federation system redirects us to the source ADFS Farm, the password is entered and… the attempt fails: Incorrect username or password.

Hmm… a very generic error, and so the usual sequence of checks begins:

• Is the user active in the target? > Yes

• Password reset in the target > still KO

• Attempt to log on to ADFS using SamaccountName (DOMAIN\username) > same error

• Does DNS resolution work? > Yes

• Are the requirements for multi-forest ADFS scenarios met? > OK

• Is the Trust configured correctly? > …

This is the moment when the detail that changes everything emerges.

By analysing the Trust configuration between the two Active Directory environments, it becomes clear that an External Trust had been enabled, or rather inherited, instead of a more sophisticated Forest Trust.

Another important detail, already mentioned above, is that the users being migrated use additional UPN suffixes, for example: <username>@UPNsuffix.xyz

These are defined at forest level and are part of the metadata shared through the Configuration partition.

The Name / UPN Suffix Routing mechanism uses this information and is available only in the Forest Trust context.

“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.”

External Trusts, operating exclusively at domain level, do not have visibility over forest metadata and therefore cannot route additional UPN suffixes.

For this reason, an attempt to log on using the additional UPN suffix, carried out through the ADFS Farm in the source environment, cannot correctly route the request towards the Domain Controllers in the target Active Directory environment.

So, we are dealing with an inherited configuration, certainly functional for its original purpose, but incompatible with the current scenario.

At this point, the question becomes inevitable: how do we solve it?

The most obvious technical solution would be to replace the External Trust with a Forest Trust. Logical, right?

The problem is that, in real projects, obvious solutions are not always practical, and they clash with corporate policies.

In this case, the customer was very clear: no architectural change could be approved without a formal impact assessment, carried out in a controlled environment that reproduced production faithfully. And there was an additional, non-negotiable constraint: the user experience must not change.

Understandable requirements indeed, correct and protective ones, but in practice they meant only one thing: the simplest path was blocked.

This is one of those moments when the tightrope walker’s work truly makes itself felt. You have the diagnosis, you know the cure, but you cannot administer it. You must find an alternative path that respects the constraints, does not compromise the user experience and does not blow up the project timeline.

The solution identified was to work around the limit without ignoring it: introduce a new ADFS Farm in the target environment, validate the architecture and the user experience with a dedicated UPN suffix, and collect the evidence needed to bring a formal proposal for architectural change to the table at a later stage.

Not the ideal answer. But the possible answer in that specific context.

This is the resulting diagram:

Once again, we are facing an extra effort that can hardly be anticipated during the normal assessment phase.

The Trust was active and was doing exactly what it had been designed to do, but it was not sufficient to support the migration scenario.

Assuming that the Trust was put in place after 2003, it becomes natural to reflect on the foresight of the decision that led to the use of an External Trust and on the constraints it carries forward over time.

Lessons learned from the Trust

Trust, in computer systems, is one of those concepts that we take for granted until it stops working.

It is an invisible, silent companion that accustoms us to its presence without ever making itself heard. And yet, when it is designed or inherited without full awareness, it can determine the success or failure of entire architectures.

The case seen in this chapter clearly shows a point that is often overlooked: a trust is not just a technical connection, it is a design choice.

A choice that is born in a specific context, to solve a specific problem, and that can remain perfectly valid for years… until the context changes.

When hybrid identities, federations, additional UPN suffixes and cloud continuity requirements come into play, that same trust can become an invisible constraint.

Not because it is “wrong”, but because it was designed for a different world, with simpler boundaries and less articulated authentication paths.

The most important lesson is that trust does not automatically scale with complexity.

Adding new components, such as Entra ID, ADFS and multi forest synchronisations, without rethinking the trust model often means building on foundations that were not designed to bear that weight.

There is then a second lesson, even more subtle: trust related problems rarely manifest themselves explicitly.

They do not produce clear errors, they do not point to a precise cause. They present themselves as ambiguous behaviours, authentications that fail “for no reason”, configurations that appear correct but do not work. And it is precisely this ambiguity that makes them costly to diagnose and resolve.

As in the case of the guardian seen in Chapter 1, the problem is not the trusts themselves.

They continue to do exactly what they were designed to do: define perimeters, establish boundaries, and determine who can trust whom.

The problem arises when modern design ignores those boundaries, assuming that trust is implicit, transitive or adaptable by default.

In hybrid environments, trust is not an operational detail but a first level architectural decision.

Treating it as an inheritance to be endured, rather than as an element to be understood and redesigned, means pushing problems further into the future, where they will inevitably become more complex and more expensive, especially when “political” constraints are added to the equation.

And it is precisely from here that Legacy Things continues its path: bringing back to light those silent mechanisms which, although born decades ago, still determine the behaviour of modern infrastructures.

Because ignoring the past does not make it harmless. It only makes it harder to recognise when it makes itself felt again.

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?

December 15th, 1999.
The world is living through a strange mix of excitement and tension.

In Italian cinemas, The Green Mile is on screen. In the United States, people debate Fight Club and are shocked by the ending of The Sixth Sense.
On the radio, “Move Your Body” by Eiffel 65 plays nonstop, while “Mambo No. 5” by Lou Bega echoes across Europe.

But deep inside the IT world, attention is focused elsewhere.

Sixteen days remain before the turn of the millennium. The IT industry is holding its breath for the Millennium Bug, fearing that systems written decades earlier may fail when the date flips to January 1st, 2000.

In this climate of uncertainty, Microsoft releases Windows 2000 RTM, an operating system that breaks with the past and makes everything before it feel suddenly outdated, thanks to the introduction of Active Directory.

And the guardian is already there: AdminSDHolder is a native component, designed as an internal line of defense for the directory’s most critical mechanisms. It cannot be stopped or disabled. It can only be understood.

What It Is and How It Works

AdminSDHolder refers to one of the most important — and most forgotten — protection mechanisms in Active Directory.

Its goal is simple: to protect the most privileged accounts and groups in the domain, preventing incorrect permissions or overly permissive delegations from compromising them, either accidentally or intentionally.

In simple terms: to avoid locking yourself out of your own house — or letting someone else do it for you.

To achieve this, Active Directory adopts a rigid and intentionally non‑negotiable approach, documented in Microsoft’s official guidance on protected accounts and groups.

Within every Active Directory domain, there is a special object called AdminSDHolder, located in the System container.

This object is not a user or a group. It is a branch of Active Directory that contains a security template.

More precisely, its security descriptor (ACL) defines the standard permissions that must be enforced on all objects considered critical.

In other words:

• AdminSDHolder is the template

• the objects to be protected are the targets to which the template is applied

Whenever Active Directory detects a discrepancy between the template and a target object, it intervenes to restore the correct state. But how?

The entire mechanism is driven by an internal “engine” called SDProp (Security Descriptor Propagator).

SDProp is triggered on the Domain Controller holding the PDCE (Primary Domain Controller Emulator) role. It does not act in real time; instead, it performs a control cycle with a default interval of 60 minutes, which can be customized via a registry key.

During this cycle, it works like a guardian: if it finds something out of place, it brings it back to the expected state.

But which objects need to be protected?

The determining factor is membership in built‑in groups that hold a minimum level of privilege within the Active Directory environment. Here is the complete list:

• 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

All of these groups and their respective members are subject to the AdminSDHolder template.

Note:
By “members” we mean both direct membership and indirect membership through group nesting, which can sometimes make it difficult to identify which objects fall within scope.

This explains one of the most frustrating behaviors for those unfamiliar with the mechanism:

“I set permissions on the objects, everything works… and an hour later they’re gone.”

But how is the template actually applied?

In an intentionally aggressive way: Active Directory assumes that no standard delegation should ever have control over these objects.

When an object falls within scope, three fundamental things happen:

1. Permission inheritance is disabled

• The object stops inheriting ACLs from its parent OU.

• This means that delegations configured at the OU level no longer apply.

2. AdminSDHolder permissions are applied

• The object’s ACL is aligned with the template, regardless of where the object is located in the directory structure.

3. The adminCount attribute is set

• The adminCount attribute is set to 1, indicating that the object is (or has been) protected.

• This attribute, however, is not automatically reset when the object is removed from privileged groups, often leading to confusion and paradoxical situations.

The last thing to remember is that this mechanism cannot be disabled.
Its dynamics must be clearly understood in order to properly design IT processes that interact with Active Directory — especially those that rely on specific ACLs.

What Can Go Wrong

Now that we understand how the mechanism works, we get to what I personally find the most interesting part: seeing what can go wrong when these mechanisms are not fully understood.

To do that, I found it effective to bring in real‑world cases taken directly from the field.

Real Case #1 – The Group You Don’t Expect

We are in the middle of a complex migration project in a classic hybrid environment: Active Directory + Entra ID.

There is:

• a source AD domain with source users

• a target AD domain with target users

• Entra Connect configured to work with both domains and synchronize everything to Entra ID

Only the source users are currently synchronized.

The goal is as clear as it is ambitious: detach the source users and attach the target users, without any impact on the cloud.

For those who have never been involved in a project like this, I’ll restate my point of view: migrating resources in a modern hybrid environment is a balancing act.

Every single aspect must be aligned with absolute precision — otherwise, failure is almost guaranteed.

As soon as the migration procedure is prepared, the first problems emerge: more than half of the users show inconsistent attributes between on‑premises and cloud.

At a quick glance, Entra Connect reports recurring errors: permission-issue.

First check: the permissions of the Entra Connect service account, as suggested by this official article.

Nothing unusual at first glance.

Digging deeper, however, a curious detail emerges: all the users affected by the issue have one thing in common: from a certain point onward, new users are being created with an “unexplained” membership > Print Operators.

That detail changes everything: Print Operators is one of the protected groups in Active Directory.

Becoming a member automatically places the object within the AdminSDHolder scope, with inheritance disabled, permissions rewritten by SDProp, and ACLs that no longer follow the OU structure.

A mechanism designed 25 years ago was blocking the correct data flow to the cloud.

The solution turned out to be anything but straightforward:

• review of provisioning mechanisms

• removal of incorrect group memberships

• restoration of correct permissions on hundreds of user accounts

• realignment with the cloud

In short, a significant effort across multiple fronts — one that could have been avoided from the start with a bit more awareness in the design of provisioning flows.

In this case, poor AdminSDHolder was not blocking the migration at all.
It was simply doing its job, protecting accounts that should never have been treated as privileged in the first place.

Real Case #2 – When Security Meets Legacy

Another customer, another hybrid environment: Active Directory + Entra ID, with Entra Connect properly configured.
This time, however, the context is different: a stable environment, with no migration in progress.

A User Maintenance solution is introduced, with two clearly defined goals:

• notify users of upcoming password expiration, allowing them to change it from Entra ID using password writeback to Active Directory

• automatically disable user accounts for which no activity is detected, either on‑premises or in the cloud, for a given period of time

All of this is implemented in strict compliance with the Principle of Least Privilege (POLP).

A Service Principal is created for Entra ID and a GMSA for Active Directory.
Only the strictly necessary permissions are assigned to the service accounts (POLP).
The solution is configured, tested, and put into production.

Everything is designed and implemented according to modern security standards, and at first, everything appears to be working correctly.

After a short time, however, the first problems begin to surface:

• some users are unable to change their passwords

• others cannot be automatically disabled

At this point, the analysis focuses where experience has taught us to look:
permissions on the affected accounts, AdminSDHolder, and SDProp.

What emerges is a situation that is less rare than one might expect.

There are users who previously belonged to protected groups, but were later removed from them, leaving behind an inconsistent configuration: objects that are no longer privileged, yet still have adminCount = 1, permission inheritance disabled, and the AdminSDHolder template applied.

In this specific case, the root cause was identified in the use of dynamic assignments to privileged groups, based on Just‑In‑Time Administration, still fully compliant with POLP.

A correct choice from a security standpoint — but one that failed to account for the persistent effects of AdminSDHolder on the affected objects.

On paper, the solution might have seemed simple: clean things up and move on.
In reality, it turned out to be more complex than expected due to additional implications.

The first issue was that, to allow the User Maintenance solution to function correctly, it became necessary to assign permissions directly on the AdminSDHolder template to the service account.
This was required to enable the manipulation of objects that had become “stuck” in a permissions limbo.

Once again, a small detail completely changes the scenario.

This has a significant impact from a security perspective: the system running the solution effectively becomes a critical asset, which must be treated as Tier 0 according to the AD Tier Model, with all the associated implications in terms of hardening, access control, and segregation.

For these aspects, I refer you to the excellent article by my friend Stefano Nieri.

Finally, it is important to realize that even all of this is not sufficient on its own to fully resolve the issue: objects stuck in this limbo are still excluded from subsequent SDProp cycles.
This allows them to “bypass” the new permission set that would otherwise enable the solution to work correctly.

The only way to resolve the situation is an ad‑hoc cleanup, aimed at bringing the environment back to a stable state.

After reviewing the entire setup:

• a password reset in the cloud is correctly propagated to Active Directory

• a user who has not accessed either the cloud or on‑premises for a long time can be properly disabled

Once again, this is not a case of incorrect configuration.
It is the result of the interaction between legacy mechanisms and modern security requirements, whose design — if treated lightly — can lead to misleading results.

Hybrid environments, therefore, with today’s required security standards, are intrinsically more complex than cloud‑only environments.

In this case as well, greater awareness during the design phase would have made it possible to set things up correctly from the start, avoiding costly corrective actions later on.

Lessons learned from the Guardian

AdminSDHolder is a perfect example of how a “gear” that has been running under the hood for more than twenty years can be forgotten: it requires no maintenance, generates no alerts, and makes no noise.

And yet, the result of its work is always present — even, and especially, in modern cloud‑oriented environments.

The first lesson the guardian teaches us is simple, but often underestimated:
ignoring a mechanism does not make it harmless.

AdminSDHolder continues to do exactly what it was designed to do, enforcing security rules meant to protect the foundations of Active Directory — even when, on top of those foundations, we build automation, cloud integrations, and “modern” processes.

The second lesson is that doing things correctly is not always enough if there is no awareness of what happens underneath.

In the cases we’ve seen, there were no improvised configurations or neglected environments.
There were planned migrations, least‑privilege principles, Just‑In‑Time administration, and solutions designed according to current security standards.

And yet, without understanding the persistent effects of AdminSDHolder, even correct choices produced unexpected results.

The guardian also teaches us that legacy in systems is not always visible, but sooner or later, it comes back to collect its due.

Users who once belonged to privileged groups, attributes like adminCount that were never reset, broken permission inheritance — these are elements that can remain latent for years, until a new project, a new integration, or a new security requirement suddenly brings them to light.

When that happens, the problem does not manifest as a clear error, but as a “strange” behavior that is difficult to interpret, hard to diagnose, and often far more expensive to fix than expected.

Finally, there is a broader design lesson: in hybrid environments, complexity is not an exception — it is the norm.

Cloud and on‑premises are not separate worlds, but parts of the same system.
Rules from the past continue to influence the present, and designing modern solutions without knowing them simply means pushing problems further down the road.

It is precisely from this awareness that Legacy Things was born.

AdminSDHolder is not an isolated case, but only the first of many “old gears” that continue to operate beneath the surface of today’s infrastructures.
In the next chapters, we will explore other legacy mechanisms — other design choices from the past that still shape how we build, protect, and evolve our systems today.

And to you, who made it all the way to the end of this first chapter, I ask:

which hidden mechanisms would you like to see brought into the light next?

Osservando ciò che accade nelle moderne infrastrutture IT, mi capita sempre più spesso di imbattermi in malfunzionamenti o inefficienze che non nascono da bug di sistema o errori di progettazione, ma da qualcosa di molto più semplice: un gap di conoscenza.

I nuovi custodi delle infrastrutture enterprise sono cresciuti in un contesto dinamico, dove il cloud è il minimo sindacale e i sistemi si parlano tramite API o protocolli moderni. Sono estremamente competenti quando si parla di app, federazioni, container, AI.
Spesso però non hanno mai avuto l’opportunità di approfondire davvero le fondamenta on-premise che ancora reggono tutto e quando ci devono mettere le mani improvvisano o si affidano alle dubbie risposte dell’AI.

Meccanismi che per chi ha iniziato tra Windows 2000 e le prime foreste Active Directory sono familiari, oggi diventano enigmi a volte incomprensibili.
Ma non hanno colpe, stanno semplicemente vivendo un’epoca dove i temi on-premise sono stati “messi in soffitta”, perché nel tempo hanno perso di interesse e quindi di essere divulgati.

Sono argomenti che non generano più nuovo business, non vengono presentati ad un keynote, non fanno marketing. Restano lì, latenti, nell’ombra di tecnologie più interessanti che sono il cuore pulsante degli articoli tecnici e degli eventi IT.

Eppure, nonostante siano da molti “dichiarate morte”, queste tecnologie resistono ai decenni e restano operative, come dei soldati fedeli a cui nessuno ha detto che la guerra è finita.

Tutto questo porta però ad effetti domino inevitabili: una configurazione errata nelle fondamenta di Active Directory può produrre conseguenze a cascata sui sistemi di autenticazione cloud (Entra ID) o sull’accesso a piattaforme SaaS.

La cosa interessante che noto è però che, quando questi temi vengono spiegati, l’interesse è altissimo. Il problema non è la mancanza di curiosità, è la mancanza di esposizione.

È da questa osservazione che nasce questo piccolo progetto: Legacy Things.
Una serie di articoli per esplorare quei meccanismi progettati venti e passa anni fa che continuano a influenzare le infrastrutture di oggi, sperando così di poter colmare almeno un poco questo gap di conoscenza.

Nel primo capitolo partiremo da uno di quei meccanismi silenziosi che, di recente, ha dimostrato sul campo quanto il passato sia ancora profondamente intrecciato con il presente.

While observing what happens in modern IT infrastructures, I increasingly find myself dealing with malfunctions and inefficiencies that are not caused by bugs or design flaws, but by something much simpler: a knowledge gap.

The new custodians of enterprise infrastructures have grown up in a dynamic environment, where the cloud is the baseline and systems communicate through APIs and modern protocols.
They are highly skilled when it comes to applications, federations, containers, and AI.

Yet many of them have never had the opportunity to truly understand the on‑premise foundations that still hold everything together. And when they are forced to interact with them, they often improvise or rely on questionable answers from AI tools.

Mechanisms that were familiar to those who started their careers with Windows 2000 and the first Active Directory forests have now become puzzling, sometimes incomprehensible.

This is not their fault.
They are simply operating in a time when on‑premise topics have been pushed aside, having lost visibility, interest, and therefore proper documentation and discussion.

These are not topics that generate new business.
They are not showcased in keynotes.
They do not drive marketing narratives.

They remain there, latent, in the shadow of more appealing technologies that dominate technical articles and IT events.

And yet, despite being declared “dead” by many, these technologies have endured for decades and continue to operate — like loyal soldiers who were never told the war was over.

This inevitably leads to cascading effects: a misconfiguration in the foundations of a system can ripple through cloud authentication services or access to SaaS platforms.

What I find most interesting is that, when these topics are properly explained, interest is always high.
The problem is not a lack of curiosity — it is a lack of exposure.

It is from this observation that Legacy Things was born:
a series of articles aimed at exploring mechanisms designed more than twenty years ago that still influence today’s infrastructures, with the hope of closing at least part of this knowledge gap.

In the first chapter, we’ll start from one of those silent mechanisms that has recently shown, in real‑world scenarios, just how deeply the past is still intertwined with the present.