Opzioni dell'infrastruttura di gestione delle identità parallele e combinate

Microsoft offre una gamma di tecnologie e soluzioni per l'integrazione tra i diversi componenti locali e cloud dell'infrastruttura di gestione delle identità. Spesso i clienti non sono chiari su quali tecnologie sono più corrette e potrebbero erroneamente pensare "la versione più recente riguarda tutti gli scenari delle versioni precedenti della tecnologia".

Questo articolo illustra gli scenari in cui l'azienda esamina uno scenario complesso descritto di seguito e cerca di combinare le informazioni sull'identità. Idealmente, un'organizzazione con una singola origine HR, una singola foresta di Active Directory e un singolo tenant di Microsoft Entra, tutti integrati con gli stessi utenti in ognuno di essi, avrà la migliore esperienza di gestione delle identità per Microsoft Online Services. Tuttavia, in pratica, un cliente aziendale potrebbe non essere sempre in una situazione in cui ciò è possibile. Ad esempio, il cliente potrebbe passare attraverso una fusione o avere la necessità di isolamento per alcuni utenti o applicazioni. Un cliente con più risorse umane, più tenant di Active Directory o più tenant di Microsoft Entra deve decidere se combinare un numero minore di istanze di ognuna o mantenerle in parallelo.

In base ai commenti e suggerimenti dei clienti, di seguito sono riportati alcuni degli scenari e dei requisiti comuni.

Scenari che si presentano per identità multicloud e multi-organizzative

• Fusioni e acquisizioni (M&A) – si riferisce a una situazione in cui, in genere, la Società A acquista la Società B.
• Rebranding: nome della società o modifica del marchio e in genere modifica del nome di dominio di posta elettronica.
• Consolidamento dei tenant di Microsoft Entra ID o Office 365: le aziende con più tenant di Office 365 possono voler unire a causa di requisiti di conformità o esigenze storiche.
• Consolidamento di domini o foreste di Active Directory: aziende che valutano l'esecuzione del consolidamento di domini o foreste di Active Directory.
• Divestitures: dove una divisione o un gruppo aziendale di una società viene venduta o diventa indipendente.
• Privacy delle informazioni utente: dove le aziende hanno requisiti per impedire la visibilità pubblica di determinati dati (attributi) e solo i gruppi delegati o gli utenti autorizzati possono leggere, modificare e aggiornarlo.

Requisiti che derivano da questi scenari

• Porta tutti i dati di utenti e gruppi in un'unica posizione, inclusi l'email e la disponibilità di stato per la programmazione delle riunioni, creando una directory centrale o universale.
• Mantenere un singolo nome utente e credenziali riducendo al contempo la necessità di immettere nomi utente e password in tutte le applicazioni implementando Single Sign On.
• Semplificare l'onboarding dell'utente in modo da non richiedere settimane o mesi.
• Preparare l'organizzazione per future acquisizioni e richieste di gestione degli accessi.
• Abilitare e migliorare la collaborazione e la produttività tra aziende.
• Ridurre la probabilità di una violazione della sicurezza o di esfiltrazione di dati con i criteri di sicurezza distribuiti in modo centralizzato e coerente.

Scenari non trattati in questo articolo

• M&A parziale. Ad esempio, un'organizzazione acquista parte di un'altra organizzazione.
• Cessione o suddivisione delle organizzazioni
• Ridenominazione delle organizzazioni.
• Joint ventures o partner temporanei

Questo articolo illustra vari ambienti di gestione delle identità multicloud o multi-organizzazione, inclusi gli scenari M&A supportati da Microsoft e illustra come un'organizzazione potrebbe selezionare le tecnologie appropriate a seconda del modo in cui si avvicinano al consolidamento.

Opzioni di consolidamento per uno scenario ipotetico di M&A

Le sezioni seguenti illustrano quattro scenari principali per uno scenario ipotetico di M&A:

