11 febbraio 1956, CBS Studio 50, New York City. Dietro le quinte di Stage Show l’aria è quella delle grandi occasioni. Tra gli ospiti più attesi c’è un giovane Elvis Presley.
Non è la sua prima apparizione allo show, ne ha già fatte altre due con grande successo, ma quella sera è speciale: ha il permesso di cantare qualcosa di nuovo.
Nel viaggio da Charlotte verso New York, lo attende una tempesta di neve che quasi gli fa perdere l’occasione, ma riesce comunque ad arrivare poco prima della messa in onda.
Un rapido passaggio nel camerino e poi via, sul palco. Si accendono i riflettori, le telecamere puntano su di lui, Elvis attacca con quella Blue Suede Shoes che Carl Perkins aveva scritto l’anno prima e la trasforma in un fenomeno mondiale.
Quelle scarpe blu diventano rapidamente un fenomeno di costume, l’oggetto del desiderio di una generazione, riempiendo vetrine, armadi e immaginario collettivo.
Ma come tutte le mode, anche loro passano. Restano oggetti bellissimi, magari ancora perfettamente utilizzabili, ma dimenticati in un angolo perché il mondo intorno ha iniziato a desiderare altro.
Dando uno sguardo al mondo IT, il 1956 è anche l’anno della conferenza di Dartmouth, organizzata da John McCarthy, che consacra la nascita dell’Intelligenza Artificiale come campo di ricerca.
Sempre nello stesso anno IBM presenta il RAMAC 305, il primo computer commerciale dotato di un’unità disco ad accesso casuale: l’IBM 350, progenitore degli hard disk moderni.
Da lì, chi si occupa di IT ha imparato rapidamente a conservare tutto: dati, configurazioni, account, chiavi, impostazioni nate per risolvere un problema preciso e poi lasciate lì, perché in fondo continuavano a funzionare.
E come per le mode che vengono dimenticate, anche nell’IT il ciclo si è accorciato. A una funzionalità cloud, oggi, possono bastare dieci anni per trasformarsi in un’eredità.
Ed è qui che comincia la storia di AZUREADSSOACC$, l’account dimenticato in tante Active Directory.
Seamless Single Sign-On: la novità del 2016
Per capire perché quell’account finisca lì, dimenticato in un angolo del dominio, bisogna tornare al momento in cui nasce l’idea che ci sta dietro.
Siamo nel 2016 e Office 365 sta accelerando. Sempre più aziende iniziano a portare posta, collaborazione e servizi applicativi fuori dal perimetro tradizionale, ma la maggior parte delle identità, dei servizi e soprattutto delle postazioni di lavoro resta ancora saldamente dentro Active Directory. Il cloud cresce in fretta, l’identità rimane ibrida.
In quel contesto l’esperienza utente diventa un tema centrale. L’azienda inizia a portare gli utenti su Office 365, ma non vuole che ogni accesso al browser, a Outlook o ai servizi cloud diventi una nuova richiesta di credenziali. L’utente ha già acceso il PC, ha già inserito le credenziali, è già autenticato nel dominio. Chiedergli di farlo nuovamente è assurdo in un mondo dove il SSO la fa da padrone da anni.
La risposta più completa al problema, però, esiste e in quel momento si chiama Active Directory Federation Services. ADFS permette di mantenere il controllo dell’autenticazione on-premise ma allo stesso tempo di parlare nativamente la stessa lingua del cloud. Funziona, è maturo, è potente. Ma non è leggero.
Per mettere in piedi ADFS serve infrastruttura, servono server, bilanciamento, certificati, pubblicazione sicura verso Internet, monitoraggio, patching, gestione delle scadenze e competenze specifiche. Non è una semplice opzione da aggiungere. È un pezzo di architettura da progettare, proteggere e mantenere.
Se ADFS non viene governato correttamente, il problema classico è il certificato che scade mentre l’IT è in ferie, bloccando tutto all’improvviso.
Ed è proprio in questo contesto che Microsoft decide di cercare una via d’uscita più semplice. L’obiettivo non è mantenere una federation farm completa, ma solo evitare all’utente la richiesta esplicita di credenziali quando si trova su un PC aziendale e dentro la rete aziendale. La domanda a cui rispondere diventa quindi: si può ottenere lo stesso risultato con qualcosa di molto più piccolo?
Nasce così Seamless Single Sign-On, una funzionalità pensata per accompagnare gli scenari di autenticazione cloud basati su Password Hash Synchronization o Pass-through Authentication. Non sostituisce quei metodi, ci si appoggia sopra. Il suo compito è molto preciso: togliere di mezzo il prompt di autenticazione quando ci sono le condizioni giuste.
Con Password Hash Synchronization l’autenticazione viene gestita nel cloud usando informazioni derivate dagli hash delle password sincronizzate da Active Directory. Con Pass-through Authentication la verifica passa invece attraverso agent locali che interpellano il dominio. Percorsi diversi, stesso effetto percepito dall’utente: prima o poi arriva una richiesta esplicita di credenziali.
Seamless SSO prova a rendere invisibile quel passaggio. Non cambia il metodo di autenticazione principale, non trasforma PHS o PTA in ADFS, e soprattutto non si inventa un nuovo protocollo. Usa invece una cosa che in tutti questi ambienti esiste già da anni: la sessione Kerberos dell’utente su un dispositivo domain-joined.
E qui il contesto del 2016 è fondamentale per comprendere quelle scelte architetturali.
Gli ambienti enterprise sono ancora pieni di Windows 7, Internet Explorer, domini Active Directory classici, Group Policy, reti aziendali perimetrali e postazioni che vivono quasi sempre dentro l’ufficio. L’idea di un PC aziendale, collegato alla LAN, già autenticato al dominio, è ancora lo standard di fatto dell’esperienza utente.
Dal punto di vista operativo, il grosso vantaggio della soluzione è questo: non servono altri server on-premise, non serve più una farm ADFS, non serve pubblicare nulla verso Internet. Si abilita la funzionalità da Microsoft Azure AD Connect (Entra arriverà dopo…) e il sistema crea in Active Directory un account computer speciale, chiamato AZUREADSSOACC$.
Ok, tutto qui? Chiaramente no.
Quell’account dà il via a tutto il meccanismo, diventando il punto di contatto tra due mondi, ma vediamo cosa c’è “sotto il cofano”.
Non potendo portare i protocolli moderni dal cloud su Active Directory, è necessario fare il contrario e il fulcro della questione è una nostra vecchia conoscenza: il protocollo Kerberos.
Per AZUREADSSOACC$ vengono registrati gli SPN necessari al processo di sign in verso gli endpoint di Microsoft Entra ID e la chiave Kerberos dell’account viene condivisa in modo sicuro con il cloud. Da quel momento Entra ID è in grado di capire e validare un ticket Kerberos emesso dall’Active Directory locale per quello specifico servizio.
Il flusso, semplificando, è questo:
- l’utente accede al proprio PC joined al dominio e riceve i normali ticket Kerberos.
- quando apre un servizio Microsoft 365 compatibile, il browser prova a raggiungere l’endpoint di autenticazione dedicato a Seamless SSO.
- se quell’endpoint è trattato come “zona intranet” (quindi con Windows Integrated Authentication abilitata) e il dispositivo riesce a parlare con un Domain Controller, il browser ottiene un service ticket Kerberos per il servizio rappresentato da AZUREADSSOACC$ e lo presenta a Microsoft Entra ID.
A quel punto il cloud usa la chiave condivisa per decifrare il ticket, associa l’identità ricevuta all’utente sincronizzato e completa l’accesso senza chiedere nuovamente la password.
Per l’utente è tutto facile e trasparente. Per l’amministratore è poco più di una configurazione. Per Active Directory, invece, è semplicemente Kerberos che continua a fare il proprio mestiere.
La scarpa dimenticata nell’armadio IT
Il mondo IT è da sempre pervaso dalla filosofia del “quel che funziona non si tocca”, secondo la quale è un peccato mortale mettere in discussione un qualsiasi processo che stia funzionando in silenzio e senza lamentele.
Seamless SSO ha incarnato perfettamente questa filosofia.
Era una soluzione perfetta per il contesto in cui era stata progettata: Active Directory, Kerberos, PC domain-joined e una rete aziendale considerata il centro naturale dell’esperienza utente.
Il problema è che quel mondo non è più lo stesso.
Negli anni il baricentro dell’identità si è spostato verso un modello differente, nel quale i sistemi hanno iniziato a parlare direttamente con il cloud, i browser di nuova generazione hanno preso piede, fino a rendere l’autenticazione moderna il nuovo standard.
Tutto questo è stato supportato dal consolidamento di protocolli come OAuth 2.0 e OpenID Connect, affiancato da uno spostamento progressivo del mondo applicativo e dei controlli verso il cloud.
Nel mondo Azure AD, poi diventato Entra ID, due elementi hanno cambiato radicalmente il panorama: Conditional Access per il governo e la sicurezza degli accessi, e Windows Hello for Business per l’esperienza utente.
Non tutto questo è arrivato ovunque nello stesso momento, e non tutti gli ambienti si sono mossi alla stessa velocità. Però una cosa è evidente: la comodità che nel 2016 sembrava perfettamente allineata al modo in cui lavoravano le aziende, oggi in molti contesti ha perso la propria utilità.
Ma la sua presenza rimane una costante e ne abbiamo avuto una chiara evidenza durante le recenti attività di bonifica dell’uso di RC4 in Kerberos: ogni report generato includeva sempre un riferimento ad AZUREADSSOACC$.
Seamless SSO è stato lentamente dimenticato come una vecchia “scarpa blu” dentro l’armadio dell’IT. Ma la sua presenza oggi ha cambiato radicalmente significato.
In ambienti ormai dominati da Windows 11, con qualche Windows 10 ancora presente, l’esperienza di accesso integrato è sempre più legata a configurazioni Hybrid Join o Entra Join, riducendo drasticamente gli scenari in cui Seamless SSO mantiene ancora una reale utilità.
La funzionalità ci ha però lasciato due scomode eredità Kerberos: la cifratura RC4 e la gestione della chiave.
La prima eredità è legata al modo in cui l’account viene creato. AZUREADSSOACC$ nasce storicamente con RC4 abilitato, e questo lo rende un caso particolare rispetto alla normale lettura degli ambienti descritta nel capitolo 4. Non siamo davanti a un normale account da bonificare. Siamo davanti a una funzionalità nata così, con una scelta di compatibilità incorporata nel proprio disegno iniziale.
La seconda eredità è ancora più subdola, perché non riguarda solo una configurazione tecnica, ma il modo in cui quella configurazione dovrebbe essere governata nel tempo.
Microsoft raccomanda di ruotare la chiave Kerberos di AZUREADSSOACC$ almeno una volta ogni 30 giorni. Sulla carta è una raccomandazione sensata: quella chiave è il segreto che permette a Microsoft Entra ID di validare i ticket Kerberos emessi dall’Active Directory locale per Seamless SSO. Per prevenire compromissioni serve avere un ciclo di vita controllato.
Il problema è che qui il disegno operativo si è sempre portato dietro una contraddizione: la rotazione è raccomandata, ma non è mai diventata una funzione automatica del prodotto.
Per ruotare la chiave serve eseguire una procedura PowerShell sul server di Entra Connect, autenticandosi verso il cloud con un ruolo amministrativo elevato e verso Active Directory con privilegi sufficienti a modificare l’account computer.
In parole povere stiamo parlando di un comando interattivo da eseguire con diritti elevati nel cloud e una connessione attiva on-premise.
Inizialmente si poteva prendere quello script, perfezionarlo e trasformarlo in un task schedulato. Col tempo, però, automatizzare davvero un’operazione che richiede credenziali privilegiate in due mondi diversi è diventato quasi un paradosso.
Da una parte Entra ID richiede sempre più spesso MFA, Conditional Access e controlli stringenti sui ruoli privilegiati; dall’altra il task pianificato vorrebbe solo partire alle tre di notte e fare il suo lavoro senza che nessuno debba intervenire.
Ed è qui che la raccomandazione dei 30 giorni incontra la realtà, con l’effetto pratico di venire bellamente ignorata.
Così quell’account resta lì, con una chiave Kerberos che in teoria dovrebbe ruotare ogni mese e che in pratica, in troppi ambienti, non gira da anni.
Risultato: in ogni ambiente in cui Seamless SSO è ancora attivo, un potenziale attaccante sa già quale account cercare. E troppo spesso trova una chiave Kerberos ferma da anni, associata a una configurazione crittografica nata intorno a RC4.
Un invito troppo goloso per essere ignorato.
Ecco come una funzionalità utilissima si è trasformata silenziosamente in una superficie di rischio. Se quella chiave venisse compromessa, il problema non resterebbe confinato al perimetro on-premise, ma potrebbe aprire la strada a un attacco di tipo silver ticket: un ticket Kerberos costruito ad arte per presentarsi al servizio come se fosse legittimo, consentendo di impersonare utenti verso Microsoft Entra ID attraverso Seamless SSO.
AZUREADSSOACC$ non va quindi trattato come un oggetto qualsiasi, ma come un asset critico. Un oggetto da valutare attentamente nel proprio Tier Model, perché la sua compromissione può avere effetti molto più ampi di quanto lasci intendere il suo aspetto innocuo.
Ed eccoci al punto: Seamless SSO non è diventato un problema perché era sbagliato. Nel 2016 era una risposta pragmatica a un’esigenza reale, esattamente come tante tecnologie che abbiamo visto in questa serie. Il problema nasce quando quella risposta resta lì dopo che la domanda è cambiata.
Una funzionalità nata per semplificare l’accesso in un mondo fatto di PC domain-joined, reti aziendali e browser da addomesticare, oggi rischia pertanto di restare attiva in ambienti che non ne hanno più davvero bisogno. Non perché qualcuno l’abbia lasciata consapevolmente, ma perché nessuno si è ricordato di toglierla da un mondo che non le appartiene più.
La domanda giusta da farsi non è quindi “come lo gestisco?”, ma “ne ho ancora bisogno?”.
Cosa ci ha insegnato la scarpa dimenticata
La prima lezione che questa scarpa dimenticata ci lascia è che nei sistemi informatici è quasi sempre più facile aggiungere una funzionalità che rimuoverla. Seamless SSO nasceva come una semplice opzione dentro Azure AD Connect: pochi passaggi, nessuna nuova infrastruttura e un beneficio rapidamente visibile agli utenti. Nessuno, in quel momento, aveva motivo di chiedersi come sarebbe uscito di scena.
Purtroppo, questa è un’asimmetria ricorrente nelle architetture enterprise: l’ingresso di una nuova commodity è accompagnato da un progetto, da un’esigenza chiara e da persone che ne conoscono il motivo. La sua uscita, invece, avviene anni dopo, quando il contesto è cambiato, le persone non sono più le stesse e quella funzionalità è ormai diventata parte del rumore di sottofondo.
La seconda lezione è che ogni comodità introdotta in un’architettura comporta anche un debito di gestione. Nel caso di Seamless SSO quel debito ha preso la forma di un account critico, una chiave Kerberos da ruotare, una configurazione crittografica da mantenere e una dipendenza tra Active Directory ed Entra ID. Il beneficio è arrivato subito, il conto molto più tardi, spesso a persone diverse da quelle che avevano compiuto la scelta iniziale.
C’è poi un paradosso ancora più interessante: l’evoluzione della sicurezza non ha semplicemente reso Seamless SSO meno necessario, ma ha reso più difficile governarlo secondo le raccomandazioni originali. MFA, Conditional Access e protezione dei ruoli privilegiati sono progressi indispensabili, ma si sposano male con un task pianificato che dovrebbe utilizzare silenziosamente privilegi elevati nel cloud e nel dominio. Il nuovo modello di sicurezza finisce così per rendere incompatibile l’approccio di manutenzione della vecchia commodity, lasciandola troppo spesso in uno stato che aumenta la superficie d’attacco.
La terza lezione riguarda i criteri con cui decidiamo cosa può restare dentro un’architettura. Una funzionalità non dovrebbe rimanervi soltanto perché nessuno ha ancora trovato il motivo di spegnerla. Dovrebbe rimanervi perché qualcuno ha verificato che esiste ancora uno scopo per tenerla accesa, che il beneficio è reale e che il costo necessario a governarla è proporzionato.
Se Seamless SSO serve ancora davvero, allora va governato come l’asset critico che è: documentato, monitorato, protetto e mantenuto. Se invece il beneficio residuo è diventato marginale, mentre il costo e il rischio continuano a crescere, rimuoverlo non significa arrendersi al cambiamento. Significa fare manutenzione architetturale.
Forse è questa la vera lezione della scarpa che abbiamo trovato dimenticata negli armadi IT: non tutto ciò che abbiamo conservato merita necessariamente di essere restaurato. Alcune cose hanno semplicemente terminato il compito per cui le avevamo scelte, e continuare a lucidarle non le renderà di nuovo necessarie. A volte la scelta più responsabile è aprire l’armadio, riconoscere ciò che non serve più e fare spazio.