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.

Iscriviti ora

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.

April 1983. A year earlier, Imagination had been playing “Just an Illusion”, and without knowing it they were giving the perfect title to what would become a milestone in entertainment.

I do not remember what I was doing. I was six years old and certainly did not yet have a keyboard in my hands. But that feeling I remember well, because when the brain realizes it has been fooled, it makes a note of it for later.

We are in New York City, on Liberty Island. The show is ready, the lights are on, and thousands of people are about to witness something impossible. The world-famous David Copperfield has a very ambitious act in store: making the Statue of Liberty disappear live.

The show begins, tension builds, a large curtain drops and the “magic” happens. A few minutes pass, the curtain slides to the ground and… the statue is gone!

The illusion has taken place. Or at least it has for the audience. Those who know what happens behind the scenes know that the statue has not moved, it is the audience that has been moved.

Reality does not change, what changes is the point from which you observe it.

Turning the spotlight on the IT world, 1983 was a year full of ferment. On January 1st Arpanet, which would later become the Internet, adopts the TCP/IP protocol. At Microsoft, MS-DOS 2.0 is released and, at the end of the year, Windows is announced, long before the world would actually see it.

So many small seeds that would put down deep roots in modern IT. And that, in that moment, gave the illusion of already holding the future in one’s hands.

Forty years later, illusions are still with us, only more sophisticated. Today’s case does not show up as a clear error, but as a “strange” behaviour that seems to turn logic upside down… until we decide to change perspective.

Iscriviti ora

The “strange” case

2026. A customer, a member server, an apparently ordinary need.

On that machine a software module needs to be installed which, in order to do its job, requires two things:

· being a local administrator

· being able to perform some operations on Active Directory through the Remote Server Administration Tools (RSAT)

It is a request that anyone working in IT has seen dozens of times. Nothing that requires particular attention, apart from defining the precise delegation on Active Directory.

We proceed following the Principle of Least Privilege (POLP):

· a gMSA is created

· it is configured to run the service

· for the “local” operations it is added to the Administrators of the member server

Not a Domain Admin, not a personal account, no rushed solutions. It is the classic service identity, for which we are building the delegations needed to make it work.

Then we get to the most delicate operational part: the minimum permissions on Active Directory.

The RSAT are installed on the server, the Active Directory Users and Computers (ADUC) console is opened directly from there, and the consultant starts configuring the necessary delegations.

So far everything is straightforward: the gMSA is a normal domain user, it is a local admin only on that server, and the goal is to assign it a few targeted permissions on specific OUs.

In a POLP context, however, every delegation must be certified in the field.

So we move on to checking which effective permissions that account receives on the Active Directory tree, and it is at that point that something happens that should not happen: the gMSA seems to have rights well beyond the delegation just set.

We open an Organizational Unit > Properties > Security > Advanced > Effective Access.

We look at the permissions received by the gMSA, and it is all really strange: the interface says the account has “almost-full” permissions over the entire tree!

We re-check the account: it is a member only of the Domain Users.

The consultant has an intuition: what if we try removing the account from the local administrators of the member server?

No sooner said than done, we run a new check, and that is where things get even stranger: now the permissions on the Active Directory tree are correct.

That is when the matter lands on my desk. The consultant is rather confused: how can a local membership influence domain permissions? It is the world turned upside down!

I think over the information I have received, and in my mind an idea begins to take shape, one whose roots reach back to that distant 1983:

the behaviour is not real, we are facing an illusion!

The illusion revealed

Common logic says that a local membership cannot have effects on a directory that lives elsewhere. And yet, the checks seem to confirm it.

The system is saying that that identity, from that point of observation, is no longer a simple service with minimal privileges. Quite the opposite.

And this is exactly where the illusion becomes interesting, because if reality has not changed, then something else has.

And, as with the Statue of Liberty, the right question is not “what happened”, but:

“where are we looking from”?

The idea in my head becomes more and more present, and I ask the consultant: put things back the way they were, let us make sure the problem is present, then let us change our point of observation.

With the user put back into the local administrators of the member server, we verify that the “effective access” shows full permissions.

At that point I ask: shall we open the ADUC from a Domain Controller and run the same check from there?

As is clear from the image, the effective access is absolutely consistent with the delegation, there is no longer any trace of the almost-full permissions.

By changing perspective, the result changed, and this confirms the illusion.

But what, then, is creating this illusion?

I look at the consultant with a slight smile and tell him: I understand what happened, the test we just ran is the confirmation, it is a matter of Security Identifiers (SID).

I ask him to perform these two operations:

· from the member server, show the SID of the local Administrators group

· from the Domain Controller, show the SID of the built-in domain local Administrators group

And there is the illusion explained: the SID in the two cases is exactly the same!

Here is the Legacy Thing coming to the surface, once again we are facing one of those subtle default mechanisms that have been there for decades and whose memory has been lost: the well-known SIDs.

What they are and why they are still there

We already dealt with the concept of the Security Identifier (SID) in chapter 2, so I will not go back over it. What matters here is a very particular category of them: the well-known SIDs.

The vast majority of SIDs are born “unique”: they are generated at the exact moment the object is created, by the Local Security Authority (LSA) for the local objects of a machine or by the Domain Controller for domain objects, and are never reused to identify anyone else. The well-known SIDs do exactly the opposite: they have a fixed value, identical on any system. They are not generated: they simply exist.

There is even a precise date to which their practical debut can be traced. SIDs are not born with Active Directory, nor with some intermediate version of Windows: they arrive already with Windows NT 3.1, the very first release of the NT family, shipped on July 27, 1993.

They were an integral part of the new security model designed by Dave Cutler’s team, the one built on access tokens and access control lists (ACL). In other words, when we talk about well-known SIDs we are not looking at a recent detail, but at a piece of architecture that has been with us, substantially unchanged, for over thirty years.

But where does the rule that imposes those fixed values come from? Who decided it, and where is it written? It is not an informal convention, nor a choice left to the individual implementation: it is set down in black and white in an official specification. The well-known SIDs are listed, one by one, in the [MS-DTYP] Windows Data Types document, in the section dedicated to the Well-Known SID Structures, where it is explicitly stated that their values “remain constant across all operating systems”.

It is one of Microsoft’s Open Specifications, that is, the protocol documentation designed so that anyone can implement the same model in an interoperable way. In other words, it is not that “Windows does it this way”: it is that anyone who wants to speak the same language is required to use exactly those numbers.

And here we come to a point that often surprises: the SID is not exclusive to the Windows world. The documentation itself distinguishes two families. On one side there are the universal well-known SIDs, which are meaningful “on all secure systems that adopt this security model, including operating systems other than Windows”, such as Everyone / World (S-1-1-0) or Creator Owner (S-1-3-0), the latter used as a placeholder in inheritable ACEs. On the other side there are the Windows-specific ones, including the BUILTIN groups.

That this is not just theory is confirmed in the field: implementations such as Samba, which today can act as an Active Directory Domain Controller on Linux, reason with exactly the same SIDs. For them the local Administrators group is the identical S-1-5-32-544, and components like winbind exist precisely to map those SIDs onto the UID/GID of the Unix world.

The security model, in short, crossed the boundaries of Windows long ago.

Let us go back to our case. The Administrators group of the “built-in domain” has a very specific well-known SID: S-1-5-32-544. It is worth reading it piece by piece: the 5 is the NT authority, the 32 identifies precisely the built-in domain, and the 544 is the RID of the Administrators group.

Always that one: on the member server, on the Domain Controller, on the consultant’s laptop. Identical, and not by chance.

The detail that generates the illusion lies entirely in that shared value. On a member server, S-1-5-32-544 is the group of the local administrators of that machine, and nothing more. On a Domain Controller, however, the “built-in domain” coincides with the domain itself: that same identical SID represents there the administrators of the domain, with all the authority over the directory that comes with it.

When the Effective Access is calculated from the member server, the tool sees that the gMSA belongs to S-1-5-32-544 and compares it with the ACLs of Active Directory, where that same SID enjoys full permissions. The tool does not know, and cannot know, that “that 544, seen from here, is only valid locally”. It puts together two different contexts that share the same label and returns an inflated picture. It is enough to move the point of observation to a DC for the ambiguity to disappear: from there the context is only one, and the numbers add up.

So why, after decades, are they still there? For the same reason you do not switch language halfway through a conversation. The well-known SIDs are one of the fundamental bricks of the authorization model: inherited ACEs, access tokens, delegations, default permissions, everything rests on them. Changing them would mean breaking compatibility with anything written in the last thirty years, and not only on the Windows side. They are stable by design: it is the specification itself that binds them to remain constant over time and across different systems.

They are not, therefore, an error, nor an oversight left lying around out of laziness. They are exactly what they were meant to be. The problem is not the SID: it is that we, faced with an interface, tend to read a label while forgetting where we are looking at it from. And the point of observation, as usual, is everything.

What it taught us

The first lesson this case leaves us is only simple in appearance: the tool was not lying. The Effective Access did exactly its job, it calculated the access starting from what it saw from that point, and it answered in a formally correct way. The problem is that we were looking for another truth, that of the real permissions on the directory, and it had never promised to tell us that one. So I come back to that motto I have already used in these pages, because there is no better summary: IT systems do not do what you want, they do what you tell them to do. We had effectively asked that tool “tell me what you see from here”, and it, with implacable consistency, answered exactly that. The illusion was not in the software, but in having mistaken its answer for the question we had in our heads.

The second lesson concerns the way we react when facing an “impossible” behaviour. The instinct, almost always, is to immediately look for a culprit: a bug, a wrong configuration, a compromise, something that “broke”. But in this case nothing had broken, and no hunt for a culprit would have led anywhere. The turning point came only when we stopped asking ourselves “what happened” and started asking “where are we looking from”. Moving the point of observation, from the member server to the Domain Controller, made the anomaly vanish exactly as the Statue of Liberty returned to its place the moment the audience realized it had moved. The consultant, faced with those impossible permissions, had exclaimed “it is the world turned upside down!”. And that is precisely where the lesson lies:

When the world seems absurdly upside down, almost always it is not the world that has flipped over: it is your point of observation that is wrong.

Before believing that it is reality spinning the wrong way, it is worth checking where we are looking at it from.

There is, finally, a third lesson, and it is the one that holds the entire series together: legacy is not a defect, it is lost memory. The well-known SID was not an error left there out of laziness, it was exactly what it was meant to be, stable by design for over thirty years. What was missing was not the correctness of the system, but our knowledge of the model, knowing that that 32 means “built-in domain” and that that 544 is worth the exact same number in different worlds. It is the same thread that runs through all these chapters. The guardian of AdminSDHolder rewriting permissions no one was asking for anymore, the trusts born to give shape to trust and turned into an invisible constraint, the Domain Controller that seemed to lie while it was telling the truth. Every time, the point was not that the system was broken. The point was that the system kept doing what it had been designed to do, while we had lost part of the memory of that design.

Perhaps this is the real illusion of legacy systems: they do not deceive us by hiding, they deceive us by staying in plain sight, so obvious and silent that we stop really looking at them. They keep answering with precision, but we have forgotten the question they were answering. And so, as in front of the Statue of Liberty, the only way to recognize the trick is not to stare more intensely at the same spot, but to have the humility to move and ask ourselves where we are looking from.

And it is exactly from here that Legacy Things continues its journey: bringing back to light those silent mechanisms that, although born decades ago, still govern the behaviour of modern infrastructures. Not out of nostalgia, but because ignoring them does not make them harmless. It only makes them better at showing us things that do not exist.

1987. Il mondo ragionava per blocchi, confini e recinti. L’esempio più eclatante: la guerra fredda tra USA e Unione Sovietica.

Berlino ne era il simbolo più evidente e il Muro era ancora in piedi a ricordarlo a tutti. Il 12 giugno di quell’anno il presidente USA di allora, Ronald Reagan, davanti alla Porta di Brandeburgo, pronunciava una frase destinata a restare nella storia come una provocazione e una speranza insieme:

“Mr. Gorbachev, tear down this wall!”

Pochi mesi dopo, l’8 dicembre, Stati Uniti e Unione Sovietica firmavano il trattato INF, primo segnale concreto di un equilibrio che iniziava lentamente a incrinarsi. Fuori c’erano ancora i muri, ma da qualche parte si iniziava già a parlare di futuro.

È in quella strana sospensione, tra muri ancora intatti e crepe già visibili, che nasceva un algoritmo di cifratura destinato a durare a lungo: RC4.

Non come standard aperto, non come bene comune, ma come segreto industriale. In quell’anno infatti Ron Rivest, uno dei fondatori di RSA Data Security, progetta l’algoritmo come componente della libreria crittografica proprietaria RSA.

La sigla viene comunemente tradotta in “Rivest Cipher 4”, anche se secondo Ron Rivest stesso le lettere RC stavano per “Ron’s Code”.