Supponiamo che Contoso sia un cliente aziendale e che l'IT disponga di un singolo sistema di risorse umane (locale), di una foresta Active Directory singola, di un singolo tenant Microsoft Entra ID per le loro app, in esecuzione come previsto. Gli utenti vengono portati dal proprio sistema HR in Active Directory e proiettati nell'ID Microsoft Entra e da lì nelle app SaaS. Questo scenario è illustrato con il diagramma seguente, con le frecce che mostrano il flusso delle informazioni sull'identità. Lo stesso modello è applicabile anche ai clienti con sistema hr cloud, ad esempio Workday o SuccessFactors che effettua il provisioning di Active Directory, non solo ai clienti che usano Microsoft Identity Manager (MIM).

Successivamente, Contoso ha iniziato a fondersi con Litware, che in precedenza gestiva la propria informatica in modo indipendente. Contoso IT gestirà la fusione e prevede che l'IT di Contoso continuerà a mantenere invariate le app di Contoso, ma vuole essere in grado di consentire agli utenti di Litware di ricevere l'accesso e collaborare all'interno di tali app. Per le app Microsoft, le app SaaS di terze parti e le app personalizzate, lo stato finale deve essere che gli utenti contoso e Litware abbiano accesso concettualmente agli stessi dati.

La prima decisione IT è quanto desiderano combinare l'infrastruttura. Potrebbero scegliere di non basarsi sull'infrastruttura di identità di Litware. Oppure potrebbero prendere in considerazione l'uso dell'infrastruttura di Litware e convergere nel tempo riducendo al minimo l'interruzione dell'ambiente di Litware. In alcuni casi, il cliente potrebbe voler mantenere indipendente l'infrastruttura di gestione delle identità esistente di Litware e non convergerla, pur continuando a usarla per concedere ai dipendenti Litware l'accesso alle app Contoso.

Se il cliente sceglie di mantenere parte o tutta l'infrastruttura di identità di Litware, ci sono compromessi su quanto dei Servizi di Dominio Active Directory di Litware o di Microsoft Entra ID vengono utilizzati per garantire agli utenti Litware l'accesso alle risorse di Contoso. Questa sezione esamina le opzioni utilizzabili, in base a ciò che Contoso userebbe per gli utenti di Litware:

• Scenario A: non usare alcuna infrastruttura di identità di Litware.
• Scenario B- Usare le foreste Active Directory di Litware, ma non l'ID Microsoft Entra di Litware (se disponibile)
• Scenario C: usare l'ID Microsoft Entra di Litware.
• Scenario D - Usare l'infrastruttura di identità non Microsoft di Litware (se Litware non usa Active Directory/Microsoft Entra ID)

La tabella seguente riepiloga ogni opzione con le tecnologie per il modo in cui il cliente potrebbe ottenere tali risultati, i vincoli e i vantaggi di ognuno di essi.

