Automatizzare l'offboarding di Microsoft 365 con i Lifecycle Workflows di Entra

Per automatizzare l'offboarding di Microsoft 365, costruite flussi di uscita in Microsoft Entra ID Lifecycle Workflows che si attivano su un attributo di data presente sull'oggetto utente anziché su un ticket che qualcuno deve ricordarsi di aprire. Impostate employeeLeaveDateTime sull'account, ed Entra esegue un flusso di pre-offboarding prima dell'ultimo giorno, un flusso di offboarding nel giorno stesso e un flusso di post-offboarding successivamente, ciascuno con attività integrate come Disable User Account, Remove user from all groups, Remove all licenses for user e Delete User Account. L'innesco è una data, l'ambito è una regola, e l'esecuzione lascia una cronologia che potete mostrare a un revisore. Questa guida percorre l'intera costruzione, dichiara onestamente la licenza che richiede e copre le quattro cose che non farà al posto vostro.

Chi ha lasciato l'azienda e ha tenuto una licenza per quattro mesi

Partite dal fallimento che tutto questo dovrebbe risolvere, perché non è quasi mai un fallimento tecnico. Qualcuno se ne va. L'help desk blocca l'accesso nel suo ultimo giorno, viene dirottato su qualcosa di urgente, e il resto della sequenza non avviene mai. Quattro mesi dopo l'account è ancora abilitato in tre gruppi di sicurezza, detiene ancora una postazione completa ed è ancora conteggiato in fattura.

Vale la pena fare il conto con i vostri numeri anziché con il parametro di riferimento di qualcun altro. Un'organizzazione da 250 utenti con un ricambio tipico può perdere 30 persone all'anno. Se ogni uscita viene completata in media con sei settimane di ritardo, sono circa 3,5 mesi-postazione di spreco per persona, quindi all'incirca 105 mesi-postazione all'anno. A £22 a postazione sono poco più di £2,300; a £35 si arriva vicino a £3,700. Cambiate un qualsiasi dato di partenza e la risposta si sposta, ed è proprio questo il punto: il vostro responsabile finanziario può verificare quel conto a mente.

Il costo è la parte che apre una conversazione sul budget. Il rischio è la parte che apre una conversazione con il consiglio di amministrazione. Chi lascia l'azienda con appartenenze ai gruppi ancora attive conserva tutto ciò che quei gruppi concedono, e tra 50 e 600 utenti la stessa persona di solito detiene credenziali condivise, l'appartenenza a un team di Teams con dati dei clienti dentro e una casella di posta che nessuno legge da quando se n'è andata. L'automazione conta qui non perché i passaggi manuali siano difficili, ma perché un processo manuale eseguito 30 volte l'anno verrà saltato almeno una volta, e non saprete quale.

Cosa copre davvero l'eliminazione dall'interfaccia di amministrazione

Vale la pena essere precisi sulla base manuale. Nell'interfaccia di amministrazione di Microsoft 365, sotto Users e poi Active users, selezionare una persona e scegliere Delete user esegue un pacchetto di azioni: può rimuovere le licenze, dare a qualcuno l'accesso al OneDrive e alla posta, e poi eliminare l'account. È un percorso davvero utile per una singola uscita e non dovete vergognarvi di usarlo.

Ciò che non è, è un processo. Non fa nulla finché una persona non lo apre, tratta ogni uscita in modo identico a prescindere da ruolo o reparto, non produce alcuna traccia oltre al log di audit che qualcuno riconoscerebbe come evidenza, e non può essere eseguito una settimana prima dell'ultimo giorno né trenta giorni dopo. Anche rispettare il giusto ordine delle operazioni conta più di quanto si creda, perché rimuovere una licenza prima di aver gestito la casella di posta comporta la perdita di dati. La checklist di offboarding Microsoft 365 espone quella sequenza passo per passo, e resta il riferimento corretto per capire come dovrebbe essere fatta. Questo articolo riguarda il modo di far girare quella sequenza da sola.

La questione della licenza, risolta prima di progettare qualsiasi cosa

Chiaritevi su questo punto prima di progettare qualunque cosa, perché decide se il resto dell'articolo vi riguarda.

