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.