Quando penso a quel 1987, però, non riesco a sentirci solo la geopolitica o la tensione della Guerra Fredda. Ci sento anche altro.

Nei club la musica House vive la sua epoca d’oro, e il sottoscritto ne rimane ammaliato, muovendo i primi passi tra vinili, mixer e dei fidatissimi Technics SL-1210 MK2. La cosa curiosa è che, come l’RC4, anche la tecnologia musicale di allora era progettata per durare. Ancora oggi posso accendere lo stesso impianto e suonare gli stessi vinili senza alcun problema.

Ma parlando di vinili, se ne devo scegliere uno per fare da cornice al contesto storico, il primo che mi viene in mente è Promised Land di Joe Smooth. Perché mentre fuori il mondo era ancora fatto di separazioni, dentro quel suono girava già un’idea opposta:

“brothers and sisters, one day we will be free”

non più divisione, non più conflitto, ma l’idea che si possa finalmente camminare nella stessa direzione.

Poi arrivò il 9 novembre 1989, e il Muro di Berlino cadde davvero. Con lui non venne giù soltanto una barriera di cemento, ma l’idea stessa che certi recinti fossero naturali, inevitabili o destinati a durare per sempre. Da lì in avanti il cambiamento non fu solo politico. Fu culturale. Cambiò il modo di guardare ai confini, alla circolazione delle idee, alla pretesa che alcune cose dovessero restare chiuse in eterno, creando un effetto domino che si diffuse ovunque negli anni seguenti.

Cinque anni dopo, 1994, quel mondo non è ancora finito del tutto, ma ha già perso la sua rigidità originaria. E infatti, in un modo perfettamente anni Novanta, anche RC4 esce dal recinto con un leak dalla grande risonanza mediatica: una descrizione dell’algoritmo viene pubblicata anonimamente sulla mailing list dei cypherpunks e poi rilanciata su sci.crypt. Il segreto smette di essere tale e comincia la sua divulgazione.

Il caso finisce anche su TIME con un articolo dal nome “The Secret’s Out”. Segno che il leak non è più solo materia da addetti ai lavori.

Ma invece di decretarne la fine, quel leak ne inaugurò una seconda vita: da segreto industriale RC4 diventò oggetto di circolazione, implementazione e discussione sempre più ampia.

Passano altri cinque anni, 1999, anche Microsoft decide di adottare RC4 come algoritmo di cifratura standard per la propria implementazione Kerberos, usandolo come ponte di compatibilità per accompagnare la transizione dagli ambienti Windows NT esistenti e contribuendo a farlo diventare uno dei pilastri delle autenticazioni Windows per i decenni a venire.

La cosa curiosa è che nemmeno allora la storia si considera davvero completa, bisogna aspettare addirittura dicembre 2006 perché questa parte della sua vita venga formalizzata in un RFC (4757) che documenta i tipi di cifratura RC4-HMAC usati da Microsoft in Windows.

Più di dieci anni dopo la sua rivelazione pubblica, quasi vent’anni dopo la sua nascita. Come se la burocrazia, ancora una volta, si limitasse a registrare qualcosa che la pratica aveva già accettato da tempo.

E proprio qui, tra un segreto troppo bello per restare tale e un’idea troppo utile per sparire subito, comincia davvero la storia del suo declino.

Iscriviti ora

Perché RC4 è arrivato davvero al tramonto

Prima di raccontare perché RC4 sia arrivato al tramonto, vale la pena ricordare perché abbia avuto così tanta fortuna. Non si è diffuso per caso, né soltanto perché era disponibile. Per il mondo degli anni Novanta era quasi perfetto: era veloce, semplice da implementare, leggero per l’hardware dell’epoca e abbastanza flessibile da infilarsi in contesti molto diversi tra loro. Non richiedeva strutture particolarmente complesse, lavorava bene in software e poteva essere adottato in protocolli che avevano bisogno di cifrare flussi di dati in modo pratico, senza appesantire troppo sistemi e applicazioni.

Per questo finì ovunque: nelle prime versioni di SSL e TLS, nelle reti Wi‑Fi con WEP, poi WPA/TKIP, e infine come già visto dentro Kerberos in ambiente Windows. In altre parole, RC4 non era solo un algoritmo: era una soluzione pratica a un problema molto concreto, quello di portare un po’ di cifratura in un mondo che stava diventando sempre più connesso, ma che non poteva ancora permettersi di cambiare tutto insieme.

Ma quindi, cosa ne sta decretando la fine?

RC4 non esce di scena perché qualcuno ha deciso, all’improvviso, che fosse soltanto “vecchio”. Esce di scena perché il mondo che lo aveva reso una buona idea è cambiato. Per anni è stato il compromesso perfetto: solido quanto bastava per sembrare moderno, flessibile quanto serviva per accompagnare sistemi che dovevano evolvere senza potersi permettere di buttare via tutto ciò che c’era prima.

Il punto è che i compromessi tecnici invecchiano male quando il contesto smette di proteggerli. Ed è esattamente quello che è successo a RC4. Con il tempo sono emerse debolezze crittografiche sempre più difficili da ignorare, mentre intorno crescevano attacchi più pratici, più accessibili e alternative più solide. Non è un caso se RC4 ha iniziato a uscire di scena in più ambiti: nel 2015 l’IETF ne vieta l’uso in TLS, nel 2020 ne depreca formalmente l’uso in SSH, e nel mondo Wi‑Fi il settore spinge da anni verso WPA2 con AES, lasciandosi alle spalle le soluzioni transitorie che ancora si appoggiavano allo stesso cipher di fondo.

Questo introduce il caso Microsoft, che non va letto come un’eccezione, ma come uno degli ultimi capitoli di una storia già iniziata altrove. Nel post ufficiale Beyond RC4 for Windows authentication, Microsoft dice apertamente che RC4 è suscettibile ad attacchi come il Kerberoasting e che un’autenticazione Windows sicura non ha più bisogno di lui, perché AES è disponibile da anni su tutte le versioni supportate. In altre parole, RC4 non smette di funzionare: arriva al tramonto quando il presente smette di avere buone ragioni per continuare a farne uso.

Come Microsoft sta accompagnando RC4 fuori scena

A guardarla bene, questa storia non comincia quest’anno. Microsoft aveva già iniziato a spostare il baricentro lontano da RC4 almeno dal 2022, quando gli aggiornamenti legati a CVE-2022-37966 hanno portato AES a diventare il default per le session keys sugli account senza impostazioni esplicite. Non era ancora una dismissione finale, ma il segnale era già chiaro: il vecchio compromesso stava perdendo terreno. Anche la documentazione più recente lo riconosce apertamente, spiegando che quel cambio ha già ridotto in modo significativo l’uso di RC4, pur senza eliminarlo del tutto.

Il 2025 e soprattutto il 2026, però, cambiano il tono della musica. Non siamo più nel campo dell’hardening progressivo o del dettaglio tecnico che passa quasi inosservato in una cumulative update. Siamo nel momento in cui Microsoft decide di rendere esplicita la traiettoria e di scandirla in fasi molto leggibili: prima l’audit, poi il cambio di comportamento di default, infine la chiusura della tolleranza implicita. È come se per anni ci fosse stato un cartello “lavori in corso” all’ingresso, e solo quest’anno qualcuno avesse cominciato davvero a chiudere la strada.

Il punto di svolta, a quel punto, diventa luglio 2026. Perché è lì che la timeline smette di essere una successione di avvisi e diventa scadenza vera. KB5073381 dice che gli aggiornamenti rilasciati in quel periodo abiliteranno programmaticamente la Enforcement Phase; la procedura operativa che stiamo usando sul campo lo traduce in maniera ancora più netta: niente rollback comodo, niente ritorno al passato per inerzia, niente fallback implicito lasciato lì a proteggere ciò che nessuno ha ancora messo in ordine. Da quel momento RC4 continua a vivere solo dove qualcuno lo avrà mantenuto in modo esplicito, account per account, eccezione per eccezione.

Ed è proprio qui che la faccenda si fa interessante. Perché Microsoft mette a disposizione strumenti ufficiali per affrontare il problema: più visibilità nei log, una pagina di guidance su come rilevare e correggere l’uso di RC4, e degli script PowerShell di auditing richiamati nella documentazione ufficiale. Ma la realtà è che questi strumenti, da soli, rischiano di restituire una fotografia piena di rumore.

La documentazione Microsoft stessa spiega che RC4 continua a comparire per ragioni diverse: sistemi legacy, account senza impostazioni esplicite, configurazioni incomplete. E l’esperienza sul campo aggiunge un dettaglio ancora più concreto: i grandi numeri grezzi possono essere fuorvianti, l’assenza di traffico RC4 rilevato non è sempre conclusiva, e certe categorie, come gli account “senza AES keys” letti in modo superficiale, rischiano di allargare il problema più di quanto serva davvero.

Per questo il passaggio successivo non può essere solo tecnico. Serve un approccio ampio, sì, ma soprattutto pragmatico: abbastanza esteso da non perdere i segnali deboli, abbastanza lucido da non farsi travolgere dal rumore di fondo.

Perché nei sistemi enterprise il passato non si presenta quasi mai in modo ordinato. Si annida nelle abitudini, nelle impostazioni ereditarie, nei default lasciati lì per anni, nei comportamenti che sembrano normali solo perché nessuno li guardava più da vicino.

Ed è da lì che bisogna partire, se davvero si vuole arrivare ai nodi chiave e iniziare a sbrogliare la matassa.

Cosa sta emergendo dalle analisi che stiamo facendo

Quando si passa dalla teoria ai sistemi veri, la faccenda smette subito di sembrare lineare. Sulla carta il problema potrebbe apparire quasi banale: Microsoft cambia un default, RC4 esce di scena e chi è rimasto indietro si adegua.

Mi è capitato più volte di sentire frasi del tipo: “sono abbastanza sicuro che da noi non avrà impatti”. E ogni volta mi sono chiesto da dove arrivasse tutta quella sicurezza.

Nella pratica, infatti, i sistemi enterprise non ragionano mai in modo così pulito. Ragionano per abitudini, per stratificazioni, per impostazioni ereditate che continuano a produrre effetti molto tempo dopo che ci si è dimenticati perfino il motivo per cui erano state messe lì. Ed è proprio in questa zona grigia che RC4 continua a lasciare tracce.

Guardando i dati emersi sul campo, la prima cosa che si capisce è che i numeri grezzi aiutano fino a un certo punto.

Partendo da uno sguardo d’insieme, il quadro tende quasi sempre a restringersi attorno agli stessi punti sensibili. Non tanto i grandi volumi indistinti, ma una manciata di account di servizio con SPN, password storiche mai ruotate, qualche sistema non Windows o non chiaramente AES-capable, e tutti quei pezzi d’infrastruttura che vivono tranquilli da anni proprio perché nessuno ha più avuto motivo di toccarli.

A contorno centinaia o migliaia di oggetti utente e computer che si sistemano con un approccio pragmatico, ma che nascondono alla vista i nodi focali.

Nei report che stiamo producendo la logica torna spesso la stessa: il lavoro vero non sta nei grandi numeri che fanno impressione in una tabella, ma in pochi oggetti che tengono ancora in piedi dipendenze pesanti e poco visibili.

C’è poi un altro aspetto, forse il più insidioso: l’assenza di evidenze forti non coincide automaticamente con l’assenza di problemi.

In più di un caso la raccolta eventi è risultata limitata o parziale, e la raccomandazione è quella di impostare una finestra di audit abbastanza ampia quando i dati non bastano a chiudere il quadro.

Anche qui torna il solito paradosso dei sistemi legacy: il passato non fa rumore quando è davvero presente, anzi spesso resta tranquillo finché qualcuno non decide di guardarlo meglio.

Per questo, più andiamo avanti, più il punto mi sembra chiaro: affrontare RC4 non significa semplicemente “cercare dove appare” e spegnerlo ovunque. Significa leggere i sistemi con una lente abbastanza larga da non perdere il contesto, ma abbastanza pragmatica da individuare i nodi che contano davvero.

Non serve inseguire ogni riflesso. Serve capire quali segnali portano a dipendenze reali, quali sono solo rumore di fondo e dove conviene intervenire senza farsi travolgere dal groviglio.

Ed è proprio qui che l’esperienza sul campo diventa vitale: perché nei sistemi legacy il problema raramente è dove lo vedi subito. Più spesso è dove nessuno pensava più di dover guardare.

Note pratiche dal campo

A questo punto vale la pena scendere ancora di un livello. Perché i dati aiutano, ma sono gli esempi concreti a far capire dove il passato continua davvero a pesare. In questo caso ho chiesto aiuto al collega Mattia Grandi, che ha riassunto bene gli aspetti più tecnici in questo articolo.