Lifecycle Workflows richiede licenze Microsoft Entra ID Governance o Microsoft Entra Suite. Non è incluso in Microsoft Entra ID P1, non è incluso in Microsoft Entra ID P2 e quindi non è incluso in Microsoft 365 E3 o E5 in virtù del piano Entra che comprendono. Microsoft Entra ID Governance è una sottoscrizione separata che si aggiunge a un piano idoneo, e Microsoft ha dichiarato esplicitamente che nessuna nuova funzionalità di governance delle identità verrà aggiunta allo SKU Entra ID P2.

Servono inoltre licenze sufficienti a coprire ogni utente membro nell'ambito del flusso, più chi lo configura, e non una singola postazione di amministratore. L'esempio pratico di Microsoft stessa riguarda un flusso di pre-offboarding con ambito su 50 utenti, che richiede 51 licenze. Per un'organizzazione da 300 utenti che gestisce 30 uscite all'anno, questo cambia la forma del business case: non state licenziando 30 persone in uscita, state licenziando l'intera popolazione coperta dall'ambito del flusso.

Esiste una versione di prova. Un Global Administrator in un tenant commerciale che detiene già un prodotto idoneo come Microsoft Entra ID P1, e che non l'ha ancora provata, può avviarla dall'interfaccia di amministrazione di Microsoft 365 sotto Billing e poi Purchase services, cercando Microsoft Entra ID Governance e selezionando Details e poi Start free trial. È il modo onesto di testare i flussi qui sotto sul vostro tenant prima che qualcuno firmi qualcosa.

Costruire il flusso di uscita

La creazione di un flusso nell'interfaccia di amministrazione di Microsoft Entra parte sempre da un modello, e ce ne sono 14 integrati. Quattro riguardano le uscite, e il motivo per cui sono quattro è che l'offboarding non è un momento solo.

Pre-Offboarding of an employee viene eseguito per impostazione predefinita sette giorni prima di employeeLeaveDateTime, con Remove user from selected groups e Remove user from selected Teams. È quello che si salta e poi si rimpiange: è il punto in cui togliete qualcuno dal gruppo delle paghe e dal Team della finanza mentre è ancora presente per il passaggio di consegne.

Offboard an employee viene eseguito nel giorno stesso dell'uscita, con Disable User Account, Remove user from all groups e Remove user from all Teams. È il flusso che chiude la porta.

Post-Offboarding of an employee viene eseguito dopo la data di uscita, con Remove all licenses for user, Remove user from all Teams e Delete User Account. È il flusso che ferma la fatturazione della postazione, e lo scarto che scegliete qui è il numero più costoso dell'intera progettazione.

Real-time employee termination non ha alcuna condizione di esecuzione. È solo su richiesta, con Remove user from all groups, Delete User Account e Remove user from all Teams, ed esiste per il caso dell'uscita immediata.

Il catalogo di attività più ampio è il punto in cui mettete a punto ciascuno di essi. Accanto alle attività qui sopra comprende Revoke all refresh tokens for user, Remove all access package assignments for user, Send email to manager before user's last day, Send email on user's last day e Send email to user's manager after their last day. Vale la pena notare che la revoca delle sessioni sia un'attività integrata, perché molte guide all'offboarding la presentano ancora come qualcosa da scriptare.

Altri due modelli meritano una menzione anche se non sono strettamente guidati dall'uscita: Pre-Offboard inactive users e Offboard inactive users si attivano sull'inattività di accesso anziché su una data di uscita, con 90 e 120 giorni come impostazione predefinita rispettivamente. Sono la versione automatizzata del report della nostra guida su come trovare gli utenti Microsoft 365 inattivi, e intercettano gli account che non hanno mai avuto una data di uscita perché nessuno ha mai detto a nessuno che la persona se n'era andata.

Pianificazione, ambito e l'attributo da cui dipende tutto

Tre dettagli di configurazione decidono se la cosa funziona nella pratica.