Considerazioni	A1: Singolo HR, singolo IAM e tenant	A2: risorse umane separate, IAM singolo e tenant	B3: Trust fra foreste di Active Directory, singolo Microsoft Entra Connect	B4: Microsoft Entra Connect il proprio Active Directory al tenant singolo	B5: Microsoft Entra Connect per la sincronizzazione cloud del loro Active Directory.	C6: configurare in parallelo più tenant nelle app	C7: leggere dal tenant e B2B invitare gli utenti	C8: singoli utenti IAM e B2B in base alle esigenze	D9: DF con il relativo provider di identità non Azure AD
Impegno per la migrazione	Alto	Sforzo medio	Sforzo inferiore	Impegno basso	Impegno basso	Nessuno	Nessuno	Nessuno	Nessuno
Sforzo di implementazione	Minore sforzo	Sforzo medio	Sforzo medio	Sforzo medio	Basso livello	Basso livello	Alto	Alto	Molto alto
Impatto dell'utente finale durante la migrazione	Alto	Alto	Intermedio	Intermedio	Intermedio	Nessuno	Nessuno	Nessuno	Nessuno
Sforzo operativo	Costi contenuti	Costi contenuti	Costi contenuti	Costi contenuti	Costi contenuti	Alto	Alto	Alto	Molto alto
Funzionalità di privacy e dati (percorsi geografici/limiti dei dati)	Nessuno (blocco principale per scenari di posizione geografica)	Isolamento limitato anche se impegnativo	Isolamento limitato in locale, ma non nel cloud	Isolamento limitato in locale, ma non nel cloud	Isolamento limitato in locale, ma non nel cloud	Buon isolamento sia locale che nel cloud	Isolamento limitato sia in sede che nel cloud	Isolamento limitato sia in sede che nel cloud	Isolamento sia locale che nel cloud
Isolamento (delega separata e configurazione di modelli amministrativi diversi) Nota: come definito nel sistema di origine (HR)	Non possibile	Possibile	Possibile	Possibile	Possibile	Altamente possibile	Altamente possibile	Altamente possibile	Possibile
Funzionalità di collaborazione	Eccellente	Eccellente	Eccellente	Eccellente	Eccellente	Povero	Medio	Medio	Povero
Modello di amministratore IT supportato (centralizzato e separato)	Centralizzato	Centralizzato	Centralizzato	Centralizzato	Centralizzato	Decentralizzato	Decentralizzato	Decentralizzato	Decentralizzato attivamente
Limitazioni	Nessun isolamento	Isolamento limitato	Isolamento limitato	Isolamento limitato	Isolamento limitato. Nessuna funzionalità di writeback	Non funzionerà per le app di Microsoft Online Services. Altamente dipendente dalla funzionalità dell'app	Richiede che le app siano in grado di essere consapevoli di B2B	Richiede che le app siano in grado di essere consapevoli di B2B	Richiedere che le app siano orientate al B2B. Incertezza su come tutto funzioni insieme.

Dettagli della tabella

• L'impegno dei dipendenti tenta di prevedere le competenze necessarie e il lavoro aggiuntivo necessario per implementare la soluzione in un'organizzazione.
• Lo sforzo operativo tenta di prevedere i costi e il lavoro necessario per garantire la continuità operativa della soluzione.
• Le funzionalità di privacy e dati indicano se la soluzione consente il supporto per la posizione geografica e i limiti dei dati.
• L'isolamento indica se questa soluzione offre la possibilità di separare o delegare i modelli di amministrazione.
• Le funzionalità di collaborazione mostrano il livello di collaborazione supportato dalla soluzione, soluzioni più integrate offrono una maggiore fedeltà al lavoro in team.
• Il modello di amministratore IT indica se il modello di amministratore richiede la centralizzazione o può essere decentralizzato.
• Limitazioni: eventuali problemi o sfide che meritano di essere elencati.

Albero delle decisioni

Usare l'albero delle decisioni seguente per decidere quale scenario può funzionare meglio per l'organizzazione.

Il resto di questo documento descrive quattro scenari A-D con varie opzioni che li supportano.

Scenario A: se Contoso non vuole basarsi sull'infrastruttura di identità esistente di Litware

Per questa opzione, Litware potrebbe non avere sistemi di identità (ad esempio, una piccola azienda) o il cliente potrebbe voler disattivare l'infrastruttura di Litware. Oppure vogliono lasciarlo invariato, per l'uso da parte dei dipendenti Litware per l'autenticazione alle app di Litware, ma dare ai dipendenti Litware nuove identità come parte di Contoso. Ad esempio, se Alice Smith era un dipendente litware, potrebbe avere due identità, Alice@litware.com e ASmith123@contoso.com. Queste identità sarebbero completamente distinte l'una dall'altra.

Opzione 1 - Combinare in un singolo sistema HR

In genere, i clienti integrerebbero i dipendenti di Litware nel sistema delle risorse umane di Contoso. Questa opzione attiva i dipendenti per ricevere account e l'accesso corretto alle directory e alle app di Contoso. Un utente Litware avrà quindi una nuova identità Contoso, che potrebbe usare per richiedere l'accesso alle app Contoso corrette.

Opzione 2 - Mantenere il sistema HR Litware

A volte la convergenza dei sistemi HR potrebbe non essere possibile, almeno a breve termine. Invece, il cliente connetterà il proprio sistema di provisioning, ad esempio MIM, per ottenere dati da entrambi i sistemi HR. In questo diagramma, l'HR principale è l'ambiente Contoso esistente, e il secondo HR è l'aggiunta dell'infrastruttura da parte di Litware.