Parlando di casi emblematici il primo che mi viene in mente è Kemp Loadmaster, molto spesso usato per fare ripubblicazioni con Kerberos Constrained Delegation (KCD).

Questo è uno di quei casi in cui l’implementazione Kerberos non è “Windows native”. Di conseguenza il cambio di algoritmo va effettuato con cautela, identificando bene la sequenza operativa e una finestra manutentiva dedicata. È un pattern comune nelle implementazioni Kerberos di terze parti.

Guardando poi “verso il cielo” ci possiamo trovare a dover gestire lo storico account AZUREADSSOACC$, utilizzato per la funzionalità di Seamless Single Sign-On per Entra ID.

È un classico esempio di implementazione cloud-driven che, proprio perché nata con un default storico su RC4, oggi mostra tutti i limiti di quella scelta.

Bisogna poi ricordarsi che il Kerberos per sua natura non è confinato a un solo dominio, ma spesso esce dai confini attraverso le Trust.

Queste ultime sono altrettanto suscettibili rispetto all’algoritmo di funzionamento impostato: se ho una Trust che non supporta AES, o che non ha AES configurato, la chiusura del RC4 la “romperà” come se fosse un PC qualsiasi, ma con effetti molto più diffusi.

Parliamo infine di sistemi legacy, che siano dei Windows Server 2003 sopravvissuti ai decenni o implementazioni di terze parti che non supportano AES, ad esempio gli immortali sistemi AS/400.

In questi casi non sempre sarà possibile chiudere RC4 in modo netto e immediato.

Sarà invece necessario indagare in maniera puntuale quale sia l’utilizzo effettivo che viene fatto del Kerberos. Questo per poter gestire esclusioni mirate e consapevoli.

Come vedete, lo spettro d’azione si allarga in fretta. Il rischio non è solo rompere qualcosa, ma perdere il controllo della situazione o concentrare gli sforzi dove non serve davvero.

Cosa ci ha insegnato il tramonto di RC4

La prima lezione che il tramonto di RC4 ci lascia è semplice solo in apparenza: i compromessi tecnici più riusciti sono anche quelli più difficili da mandare in pensione. RC4 è sopravvissuto così a lungo non perché fosse perfetto, ma perché per anni è stato veloce, pratico, compatibile e sufficientemente leggero da diventare invisibile. E quando una tecnologia diventa invisibile, smette di essere discussa molto prima di smettere di produrre effetti reali.

La seconda lezione riguarda il modo in cui trattiamo il passato nei sistemi enterprise. Ignorarlo non lo rende innocuo. Lo rende solo più difficile da riconoscere quando torna a presentare il conto. Nel caso di RC4 quel conto ha anche una data abbastanza precisa: luglio 2026. Chi arriverà a quel punto ancora dipendente da questo vecchio compromesso non si troverà davanti a un mistero, ma a fallimenti di autenticazione ampiamente prevedibili.

Questo non significa affrontare il tema in modo ideologico. Nei sistemi reali esistono sempre eccezioni, dipendenze, appliance che non seguono i tempi del resto dell’infrastruttura, sistemi davvero non AES-capable e integrazioni che richiedono una transizione più lenta. Ma proprio perché queste eccezioni esistono, devono restare quello che sono: eccezioni vere, documentate, approvate e riesaminate. Non una nuova normalità dietro cui continuare a nascondere l’inerzia.

Perché compatibilità e inerzia non sono la stessa cosa. La compatibilità è una scelta progettuale consapevole: serve a far evolvere un sistema senza spezzarlo. L’inerzia, invece, è quello che rimane quando quella scelta smette di essere governata. È il default lasciato lì troppo a lungo, l’account di servizio mai rivisto, la trust che nessuno tocca più, il sistema legacy che continua a funzionare non perché sia stato compreso, ma perché nessuno ha ancora avuto il coraggio o il tempo di guardarci dentro.

In fondo è lo stesso filo che attraversa tutti questi capitoli. Il guardiano di AdminSDHolder, le trust nate per dare forma alla fiducia, il Domain Controller che sembrava mentire: ogni volta il punto non era che il sistema fosse rotto. Il punto era che il sistema continuava a fare quello per cui era stato progettato, mentre noi avevamo perso parte della memoria di quel progetto.

RC4 racconta la stessa cosa da un’altra angolazione. Non è il mostro da cancellare dalla storia, e nemmeno il simbolo di un errore clamoroso. È stato una buona risposta a un problema del suo tempo. Solo che il tempo, a un certo punto, cambia domanda. E quando cambia domanda, continuare a dare la stessa risposta non è più compatibilità: è ostinazione.

Forse è questa la lezione più importante del suo tramonto: non possiamo pretendere che i sistemi legacy spariscano da soli, né che smettano spontaneamente di influenzare il presente. Dobbiamo guardarli, capirli, decidere cosa salvare e cosa accompagnare fuori scena. Senza nostalgia, ma anche senza arroganza. Perché molte delle cose che oggi chiamiamo legacy sono state, nel loro momento, ottime soluzioni.

Il problema nasce quando continuiamo a trattarle come se il mondo intorno non fosse cambiato.

RC4 ha avuto una vita lunga, utile e per certi versi sorprendente. Adesso però il tramonto non è più una metafora: è una deadline. E, come spesso accade nelle infrastrutture enterprise, la differenza tra una transizione ordinata e un incidente evitabile sta tutta nel decidere se occuparsene quando c’è ancora luce, oppure aspettare il buio.

1987. The world still thought in blocs, borders and enclosures. The clearest example was the Cold War between the United States and the Soviet Union.

Berlin was its most visible symbol, and the Wall was still standing there to remind everyone of it. On June 12 of that year, the then President of the United States, Ronald Reagan, stood in front of the Brandenburg Gate and spoke a sentence that would remain in history as both a provocation and a hope:

“Mr. Gorbachev, tear down this wall!”

A few months later, on December 8, the United States and the Soviet Union signed the INF Treaty, the first concrete sign of a balance that was slowly beginning to crack. Outside, the walls were still there, but somewhere people had already started talking about the future.

It was in that strange suspension, between walls still intact and cracks already visible, that an encryption algorithm destined to last for a very long time was born: RC4.

Not as an open standard, not as a common good, but as an industrial secret. In that same year, Ron Rivest, one of the founders of RSA Data Security, designed the algorithm as part of RSA’s proprietary cryptographic library.

The acronym is commonly expanded as “Rivest Cipher 4”, although according to Ron Rivest himself, the letters RC stood for “Ron’s Code”.

When I think about that 1987, though, I cannot hear only geopolitics or the tension of the Cold War. I hear something else too.

In the clubs, House music was living its golden age, and I was completely fascinated by it, taking my first steps among vinyl records, mixers and a pair of faithful Technics SL-1210 MK2 turntables. The curious thing is that, just like RC4, the musical technology of that time had been built to last. Even today I can switch on the same system and play the same records without any problem.

But speaking of vinyl, if I had to choose one record to frame that historical moment, the first one that comes to mind is Promised Land by Joe Smooth. Because while the world outside was still made of separations, inside that sound there was already the opposite idea:

“brothers and sisters, one day we will be free”

no more division, no more conflict, but the idea that one day we might finally walk in the same direction.

Then November 9, 1989, arrived, and the Berlin Wall really fell. What came down with it was not only a concrete barrier, but the very idea that some fences were natural, inevitable or meant to last forever. From that moment on, the change was not only political. It was cultural. It changed the way people looked at borders, at the circulation of ideas, at the assumption that some things should remain closed forever, creating a domino effect that spread everywhere in the following years.

Five years later, in 1994, that world had not completely ended yet, but it had already lost its original rigidity. And, in a very Nineties kind of way, RC4 also escaped its enclosure through a leak that gained significant public attention: a description of the algorithm was anonymously posted to the cypherpunks mailing list and then reposted on sci.crypt. The secret stopped being a secret and began to circulate.

The story even appeared in TIME with an article titled “The Secret’s Out”. A sign that the leak was no longer only a matter for specialists.

But instead of marking its end, that leak opened a second life for RC4: from an industrial secret it became something that could be shared, implemented and discussed more and more widely.

Another five years passed and, in 1999, Microsoft also decided to adopt RC4 as the standard encryption algorithm for its Kerberos implementation, using it as a compatibility bridge to accompany the transition from existing Windows NT environments and helping it become one of the pillars of Windows authentication for decades to come.

The curious thing is that even then the story was not really considered complete. It would take until December 2006 for this part of its life to be formalized in an RFC, number 4757, documenting the RC4-HMAC encryption types used by Microsoft in Windows.

More than ten years after its public disclosure, almost twenty years after its birth. As if bureaucracy, once again, were simply recording something that practice had already accepted long before.

And right there, between a secret too good to remain hidden and an idea too useful to disappear at once, the story of its decline truly begins.

Iscriviti ora

Why RC4 has really reached sunset

Before explaining why RC4 has reached sunset, it is worth remembering why it was so successful in the first place. It did not spread by chance, nor simply because it was available. For the world of the Nineties, it was almost perfect: fast, simple to implement, light for the hardware of the time and flexible enough to fit into very different contexts. It did not require particularly complex structures, worked well in software and could be adopted in protocols that needed to encrypt data streams in a practical way, without making systems and applications too heavy.

That is why it ended up almost everywhere: in the early versions of SSL and TLS, in Wi-Fi networks with WEP, then WPA and TKIP, and finally, as we have already seen, inside Kerberos in Windows environments. In other words, RC4 was not just an algorithm: it was a practical answer to a very concrete problem, bringing some encryption into a world that was becoming more and more connected, but still could not afford to change everything at once.

So what is really bringing it to an end?

RC4 is not leaving the stage because someone suddenly decided it was simply “old”. It is leaving because the world that had made it a good idea has changed. For years it was the perfect compromise: solid enough to look modern, flexible enough to accompany systems that needed to evolve without throwing away everything that already existed.

The point is that technical compromises age badly when the context stops protecting them. And that is exactly what happened to RC4. Over time, cryptographic weaknesses emerged that became harder to ignore, while attacks around them became more practical, more accessible and better alternatives became available. It is no coincidence that RC4 began to leave the stage in several areas: in 2015 the IETF banned its use in TLS, in 2020 its use in SSH was formally deprecated, and in the Wi-Fi world the industry had long been moving toward WPA2 with AES, leaving behind the transitional solutions that still relied on the same underlying cipher.

This brings us to the Microsoft case, which should not be read as an exception, but as one of the last chapters of a story that had already started elsewhere. In the official post Beyond RC4 for Windows authentication, Microsoft openly states that RC4 is susceptible to attacks such as Kerberoasting and that secure Windows authentication no longer needs it, because AES has been available for years on all supported versions. In other words, RC4 does not stop working: it reaches sunset when the present no longer has good reasons to keep using it.

How Microsoft is accompanying RC4 off stage

If we look closely, this story does not begin this year. Microsoft had already started moving the center of gravity away from RC4 at least in 2022, when the updates related to CVE-2022-37966 made AES the default for session keys on accounts without explicit settings. It was not the final retirement yet, but the signal was already clear: the old compromise was losing ground. The most recent documentation also recognizes this openly, explaining that the change has already significantly reduced the use of RC4, although without eliminating it completely.

2025 and especially 2026, however, change the music. We are no longer around progressive hardening or of a technical detail that almost disappears inside a cumulative update. We are at the point where Microsoft decides to make the direction explicit and to mark it in very readable phases: first audit, then a change in default behavior, and finally the end of implicit tolerance. It is as if for years there had been a “work in progress” sign at the entrance, and only this year someone had really started closing the road.

At that point, the turning point becomes July 2026. Because that is when the timeline stops being a sequence of warnings and becomes a real deadline. KB5073381 says that the updates released in that period will programmatically enable the Enforcement Phase; the operating procedure we are using in the field translates it even more clearly: no comfortable rollback, no return to the past by inertia, no implicit fallback left there to protect what no one has yet put in order. From that moment on, RC4 continues to live only where someone has kept it explicitly, account by account, exception by exception.

And this is exactly where things become interesting. Microsoft provides official tools to address the problem: more visibility in the logs, guidance on how to detect and remediate RC4 usage, and PowerShell auditing scripts referenced in the official documentation. But the reality is that these tools, on their own, risk returning a very noisy picture.

Microsoft’s own documentation explains that RC4 can still appear for different reasons: legacy systems, accounts without explicit settings, incomplete configurations. And field experience adds an even more concrete detail: raw large numbers can be misleading, the absence of detected RC4 traffic is not always conclusive, and some categories, such as accounts “without AES keys” read too superficially, risk making the problem look larger than it really is.

That is why the next step cannot be only technical. The approach must be broad, yes, but above all pragmatic: wide enough not to miss the weak signals, lucid enough not to be overwhelmed by background noise.