L'attributo non è gratis. employeeLeaveDateTime non viene popolato al posto vostro. Arriva dal provisioning guidato dalle risorse umane, da Microsoft Entra Connect o da uno script che lo scrive tramite Microsoft Graph. Scriverlo in un contesto delegato richiede il ruolo Global Administrator insieme alle autorizzazioni User.Read.All e User-LifeCycleInfo.ReadWrite.All, che è un requisito più alto di quello della maggior parte delle attività di reporting e vale la pena sollevarlo per tempo con chi gestisce la vostra integrazione HR. Se nessuno imposta la data non viene eseguito nulla, e il flusso sembrerà rotto quando è semplicemente inattivo.

La pianificazione va attivata. I nuovi flussi sono abilitati per impostazione predefinita, ma non pianificati, quindi un flusso può restare lì con un aspetto corretto senza mai attivarsi. Una volta pianificati, i flussi vengono valutati secondo un intervallo valido per l'intero tenant, impostato per impostazione predefinita su ogni tre ore e configurabile da 1 a 24 ore, sotto ID Governance e poi Lifecycle workflows e poi Workflow settings nell'interfaccia di amministrazione di Microsoft Entra. Per modificarlo serve almeno il ruolo Lifecycle Workflows Administrator.

Le esecuzioni su richiesta ignorano le vostre condizioni di esecuzione. Eseguire un flusso su richiesta applica le sue attività all'utente indipendentemente dal fatto che soddisfi ambito e innesco. È esattamente ciò che volete per un licenziamento in giornata ed esattamente ciò che non volete mentre state facendo test, quindi provate su un account che siete disposti a perdere.

Una buona notizia sui tempi: se la data di uscita viene impostata in ritardo, per esempio perché il sistema HR è stato aggiornato a posteriori, Lifecycle Workflows tenterà comunque di elaborare l'utente a condizione che la configurazione sia completata entro tre giorni dall'orario di elaborazione previsto. Questo comportamento di recupero non si applica all'opzione Time based attribute V2 attualmente in anteprima pubblica.

Cinque mosse. Entra automatizza la prima, la seconda, la terza e la quinta. La quarta è quella che decide se qualcuno si fida delle altre quattro.

Le quattro cose che non farà

Lifecycle Workflows governa l'identità. L'offboarding di Microsoft 365 è più ampio dell'identità, e queste quattro lacune restano vostre.

La casella di posta. Non esiste un'attività per convertire una casella di posta utente in una casella condivisa, e la trappola dell'ordine è reale: la casella deve avere ancora la licenza nel momento in cui la convertite, quindi questo deve avvenire prima che il flusso di post-offboarding tolga la licenza, non dopo.

I file. Dare a un responsabile l'accesso al OneDrive di chi lascia l'azienda è un compito dell'interfaccia di amministrazione di SharePoint. Nulla nei modelli di uscita lo tocca.

Il dispositivo. Retire e wipe risiedono nell'interfaccia di amministrazione di Microsoft Intune, e nessuna attività del ciclo di vita li raggiunge. I report Intune pianificati sono il modo pratico di dimostrare quali dispositivi di chi ha lasciato l'azienda si siano davvero registrati e risultassero conformi.

La fattura. Remove all licenses for user libera l'assegnazione. Non riduce la quantità di una sottoscrizione prepagata, quindi il risparmio raggiunge la vostra fattura solo quando qualcuno interviene al rinnovo. Se la licenza proveniva da un'assegnazione basata sui gruppi, è l'appartenenza al gruppo a trattenere la postazione, ed è per questo che le attività sui gruppi e quella sulle licenze appartengono allo stesso flusso.

Ecco lo script per la prima lacuna, dimensionato per essere eseguito una volta per ogni uscita, nella finestra tra l'ultimo giorno e l'esecuzione del post-offboarding.

# Fills the gaps Lifecycle Workflows does not cover, before the licence is removed
Connect-ExchangeOnline
Connect-MgGraph -Scopes "User.RevokeSessions.All"
$Leaver  = "leaver@contoso.com"
$Manager = "manager@contoso.com"
# Belt and braces: end every active session now rather than waiting for token expiry
Revoke-MgUserSignInSession -UserId $Leaver
# Convert while the mailbox is still licensed, or the conversion is not available
Set-Mailbox -Identity $Leaver -Type Shared
Add-MailboxPermission -Identity $Leaver -User $Manager -AccessRights FullAccess -InheritanceType All
Add-RecipientPermission -Identity $Leaver -Trustee $Manager -AccessRights SendAs -Confirm:$false
Write-Host "$Leaver converted to shared and delegated to $Manager"