Lo stesso scenario sarebbe possibile anche utilizzando Microsoft Entra Workday o SuccessFactors in ingresso. Contoso potrebbe integrare gli utenti dalla risorsa HR Workday di Litware insieme ai dipendenti esistenti di Contoso.

Risultati del consolidamento di tutte le infrastrutture di gestione delle identità

• Infrastruttura IT ridotta, un solo sistema di identità da gestire, nessun requisito di connettività di rete, ad eccezione di un sistema HR.
• Esperienza amministrativa e utente finale coerente

Vincoli del consolidamento di tutta l'infrastruttura di identità

• Tutti i dati necessari per i dipendenti contoso originati in Litware devono essere migrati nell'ambiente Contoso.
• Tutte le app integrate di Active Directory o Microsoft Entra di Litware che saranno necessarie per Contoso devono essere riconfigurate nell'ambiente Contoso. Questa riconfigurazione può richiedere modifiche alla configurazione, ai gruppi usati per l'accesso o potenzialmente alle app stesse.

Scenario B - Se Contoso vuole mantenere le foreste Active Directory di Litware, ma non utilizzare Microsoft Entra ID di Litware

Litware potrebbe avere molte app basate su Active Directory esistenti su cui si basano e quindi Contoso potrebbe voler continuare a fare in modo che i dipendenti litware mantengano le proprie identità nell'AD esistente. Un dipendente litware userà quindi la propria identità esistente per l'autenticazione delle risorse esistenti e l'autenticazione delle risorse Contoso. In questo scenario Litware non ha identità cloud in Microsoft Online Services. Litware non era un cliente di Microsoft Entra, nulla degli asset cloud di Litware doveva essere condiviso con Contoso o Contoso ha migrato gli asset cloud di Litware per far parte del tenant di Contoso.

Opzione 3 - Trust della foresta con la foresta acquisita

Usando un trust tra foreste Active Directory, Contoso e Litware possono connettere i domini di Active Directory. Questa relazione di trust consente agli utenti di Litware di autenticare le app integrate in Active Directory di Contoso. Microsoft Entra Connect può anche leggere dalla foresta di Active Directory di Litware, in modo che gli utenti di Litware eseguano l'autenticazione con le app di Microsoft Entra integrate di Contoso. Questa topologia di distribuzione richiede una route di rete configurata tra i due domini e la connettività di rete TCP/IP tra qualsiasi utente Litware e app integrata in Contoso Active Directory. È anche semplice configurare trust bidirezionali, in modo che gli utenti contoso possano accedere alle app integrate di Litware AD (se presenti).

Risultato della configurazione di un trust tra foreste

• Tutti i dipendenti litware possono autenticare le app integrate di Active Directory o Microsoft Entra di Contoso e Contoso possono usare gli strumenti correnti basati su AD per gestire l'autorizzazione.

Vincoli per la creazione di un trust di foresta

• Richiede la connettività TCP/IP tra gli utenti collegati a un dominio di una foresta e risorse collegate all'altra foresta.
• Richiede che le app basate su Active Directory nella foresta Contoso siano in grado di supportare più foreste

Opzione 4 - Configurare Microsoft Entra Connect per la foresta acquisita senza relazioni di trust tra foreste

Un cliente può anche configurare Microsoft Entra Connect per leggere da un'altra foresta. Questa configurazione consente agli utenti di Litware di eseguire l'autenticazione alle app integrate di Microsoft Entra di Contoso, ma non fornisce l'accesso alle app integrate di Active Directory di Contoso all'utente Litware. Tali app Contoso non riconoscono gli utenti litware. Questa topologia di distribuzione richiede la connettività di rete TCP/IP tra i controller di dominio di Microsoft Entra Connect e Litware. Ad esempio, se Microsoft Entra Connect si trova in una macchina virtuale IaaS Contoso, è necessario stabilire un tunnel anche alla rete di Litware.

Risultato dell'uso di Microsoft Entra Connect per effettuare il provisioning di un tenant

• Tutti i dipendenti litware possono autenticare le app integrate di Microsoft Entra di Contoso.