Because in enterprise systems the past almost never presents itself in an orderly way. It hides in habits, inherited settings, defaults left there for years, behaviours that seem normal only because no one had looked at them closely anymore.

And that is where we need to start, if we really want to reach the key knots and begin untangling the thread.

What is emerging from the analyses we are doing

When you move from theory to real systems, the matter immediately stops looking linear. On paper, the problem may almost seem trivial: Microsoft changes a default, RC4 leaves the stage, and whoever is left behind adapts.

More than once, I have heard sentences like: “I am pretty sure this will not impact us”. And every time I wondered where all that certainty came from.

In practice, enterprise systems never think that cleanly. They think through habits, layers, inherited settings that keep producing effects long after everyone has forgotten why they were put there in the first place. And it is precisely in this gray area that RC4 continues to leave traces.

Looking at the data emerging in the field, the first thing you understand is that raw numbers only help up to a point.

Starting from the big picture, the view almost always narrows around the same sensitive points. Not so much the large indistinct volumes, but a handful of service accounts with SPNs, historical passwords that were never rotated, some non-Windows or not clearly AES capable systems, and all those pieces of infrastructure that have been living quietly for years precisely because no one had a reason to touch them anymore.

Around them, hundreds or thousands of user and computer objects that can be handled with a pragmatic approach, but that tend to hide the focal knots from view.

In the reports we are producing, the logic often comes back to the same point: the real work is not in the big numbers that look impressive in a table, but in a few objects that still hold heavy and poorly visible dependencies together.

Then there is another aspect, perhaps the most insidious one: the absence of strong evidence does not automatically mean the absence of problems.

In more than one case, event collection turned out to be limited or partial, and the recommendation is to set a sufficiently wide audit window when the available data is not enough to close the picture.

Here too the usual paradox of legacy systems comes back: the past does not make noise when it is truly present. In fact, it often stays quiet until someone decides to look more carefully.

That is why, the further we move on, the clearer the point seems to me: addressing RC4 does not simply mean “looking for where it appears” and turning it off everywhere. It means reading systems through a lens wide enough not to lose context, but pragmatic enough to identify the knots that really matter.

There is no need to chase every reflection. What matters is understanding which signals lead to real dependencies, which ones are only background noise, and where it makes sense to intervene without being swallowed by the tangle.

And this is exactly where field experience becomes vital: because in legacy systems, the problem is rarely where you see it immediately. More often, it is where no one thought they still needed to look.

Practical notes from the field

At this point it is worth going down one more level. Because data helps, but concrete examples are what make it clear where the past is still carrying weight. In this case I asked my colleague Mattia Grandi for help, and he summarized the most technical aspects well in his article.

Speaking of emblematic cases, the first one that comes to mind is Kemp Loadmaster, very often used for republishing with Kerberos Constrained Delegation, or KCD.

This is one of those cases where the Kerberos implementation is not Windows native. Therefore, the algorithm change must be handled with care, clearly identifying the operating sequence and a dedicated maintenance window. It is a common pattern in third party Kerberos implementations.

Looking then “toward the cloud”, we may have to deal with the historical AZUREADSSOACC$ account, used by the Seamless Single Sign-On feature for Entra ID.

It is a classic example of a cloud driven implementation that, precisely because it was born with a historical default on RC4, now shows all the limits of that choice.

We must also remember that Kerberos, by its nature, is not confined to a single domain, but often crosses boundaries through Trusts.

These too are just as sensitive to the algorithm that has been configured for them: if I have a Trust that does not support AES, or that does not have AES configured, the closure of RC4 will “break” it as if it were any ordinary PC, but with much broader effects.

Finally, let us talk about legacy systems, whether they are Windows Server 2003 machines that survived the decades or third-party implementations that do not support AES, such as the immortal AS/400 systems.

In these cases, it will not always be possible to shut down RC4 cleanly and immediately.

Instead, it will be necessary to investigate precisely what Kerberos is actually being used for. This is the only way to manage targeted and conscious exclusions.

As you can see, the field of action widens quickly. The risk is not only breaking something, but losing control of the situation or focusing effort where it is not really needed.

What we learned from the sunset of RC4

The first lesson left by the sunset of RC4 is only apparently simple: the most successful technical compromises are also the hardest ones to retire. RC4 survived for so long not because it was perfect, but because for years it was fast, practical, compatible and light enough to become invisible. And when a technology becomes invisible, it stops being discussed long before it stops producing real effects.

The second lesson concerns the way we treat the past in enterprise systems. Ignoring it does not make it harmless. It only makes it harder to recognize when it comes back to ask for payment. In the case of RC4, that bill also has a precise date: July 2026. Anyone who reaches that point still depending on this old compromise will not be facing a mystery, but widely predictable authentication failures.

This does not mean approaching the subject ideologically. In real systems there are always exceptions, dependencies, appliances that do not follow the timing of the rest of the infrastructure, systems that are truly not AES capable and integrations that require a slower transition. But precisely because these exceptions exist, they must remain what they are: real exceptions, documented, approved and reviewed. Not a new normal behind which inertia can continue hiding.

Because compatibility and inertia are not the same thing. Compatibility is a conscious design choice: it helps a system evolve without breaking it. Inertia, instead, is what remains when that choice stops being governed. It is the default left there for too long, the service account never reviewed, the trust no one touches anymore, the legacy system that keeps working not because it has been understood, but because no one has yet had the courage or the time to look inside it.

After all, it is the same thread that runs through all these chapters. The guardian of AdminSDHolder, the trusts created to give shape to trust, the Domain Controller that seemed to lie: every time, the point was not that the system was broken. The point was that the system kept doing what it had been designed to do, while we had lost part of the memory of that design.

RC4 tells the same story from another angle. It is not the monster to erase from history, nor the symbol of a catastrophic mistake. It was a good answer to a problem of its time. Only time, at some point, changes the question. And when the question changes, continuing to give the same answer is no longer compatibility: it is stubbornness.

Maybe this is the most important lesson of its sunset: we cannot expect legacy systems to disappear on their own, nor to spontaneously stop influencing the present. We need to look at them, understand them, decide what to preserve and what to accompany off stage. Without nostalgia, but also without arrogance. Because many of the things we call legacy today were, in their moment, excellent solutions.

The problem begins when we keep treating them as if the world around them had not changed.

RC4 had a long, useful and in some ways surprising life. Now, however, sunset is no longer a metaphor: it is a deadline. And as often happens in enterprise infrastructures, the difference between an orderly transition and an avoidable incident lies entirely in deciding whether to deal with it while there is still light, or wait for the dark.

Estate 1998, primo vero lavoro: sottomano mi passano centinaia di Motorola 8700, il telefono con il flip che tutti volevano. Nel giro di poco riesco a connettere i sistemi in un dominio Windows NT, trasformando il modo di lavorare disconnesso degli operatori in qualcosa di moderno.

Fuori da quella stanza, il mondo stava vivendo un’estate intensa.

Nelle sale italiane The Truman Show teneva banco: un uomo che viveva una vita perfetta, ignaro del fatto che ogni dettaglio intorno a lui era costruito a tavolino. Una realtà impeccabile nella forma, falsa nella sostanza. Nei Mondiali di calcio in Francia si consumava invece un altro piccolo mistero: si diceva che il sorteggio del girone, presieduto da Platini, non fosse poi così casuale come appariva. La distinta ufficiale parlava chiaro, i numeri erano lì a disposizione, eppure il risultato sembrava scritto prima ancora di iniziare. Qualcosa non tornava e l’ammissione arriverà solo 20 anni dopo. E mentre i ragazzi consumavano le ore su FIFA Road to World Cup 98 con Song 2 dei Blur nelle orecchie, dall’altra parte dell’Atlantico Bill Clinton, a gennaio, guardava dritto in camera e dichiarava al mondo intero di non aver avuto alcuna relazione con Monica Lewinsky. Verrà smentito il 17 agosto.

Tre storie diverse, un unico filo: una fonte attendibile che restituisce una risposta che non corrisponde alla realtà.

In quegli stessi giorni, in un datacenter Microsoft, veniva rilasciato silenziosamente Windows NT 4.0 Terminal Server Edition, nome in codice Hydra. Con lui nasceva quello che tutti avrebbero chiamato Terminal Services, e che il mondo conosce oggi come RDP.

Quasi ventisette anni dopo, su un sistema protetto da una delle piattaforme di sicurezza più avanzate al mondo, un utente prova ad aprire una sessione RDP e si trova davanti un messaggio inequivocabile: “A user account restriction is preventing you from logging on.”

Il Domain Controller ha parlato, l’IP è quello giusto, la fonte è attendibile.

Eppure anche qui, qualcosa non tornava.

Iscriviti ora

Lo scenario

A differenza dei capitoli precedenti, in questo articolo non parleremo della tecnologia in sé, il protocollo RDP è solamente l’innesco di una situazione più intrecciata, per questo motivo andremo invece ad approfondire lo specifico scenario che si è rivelato essere molto interessante.

Iniziamo descrivendo il contesto che, a una prima occhiata, non ha legami con tecnologie cloud, risulta essere molto comune, quasi banale.

È uno di quegli ambienti che chi lavora con Active Directory incontra spesso, soprattutto nel mondo enterprise:

Una filiale italiana di una multinazionale, forte focus on‑premise, con un’infrastruttura Active Directory stratificata nel tempo. Le linee guida arrivano dall’HQ.
Un child domain, eredità di una riorganizzazione avvenuta anni prima, e una manciata di Domain Controller distribuiti su più siti: alcuni fisicamente in sede, altri ospitati su infrastruttura cloud, integrati nel disegno come semplice estensione del perimetro aziendale.

Niente di particolare. Niente che, sulla carta, faccia pensare a problemi imminenti.

Sembra quasi l’incipit di “Un giorno di ordinaria follia”, ma quello è un altro film…

Da anni, per le attività operative quotidiane sull’applicativo XYZ, viene utilizzato un account amministrativo generico, condiviso tra più persone: XYZ-admin.
Una scelta che oggi farebbe storcere il naso a chiunque parli di Identity governance o Zero Trust, ma che nel tempo aveva sempre fatto il suo lavoro e per la logica del “funziona = non si tocca” è rimasto come eredità.
Accessi RDP, attività di manutenzione, interventi urgenti: tutto è passato di lì per anni, senza intoppi.

Finché, un giorno, smette di funzionare.

Non gradualmente. Non “a volte sì, a volte no”. Improvvisamente non si accede più.

Ogni tentativo di accesso RDP con quell’account restituisce lo stesso risultato:

“A user account restriction is preventing you from logging on.”

Nessun cambiamento apparente, nessuna modifica dichiarata, nessun alert che indichi cosa stia succedendo.

La problematica scala al personale IT del cliente che inizia un primo troubleshooting. Il primo istinto è quello più naturale: provare a cambiare Domain Controller.
Forzare l’autenticazione verso DC diversi, magari su site differenti, per escludere un problema puntuale.
Ma il risultato non cambia, stessa risposta, stesso errore.

Nel frattempo, emerge una coincidenza temporale difficile da ignorare: nei giorni precedenti è stato eseguito un ciclo di patching sui Domain Controller.
La pista sembra promettente.
Il cliente controlla gli aggiornamenti installati, si cercano articoli su internet, si confrontano versioni, si ipotizzano bug diffusi spulciando i forum IT.
È una spiegazione logica e rassicurante: qualcosa è cambiato, quindi qualcosa si è “rotto”.

Il problema è che, anche scavando, non emerge nulla:

· Le patch sui DC sono allineate

· Non ci sono altri utenti che si lamentano di mancato accesso

· Non ci sono errori evidenti nei log che giustifichino un comportamento così selettivo

A questo punto le idee del cliente iniziano ad esaurirsi.
Le ipotesi più ovvie sono state esplorate, le verifiche standard eseguite, non sono emerse soluzioni rapide.

È solo allora che il cliente decide di aprire il ticket verso il nostro supporto.

Ed è proprio qui che la situazione diventa interessante.

L’analisi

La problematica viene quindi assegnata ad uno dei consulenti del mio team, che inizia ad approfondire. Come prima cosa ri-verifica il percorso fatto dal cliente, per la logica del “fidarsi è bene ma non fidarsi è meglio”. Nulla di nuovo.

Passa quindi ad analizzare in dettaglio il messaggio di errore: “A user account restriction is preventing you from logging on.”

Le “user account restriction” sono impostazioni che arrivano da lontano, dai tempi di Windows NT 4, quelle che hanno un effetto diretto sulle sessioni RDP di solito sono: Logon Time Restriction e Workstation Restriction.

Viene controllato l’utente ma nessuna traccia di quelle impostazioni, sembra tutto in ordine, idem per le GPO applicate allo stesso.

Si controllano quindi gli eventi sul Target System, ma anche lì nulla.