Leggetelo prima di eseguirlo. Revoke-MgUserSignInSession è ridondante se il vostro flusso di offboarding porta già l'attività di revoca, e innocuo se non la porta. La conversione mantiene posta e calendario raggiungibili fino a 50 GB senza una postazione a pagamento, ed è ciò che rende sicuro lasciare che il flusso tolga la licenza il giorno dopo. Non eliminate l'account finché la casella condivisa è in uso, perché è l'account a farle da ancoraggio.

Se quella sequenza vi sembra qualcosa che preferireste vedere girare in continuo anziché ricordare per ogni uscita, una prova EtherInsights di 14 giorni mostra gli stessi controlli sul vostro tenant.

Il limite onesto di automatizzare tutto questo

Lifecycle Workflows è buono. È anche un meccanismo, non un risultato, e tre cose separano le due cose.

Qualcuno deve esserne responsabile. Un flusso senza un responsabile va alla deriva: la regola di ambito smette di corrispondere a un reparto che è stato rinominato, un modello viene modificato durante una settimana intensa, e nessuno se ne accorge finché un'uscita non produce silenziosamente alcun effetto. La cronologia dei flussi vi dà la materia prima, consultabile per utenti, esecuzioni e attività, ma la materia prima non è una revisione.

Qualcuno deve produrre le evidenze. Il vostro revisore, il vostro valutatore Cyber Essentials e il questionario di sicurezza del vostro cliente più grande fanno tutti la stessa domanda con parole diverse: dimostratemi che gli accessi sono stati rimossi entro i tempi dichiarati, per queste persone nominate, in queste date. È un lavoro di reporting che si aggiunge al flusso, non un suo sottoprodotto.

E qualcuno deve seguire il recupero fino alla fattura. La postazione liberata dal flusso è un risparmio solo quando la quantità della sottoscrizione scende. Tra quei due eventi ci sono una data di rinnovo e una conversazione con la finanza, ed è lì che la maggior parte del lavoro di recupero muore silenziosamente. La nostra guida su dimostrare i risparmi sul cloud spiega perché quell'ultimo passo richiede un prima e un dopo anziché un'affermazione.

Niente di tutto ciò è un argomento contro la costruzione dei flussi. Costruiteli questo mese. È un argomento per essere chiari sul fatto che l'automazione risolve il problema dell'esecuzione e lascia il problema della responsabilità esattamente dov'era.

Dove si inserisce EtherInsights

EtherInsights è la console che si colloca sopra tutto questo. Controlla l'offboarding in continuo anziché ticket per ticket, fa emergere chi ha lasciato l'azienda ed è ancora abilitato o ancora con licenza come constatazioni con un responsabile nominato e un'azione successiva, e conserva il prima e il dopo perché un recupero arrivi alla vostra revisione finanziaria come evidenza anziché come affermazione. Dove avete Lifecycle Workflows, vi dice se i flussi hanno davvero fatto ciò per cui li avete progettati. Dove non li avete, perché la licenza di governance non è ancora stata approvata, vi dà la stessa visibilità senza di essa.

La gestione delle licenze e l'offboarding di Microsoft 365 fa girare il ciclo di ingresso, cambio ruolo e uscita come un unico processo su tutti i tenant, con il lavoro sulle postazioni dormienti di come trovare le licenze inutilizzate nella stessa vista. Costa £0.79 per utente attivo con una prova di 14 giorni, quindi potete misurare il divario tra le vostre date di uscita e le vostre rimozioni di licenze prima di impegnarvi, ed è di solito il numero che chiude la discussione.

Impostate correttamente la data di uscita, costruite i tre flussi pianificati, scriptate la casella di posta e fissate una revisione mensile in calendario. Se quella revisione continua a slittare, avete trovato il vero vincolo, e non è mai stato lo strumento.

Esplora la gestione delle licenze e l'offboarding di Microsoft 365 per vedere i controlli sulle uscite, il recupero delle licenze e la traccia delle evidenze gestiti come un unico processo continuo anziché come un flusso che nessuno sta guardando.