Vincoli di utilizzo di Microsoft Entra Connect per effettuare il provisioning di un tenant

• Richiede la connettività TCP/IP tra i domini di Microsoft Entra Connect di Contoso e Active Directory di Litware.
• Non consente agli utenti di Litware di avere accesso alle applicazioni basate su Active Directory di Contoso

Opzione 5 - Distribuire la sincronizzazione cloud di Microsoft Entra Connect nella foresta acquisita

Il provisioning cloud di Microsoft Entra Connect rimuove il requisito di connettività di rete, ma è possibile avere un solo collegamento di Active Directory a Microsoft Entra ID per un determinato utente con sincronizzazione cloud. Gli utenti litware possono autenticare le app integrate di Microsoft Entra di Contoso, ma non le app integrate di Active Directory di Contoso. Questa topologia non richiede alcuna connettività TCP/IP tra gli ambienti litware e gli ambienti locali di Contoso.

Risultato della distribuzione della sincronizzazione cloud di Microsoft Entra Connect nella foresta acquisita

• Tutti i dipendenti litware possono autenticare le app integrate di Microsoft Entra di Contoso.

Vincoli dell'utilizzo della cloud sync di Microsoft Entra Connect nella foresta acquisita.

• Non consente agli utenti di Litware di avere accesso alle applicazioni basate su ACTIVE Directory di Contoso

Scenario C - Se Contoso vuole mantenere l'ID Microsoft Entra di Litware

Litware può essere un cliente di Microsoft Online Services o Azure o può avere una o più app basate su ID di Microsoft Entra su cui si basano. Contoso potrebbe quindi voler continuare a fare in modo che i dipendenti litware mantengano le proprie identità per l'accesso a tali risorse. Un dipendente litware userà quindi la propria identità esistente per l'autenticazione delle risorse esistenti e l'autenticazione delle risorse Contoso.

Questo scenario è adatto nei casi in cui:

• Litware ha un ampio investimento in Azure o Microsoft Online Services, inclusi più tenant di Office 365 che sarebbero costosi o dispendiosi in termini di tempo per eseguire la migrazione a un altro tenant.
• Litware potrebbe essere scorporato in futuro o è una partnership che verrà gestita in modo indipendente.
• Litware non ha un'infrastruttura locale

Opzione 6 - Mantenere il provisioning parallelo e il Single Sign-On per le app in ogni ID Microsoft Entra

Un'opzione consiste nel fornire in modo indipendente l'accesso Single Sign-On e il provisioning degli utenti dalla directory all'app di destinazione. Ad esempio, se Contoso IT usa un'app come Salesforce, fornirà a Litware diritti amministrativi per creare utenti nella stessa sottoscrizione di Salesforce.

Risultato del provisioning parallelo

• Gli utenti possono autenticare le app usando l'identità esistente, senza apportare modifiche all'infrastruttura di Contoso.

Vincoli del provisioning parallelo

• Se si usa la federazione, è necessario che le applicazioni supportino più provider di federazione per la stessa sottoscrizione.
• Non è possibile per le app Microsoft, ad esempio Office o Azure
• Contoso non ha visibilità nell'ID di Microsoft Entra per l'accesso alle applicazioni degli utenti di Litware

Opzione 7 - Configurare gli account B2B per gli utenti dal tenant acquisito

Se Litware gestisce il proprio tenant, Contoso può leggere gli utenti da quel tenant e, tramite l'API B2B, invitare ognuno di questi utenti nel tenant Contoso. Questo processo di invito in blocco può essere eseguito tramite il connettore a grafo MIM, ad esempio. Se Contoso dispone anche di app basate su AD che desiderano rendere disponibili agli utenti litware, MIM potrebbe anche creare utenti in Active Directory che eseguirebbero il mapping agli UPN degli utenti di Microsoft Entra, in modo che il proxy dell'app possa eseguire KCD per conto di una rappresentazione di un utente Litware in Active Directory di Contoso.

Quindi, quando un dipendente Litware vuole accedere a un'app Contoso, può farlo autenticandosi nella propria directory, con l'assegnazione di accesso al tenant della risorsa.