Si cambia quindi prospettiva passando a prove empiriche con altri account, scoprendo comportamenti curiosi:

· Provando ad accedere in RDP allo stesso server con l’utente del consulente, l’accesso va a buon fine

· Provando a creare un nuovo utente e ad accedere con questo in RDP, si ottiene lo stesso errore

· Provando a usare un Source System differente e l’utente XYZ-admin l’accesso va a buon fine

Non è quindi una questione di solo utente, ma una combinazione di: utente + Source System + Target System.

Anche in questo caso la questione arriva sul mio tavolo per un parere. Iniziamo ad andare a fondo, partendo da quelle che considero le tavole della legge del troubleshooting:

Si passa quindi a fare una traccia di rete sul Source System, iniziando a scoprire cose interessanti:

· La sessione RDP non arriva a dialogare con il Target System, il blocco avviene prima

· Viene individuata la corrispondenza con il messaggio di errore:

o Il Source System inizia una sessione RDP verso il Target System

o il Source System dialoga quindi con un Domain Controller chiedendo autorizzazione all’accesso RDP per l’utente XYZ-admin@domain.xyz verso il Target System

o A quel punto il Domain Controller risponde con un errore Kerberos: KDC_ERR_POLICY

· Quando la connessione avviene dal Source System 2, non vi è traccia dell’errore Kerberos

· Quando la connessione avviene dal Source System, ma con l’utente del consulente non si ottiene alcun errore Kerberos

Si passa quindi a verificare cosa succede sul Domain Controller in questione, analizzandone i log in dettaglio. Qui succede una cosa incomprensibile: viene tracciato un evento che corrisponde in maniera precisa, per data, ora e ambito, a quello presente nella traccia di rete, peccato che abbia esito affermativo: è un’autorizzazione lecita all’accesso!

Il Domain Controller è quindi convinto di aver rilasciato un OK, mentre il Source System riceve in risposta un KO. Chi o cosa nel mezzo sta mentendo???

L’analisi prosegue e facendo altre tracce di rete si scoprono altre cose curiose:

· Tutte le chiamate che vanno a buon fine dal Source System 2 richiedono sempre autorizzazione ad uno specifico Domain Controller.

· Tutte le chiamate che vanno in errore dal Source System non chiedono mai autorizzazione al Domain Controller con cui dialoga il Source System 2, anzi vengono contattati Domain Controller a caso nel mondo.

Abbiamo quindi identificato la sequenza di errore ma la causa non è ancora chiara, anzi le prove non fanno altro che confondere le idee.

Con la convinzione che “ci sia qualcosa nel mezzo”, supportata dal mancato dialogo con l’unico Domain Controller “buono”, si torna ad indagare sulla rete aprendo questa volta un ticket al supporto network di HQ.

Rimangono comunque dubbi sul come mai l’account del consulente funzioni regolarmente.

Passa qualche giorno e da HQ arriva un messaggio interessante: ho sistemato l’account, riprovate adesso.

Aspetta… come “ho sistemato l’account”, qual è la spiegazione con tutto questo?

Ad ogni modo si procede con un nuovo test e, meraviglia, tutto funziona!

Vengono quindi richiesti maggiori chiarimenti, dopo tutta questa fatica abbiamo bisogno di capire.

La risposta è disarmante: è colpa di CrowdStrike, che aveva marcato l’utente come “non umano”.

Quindi avevamo ragione, c’era veramente qualcosa nel mezzo! Solo che nessuno aveva visibilità su cosa.

Ma andiamo con ordine e ricostruiamo quello che è successo, perché è una di quelle situazioni interessanti dove il caos e le incomprensioni la fanno da padrona:

· CrowdStrike ha un modulo che si chiama “Identity Protection”

· HQ ha distribuito l’agente di CrowdStrike sui Domain Controller, tutti tranne quello con cui parlava Source System 2

· CrowdStrike ha fatto una scansione e ha identificato XYZ-admin come Non-Human Identity

· L’agente sui Domain Controller ha preso il controllo delle risposte Kerberos, modificandole in corsa secondo i propri parametri

· I Domain Controller erano quindi convinti di avere risposto OK, ma l’agente lo convertiva in KO

· A complicare tutto c’è stato effettivamente un problema di rete, il Source System aveva la strada bloccata verso il Domain Controller “buono” ottenendo un regolare KO per le sessioni RDP di XYZ-admin

La cosa che più mi ha colpito di questo strano caso è questa: siamo di fronte ad una tecnologia Cloud moderna (CrowdStrike) che governa tecnologie legacy senza tenere conto dei reali effetti sulle stesse, generando comportamenti strani ed errori fuorvianti.

Entra inoltre nell’equazione il concetto di Non-Human Identity, che ha radici profonde negli ambienti legacy, ma è diventato attualissimo sotto la spinta dei sistemi AI.

E per la cronaca, il povero Domain Controller non aveva colpe: lui la verità stava provando a dirla veramente…

Cosa ci ha insegnato

La prima lezione che questo caso ci lascia è semplice solo in apparenza: anche le fonti più autorevoli possono raccontare una verità distorta. E dietro non c’è sempre un bug o una cattiva configurazione, ma spesso c’è il fatto che il contesto in cui operano è cambiato, mentre loro continuano a svolgere il proprio lavoro con coerenza implacabile.

Il povero Domain Controller non era guasto o “bugiardo”.
Stava facendo il proprio mestiere rispondendo con sicurezza.
Eppure la risposta che arrivava non era quella utile. Era formalmente corretta, sostanzialmente sbagliata.

La seconda lezione riguarda il modo in cui interpretiamo gli errori.
Messaggi fuorvianti, log senza errori, comportamenti incoerenti tra sistemi identici: il troubleshooting moderno a volte non offre indizi diretti. I meccanismi legacy si intrecciano con livelli di protezione sempre più sofisticati e “governati dall’alto”, creando scenari in cui ogni pezzo della catena sembra funzionare… ma il risultato continua a non tornare.

Infine, riagganciandoci al capitolo 2, c’è un insegnamento più grande: la fiducia nel sistema è spesso data per scontata.
Ci fidiamo del Domain Controller, del DNS, del network, degli agent, dei layer di protezione cloud. Ma ogni elemento introduce il proprio modello di verità, costruito nel proprio perimetro. Quando questi modelli non sono allineati o non dialogano tra di loro in maniera coerente, ciò che riceviamo non è un errore esplicito, ma una risposta “corretta” che non rappresenta più la realtà.

E questo vale non solo per gli account umani.
Sempre più spesso, nelle infrastrutture moderne, le identità realmente critiche non sono quelle delle persone, ma quelle dei processi, dei servizi, dei connettori, dei job schedulati. Le Non‑Human Identities operano sottotraccia, con privilegi spesso invisibili, e prendono decisioni in autonomia. Sarebbe ingenuo pensare che non possano incappare negli stessi paradossi, o crearne di nuovi.
What Are Non-human Identities? | Microsoft Security

Per ora, la lezione resta chiara:
nei sistemi complessi la verità non sparisce in maniera netta. Si nasconde in silenzio, finché qualcuno non decide di guardare nel posto giusto.

Questo capitolo è per Denys, che ha trovato la verità nel posto giusto. Spero che anche ora sia nel posto giusto.

Summer 1998, my first real job: I find myself handling hundreds of Motorola 8700s, the flip phone everybody wanted. Before long, I manage to connect the systems into a Windows NT domain, transforming the operators’ disconnected way of working into something modern.

Outside that room, the world was living through an intense summer.

In Italian cinemas, The Truman Show was all anyone talked about: a man living a perfect life, unaware that every detail around him had been carefully constructed. A reality flawless in form, false in substance. In the 1998 World Cup in France, another small mystery was unfolding: people said the group-stage draw, presided over by Platini, was not as random as it looked. The official sheet was crystal clear, the numbers were there for everyone to see, and yet the outcome seemed written before it had even begun. Something did not add up, and the admission would only come 20 years later. And while kids were spending hours playing FIFA Road to World Cup 98 with Song 2 by Blur in their ears, on the other side of the Atlantic Bill Clinton, in January, looked straight into the camera and told the whole world that he had not had any relationship with Monica Lewinsky. He would be contradicted on August 17.

Three different stories, one common thread: a trustworthy source returning an answer that does not match reality.

In those same days, in a Microsoft datacenter, Windows NT 4.0 Terminal Server Edition, codenamed Hydra, was quietly released. With it, what everyone would later call Terminal Services was born, and what the world now knows as RDP.

Almost twenty seven years later, on a system protected by one of the most advanced security platforms in the world, a user tries to open an RDP session and is met with an unmistakable message: “A user account restriction is preventing you from logging on.”

The Domain Controller has spoken, the IP is the right one, the source is trustworthy.

And yet here too, something did not add up.

Iscriviti ora

The scenario

Unlike the previous chapters, in this article we will not be talking about the technology itself, the RDP protocol is only the trigger for a more tangled situation, which is why we will instead dig into the specific scenario, one that turned out to be very interesting.

Let us begin by describing the context which, at first glance, has no connection with cloud technologies and appears to be very common, almost ordinary.

It is one of those environments that anyone working with Active Directory encounters often, especially in the enterprise world:

An Italian branch of a multinational company, with a strong on premises focus, and an Active Directory infrastructure layered over time. The guidelines come from HQ.
A child domain, inherited from a reorganization that took place years earlier, and a handful of Domain Controllers distributed across multiple sites: some physically on premises, others hosted on cloud infrastructure, integrated into the design as a simple extension of the corporate perimeter.

Nothing unusual. Nothing that, on paper, would suggest imminent problems.

It almost sounds like the opening of Falling Down, but that is another film entirely…

For years, the daily operational work on the XYZ application had been carried out using a shared generic administrative account: XYZ-admin.
A choice that today would make anyone who talks about Identity governance or Zero Trust wince, but which had always done its job over time and, by the logic of “if it works, do not touch it”, remained there as a legacy inheritance.
RDP access, maintenance activities, urgent interventions: everything had gone through that account for years, without issues.

Until one day, it stops working.

Not gradually. Not “sometimes yes, sometimes no”. Suddenly, access is gone.

Every RDP logon attempt with that account returns the same result:

“A user account restriction is preventing you from logging on.”

No apparent change, no declared modification, no alert explaining what is happening.

The issue escalates to the customer’s IT staff, who begin an initial round of troubleshooting. The first instinct is the most natural one: try a different Domain Controller.
Force authentication toward different DCs, perhaps in different sites, to rule out a localized problem.
But the result does not change, same answer, same error.

Meanwhile, a timing coincidence emerges that is hard to ignore: in the previous days a patching cycle had been carried out on the Domain Controllers.
The lead seems promising.
The customer checks the installed updates, looks for articles on the internet, compares versions, and starts to suspect widespread bugs by digging through IT forums.
It is a logical and reassuring explanation: something changed, therefore something “broke”.

The problem is that, even after digging, nothing emerges:

· The patches on the DCs are aligned

· No other users are complaining about access failures

· There are no obvious errors in the logs that would justify such selective behaviour

At this point the customer’s ideas begin to run out.
The most obvious hypotheses have been explored, the standard checks completed, and no quick solutions have emerged.

Only then does the customer decide to open a ticket with our support team.

And that is exactly where the situation becomes interesting.

The analysis

The issue is then assigned to one of the consultants on my team, who starts digging deeper. The first thing he does is retrace the path already taken by the customer, following the old logic that “trust is good, not trusting is better”. Nothing new.

He then turns to a detailed analysis of the error message: “A user account restriction is preventing you from logging on.”

These “user account restrictions” are settings that come from far away, from the days of Windows NT 4. The ones that usually have a direct effect on RDP sessions are Logon Time Restriction and Workstation Restriction.

The user is checked, but there is no trace of those settings, everything seems in order, and the same goes for the GPOs applied to it.

The events on the Target System are then checked, but again, nothing.

The perspective then shifts to empirical testing with other accounts, revealing some curious behaviour:

· Trying to log on through RDP to the same server with the consultant’s user account, access succeeds

· Trying to create a new user and log on through RDP with it results in the same error

· Trying to use a different Source System and the user XYZ-admin, access succeeds

So, it is not just a user issue, but a combination of: user + Source System + Target System.

In this case as well, the matter ends up on my desk for an opinion. We begin to dig deeper, starting from what I consider the tablets of the law of troubleshooting:

A network trace is then taken on the Source System, and interesting things start to emerge:

· The RDP session never gets to talk to the Target System, the block happens earlier

· A correlation with the error message is found:

o The Source System starts an RDP session toward the Target System

o The Source System then talks to a Domain Controller, asking for authorization for RDP access for user XYZ-admin@domain.xyz toward the Target System

o At that point the Domain Controller responds with a Kerberos error: KDC_ERR_POLICY

