English version available here → [EN]
Nota di lettura: il contrasto tra le due “memorie” descritto in questo capitolo è una lettura editoriale dell’autore, non un’affermazione delle fonti tecniche citate. La scena iniziale (Sheffield, James e Franco) è di fantasia: i personaggi non sono persone reali. La Brexit è usata qui come esempio di processo, non come paragone politico.
29 marzo 2017, Sheffield, Regno Unito. Due vicini di casa si salutano la mattina mentre escono per andare al lavoro.
Alla sera James torna a casa tranquillo: la sua giornata è passata in modo normale, quasi noiosa. Decide di andare al pub.
Franco rientra inquieto, ha poca fame ed è pensieroso. Decide di andare al pub.
I due si ritrovano davanti a una pinta. Franco vive e lavora a Sheffield da anni, ma non ha il passaporto britannico. Da stasera nessuno sa dirgli a quali condizioni potrà restare.
«Hai sentito di oggi? Hanno mandato la lettera a Bruxelles. Articolo 50.»
«E quindi?»
«E quindi io che cosa sono, adesso?»
James posa il bicchiere. Vorrebbe dire qualcosa di utile, ma non gli viene niente. Non ha mai dovuto dimostrare a nessuno chi è, né da quanto tempo è lì.
Quella sera è l’inizio di uno dei processi di de-merge più clamorosi del recente periodo. Il Regno Unito notifica formalmente la propria intenzione di lasciare l’Unione europea. L’uscita formale arriverà poi il 31 gennaio 2020, con un periodo di transizione che si chiuderà il 31 dicembre 2020: poco meno di quattro anni per separare due entità che per decenni sono state profondamente intrecciate.
La decisione è la parte semplice. Poi si firma un accordo e da lì si avvia un processo complicato. Bisogna stabilire che cosa si separa, come e con che tempi, e, fra le altre cose, che cosa ne sarà delle persone che dentro quel sistema vivono e lavorano da anni ma che al termine della separazione non ne dovrebbero più fare parte.
Franco è uno di questi. È un cittadino dell’Unione europea e ancora non sa se potrà continuare la sua vita a Sheffield o se dovrà migrare altrove.
La sua identità è sempre la stessa, a cambiare non è chi è ma ciò che gli sarà permesso fare all’interno di quel nuovo perimetro.
Nel mondo dei sistemi succede spesso il contrario: a cambiare è l’account, con il suo nuovo SID, e sono i permessi che vorremmo restassero.
Alla fine, la storia è quella di sempre, ed è nota da decenni nel mondo delle aziende, dove l’IT gioca un ruolo fondamentale nell’attuare la separazione di dati, processi tecnologici e identità.
Dentro le infrastrutture si sono sviluppate nel tempo funzionalità che permettono di supportare sul fronte tecnologico questi processi. In ambito Active Directory uno degli strumenti centrali è il concetto di “sIDHistory”, che permette di portarsi dietro i permessi anche quando l’account cambia.
Nel maggio 2017, poche settimane dopo quella sera, Microsoft rilascia la versione 1.1.524.0 di Azure AD Connect. Sembra un aggiornamento come un altro ma dal changelog, che oggi riporta il nuovo nome del prodotto, si legge:
Microsoft Entra Connect now automatically enables the use of ConsistencyGuid attribute as the Source Anchor attribute for on-premises AD objects. Further, Microsoft Entra Connect populates the ConsistencyGuid attribute with the objectGuid attribute value if it’s empty.
Quella piccola parola “ConsistencyGuid” sarà la chiave per supportare in maniera efficace la nuova ondata di migrazioni ibride, dove il cloud la fa da padrona.
Perché mentre il mondo delle migrazioni on-premises ragiona da anni sul SID, il cloud usa un approccio differente per identificare gli utenti, creando non pochi grattacapi all’IT.
Autorizzazione vs identità: due modi di ricordare
Acquisizioni, cessioni, fusioni, quando arriva una notizia di questo tipo chi lavora nell’IT sa già cosa succederà: c’è da organizzare una migrazione.
Il lavoro da fare è normalmente parecchio, spesso lo paragono ad un trasloco, dove c’è da catalogare cose, buttarne altre, impacchettare il tutto e trovare il mezzo di trasporto più adatto per arrivare a destinazione.
Osservando le cose dalla prospettiva Microsoft, il perimetro d’azione è stato per decenni il dominio di autenticazione (Active Directory) per poi estendersi al cloud con Azure AD (poi Entra ID).
E all’interno di questi perimetri c’è da migrare sicuramente una buona dose di dati, applicativi e servizi, ma la colonna portante di tutto il processo è una sola: le identità.
Identità che possono rappresentare persone vere o processi non presidiati.
Perché alla fine quello che conta maggiormente è permettere a queste identità di fare quello che facevano prima anche nel nuovo perimetro.
Sul piano pratico si può operare in due direzioni: sull’autorizzazione e sull’identità stessa.
La memoria nell’autorizzazione
Per autorizzazione si intende in maniera allargata “quello che ti è permesso di fare”, che sia l’accesso a un file o a un applicativo o il permesso di entrare in un locale fisico.
Focalizzandoci sul perimetro on-premises di Active Directory, il tutto si rifà al Security Identifier dell’utente o del gruppo di cui fa parte, ovvero il SID.
Il SID è già stato trattato nel capitolo 2, non torneremo pertanto sull’argomento.
Ogni risorsa a cui l’identità deve fare accesso include a sua volta i suddetti SID nelle proprie “Access Control List” (ACL), determinando cosa quell’identità può fare su quella risorsa.
È un meccanismo datato, ma solido e funziona da decenni.
Il problema principale nasce quando un utente o un gruppo deve essere “migrato” in un nuovo ambiente Active Directory: di fatto viene ricreato, con un nuovo SID.
Chiaramente, con il solo nuovo SID, l’utente non sarebbe più riconosciuto dalle ACL che fanno riferimento al precedente.
Per ovviare a questo problema con la versione Windows 2000 è stato introdotto un nuovo attributo di tipo multi-valore: il sIDHistory.
sIDHistory può ospitare uno o più SID derivanti da precedenti domini di autenticazione e che fanno capo alla stessa identità.
Per ovvie ragioni di sicurezza non è però un campo liberamente modificabile, il modo previsto per valorizzare sIDHistory è la chiamata DsAddSidHistory (MS-DRSR), richiamata dagli strumenti di migrazione, con requisiti precisi di permessi, audit e trust.
Una volta che il nuovo account avrà in “memoria” il vecchio SID, sarà in grado di accedere a tutte le risorse precedenti.
Una cosa che però non è sempre chiara a tutti è che l’uso del sIDHistory è una soluzione temporanea: finché le risorse restano nel dominio di origine, questa continuità richiede che resti disponibile il rapporto di trust necessario per raggiungerle, per i cui dettagli vi rimando sempre al capitolo 2.
Se la trust viene rimossa, per quelle risorse l’accesso basato sul vecchio SID non è più utilizzabile: senza quel rapporto di fiducia l’utente non può più arrivare alle risorse rimaste nel dominio d’origine, e la “memoria” si perde di conseguenza. Sulle risorse già migrate, invece, sopravvive anche alla trust: ed è proprio per questo che va pulita.
Per poterla pulire senza interrompere gli accessi serve una tecnica complementare: il re-ACLing.
Si tratta di un processo secondo il quale i riferimenti al SID originale presenti nelle ACL vengono sostituiti o affiancati dal SID di destinazione.
È un processo spesso lungo, ma è l’unico che consente di arrivare a terminare con successo una migrazione, dove “con successo” si intende la dismissione del perimetro di autenticazione originale.
E non va dimenticata la fase finale di cleanup, andando a rimuovere tutti i riferimenti sulle identità (sIDHistory) e sulle risorse (ACL) per i vecchi SID.
Sembra la parte più facile ma è quella più critica, dove si scopre se il lavoro precedente è stato fatto bene.
Ok, tutto fila quando c’è di mezzo Active Directory, ma se nell’equazione inserisco anche Entra ID cosa succede?
La memoria nell’identità
Come anticipato, Entra ID non usa il SID per governare gli accessi: si basa su un identificativo proprio. Per capire cosa significhi in pratica partiamo da un concetto arcinoto ma fondamentale: nel cloud Microsoft il perimetro è il tenant.
Ogni oggetto del tenant, che sia un utente o un gruppo, ha un Object ID che lo identifica in modo univoco: è la sua chiave. Nello stesso perimetro vivono poi le risorse, come le mailbox, i siti SharePoint e le applicazioni di terze parti, e l’accesso a ciascuna di esse è governato puntando, in modo diretto o indiretto, a quell’Object ID.
Se prendiamo il caso di una migrazione tenant to tenant, gli strumenti standard di provisioning non prevedono la possibilità di riportare un Object ID in una “history” sul tenant di destinazione: tra i campi impostabili dalle API di creazione utente l’id non compare. Il nuovo oggetto nasce quindi con un nuovo ID, e risorse e accessi vanno replicati su di esso.
Si tratta quindi di una migrazione con cut-over: la copia dei dati può essere graduale, ma il passaggio avviene in un momento preciso. Da quel momento l’utente accede con la nuova identità e si ritrova tutto quello che aveva prima. Il legame col passato rimane solo dentro le singole configurazioni applicative.
È come se il nostro Franco fosse costretto a migrare in un altro paese: fa le valigie, porta con sé quello che riesce a caricare e ricomincia in una casa nuova, con regole e servizi nuovi. Un taglio netto.
Questo però è solo il caso più lineare. Ormai da anni molti ambienti sono ibridi, e lo sono anche le migrazioni, che toccano sia Active Directory sia Entra ID.
Cosa succede quando il tenant resta dov’è e a cambiare è soltanto l’Active Directory?
Per capirlo ripercorriamo il meccanismo che sta alla base dell’ibridazione.
Il motore che si occupa di tenere unite le identità on-premises con quelle cloud è tipicamente Entra Connect (ex Azure AD Connect), attraverso un meccanismo di sync.
Sui due mondi ogni oggetto ha un identificativo proprio: il SID in Active Directory, l’Object ID in Entra. Hanno però una stabilità diversa. L’Object ID accompagna l’oggetto per tutta la sua vita, mentre il SID cambia quando l’oggetto cambia dominio.
Qualsiasi meccanismo di sync ha bisogno di un’“ancora” che metta in relazione i due oggetti, e un valore che cambia non può farlo. Nella prima concezione di Azure AD Connect si è scelto un altro attributo di Active Directory: l’objectGUID.
Si tratta di un altro attributo univoco per l’oggetto AD, ma presente anche su oggetti differenti da utenti e security group, ad esempio lo possiedono anche i contatti, che un SID non ce l’hanno.
L’objectGUID viene preso, convertito in base64 e riportato in un campo cloud denominato “immutableId”.
La fragilità di questo meccanismo compare proprio quando interviene una modifica sul lato Active Directory, mentre a rimanere fermo è il tenant: il nuovo oggetto avrà un nuovo objectGUID, generando di conseguenza un immutableId differente.
Se UPN e indirizzi di posta non trovano corrispondenza, questo causerebbe la creazione in cloud di un nuovo oggetto, con il nuovo immutableId e chiaramente un nuovo Object ID, che di conseguenza non avrebbe accesso alle stesse risorse. Se invece coincidono con quelli dell’oggetto cloud, che nel tenant devono essere unici, la sincronizzazione andrebbe semplicemente in errore.
Ed eccoci arrivati all’introduzione del “mS-DS-ConsistencyGuid”, inizialmente disponibile solo per le nuove installazioni. L’estensione alle installazioni esistenti arriverà poco dopo, con la versione 1.1.553.0 di giugno 2017.
Nonostante quello che è riportato nel changelog di prodotto, il nome completo dell’attributo è mS-DS-ConsistencyGuid. Si tratta di un attributo single-value, presente sin dal primo schema di Windows 2000, il cui scopo originale era “used to check consistency between the directory and another object, database, or application, by comparing GUIDs”.
L’intuizione del 2017 è quella di impiegarlo in maniera simile al sIDHistory per conservare la “memoria” dell’identità. La differenza principale è che non si va in “add”, ma in “replace”.
Impostando per gli utenti l’ancora di Azure AD Connect su mS-DS-ConsistencyGuid, succede quanto segue:
· Alla prima sync utile, se è vuoto, viene preso il valore dell’objectGUID e riportato nel mS-DS-ConsistencyGuid
· Successivamente viene preso il valore del mS-DS-ConsistencyGuid, convertito in base64 e scritto nell’immutableId dell’oggetto cloud
· Da quel momento l’ancora è il mS-DS-ConsistencyGuid e l’objectGUID non viene più impiegato a questo scopo
Manipolando questo attributo è quindi possibile “agganciare” l’identità cloud a un utente Active Directory migrato, semplicemente scrivendo nell’utente target, prima che Entra Connect lo importi, il mS-DS-ConsistencyGuid con il valore di origine.
La memoria “giusta”
Ricapitolando, siamo di fronte a due memorie, che funzionano in modalità differenti.
La prima parla di autorizzazione. sIDHistory ricorda i SID precedenti dell’utente e permette continuità negli accessi alle risorse, in un mondo dove utenti e risorse vivono spesso in perimetri differenti. È cumulativa, ma finché le risorse restano nel dominio di origine dipende dalle trust, ed è pensata per essere temporanea: finito il re-ACLing, si pulisce.
La seconda parla di identità. Il mS-DS-ConsistencyGuid non cambia e ricorda chi è l’utente, non cosa poteva fare. Funziona da ancora verso il corrispettivo oggetto cloud e permette di riagganciarvi l’utente migrato.
Le due memorie vengono impiegate in contesti storico/tecnologici differenti e risolvono il problema della migrazione in maniera altrettanto differente, ma la domanda è: devo scegliere quella “giusta” o posso usarle insieme?
Vediamolo in un caso reale.
Il caso reale: una cessione di ramo d’azienda
Non ho mai capito come mai, ma la categoria dei progetti di migrazione è da sempre definita “Mergers & Acquisitions” (M&A), sigla che sembra volutamente ignorare la prospettiva di chi vende, forse per non spaventare chi se ne deve occupare.
La cessione di un ramo d’azienda è una delle situazioni più complesse che mi sia capitato di affrontare nella categoria M&A, quella dove occorre operare un “taglio” e non si sa mai dove esattamente finisca il perimetro di ciò che rimane rispetto a quello che deve essere ceduto.
Le cose sono inoltre complicate da una diffusa diffidenza tra le parti: i due IT, quello di chi compra e quello di chi vende, di solito non vogliono che i propri sistemi entrino in contatto diretto.
A livello operativo, per l’on-premises questo si traduce quasi sempre nella stessa scelta: nell’ambiente del cliente sorgente viene creato un nuovo ambiente Active Directory “di transito”, che costituirà poi il perimetro da consegnare a chi ha acquisito.
A livello cloud non è sempre immediato fare la stessa cosa, inoltre l’unico punto di contatto sono gli strumenti di migrazione, ai quali è possibile limitare in maniera puntuale il perimetro d’azione.
Prendendo quindi un ambiente ibrido e unendo tutti i puntini in un piano di migrazione, quello che ne esce è un programma in due fasi:
· Una fase 1 con la migrazione delle risorse on-premises verso l’Active Directory di transizione, mantenendo fermo appunto il tenant Entra ID
· Una fase 2 con la successiva migrazione tenant to tenant
Oggi parliamo della fase 1.
Per non mettere in contatto chi compra e chi vende, il lavoro di questa fase deve essere svolto nell’ambiente del cliente sorgente, limitando e controllando in maniera puntuale ogni comunicazione con sistemi esterni. L’ambiente del cliente target non deve essere toccato.
Tralasciando la creazione del nuovo ambiente Active Directory e della relazione di trust, il primo passaggio prevede la replica nella directory di transizione degli utenti e dei gruppi con i relativi attributi.
Data la natura ibrida dello scenario è fondamentale iniziare ad applicare in contemporanea entrambe le tecniche di migrazione descritte in precedenza. Sugli utenti vengono quindi replicati sIDHistory e mS-DS-ConsistencyGuid, mentre per i gruppi si usa solo sIDHistory.
Il sistema Entra Connect viene configurato per dialogare con entrambe le directory, ma gli oggetti della directory di transizione vengono inizialmente esclusi per non generare conflitti.
Il secondo passaggio prevede la preparazione delle risorse sorgente, applicando dove necessario il re-ACLing e approfondendo le configurazioni applicative che non possano essere affrontate con tecniche basate sul SID.
Prima di andare oltre c’è da considerare una cosa importante: in tutte le migrazioni il vincolo principale è legato al suffisso UPN impiegato dagli utenti.
Il suffisso UPN è una configurazione impostata a livello di foresta e non può essere instradato contemporaneamente da entrambi i lati di una Forest Trust senza generare una “UPN suffix collision”, come abbiamo già discusso nel Capitolo 2.
Nella directory di transizione verrà quindi impiegato un suffisso UPN temporaneo, a meno che non si decida proprio di cambiarlo in fase di migrazione.
Teniamo per buona la prima scelta, a questo punto avremo:
· utenti nella directory di transizione con sIDHistory e mS-DS-ConsistencyGuid popolati, suffisso UPN temporaneo
· gruppi nella directory di transizione con sIDHistory
· risorse in sorgente con i permessi pronti
· Entra Connect esteso alla foresta di transizione
Il passo successivo è la migrazione delle postazioni di lavoro, dove interviene la prima delle due “memorie”, che consente agli utenti di conservare l’accesso alle risorse, mentre gli strumenti di migrazione delle postazioni riallineano i profili locali.
Durante questa transizione l’accesso alle risorse cloud continua a passare attraverso l’account sorgente.
Per i gruppi che governano l’accesso alle risorse cloud si possono seguire due strade. La prima, preferibile, è creare gruppi cloud-only e replicare i relativi permessi. La seconda è sincronizzare in anticipo i gruppi dalla directory di transizione, sapendo però che le membership arriveranno soltanto con il cut-over delle identità. In entrambi i casi i permessi sulle risorse cloud devono essere replicati.
Una volta completata la migrazione delle postazioni di lavoro è il momento di affrontare la fase di cut-over del suffisso UPN:
· Entra Connect viene messo in pausa
· Sulle utenze sorgente viene “liberato” il suffisso UPN impostandone uno differente
· Il suffisso viene poi rimosso dalla foresta sorgente e aggiunto a quella di transizione
· Alle utenze migrate viene impostato il suffisso UPN corretto
Siamo quindi pronti per vedere in azione il mS-DS-ConsistencyGuid.
A questo punto, in Entra Connect, gli oggetti sorgente vengono esclusi dalla sincronizzazione e quelli della directory di transizione vengono inclusi. Riattivando la sincronizzazione, il medesimo source anchor permette di associarli agli oggetti cloud esistenti.
Se abbiamo fatto tutto bene la “seconda memoria” entra in scena, riagganciando alle utenze cloud le corrispettive identità della directory di transizione.
A questo punto avremo:
· Postazioni di lavoro migrate
· Utenti migrati e riagganciati alle identità cloud
· Gruppi e permessi cloud predisposti
Mancano all’appello “solo” le risorse, che spesso vanno affrontate con più cautela in quanto a volte riservano sorprese. Inoltre, il perimetro potrebbe essere solo parziale, obbligando a migrare solamente dei dati o a reinstallare completamente nuove farm applicative direttamente nel nuovo perimetro di transizione.
Una volta terminato il “trasloco” anche di questa parte è possibile affrontare la fase finale di cleanup, durante la quale si rimuoveranno da sIDHistory i SID non più necessari e si puliranno le ACL corrispondenti.
A questo punto sarebbe il momento della fase 2, ma è qualcosa che va fuori ambito rispetto a questo articolo e non verrà trattato qui.
Cosa ci insegnano le due memorie
Partecipare ad un processo di migrazione non è quasi mai un’esperienza banale, alla fine qualcosa rimane sempre impresso nella memoria di chi l’ha vissuta, che sia un particolare tecnico, una difficoltà organizzativa o una soluzione geniale.
E come abbiamo visto qualcosa deve sempre transitare dalla memoria degli oggetti che stiamo migrando, perché anni di lavoro pregresso non si possono cancellare senza impatto. Resta solo da decidere cosa va ricordato e come.
Autorizzazione e identità hanno scopi differenti. La prima stabilisce cosa possiamo fare, la seconda permette ai sistemi di capire chi siamo. Durante una migrazione dobbiamo preoccuparci di farle sopravvivere entrambe al cambiamento, ma lo faremo con percorsi quasi opposti.
sIDHistory accumula chiavi di accesso. Conserva i vecchi SID e li porta con sé per tutto il tempo necessario a raggiungere le risorse che ancora li riconoscono. È una memoria efficace ma rischia di diventare onerosa e nasce con una data di scadenza: quando il re-ACLing è terminato, il vecchio perimetro può essere dismesso. È ora di buttare via le vecchie chiavi inutilizzate.
mS-DS-ConsistencyGuid segue una logica differente. Non accumula nulla, conserva un riferimento ad una sola identità e permette di riconoscerla anche quando cambia l’account che la rappresenta. Una volta impiegato come ancora verso il cloud, quel valore non è qualcosa da ripulire a fine progetto: è ciò che consente all’identità di rimanere la stessa mentre l’on-premises viene sostituito.
Attenzione però, per non diventare parte dell’arredamento IT, ogni memoria deve avere un proprietario e uno scopo dichiarato. Qualcuno deve sapere perché è stata creata, fino a quando deve restare e quale evento ne determina la fine. Senza questa responsabilità, sIDHistory rischia di trasformarsi in un’eredità permanente di accessi che nessuno ha più il coraggio di rimuovere, mentre con un source anchor gestito senza attenzione si può interrompere inavvertitamente il legame con l’identità cloud.
Ma la lezione più importante è questa: una migrazione non si può semplicemente considerare riuscita quando il nuovo account effettua il primo accesso o quando i dati risultano copiati. È riuscita quando la memoria temporanea ha finito di svolgere il proprio compito, quando i vecchi permessi possono essere rimossi senza paura e quando l’identità continua a essere riconosciuta anche dopo che il suo contenitore è cambiato.
Le due memorie che abbiamo visto lavorano bene insieme proprio per questo: una ci permette di attraversare la transizione, l’altra di sopravviverle.