Risultato della configurazione degli account B2B per gli utenti dell'altro tenant

• Gli utenti Litware possono effettuare l'autenticazione nelle app di Contoso, e Contoso controlla l'accesso nel loro tenant.

Vincoli di configurazione degli account B2B per gli utenti dell'altro tenant

• Richiede un account duplicato per ogni utente Litware che richiede l'accesso alle risorse contoso.
• Richiede che le app siano idonee per il B2B e per SSO.

Opzione 8 - Configurare B2B ma con un feed HR comune per entrambe le directory

In alcune situazioni, dopo l'acquisizione l'organizzazione può convergere su una singola piattaforma HR, ma eseguire ancora sistemi di gestione delle identità esistenti. In questo scenario, MIM potrebbe effettuare il provisioning degli utenti in più sistemi Active Directory, a seconda di quale parte dell'organizzazione l'utente è associato. Potrebbero continuare a usare B2B affinché gli utenti eseguano l'autenticazione della directory esistente e abbiano un elenco indirizzi globale unificato.

Risultato della configurazione degli utenti guest B2B da un feed comune del sistema HR

• Gli utenti Litware possono eseguire l'autenticazione alle app Contoso e Contoso controlla tale accesso nel loro tenant.
• Litware e Contoso hanno un elenco indirizzi globale unificato.
• Nessuna modifica all'ID Active Directory o a Microsoft Entra di Litware

Vincoli nella configurazione degli utenti guest B2B da un feed comune del sistema di risorse umane

• Richiede che si apportino modifiche al provisioning di Contoso, affinché gli utenti siano inviati anche ad Active Directory di Litware, e che si stabilisca la connettività tra i domini di Litware e quelli di Contoso.
• Richiede che le app siano idonee per il B2B e per SSO.

Scenario D - Se Litware usa un'infrastruttura non Active Directory

Infine, se Litware usa un altro servizio directory, locale o nel cloud, Contoso IT può comunque configurare che i dipendenti litware eseguano l'autenticazione e possano ottenere l'accesso alle risorse di Contoso usando la propria identità esistente.

Opzione 9 - Usare la federazione diretta B2B (anteprima pubblica)

In questo scenario si presuppone che Litware abbia:

• Alcune directory esistenti, ad esempio OpenLDAP o anche un database SQL o un file flat di utenti con gli indirizzi di posta elettronica che possono condividere regolarmente con Contoso.
• Provider di identità che supporta SAML, ad esempio PingFederate o OKTA.
• Dominio DNS indirizzato pubblicamente, ad esempio Litware.com e utenti con indirizzi di posta elettronica in tale dominio

In questo approccio, Contoso configurerebbe una relazione di federazione diretta dal proprio tenant per quel dominio al provider di identità di Litware, e leggerebbe regolarmente gli aggiornamenti sugli utenti di Litware dalla loro directory per invitare gli utenti di Litware nell'ID Microsoft Entra di Contoso. Questo aggiornamento può essere eseguito con un connettore Graph MIM. Se Contoso dispone anche di app basate su Active Directory che desiderano rendere disponibili agli utenti litware, MIM potrebbe anche creare utenti in Active Directory che eseguirebbero il mapping agli UPN degli utenti di Microsoft Entra, in modo che il proxy dell'app possa eseguire KCD per conto di una rappresentazione di un utente Litware in Active Directory di Contoso.

Risultato dell'uso della federazione diretta B2B

• Gli utenti Litware eseguono l'autenticazione all'ID Microsoft Entra di Contoso con il provider di identità esistente e accedono alle app Web on-premises e cloud di Contoso.

Vincoli dell'uso della federazione diretta B2B

• Richiedere alle app Contoso di supportare il Single Sign-On per utenti B2B.

Passaggi successivi

• Che cos'è la sincronizzazione cloud di Microsoft Entra Connect
• Configurare il provisioning in ingresso per Microsoft Entra ID
• Configurare la federazione diretta B2B
• Opzioni di gestione utenti multi-tenant
• Che cos'è il provisioning delle applicazioni?