· When the connection comes from Source System 2, there is no trace of the Kerberos error

· When the connection comes from the Source System, but using the consultant’s user account, no Kerberos error is returned

Attention then shifts to what is happening on the specific Domain Controller, by analyzing its logs in detail. And here something incomprehensible happens: an event is recorded that matches precisely, by date, time and scope, the one seen in the network trace, except that it has a positive outcome: it is a legitimate authorization to access!

So, the Domain Controller is convinced it returned an OK, while the Source System receives a KO in response. Who or what in the middle is lying???

The analysis continues and, with more network traces, other curious things come to light:

· All the successful calls from Source System 2 always request authorization from one specific Domain Controller.

· All the failing calls from the Source System never request authorization from the Domain Controller that Source System 2 talks to, in fact they contact random Domain Controllers around the world.

We have therefore identified the error sequence, but the cause is still not clear. If anything, the evidence only makes things more confusing.

With the conviction that “there is something in the middle”, supported by the lack of dialogue with the only “good” Domain Controller, the investigation turns back to the network, and this time a ticket is opened with HQ network support.

There is still, however, the question of why the consultant’s account works normally.

A few days go by, and an interesting message arrives from HQ: I fixed the account, try again now.

Wait… what do you mean by “I fixed the account”, what is the explanation behind all this?

In any case, a new test is run and, wonder of wonders, everything works!

Further clarification is then requested, after all this effort we need to understand.

The answer is disarming: it is CrowdStrike’s fault, which had marked the user as “non-human”.

So, we were right, there really was something in the middle. Only no one had visibility into what it was.

But let us go in order and reconstruct what happened, because this is one of those interesting situations where chaos and misunderstandings rule the scene:

· CrowdStrike has a module called “Identity Protection”

· HQ deployed the CrowdStrike agent on the Domain Controllers, all except the one that Source System 2 was talking to

· CrowdStrike ran a scan and identified XYZ-admin as a Non-Human Identity

· The agent on the Domain Controllers took control of the Kerberos responses, modifying them on the fly according to its own parameters

· The Domain Controllers were therefore convinced they had answered OK, but the agent converted that into KO

· To make matters worse, there really was a network problem: the Source System had its path blocked toward the “good” Domain Controller, obtaining a regular KO for the RDP sessions of XYZ-admin

The thing that struck me most about this strange case is this: we are facing a modern cloud technology, CrowdStrike, governing legacy technologies without taking their real effects into account, generating strange behavior and misleading errors.

The concept of Non-Human Identity also enters the equation, something with deep roots in legacy environments, yet one that has become extremely current under the pressure of AI systems.

And for the record, the poor Domain Controller was not to blame: it really was trying to tell the truth…

Lessons learned

The first lesson this case leaves us is only simple in appearance: even the most authoritative sources can tell a distorted truth. And behind it there is not always a bug or a bad configuration, but often the fact that the context in which they operate has changed, while they continue to do their job with implacable consistency.

The poor Domain Controller was not broken or “a liar”.
It was doing its job, answering with confidence.
And yet the answer that arrived was not the useful one. It was formally correct, substantially wrong.

The second lesson concerns the way we interpret errors.
Misleading messages, logs without errors, inconsistent behaviour across identical systems: modern troubleshooting sometimes offers no direct clues. Legacy mechanisms become intertwined with ever more sophisticated layers of protection, “governed from above”, creating scenarios where every piece of the chain seems to be working… but the result still does not add up.

Finally, reconnecting with chapter 2, there is a larger lesson: trust in the system is often taken for granted.
We trust the Domain Controller, DNS, the network, the agents, the cloud protection layers. But every element introduces its own model of truth, built within its own perimeter. When those models are not aligned or do not talk to one another coherently, what we receive is not an explicit error, but a “correct” answer that no longer represents reality.

And this applies not only to human accounts.
More and more often, in modern infrastructures, the truly critical identities are not those of people, but those of processes, services, connectors and scheduled jobs. Non-Human Identities operate under the surface, often with privileges that remain invisible, and they make decisions on their own. It would be naive to think they cannot run into the same paradoxes or create new ones.
What Are Non-human Identities? | Microsoft Security

For now, the lesson remains clear:
in complex systems, truth does not disappear cleanly. It hides in silence, until someone decides to look in the right place.

This chapter is for Denys, who found the truth in the right place. I hope that even now he is in the right place.

Venerdì 13 marzo 2026, una data che sembra anonima, se vista dal lato scaramantico in alcune culture c’è chi crede che porti sfortuna, ma per me ha un significato particolare: mi è venuta un’idea e la voglio realizzare.

In realtà i semi di quell’idea arrivano da un percorso iniziato qualche tempo prima.

Il primo risale al 6 maggio 2025: European Identity Conference a Berlino, seconda sessione della giornata, tra i top trend previsti per il 2025 c’è l’esplosione degli MCP Server.

Guardo in faccia il mio collega e ci facciamo la stessa domanda: cosa diavolo è un MCP Server? Dobbiamo assolutamente approfondire!

Passano mesi e come da perfetta profezia gli MCP Server iniziano a spuntare come funghi.

Il secondo seme risale al 25 febbraio 2026: è da un po’ che sento l’esigenza di scrivere su “roba legacy”, parlo con un collega e finalmente trovo la “casa” giusta per il mio progetto. Immediatamente decido di aprire questo blog su Substack e nel giro di una settimana pubblico il primo articolo. È il 1° marzo 2026.

L’essere su questa piattaforma mi ha però dato la possibilità di leggere cose molto interessanti negli altri blog della piattaforma. Molto spesso sono argomenti distanti tecnicamente dal mio lavoro, ma che risuonano bene con il mio modo di vedere le cose.

Ma torniamo al 13 marzo 2026, leggo un post dove si parla dell’evoluzione di Claude.ai. Parla di quanto i suoi nuovi modelli siano potenti e di un esperimento di Vibe Coding estremo.

Ecco, quello è l’ultimo seme…

L’idea inizia a germogliarmi in testa, arrivato a sera inizio la mia prima chiacchierata con l’app Claude, breve botta e risposta ed ecco che trova la sua forma:

E se volessi scrivere una interfaccia MCP per Active Directory?

Ci dormo sopra (si fa per dire) e mi sveglio con un disegno piuttosto chiaro in testa.

Dopo colazione inizio a bombardare l’AI facendo un “dump” della mia memoria e lei tiene il ritmo. Arriviamo ad una prima bozza, ma c’è un bel sole e l’erba alta mi chiama, è tempo di uscire.

Taglio, medito, scarico, taglio, medito, scarico e così via…

Pomeriggio secondo round con l’AI, altro dump massivo ed arriviamo ad un disegno molto chiaro, decido che è ora da fare una scommessa:

può un vecchio sistemista, con un passato di programmazione che si è fermato a Visual Basic 6, ma che conosce bene i sistemi, creare da zero un progetto per un MCP Server open source?

È in quel momento che investo 20 euro per accedere a Claude Code e ufficialmente nasce il progetto Legacy MCP.

Domenica 15 marzo 2026, mi sveglio e mi dedico alla mia passione per la Formula 1, e faccio bene.

Una giovane promessa dell’automobilismo italiano, a soli 19 anni, parte dalla pole position, domina la gara e ottiene la sua prima vittoria, centrando una scommessa fatta dalla Mercedes quando aveva solo 11 anni. È Andrea Kimi Antonelli.

Sono euforico e penso che sarà una grande giornata, mi metto quindi all’opera per impostare i lavori e dopo pranzo “accendo le macchine”, tempo un paio d’ore ed ho il primo prototipo funzionante.

Quando vedo che posso interrogare i dati esattamente come mi ero immaginato mi casca la mascella e rimango letteralmente a bocca aperta, pensando: sì questa è una scommessa che va portata a termine!

Questo articolo non nasce per spiegare una tecnologia, ma per raccontare un percorso.
È il racconto di cosa succede quando un’idea legacy incontra strumenti nuovi, e qualcuno decide di provarci davvero, mettendo in contatto i due mondi.

Iscriviti ora

Perché serviva farlo

Se avete letto i miei articoli precedenti (Capitolo 1, Capitolo 2 ) saprete già il mio punto di vista, per i nuovi lettori lo riassumo brevemente: nonostante la spinta al cloud, le tecnologie legacy continuano a sopravvivere. Solo che, col tempo, stanno iniziando a diventare misteriose e quindi serve un modo per tramandarle.

Ogni progetto che viene avviato dal mio team parte sempre dallo stesso punto: dobbiamo fare un assessment e produrre un documento.

E nella stragrande maggioranza dei casi, il cuore dell’assessment è sempre lui: Active Directory.

Per anni ci si è affidati alla fedele PowerShell con soluzioni scripting più o meno standard, ma con un punto fermo: l’uso dell’ottimo ADDS_Inventory_V3.ps1 del mitico Carl Webster.

Il problema è che lo sviluppo e la manutenzione di questi script stanno diventando sempre più onerosi, mentre fuori il mondo surfa veloce sull’onda dell’AI.

Non volevo buttare via quel patrimonio: volevo renderlo interrogabile, modulare e riutilizzabile.

E allora mi sono fatto una domanda semplice: perché non provare a mettere in contatto questi due mondi?

La chiave di volta l’ho trovata nel protocollo MCP. Molto spesso viene descritto come “la porta USB per l’AI”: uno standard aperto che permette di “connettere” i sistemi di AI a moduli esterni di qualsiasi tipo.

Per chi vuole approfondire rimando alla documentazione ufficiale: What is the Model Context Protocol (MCP)? - Model Context Protocol

Da qui nasce l’idea di realizzare un Server MCP che faccia da ponte tra il mondo Active Directory e i sistemi di AI: Legacy MCP.

In pratica: un modo standard per interrogare AD usando strumenti AI, spostando il focus dal come al cosa.

Come anticipato, durante i primi due giorni ho avuto intense sessioni con Claude Chat: ho definito principi e linee guida che mi hanno permesso di vedere risultati tangibili in meno di 48 ore.

Tra questi c’è la distinzione netta tra progetto open core ed enterprise: va bene che sono “solo” 20 euro, ma fare le cose bene richiede tempo, quindi serve anche darsi un limite.
La scelta è stata piuttosto semplice, naturale e coerente:

se il progetto prende spunto dal grande lavoro di Carl Webster, allora l’open core deve coprire tutto quello che per anni ha coperto lo script ADDS_Inventory_V3.ps1.

È un modo per restituire alla community una parte di quello che ho ricevuto, ma portandolo al passo con le tecnologie attuali.

Su queste basi, verrà poi portato avanti uno strato enterprise che richiede sforzi ed investimenti differenti, e che coprirà funzionalità più avanzate e sofisticate:

· open core = inventario e interrogazioni fondamentali

· enterprise = analisi avanzate / report / integrazioni

Cosa può fare per te

Legacy MCP nasce per un obiettivo semplice: rendere interrogabile Active Directory, permettendo correlazioni incrociate tra i dati e spostando il focus sul che cosa mi serve capire.

A seconda del contesto (offline, rete locale, internet) lo stesso approccio si declina in profili di deployment diversi, pensati per bilanciare praticità e sicurezza: A / B-core / B-enterprise / C.

In tutti i profili, comunque, il flusso logico è lo stesso: porto i dati in un workspace, poi interrogo. Cambia solo dove girano server e dati, e quanto è governato l’accesso.

Tutti i dettagli operativi li trovate nel repository, adesso concentriamoci su casi d’uso reali.

Tre scenari, tre livelli di fiducia: file, LAN, internet.

Caso d’uso #1 - Assessment remoto offline + report

Profilo: A (open core)

Scenario: Un consulente deve analizzare un ambiente AD remoto, a volte può avere accesso diretto in VPN o sessione condivisa, in altri casi la raccolta è demandata al cliente.

Approccio: Invece di generare un report statico, raccoglie i dati in modo standard con un collector PowerShell, o chiede al cliente di farlo. L’output è un JSON con dati e metadati di sessione.

Analisi: Sul proprio PC configura Legacy MCP in locale, “monta” il JSON nel workspace e interroga l’ambiente tramite Claude Desktop.

Risultato. Ottiene un’analisi strutturata sulle aree di proprio interesse e, quando serve, un output documentale (nel progetto sono già stati prodotti alcuni report DOCX su ambienti reali).

Un esempio reale, questa è la risposta che LegacyMCP permette di ottenere in pochi secondi a una domanda concreta sull’ambiente:

Questo è il profilo più semplice: massimizza portabilità e ripetibilità, e minimizza la dipendenza dall’ambiente del cliente. Permette anche analisi incrociate tra ambienti correlati.

Caso d’uso #2 - Dialogo interattivo live + confronto storico (snapshot)

Profilo: B-core o B-enterprise (in base al livello di sicurezza richiesto).

