In questo articolo, andremo a parlare di un argomento molto discusso negli ambienti ibridati con l’organizzazione di Microsoft 365. Una volta terminata la migrazione delle mailbox da Exchange On-Premises a Exchange Online, molti clienti desiderano decommisionare definitivamente gli Exchange On-Premises.
È possibile decommisionare l’Exchange On-Premises definitivamente? La possibilità di eseguire questa operazione dipenderà da un paio di cose che andrò a spiegarvi in questo articolo.
Quando inizio un nuovo progetto di Office 365, la prima cosa di cui mi piace discutere con un cliente è il modello di gestione di identità a lungo termine che desidera avere. Inizio sempre a parlare di identità utente come prima cosa, anche se solitamente i clienti vogliono discutere da subito sulle modalità di migrazione degli item delle mailbox, questo perché il modello di gestione delle identità è il fattore più importante che va a determinare il miglior metodo di migrazione.
Le possibilità di gestione delle identità del cliente sono due:
- Il cliente desidera di mantenere la foresta di Active Directory On-Premises per gestire l’autenticazione di servizi presenti in casa, e desidera eseguire la sincronizzazione delle identità utente con sync degli hash delle password da foresta On-Premises a Office 365 per permettere agli utenti di utilizzare lo stesso set di credenziali sia per le risorse in casa che su quelle in cloud
- Il cliente non desidera mantenere la foresta di Active Directory On-Premises e di conseguenza non andrà a sincronizzare nulla a livello di identità utente
La chiave della discussione sulle identità utente in ambiente ibrido è la sincronizzazione delle identità utente. Microsoft ha pubblicato una guida passo passo per decomissionare gli Exchange On-Premises in un ambiente ibrido. Il titolo dell’articolo è un po’ fuorviante perché NON è la configurazione ibrida che alla fine determina se è possibile decommisionare l’Exchange On-Premises o meno.
Quando la sincronizzazione delle identità è abilitata per un tenant e un utente è sincronizzato da foresta On-Premises, la maggior parte degli attributi delle identità non possono essere gestiti da Exchange Online ma devono essere gestiti dall’organizzazione Exchange On-Premises. Ciò non è dovuto alla configurazione ibrida, ma si verifica a causa della sincronizzazione delle identità. Inoltre, anche se sincronizziamo le identità On-Premises su Azure AD senza eseguire la procedura guidata di configurazione ibrida di Exchange non sarà ugualmente possibile eseguire la maggior parte dei task sulle identità dal cloud, sarà dunque sempre necessario eseguire le attività di management dall’infrastruttura On-Premises.
Per le organizzazioni che intendono mantenere il sync delle identità in place e continuare a gestire gli attributi delle identità dall’organizzazione On-Premises, si consiglia di non rimuovere l’ultimo Exchange server dall’organizzazione On-Premises. Se l’ultimo Exchange server viene rimosso, non sarà possibile apportare modifiche all’oggetto mailbox su Exchange Online perché il “SOA” (Source Of Authority) è definito come On-Premises. Il Source of Authority fa riferimento alla posizione in cui vengono
gestiti gli oggetti del servizio directory di Active Directory, come utenti e gruppi (una source di origine che definisce le copie di un oggetto) in una distribuzione ibrida.
Nel momento in cui si andasse a decomissionare l’ultimo Exchange Server On-Premises, si renderebbe obbligatorio verificare che lo schema di Active Directory è stato esteso correttamente.
Con gli attributi necessari per un’Organizzazione di Exchange, inoltre si andrebbero ad utilizzare strumenti non supportati per attività su Exchange come Active Directory Service Interfaces Editor (ADSI Edit)
per le attività amministrative comuni.
Per riassumere, se vogliamo sincronizzare le nostre identità su Azure AD permettendo così all’utente finale di utilizzare la stessa identità per autenticarsi su servizi On-premises e su servizi 365, si rende necessaria la presenza degli Exchange Management Tools che sono ovviamente presenti solo nelle installazioni di Exchange.
Quindi che tipo di migrazione scegliere? Di seguito alcuni scenari di migrazione da considerare:
- Di seguito i metodi di migrazione:
- Cutover Migration
- Staged Migration
- Hybrid configuration
- IMAP Migration
- Third party migration tools
- Se avete necessità di avere le identità sincronizzate, una Cutover Migration non è una buona scelta. Personalmente non sono fan delle migrazioni cutover, ma in particolare in scenari con identità sincronizzate una volta completata la Cutover migration è molto complicato riuscire ad aggiornare la sincronizzazione delle directory, in questo caso è importante scegliere un tipo di migrazione che ti permetta di aggiornare la sincronizzazione delle directory prima di aver completato la migrazione.
- Se avete necessità di avere le identità sincronizzate, è fortemente consigliato utilizzare l’Hybrid configuration come metodo di migrazione per facilitare il processo e il successivo management delle mailbox online. L’Hybrid richiede un po’ di lavoro in più per la configurazione, ma offre un’esperienza migliore agli amministratori e agli utenti finali in fase di migrazione.
E se volessimo assolutamente rimuovere l’Exchange On-Premises ma mantenere comunque la sincronizzazione delle identità utente? Per questo tipo di scenario probabilmente avrete già visto dei tool di terze parti, o avrete parlato con qualcuno che vi consiglia di farlo perché potrete comunque continuare a gestire gli attributi utilizzando l’ADSIEdit. Da un punto di vista puramente technico è assolutamente possibile farlo, gli strumenti di management di Exchange in questo caso non fanno altro che andare a modificare degli attributi che andremmo in alternativa a modificare a mano. Microsoft però non supporta le modifiche degli attributi di Active Directory con nulla di diverso che non siano strumenti di management di Exchange.
In tutto questo non siamo entrati nel dettaglio di scenari complessi, non abbiamo nemmeno menzionato l’ADFS. Per i clienti con molta complessità infrastrutturale o con necessità di federare la propria organizzazione con Azure è fortemente consigliato utilizzare almeno una macchina con a bordo Exchange (potete anche usare poche risorse considerato che verrà utilizzata solo per la gestione degli attributi delle identità con mailbox remota). La soluzione NON SUPPORTATA dalla casa di Redmond descritta sopra può essere dunque utilizzata da piccole realtà. Personalmente una volta allargato lo schema di AD, consiglierei sempre di mantenere un CAS di MGMT anche per realtà medio piccole.
Microsoft ha dichiarato che ha in cantiere un progetto che permetterà di poter gestire gli oggetti sincronizzati dalla directory locale anche utilizzando gli strumenti di Office 365, questo progetto fa riferimento ad un connettore ibrido che funziona in modo simile all’Azure App Proxy e all’AD Connect Passthrough Authentication. Andrà dunque installato in tutti i casi un agente nell’infrastruttura On-Premises, per le piccole realtà sicuramente preferibile all’avere un Exchange Server in più solo per la gestione degli attributi estesi delle identità sincronizzate.
CONCLUSIONI
Microsoft 365 ci offre la possibilità di avere un esperienza cloud totalmente trasparente lato utente finale, per poter usufruire di tutto questo avremo ancora necessità di gestire le nostre identità sincronizzate attraverso gli strumenti di MGMT di Exchange On-Premises, un piccolo sforzo per un grande risultato.
Stay Tuned on Technical365!!