Capitolo #3 - Il Domain Controller che diceva il falso
La fonte autorevole di una verità distorta
English version available here → [EN]
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.
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.