Scenario: Team IT o consulenti vogliono interrogare l’ambiente “dal vivo”, con la comodità del dialogo in chat, senza esportare continuamente file.

Approccio: Legacy MCP viene eseguito in rete locale su un server dell’ambiente Active Directory (member server). Le comunicazioni sono cifrate e il modello di autenticazione è coerente con il profilo scelto.

Interazione: I client (Claude Desktop) si collegano al server MCP tramite modulo bridge (mcp-remote) in LAN. Nel progetto questo pattern è già stato testato end‑to‑end su Profilo B-core con HTTPS e autenticazione basata su token/chiavi protette.

Valore extra: Quando serve “memoria”, si generano snapshot nel tempo. Questo permette di montare snapshot e live insieme chiedendo la domanda più semplice (e più potente): cosa è cambiato?

Il profilo B, lavorando su dato live, ha requisiti di sicurezza più stringenti (account dedicato, cifratura end-to-end e accesso governato). I dettagli sono nel repository.

Nota importante: Legacy MCP espone funzioni di sola lettura (read-only).

Caso d’uso #3 - Portale di analisi esposto su Internet

Profilo: C (solo enterprise)

Scenario: si vuole rendere l’assessment scalabile e fruibile come servizio: più team, più clienti, accesso da ovunque, ma senza necessità di accessi live all’infrastruttura.

Approccio: Si lavora solo su dati offline. È possibile effettuare upload dei JSON, gestione dei workspace via web. L’analisi avviene tramite agenti che consumano MCP su endpoint pubblici.

Sicurezza: Questo profilo richiede un layer di protezione su rete pubblica: API gateway (es. APIM) + WAF. L’autenticazione è demandata ad un Identity Provider (tipicamente Entra ID) con MFA all’accesso ed RBAC sui dati caricati.

Perché ha senso: È il passo che trasforma un tool in una piattaforma, con lo stesso modello logico (profili, workspace, snapshot/offline), ma con governance e accesso enterprise.

Al momento questo è solamente un caso d’uso teorico, ma con specifiche già ben definite. Va bene il Vibe Coding, ma da solo in un mese di lavoro non sarei riuscito ad arrivare a tanto.

Roma non è stata fatta in un giorno

Pensare al concetto di Vibe Coding mi fa andare in modalità Legacy Things e nelle orecchie mi inizia a suonare un famoso pezzo uscito nel 2000: Rome Wasn’t Built in a Day dei Morcheeba.

È la colonna sonora perfetta per descrivere il percorso che ho affrontato durante il mese della scommessa.

Ovunque leggo articoli e proclami che suonano più o meno così:

come ho creato qualcosa da zero in 35 minuti grazie all’AI e il Vibe Coding.

Dal mio punto di osservazione, quella è una mezza verità, fatta per catturare l’attenzione. Forse ci mettiamo anche la mia scelta di non usare un motore di coding estremo (Claude Sonnet 4.6), ma vi voglio raccontare come ho realmente vissuto l’esperienza.

Punto primo

È sicuramente vero che una volta fornite le istruzioni il motore di coding ci mette pochi minuti a creare il risultato, ma la vera questione è: quanto tempo ho impiegato tra ideare, ragionare in autonomia e conversare con una chat di AI prima di arrivare alle istruzioni?

Se prendiamo come esempio l’idea iniziale ve l’ho già svelato: due giorni.

E ne sono serviti altri 28 per arrivare ad un risultato che mi facesse dire “ok lo possiamo pubblicare”.

Chiaro, dipende molto da “che cosa” voglio realizzare, lo sforzo è proporzionale all’ambizione del progetto.

Punto secondo

Oltre al tempo, serve avere una direzione chiara e polso fermo, altrimenti l’AI ti porta a spasso dove vuole lei.

Per fare un esempio, durante una lunga e faticosa sessione di debug sull’autenticazione live verso i Domain Controller, l’AI ha provato di farmi semplificare l’approccio scalando dal protocollo Kerberos ad NTLM.
A quel punto sono rimasto fermo rimarcando i miei principi di sicurezza e alla fine siamo arrivati a farlo funzionare come volevo.

Adesso nella memoria di progetto leggo: NTLM must never be used — deprecated; Kerberos only for Live Mode

Punto terzo

Non sempre l’AI da sola ti trova la soluzione migliore, a volte perde di vista il dettaglio chiave.

Portando un altro esempio, durante la configurazione dell’accesso sicuro lato client MCP, mi sono scontrato su come gestire al meglio la chiave API senza esporla. La soluzione trovata è stata quella di passare da un PowerShell e usare le DPAPI.

Tutto bello fino a che l’avvio del PowerShell da Claude Chat moriva miseramente con uno strano errore. Dopo un’altra intensa sessione di troubleshooting è stata mia l’intuizione di avviare il codice PowerShell dentro un caro vecchio file BAT, risolvendo immediatamente.

La sessione rimane nella memoria di progetto come “BAT is King” in perfetto stile Legacy Things, dove una tecnologia “antica” risolve un problema di AI.

Timeline

Di seguito vi lascio una timeline di cosa sono riuscito ad ottenere ed in che tempi, se la guardo sono veramente impressionato, ma non è una roba da 35 minuti:

Roma non è stata fatta in un giorno e nemmeno questo progetto. L’AI accelera tutto, ma senza una guida non farebbe altro che schiantarsi.

Ti permette di raggiungere vette altissime, ma una volta in cima ci dobbiamo chiedere: chi ha veramente scalato la montagna?

Chi ha veramente scalato la montagna?

Quando l’idea ha preso forma e mi sono deciso a dedicare tempo sul serio al progetto, mi sono sentito un po’ come se avessi avuto una montagna da scalare. Questo all’inizio un po’ mi ha spaventato, ma non avevo nulla da perdere e sapevo di poter contare su strumenti veramente all’avanguardia in ambito AI.

Sono partito con una base standard sull’uso di AI chat, ma non sapevo nulla di coding con AI, un vero “newbie”.
Strada facendo mi sono però messo in gioco, mi sono documentato ed ho capito che per fare un buon lavoro, serve una buona dote di soft skill: idee chiare, forti capacità comunicative, tenacia e tanto metodo.
Volutamente mi sono spinto a scrivere codice in un linguaggio che non conosco (python) perché quello che mi interessava non era il codice, ma il risultato ottenuto.

Dopo le prime settimane mi sono reso conto che il limite tecnico principale era quello del “credito”, le sessioni di lavoro andavano distribuite ed ottimizzate, nel corso della giornata e della settimana. Senza una gestione oculata si rimaneva presto “senza benzina” sul più bello.

Per tenere bassi i consumi nel credito di Claude il punto chiave è stato quello di ridurre il contesto: usare la stessa chat per giorni saturava la finestra di contesto e consumava tantissimi token.

Col tempo ho quindi messo insieme un flusso di lavoro strutturato in tre livelli che vi voglio raccontare.

Strumenti utilizzati: Claude.ai (piano pro, per un mese) a cui ho aggiunto Perplexity.ai, un piano pro che con una promozione avevo in uso per un anno.

Ho poi creato un progetto dentro Claude ed uno spazio dentro Perplexity. In entrambe ho allegato un file status.md con il riepilogo totale. Il file viene allegato anche nella root di progetto ad uso di Claude Code.

Per il codice ho usato VS Code con l’estensione di Claude Code.

Il flusso in ingresso è stato di questo tipo:

1. Prima bozza di ragionamento su Perplexity con motore Sonnet 4.6 per coerenza con i passaggi successivi

2. La bozza di istruzioni di Perplexity viene passata a Claude Chat per una valutazione e successivo affinamento. Claude Chat apre una nuova sessione dallo status.md e genera le istruzioni per Claude Code.

3. Claude Code esegue e genera un riepilogo

4. Claude Chat valuta il riepilogo e quando arrivati ad un risultato stabile chiude la sessione aggiornando il file status.md

5. Il file aggiornato status.md viene allegato ovunque come nuovo riferimento univoco.

Questo il flusso in uscita:

1. Il riepilogo di Claude Chat viene passato a Perplexity come feedback

2. Vengono avviate le sessioni di test e debug

3. Quando necessaria qualche variazione si torna al flusso di ingresso verso Claude Chat

Come sono arrivato a questo metodo? Leggendo in giro e dialogando con l’AI. Serve molta autocritica e pensiero laterale, chiedendosi ogni tanto: posso migliorare qualcosa?

Ma torniamo alla domanda iniziale: chi ha veramente scalato la montagna?

Per rispondere uso una metafora: mi sento come se avessi scalato una montagna molto alta, arrivando dove non avrei pensato, ma ero dotato di un sofisticato esoscheletro (l’AI) che ha amplificato enormemente le mie capacità.
Ma l’esoscheletro da solo non va da nessuna parte. E più diventi bravo a sfruttarne le potenzialità, più procedi spedito.

Cosa ho osservato ed imparato

Lunedì 13 aprile, il repository è ufficialmente pubblico, la scommessa è conclusa ed è ora di tracciare un bilancio.

Sono riuscito nel mio obiettivo? Decisamente sì!

Ce l’avrei fatta senza l’aiuto dell’AI? Decisamente no!

Il primo aspetto chiave da evidenziare è la relazione di collaborazione che si instaura tra te e l’AI.

C’è di mezzo un processo di continuo apprendimento reciproco. Più tu impari ad utilizzare lo strumento nel contesto del progetto, più lui impara a conoscerti, con in mezzo una parola chiave: comunicazione.

L’AI applicata alla programmazione ha ribaltato un paradigma: non sei più tu a dover imparare un linguaggio, è lo strumento che ha imparato il tuo.

Questo sposta il focus dal come ottenere un risultato al cosa voglio realmente ottenere.

Perché questo meccanismo funzioni serve però che chi avvia la comunicazione (tu) sia capace di farlo nella maniera migliore.

Ho capito infatti che l’AI è un potente amplificatore: se escono idee confuse il risultato sarà estremamente confuso, se sono precise il risultato sarà estremamente preciso.

Il secondo aspetto fondamentale su cui ragionare è la conoscenza della materia: senza sapere esattamente come funzionano le cose si rischiano risultati divergenti dall’obiettivo senza rendersene conto, vedi il caso NTLM citato in precedenza.

Questo significa che con l’AI non ci si può adagiare “tanto ci pensa lei”, anzi bisogna concentrarsi nell’imparare il più possibile come funzionano le cose. Questo valorizzerà il ruolo di architetto che sarà sempre più importante.

Il terzo aspetto su cui ragionare è che i sistemi di AI sono alla fine degli strumenti, e come tali vanno impiegati al meglio.

Per questo motivo bisogna approcciarli con metodo, provando, sbagliando e mettendosi in discussione per migliorarlo. Ma attenzione, non esiste un solo metodo giusto, ognuno troverà quello migliore per sé stesso e per lo specifico contesto nel quale si trova ad operare.

Il mio metodo ha funzionato perché non era già scritto in partenza, ma l’ho costruito passo-passo chiedendomi: cosa posso fare meglio?

Chiudo i ragionamenti con un motto che mi porto dietro da 25 anni e che oggi trovo più attuale che mai:

i sistemi informatici non fanno quello che vuoi, ma quello che gli dici di fare.

Spero che questo racconto ti abbia appassionato almeno quanto ha appassionato me realizzarlo. La storia però non finisce qui. Quando leggerai questo articolo il codice si sarà già evoluto, e non posso andare avanti da solo.

Là fuori c’è un repository che aspetta di essere provato. Mettilo alla prova e fammi sapere come ti sei trovato.

Friday, 13 March 2026, a date that might look ordinary. Some cultures consider it unlucky, but for me it has a very specific meaning: I had an idea, and I wanted to make it real.

In fact, the seeds of that idea came from a path that started earlier.

The first seed goes back to 6 May 2025: European Identity Conference in Berlin, second session of the day. Among the top trends expected for 2025 there was the rise of MCP Servers.

I looked at my colleague, and we asked the same question: what on earth is an MCP Server? We need to dig into this!

Months passed and exactly as predicted, MCP Servers started popping up everywhere.

The second seed goes back to 25 February 2026: for a while I had felt the need to write about “legacy stuff”, I spoke with a colleague and finally found the right home for my project. I immediately decided to open this Substack blog and, within a week, I published my first article. It was 1 March 2026.

Being on this platform also gave me the chance to read many interesting posts from other authors. Most of the time these topics are technically far from my day job, yet they resonate deeply with the way I look at things.

But let’s go back to 13 March 2026. I read a post about the evolution of Claude.ai. It talked about how powerful the new models are, and about an experiment in extreme Vibe Coding.

That was the final seed…

The idea started germinating in my head. That evening I began my first conversation with the Claude app. A short back and forth, and suddenly it had a shape:

What if I tried to write an MCP interface for Active Directory?

I slept on it (more or less) and woke up with a fairly clear picture in my mind.

After breakfast I started bombarding the AI with a complete memory dump, and it kept the pace. We reached an initial draft, but the sun was shining and the tall grass was calling. Time to step away.

Cut the grass, reflect, unload, cut again, reflect again, unload again, and so on…

Second round in the afternoon. Another massive dump and the design became crystal clear, so I decided it was time to place a bet:

Can an old sysadmin, with a programming background that stopped at Visual Basic 6, but a solid understanding of systems, build an open source MCP Server project from scratch?

Right then, I spent 20 euros to access Claude Code and the Legacy MCP project was officially born.

Sunday, 15 March 2026, I woke up and dedicated time to my passion for Formula 1, and I was right to do it.

A young Italian talent, just 19 years old, started from pole position, dominated the race and secured his first victory, confirming a bet Mercedes had made on him when he was only 11. His name is Andrea Kimi Antonelli.

I was euphoric and convinced it would be a great day. After lunch I “fired up” the machines and started working, and a couple of hours later I had my first working prototype.

When I realised I could query the data exactly the way I had imagined, my jaw dropped. I was literally staring at the screen thinking: yes, this is a bet worth bringing to the finish line!

This article is not meant to explain a technology. It is meant to tell a journey.

It is the story of what happens when a legacy idea meets new tools, and someone decides to really try, connecting two worlds.

Iscriviti ora

Why it was worth doing

If you have read my previous articles (Chapter 1 and Chapter 2) you already know my point of view. For new readers, here is the short version: despite the push towards the cloud, legacy technologies keep surviving. Over time, however, they are becoming increasingly mysterious, and we need a way to pass that knowledge on.

Every project started by my team begins in the same way: we need to run an assessment and produce a document.

And in most cases, the heart of that assessment is always the same: Active Directory.

For years we relied on trusty PowerShell scripts, more or less standardised, but anchored to one constant: the excellent ADDS_Inventory_V3.ps1 by the legendary Carl Webster.

The problem is that maintaining and evolving those scripts is becoming increasingly expensive, while the outside world is surfing fast on the AI wave.

I did not want to throw that heritage away. I wanted to make it queryable, modular and reusable.

So, I asked myself a simple question: why not try to connect these two worlds?

The turning point was the MCP protocol. It is often described as “the USB port for AI”, an open standard that lets AI systems connect to external modules of any kind.

If you want to dive deeper, here is the official documentation: What is the Model Context Protocol (MCP)?

That is how the idea was born: build an MCP Server acting as a bridge between the Active Directory world and AI systems: Legacy MCP.

In practice, a standard way to query AD using AI tools, shifting the focus from how to do things to what you want to achieve.

As mentioned earlier, during the first two days I had intense sessions with Claude Chat. I defined principles and guidelines that allowed me to see tangible results in less than 48 hours.

One of those principles was a clear boundary between open core and enterprise. Even if it starts with “just” 20 euros, doing things properly takes time, so boundaries are necessary.

The choice was natural and coherent:

if the project takes inspiration from Carl Webster’s work, then the open core must cover everything ADDS_Inventory_V3.ps1 covered for years.

It is a way to give something back to the community, updated to modern technologies.

On top of that, an enterprise layer will be built, requiring different investments and efforts, covering more advanced and sophisticated capabilities.

· open core = inventory and core queries

· enterprise = advanced analysis, reports and integrations

What it can do for you

Legacy MCP was born with a simple goal: make Active Directory queryable, enabling cross correlations across data and shifting the focus towards what I really need to understand.

Depending on the context (offline, local network, internet) the same approach is implemented through different deployment profiles, designed to balance usability and security: A / B core / B enterprise / C.

Across all profiles, the logic stays the same: you bring data into a workspace, then you query. What changes is where servers and data live, and how access is governed.

All operational details are available in the repository, but here we focus on real world use cases.

Three scenarios, three trust levels: file, LAN, internet.

Use case 1 - Remote offline assessment and report

Profile: A (open core)

Scenario: A consultant needs to analyse a remote AD environment. Sometimes they have direct access via VPN or a shared session, in other cases data collection is delegated to the customer.

Approach: Instead of generating a static report, the consultant collects data in a standard way using a PowerShell collector or asks the customer to run it. The output is a JSON file with data and session metadata.

Analysis: On their own PC, the consultant runs Legacy MCP locally, “mounts” the JSON into the workspace, and queries the environment through Claude Desktop.

Result: A structured analysis focused on the areas that matter, and, when needed, a document style output. In this project, a few DOCX reports have already been produced and validated on real environments.

A real example follows. This is the kind of answer Legacy MCP can deliver in seconds to a concrete question about the environment:

This is the simplest profile: it maximises portability and repeatability and minimises dependence on the customer environment. It also enables cross analysis across related environments.

Use case 2 - Interactive live dialogue and historical comparison with snapshots

Profile: B core or B enterprise (depending on the required security level).

Scenario: IT teams or consultants want to query the environment “live”, with the convenience of a chat driven interaction, without constantly exporting files.

Approach: Legacy MCP runs on the local network on a server inside the Active Directory environment (a member server). Communications are encrypted and the authentication model matches the chosen profile.

Interaction: Clients (Claude Desktop) connect to the MCP server through a bridge module (mcp-remote) on the LAN. In this project, this pattern has been tested end to end on Profile B core with HTTPS and authentication based on protected tokens and keys.

Extra value: When “memory” matters, you create snapshots over time. This lets you mount snapshots and the live view together and ask the simplest and most powerful question: what changed?

Because it operates on live data, Profile B has stricter security requirements (dedicated service account, end to end encryption, governed access). Details are in the repository.

Important note: Legacy MCP exposes read only functions.

Use case 3 - Internet exposed analysis portal

Profile: C (enterprise only)

Scenario: You want to make the assessment scalable and usable as a service: multiple teams, multiple customers, access from anywhere, without requiring live access to the infrastructure.

Approach: Everything stays offline. You upload JSON datasets and manage workspaces via web. Analysis happens through agents that consume MCP over public endpoints.

Security: This profile requires an internet grade protection layer: API gateway (for example APIM) plus WAF. Authentication is delegated to an Identity Provider (typically Entra ID) with MFA, plus RBAC on uploaded data.

Why it makes sense: It is the step that turns a tool into a platform, keeping the same logical model (profiles, workspaces, snapshots/offline), but adding governance and enterprise access.

For now, this is a theoretical use case, but the specifications are already clear. Vibe Coding is great, but there is no way I could have built all of that alone in one month.

Rome wasn’t built in a day

Thinking about Vibe Coding immediately switches me into Legacy Things mode, and in my head, I can hear a well-known song released in 2000: Rome Wasn’t Built in a Day by Morcheeba.

It is the perfect soundtrack for the month-long journey behind this bet.

Everywhere I read articles and proclamations that sound more or less like this:

how I created something from scratch in 35 minutes thanks to AI and Vibe Coding.

From my point of view, that is a half-truth designed to capture attention. Maybe my choice not to use an extreme coding model (Claude Sonnet 4.6) also plays a role, but I want to tell you how I really lived the experience.

First point

It is true that once you provide instructions, a coding engine can produce output in minutes. The real question is this: how much time did I spend thinking, reasoning on my own, and talking with an AI chat before I even reached those instructions?

Using the initial idea as an example, I already told you: two days.

Then it took another 28 days to reach a point where I could say: “ok, we can publish this”.

Of course it depends on “what” you want to build. Effort is proportional to ambition.

Second point

Beyond time, you need a clear direction and a steady hand, otherwise the AI will take you for a walk wherever it wants.

For example, during a long and painful debugging session on live authentication towards Domain Controllers, the AI tried to persuade me to simplify the approach by switching from Kerberos to NTLM.

That is where I stood still and reinforced my security principles, and in the end, we made it work the way I wanted.

In the project memory, I now read: NTLM must never be used. Deprecated. Kerberos only for Live Mode.

Third point

AI does not always find the best solution on its own. Sometimes it loses the key detail.

Another example: while configuring secure client-side access to the MCP server, I struggled with how to handle the API key without exposing it. The solution was to use PowerShell and DPAPI.

Everything looked great until launching PowerShell from Claude Chat crashed with a strange error. After another intense troubleshooting session, the key intuition was mine: run the PowerShell through a simple BAT file, and the problem disappeared immediately.

That session lives in the project memory as “BAT is King”, in perfect Legacy Things style, where an “old” technology fixes an AI problem.

Timeline

Below is a timeline of what I managed to achieve and in what time. Looking at it, I am genuinely impressed, but this is not a 35-minute story:

Rome wasn’t built in a day, and neither was this project. AI accelerates everything, but without a guide it would simply crash.

It can help you reach very high peaks, but once you get there, there is one question we must ask: who really climbed the mountain?

Who really climbed the mountain?

When the idea took shape and I decided to dedicate serious time to the project, I felt as if I had a mountain to climb. At first that scared me a bit, but I had nothing to lose, and I knew I could rely on truly cutting-edge AI tools.

I started with a standard baseline on chat-based AI and I knew nothing about AI assisted coding. I was a real “newbie”.

Over time I challenged myself, studied, and understood that to do a good job you need solid soft skills: clear ideas, strong communication skills, tenacity, and a lot of method.

I deliberately chose to write code in a language I do not really know (Python) because what mattered to me was not the code itself, but the result.

After the first few weeks I realised that the main technical limit was the “credit”. Work sessions had to be distributed and optimised across the day and the week. Without careful management, you run “out of fuel” at the worst possible time.

To keep credit consumption low, the key was to reduce context: using the same chat for days saturates the context window and consumes a huge amount of tokens.

Over time I built a structured workflow in three levels that I want to describe.

Tools used: Claude.ai (Pro plan for one month) plus Perplexity.ai, a Pro plan I already had through a yearly promotion.

I then created a project inside Claude and a space inside Perplexity. In both, I attached a status.md file with the overall summary. The same file is also placed in the project root for Claude Code.

For coding, I used VS Code with the Claude Code extension.

Input flow:

1. First draft reasoning on Perplexity using Sonnet 4.6 for consistency with later steps.

2. Perplexity’s instruction draft is then passed to Claude Chat for review and refinement. Claude Chat starts a new session from status.md and generates the instructions for Claude Code.

3. Claude Code executes and produces a summary.

4. Claude Chat reviews the summary and, once the result is stable, closes the session and updates status.md.

5. The updated status.md is then attached everywhere as the new single source of truth.

Output flow:

1. Claude Chat’s summary is passed back to Perplexity as feedback.

2. Testing and debugging sessions start.

3. When variations are needed, the flow goes back into Claude Chat.

How did I get to this method? By reading, experimenting and talking with the AI. It takes self-criticism and lateral thinking, asking yourself from time to time: can I improve something?

But back to the original question: who really climbed the mountain?

My answer is a metaphor: I feel as if I climbed a very high mountain and reached a place I would not have expected, but I had a sophisticated exoskeleton (AI) that massively amplified my capabilities.

An exoskeleton, however, does not go anywhere on its own. The better you become at exploiting its potential, the faster you move.

What I observed and learned

On Monday, 13 April, the repository officially became public. The bet is over, and it is time to take stock.

Did I achieve my goal? Definitely yes!
Could I have done it without AI? Definitely no!

The first key aspect is the collaborative relationship that emerges between you and AI.

There is a continuous process of mutual learning. The more you learn to use the tool in the context of the project, the more it learns to understand you, with one key word in the middle: communication.

AI applied to programming flipped a paradigm: you no longer must learn a language, the tool learns yours.

This shifts the focus from how to get a result to what you really want to get.

For this mechanism to work, the person starting the conversation (you) must be able to do it in the best possible way.

I realised that AI is a powerful amplifier: if your ideas are confused, the result will be extremely confused, if they are precise, the result will be extremely precise.

The second fundamental aspect is domain knowledge: without knowing exactly how things work, you risk drifting away from the goal without noticing, as in the NTLM case mentioned earlier.

This means that with AI you cannot just relax thinking “it will handle everything”. On the contrary, you should focus on learning as much as possible about how things work. This will increase the value of the architect role, which will only become more important.

The third aspect is that AI systems are tools, and like any tool they must be used well.

That is why you need method: try, fail, question yourself and improve. Be careful though, there is no single correct method. Everyone will find what works best for themselves and for their context.

My method worked because it was not written upfront. I built it step by step, constantly asking myself: what can I do better?

I will close with a motto I have carried for 25 years, and today it feels more relevant than ever:

IT systems do not do what you want. They do what you tell them to do.

I hope this story was at least as engaging for you as it was for me to live it. But the journey does not end here. By the time you read this article, the code will already have evolved, and I cannot move forward alone.

Out there, there is a repository waiting to be tested. Put it to the test and tell me how it went.

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.