Federa Google Cloud con Microsoft Entra ID (in precedenza Azure AD)

Questo documento descrive come configurare Cloud Identity o Google Workspace per utilizzare Microsoft Entra ID (in precedenza Azure AD) come IdP e origine delle identità.

Il documento confronta la struttura logica di Microsoft Entra ID con quella utilizzata da Cloud Identity e Google Workspace e descrive come mappare tenant, domini, utenti e gruppi di Microsoft Entra ID.

Implementare la federazione

Google Cloud utilizza le identità Google per l'autenticazione e la gestione dell'accesso. La gestione manuale delle identità Google per ogni dipendente può aggiungere un overhead di gestione non necessario quando tutti i dipendenti hanno già un account in Microsoft Entra ID. Se federi le identità utente tra Google Cloud e il tuo sistema di gestione delle identità esistente, puoi automatizzare la manutenzione delle identità Google e collegare il loro ciclo di vita agli utenti esistenti in Microsoft Entra ID.

La configurazione della federazione tra Microsoft Entra ID e Cloud Identity o Google Workspace prevede due passaggi:

• Provisioning degli utenti: gli utenti e i gruppi pertinenti vengono sincronizzati periodicamente da Microsoft Entra ID a Cloud Identity o Google Workspace. Questo processo garantisce che quando crei un nuovo utente in Microsoft Entra ID o sincronizzi un nuovo utente da Active Directory a Microsoft Entra ID, questo sia disponibile anche in Google Cloud in modo che possa essere consultato in Google Cloud anche prima che l'utente associato abbia eseguito l'accesso per la prima volta. Questo processo garantisce anche la propagazione delle eliminazioni degli utenti.

  Il provisioning funziona in un'unica direzione, il che significa che le modifiche in Microsoft Entra ID vengono replicate in Google Cloud , ma non viceversa. Inoltre, il provisioning non include le password.

• Single Sign-On: ogni volta che un utente deve autenticarsi, Google Cloud delega l'autenticazione a Microsoft Entra ID utilizzando il protocollo SAML (Security Assertion Markup Language). A seconda della configurazione di Microsoft Entra ID, Microsoft Entra ID potrebbe eseguire una delle seguenti operazioni:

  • Esegui l'autenticazione.
  • Utilizza l'autenticazione pass-through o la sincronizzazione dell'hash della password.
  • Delega l'autenticazione a un server AD FS on-premise.

Se Cloud Identity o Google Workspace delegano l'autenticazione a Microsoft Entra ID, non solo si evita di dover sincronizzare le password conGoogle Cloud, ma si garantisce anche l'applicazione di eventuali criteri o meccanismi di autenticazione a più fattori (MFA) configurati in Microsoft Entra ID o AD FS.

Struttura logica di Microsoft Entra ID

Quando utilizzi Azure, utilizzi uno o più tenant Microsoft Entra ID (chiamati anche directory). I tenant Microsoft Entra ID sono una struttura di primo livello. Sono considerati confini amministrativi e fungono da contenitori per utenti, gruppi, nonché per risorse e gruppi di risorse.

Ogni tenant Microsoft Entra ID ha almeno un dominio DNS associato. Questo dominio DNS si riflette nei nomi utente (chiamati anche User Principal Name o UPN), che hanno la forma di name@domain, dove domain è uno dei domini DNS associati al tenant corrispondente.

Un'azienda potrebbe gestire più tenant di Microsoft Entra ID. I motivi comuni per avere più tenant includono la distinzione tra le diverse parti dell'organizzazione, la separazione delle risorse di produzione da quelle di sviluppo e test e l'utilizzo di tenant separati per integrare più foreste da un Active Directory on-premise.

Struttura logica di Google Cloud

In Google Cloud, le organizzazioni fungono da contenitori per tutte le risorse e possono essere ulteriormente segmentate utilizzando cartelle e progetti. Tuttavia, a eccezione degli account di servizio, le organizzazioni non vengono utilizzate per gestire utenti e gruppi, il che le rende diverse dai tenant Microsoft Entra ID.

Per la gestione di utenti e gruppi, Google Cloud si basa su Cloud Identity o Google Workspace. Un account Cloud Identity o Google Workspace funge da directory privata per utenti e gruppi. In qualità di amministratore dell'account, puoi controllare il ciclo di vita e la configurazione di utenti e gruppi e definire come può essere eseguita l'autenticazione.

Quando crei un account Cloud Identity o Google Workspace, viene creata automaticamente un' Google Cloud organizzazione. L'account Cloud Identity o Google Workspace e l'organizzazione Google Cloud associata condividono lo stesso nome e sono collegati tra loro. Tuttavia, un'organizzazioneGoogle Cloud può fare riferimento a utenti e gruppi di altri account Cloud Identity o Google Workspace.

Integra Microsoft Entra ID e Google Cloud

Nonostante alcune somiglianze tra la struttura logica di Microsoft Entra ID e Google Cloud, nessuna mappatura singola tra le due strutture funziona altrettanto bene in tutti gli scenari. L'approccio giusto per integrare i due sistemi e mappare la struttura dipende da diversi fattori:

• Come mappare i tenant di Microsoft Entra ID agli account Cloud Identity o Google Workspace
• Come mappare i domini DNS
• Come mappare gli utenti
• Come mappare i gruppi

Le sezioni seguenti esaminano ciascuno di questi fattori.

Google Cloud interagisce solo con Microsoft Entra ID, non con Active Directory on-premise. Pertanto, il modo in cui hai mappato le foreste e i domini di Active Directory on-premise a Microsoft Entra ID è di importanza secondaria.

Mappare i tenant Microsoft Entra ID

Le sezioni seguenti descrivono come mappare i tenant Microsoft Entra ID per questi scenari:

• Single-tenant
• Più inquilini
• Utenti esterni

Single-tenant

Se utilizzi un solo tenant Microsoft Entra ID, puoi mappare il tenant a un singolo account Cloud Identity o Google Workspace e configurare la federazione tra i due. Questo account Cloud Identity o Google Workspace fornisce quindi la base per una singola organizzazione Google Cloud che puoi utilizzare per gestire tutte le risorse Google Cloud .

Più inquilini

Nelle organizzazioni più grandi, non è raro avere più di un tenant Microsoft Entra ID. È possibile utilizzare più tenant per distinguere tra ambienti di test e di produzione o tra diverse parti di un'organizzazione.

È possibile mappare più tenant di Microsoft Entra ID a un singolo account Cloud Identity o Google Workspace e configurare il provisioning degli utenti e il Single Sign-On di conseguenza. Tuttavia, un mapping N:1 può indebolire l'isolamento tra i tenant di Microsoft Entra ID: se concedi a più tenant di Microsoft Entra ID l'autorizzazione a creare e modificare utenti in un unico account Cloud Identity o Google Workspace, questi tenant possono interferire e manomettere le modifiche apportate dagli altri.

In genere, un approccio migliore per l'integrazione con più tenant di Microsoft Entra ID consiste nel creare un account Cloud Identity o Google Workspace separato per ogni tenant e configurare la federazione tra ogni coppia.

In Google Cloud, viene creata un'organizzazione separata per ogni account Cloud Identity o Google Workspace. Poiché Google Cloud consente di organizzare le risorse utilizzando progetti e cartelle all'interno di un'unica organizzazione, avere più di un'organizzazione è spesso impraticabile. Tuttavia, puoi selezionare una delle organizzazioni e associarla agli altri account Cloud Identity o Google Workspace, creando di fatto un'organizzazione federata con più foreste di Active Directory. Le altre organizzazioni rimangono inutilizzate.

Utenti esterni

Con Microsoft Entra ID B2B, puoi invitare utenti esterni come ospiti nel tuo tenant Microsoft Entra ID. Per ogni ospite viene creato un nuovo utente e Microsoft Entra ID assegna automaticamente un UPN a questi utenti ospiti. L'UPN generato da Microsoft Entra ID utilizza un prefisso derivato dall'indirizzo email dell'invitato, combinato con il dominio iniziale del tenant: prefix#EXT#@tenant.onmicrosoft.com.

Il provisioning degli utenti guest da Microsoft Entra ID a Cloud Identity o Google Workspace è soggetto a determinate limitazioni:

• Non puoi mappare l'UPN degli utenti ospiti agli indirizzi email in Cloud Identity o Google Workspace perché onmicrosoft.com è un dominio che non può essere aggiunto e verificato in Cloud Identity o Google Workspace. Pertanto, devi mappare gli utenti utilizzando un attributo diverso dall'UPN.
• Se un utente ospite viene sospeso nel tenant di origine, l'utente corrispondente in Cloud Identity o Google Workspace potrebbe rimanere attivo e l'accesso alle risorse potrebbe non essere revocato correttamente. Google Cloud

Un modo migliore per gestire gli utenti guest provenienti da un tenant Microsoft Entra ID diverso è creare più account Cloud Identity o Google Workspace come descritto nella sezione precedente, ognuno federato con un tenant Microsoft Entra ID diverso. Per maggiori informazioni, vedi Provisioning degli utenti B2B di Microsoft Entra ID e Single Sign-On

Per concedere a un utente esterno l'accesso a determinate risorse Google Cloud , non è necessario che l'utente disponga di un account utente in Cloud Identity o Google Workspace. A meno che non sia limitato da criteri, puoi anche aggiungere l'utente esterno direttamente come membro ai rispettivi progetti, cartelle o organizzazione, a condizione che l'utente disponga di un'identità Google.

Mappare i domini DNS

Il DNS svolge un ruolo fondamentale sia per Microsoft Entra ID sia per Cloud Identity e Google Workspace. Il secondo fattore da esaminare quando pianifichi di federare Microsoft Entra ID e Google Cloud è come puoi condividere o mappare i domini DNS tra Microsoft Entra ID e Google Cloud.

Utilizzo dei domini DNS in Google Cloud

Accedi con Google, che Google Cloud utilizza per l'autenticazione, usa indirizzi email per identificare gli utenti. L'utilizzo di indirizzi email non solo garantisce che siano univoci a livello globale, ma consente anche a Google Cloud di inviare messaggi di notifica agli indirizzi.

Accedi con Google determina la directory o il provider di identità da utilizzare per autenticare un utente in base alla parte del dominio degli indirizzi email, che segue @. Per un indirizzo email che utilizza il dominio gmail.com, ad esempio, l'accesso con Google utilizza la directory degli utenti Gmail per l'autenticazione.

Quando ti registri a un account Google Workspace o Cloud Identity, crei una directory privata che Sign-In può utilizzare per l'autenticazione. Allo stesso modo in cui la directory Gmail è associata al dominio gmail.com, gli account Google Workspace e Cloud Identity devono essere associati a un dominio personalizzato. Vengono utilizzati tre tipi diversi di domini:

• Dominio principale: questo dominio identifica l'account Cloud Identity o Google Workspace e viene utilizzato come nome dell'organizzazione in Google Cloud. Quando ti registri a Cloud Identity o Google Workspace, devi specificare questo nome di dominio.
• Dominio secondario: insieme al dominio principale, puoi associare altri domini secondari a un account Cloud Identity o Google Workspace. Ogni utente nella directory è associato al dominio principale o a uno dei domini secondari. Due utenti, johndoe@example.com e johndoe@secondary.example.com, vengono considerati utenti separati se example.com è il dominio principale e secondary.example.com è un dominio secondario.
• Alias di dominio: un alias di dominio è un nome alternativo per un altro dominio. ovvero johndoe@example.com e johndoe@alias.example.com si riferiscono allo stesso utente se alias.example.com è configurato come dominio alias per example.com.

Tutti i domini devono soddisfare i seguenti requisiti:

• Devono essere nomi di dominio DNS globali validi. Durante la configurazione, potresti aver bisogno dell'accesso amministrativo alle rispettive zone DNS per verificare la proprietà del dominio.
• Un dominio, ad esempio example.com, può fare riferimento a una sola directory. Tuttavia, puoi utilizzare sottodomini diversi, ad esempio subdomain.example.com, per fare riferimento a directory diverse.
• I domini principali e secondari devono avere un record MX valido in modo che i messaggi inviati agli indirizzi email formati utilizzando questo nome di dominio possano essere recapitati correttamente.

Utilizzo dei domini DNS in Microsoft Entra ID

Il modo in cui Cloud Identity e Google Workspace utilizzano il DNS è simile a come Microsoft Entra ID si basa sul DNS per distinguere i tenant di Microsoft Entra ID e associare i nomi utente ai tenant. Tuttavia, tieni presente due differenze importanti:

1. Domini iniziali:quando crei un tenant Microsoft Entra ID, il tenant è associato a un dominio iniziale, che è un sottodominio di onmicrosoft.com. Questo dominio è diverso da qualsiasi nome di dominio personalizzato che potresti registrare in quanto non possiedi il dominio e non hai accesso amministrativo alla zona DNS corrispondente.

   Cloud Identity non ha un equivalente di un dominio iniziale e richiede invece che tu sia proprietario di tutti i domini che associ a un account Cloud Identity. Questo requisito significa che non puoi registrare un sottodominio onmicrosoft.com come dominio Cloud Identity.

2. Domini utilizzati negli identificatori utente: Microsoft Entra ID distingue tra indirizzi email MOERA (Microsoft Online Email Routing Addresses) e UPN. Entrambi seguono un formato RFC 822 (user@domain), ma hanno scopi diversi: mentre gli UPN vengono utilizzati per identificare gli utenti e nel modulo di accesso, solo i MOERA vengono utilizzati per la distribuzione delle email.

   Il suffisso di dominio utilizzato dai nomi UPN deve corrispondere a uno dei domini registrati del tuo tenant Microsoft Entra ID. Lo stesso requisito non si applica agli indirizzi email.

   Cloud Identity e Google Workspace non si basano sul concetto di UPN e utilizzano invece l'indirizzo email di un utente come identificatore. Di conseguenza, il dominio utilizzato dall'indirizzo email deve corrispondere a uno dei domini registrati dell'account Cloud Identity o Google Workspace.

Un tenant Microsoft Entra ID e un account Cloud Identity o Google Workspace possono utilizzare gli stessi domini DNS. Se non è possibile utilizzare gli stessi domini, puoi configurare il provisioning degli utenti e il Single Sign-On per sostituire i nomi di dominio.

Tenendo conto delle due differenze descritte sopra, devi basare la mappatura dei domini sul modo in cui prevedi di mappare gli utenti tra Microsoft Entra ID e Cloud Identity o Google Workspace.

Map users (Mappa gli utenti)

Il terzo fattore da considerare quando pianifichi di federare Microsoft Entra ID e Google Cloud è come mappare gli utenti tra Microsoft Entra ID e Cloud Identity o Google Workspace.

Per mappare correttamente gli utenti di Microsoft Entra ID agli utenti di Cloud Identity o Google Workspace sono necessarie due informazioni per ogni utente:

1. Un ID stabile e univoco che puoi utilizzare durante la sincronizzazione per monitorare quale utente di Microsoft Entra ID corrisponde a quale utente in Cloud Identity o Google Workspace.
2. Un indirizzo email per il quale la parte del dominio corrisponde a un dominio principale, secondario o alias di Cloud Identity. Poiché questo indirizzo email verrà utilizzato in tutto Google Cloud, deve essere leggibile.

Internamente, Microsoft Entra ID identifica gli utenti in base all'ObjectId, che è un ID univoco a livello globale generato in modo casuale. Sebbene questo ID sia stabile e soddisfi quindi il primo requisito, non ha significato per gli utenti e non segue il formato di un indirizzo email. Per mappare gli utenti, le uniche opzioni pratiche sono la mappatura per UPN o per indirizzo email.

Se l'utente inserisce un indirizzo email appartenente a un account Cloud Identity o Google Workspace configurato per utilizzare il Single Sign-On con Microsoft Entra ID, viene reindirizzato alla schermata di accesso di Microsoft Entra ID.

Microsoft Entra ID utilizza gli UPN, non gli indirizzi email, per identificare gli utenti, pertanto la schermata di accesso chiede all'utente di fornire un UPN.

Se il tenant Microsoft Entra ID è configurato per utilizzare AD FS per l'accesso, un altro reindirizzamento porta l'utente alla schermata di accesso AD FS. AD FS può identificare gli utenti in base al loro nome UPN di Active Directory o al loro nome di accesso precedente a Windows 2000 (domain\user).

Se l'indirizzo email utilizzato per Cloud Identity o Google Workspace, l'UPN utilizzato da Microsoft Entra ID e l'UPN utilizzato da Active Directory sono diversi, la sequenza di schermate di accesso può facilmente diventare fonte di confusione per gli utenti finali. Al contrario, se tutti e tre gli identificatori sono uguali a quelli degli screenshot di esempio (johndoe@example.com), gli utenti non sono esposti alle differenze tecniche tra UPN e indirizzi email, riducendo al minimo la potenziale confusione tra gli utenti.

Mappa di UPN

Dal punto di vista dell'esperienza utente, la mappatura dei nomi UPN di Microsoft Entra ID agli indirizzi email di Cloud Identity o Google Workspace potrebbe essere considerata l'opzione migliore. Un altro vantaggio dell'utilizzo dei nomi UPN è che Microsoft Entra ID garantisce l'unicità, in modo da evitare il rischio di conflitti di denominazione.

Tuttavia, per mappare i nomi principali utente (UPN) di Microsoft Entra ID agli indirizzi email di Cloud Identity, devi soddisfare i seguenti requisiti:

• I nomi UPN di Microsoft Entra ID devono essere indirizzi email validi in modo che tutte le email di notifica inviate da Google Cloud vengano recapitate correttamente alla casella di posta dell'utente. Se non è già così, potresti essere in grado di configurare indirizzi email alias per assicurarti che l'utente riceva queste email.
• I nomi UPN di tutti gli utenti pertinenti in Microsoft Entra ID devono utilizzare un dominio personalizzato come suffisso (user@custom-domain). I nomi UPN che utilizzano il dominio iniziale di Microsoft Entra ID (user@tenant.onmicrosoft.com) non possono essere mappati agli indirizzi email in Cloud Identity, perché il dominio iniziale non è di tua proprietà, ma di Microsoft.
• Tutti i domini personalizzati utilizzati da Microsoft Entra ID per gli UPN devono essere registrati anche in Cloud Identity. Questo requisito significa che devi avere accesso alle rispettive zone DNS per eseguire la convalida del dominio. Per evitare di sovrascrivere i record DNS TXT esistenti che potresti aver creato per verificare la proprietà del dominio in Microsoft Entra ID, puoi utilizzare un record CNAME per verificare la proprietà del dominio in Cloud Identity.

Mappare gli utenti in base all'indirizzo email

Se la mappatura degli UPN di Microsoft Entra ID agli indirizzi email di Cloud Identity o Google Workspace non è un'opzione, puoi mappare gli utenti in base all'indirizzo email.

Quando specifichi un indirizzo email in Active Directory, questo viene memorizzato nell'attributo mail dell'oggetto user corrispondente e Microsoft Entra ID Connect sincronizzerà il valore con l'attributo Mail in Microsoft Entra ID. Microsoft Entra ID rende l'attributo disponibile per il provisioning degli utenti in modo da poterlo mappare all'indirizzo email in Cloud Identity o cloudid_name_short.

Fondamentalmente, l'attributo Mail di Microsoft Entra ID non viene attualmente visualizzato nel portale Azure e può essere visualizzato e modificato solo tramite API o PowerShell. Sebbene l'interfaccia utente ti consenta di specificare un indirizzo email e un indirizzo email alternativo, nessuno di questi valori viene memorizzato nell'attributo Mail, pertanto non possono essere utilizzati per il provisioning in Cloud Identity o cloudid_name_short. Di conseguenza, mappare gli utenti di un indirizzo email è pratico solo quando crei e modifichi la maggior parte degli utenti in Active Directory, non in Microsoft Entra ID.

La mappatura degli utenti per indirizzo email richiede di soddisfare i seguenti requisiti aggiuntivi:

• Le assegnazioni email devono essere complete. A tutti gli utenti soggetti alla sincronizzazione deve essere assegnato un indirizzo email. Soprattutto quando gli utenti vengono sincronizzati da un'istanza di Active Directory on-premise, potrebbe non essere il caso perché mail è un attributo utente facoltativo in Active Directory. Gli utenti che non hanno un indirizzo email nell'attributo Mail di Microsoft Entra ID vengono ignorati automaticamente durante la sincronizzazione.
• Gli indirizzi email devono essere univoci nel tenant Microsoft Entra ID. Sebbene Active Directory non verifichi l'unicità durante la creazione dell'utente, Microsoft Entra ID Connect rileva le collisioni per impostazione predefinita, il che potrebbe causare l'esito negativo della sincronizzazione degli utenti interessati.
• I domini utilizzati dagli indirizzi email non devono essere registrati in Microsoft Entra ID, ma devono essere registrati in Cloud Identity o Google Workspace. Questo requisito implica che devi avere accesso alle rispettive zone DNS per eseguire la convalida del dominio ed esclude l'utilizzo di indirizzi email con domini che non possiedi (come gmail.com).

Mappare il ciclo di vita dell'utente

Dopo aver definito un mapping tra gli utenti di Microsoft Entra ID e gli utenti in Cloud Identity o Google Workspace, devi decidere quale insieme di utenti vuoi eseguire il provisioning. Consulta le nostre best practice per il mapping dei set di identità per indicazioni su come prendere questa decisione.

Se non vuoi eseguire il provisioning di tutti gli utenti del tenant Microsoft Entra ID, puoi attivare il provisioning per un sottoinsieme di utenti utilizzando assegnazioni utente o filtri di ambito.

La seguente tabella riassume il comportamento predefinito del provisioning di Microsoft Entra ID e mostra come l'attivazione o la disattivazione del provisioning per un utente controlla le azioni che Microsoft Entra ID eseguirà in Cloud Identity o Google Workspace.

Provisioning abilitato per l'utente Microsoft Entra ID	Stato dell'utente in Cloud Identity o Google Workspace	Azione eseguita in Microsoft Entra ID	Azione eseguita in Cloud Identity o Google Workspace
No	(non esiste)	Attiva il provisioning	Crea nuovo utente (*)
No	Esiste (attivo)	Attiva il provisioning	Aggiorna utente esistente
No	Esistente (sospeso)	Attiva il provisioning	Aggiorna utente esistente, mantieni sospensione
Sì	Esistente	Modifica utente	Aggiorna utente esistente
Sì	Esistente	Rinomina UPN/indirizzo email	Modificare l'indirizzo email principale e mantenere il precedente come alias
Sì	Esistente	Disattivare il provisioning	Sospendi utente
Sì	Esistente	Eliminare temporaneamente un utente	Sospendi utente

(*) Se esiste un account consumer con lo stesso indirizzo email, l'account consumer viene eliminato.

Gruppi di mappe

Il quarto fattore da esaminare quando prevedi di federare Microsoft Entra ID e Google Cloud è se sincronizzare i gruppi tra Microsoft Entra ID e Google Cloud e come mapparli.

In Google Cloud, i gruppi vengono comunemente utilizzati per gestire l'accesso in modo efficiente tra i progetti. Anziché assegnare singoli utenti ai ruoli IAM in ogni progetto, definisci un insieme di gruppi che modellano i ruoli comuni nella tua organizzazione. Poi assegni questi gruppi a un insieme di ruoli IAM. Modificando l'appartenenza ai gruppi, puoi controllare l'accesso degli utenti a un intero insieme di risorse.

La mappatura dei gruppi tra Microsoft Entra ID e Google Cloud è facoltativa. Una volta configurato il provisioning degli utenti, puoi creare e gestire i gruppi direttamente in Cloud Identity o Google Workspace, il che significa che Active Directory o Microsoft Entra ID rimangono il sistema centrale per la gestione delle identità, ma non per la gestione degli accessi. Google Cloud

Per mantenere Active Directory o Microsoft Entra ID come sistema centrale per la gestione delle identità e degli accessi, ti consigliamo di sincronizzare i gruppi da Microsoft Entra ID anziché gestirli in Cloud Identity o Google Workspace. Con questo approccio, puoi configurare IAM in modo da utilizzare le appartenenze ai gruppi in Active Directory o Microsoft Entra ID per controllare chi ha accesso alle risorse in Google Cloud.

Gruppi in Cloud Identity e Google Workspace

In Cloud Identity e Google Workspace esiste un solo tipo di gruppo. I gruppi in Cloud Identity e Google Workspace non sono limitati all'ambito dell'account Cloud Identity o Google Workspace in cui sono stati definiti. Possono invece includere utenti di diversi account Cloud Identity o Google Workspace, supportare i riferimenti e l'annidamento in altri account ed essere utilizzati in qualsiasi organizzazione. Google Cloud

Come per gli utenti, Cloud Identity e Google Workspace identificano i gruppi in base all'indirizzo email. L'indirizzo email non deve corrispondere a una casella di posta effettiva, ma deve utilizzare uno dei domini registrati per il rispettivo account Cloud Identity.

Quando lavori con i gruppi in IAM, spesso devi specificare i gruppi per indirizzo email anziché per nome. Pertanto, è meglio che i gruppi abbiano non solo un nome significativo, ma anche un indirizzo email significativo e riconoscibile.

Gruppi in Microsoft Entra ID

Microsoft Entra ID supporta più tipi di gruppi, ognuno dei quali è adatto a diversi casi d'uso. I gruppi sono limitati a un singolo tenant e identificati da un ID oggetto, che è un ID univoco globale generato in modo casuale. I gruppi possono essere nidificati e possono contenere utenti dello stesso tenant o utenti invitati da altri tenant utilizzando Azure B2B. Microsoft Entra ID supporta anche i gruppi dinamici, i cui membri vengono determinati automaticamente in base a una query.

Nell'ambito dell'integrazione di Microsoft Entra ID con Cloud Identity o Google Workspace, due proprietà dei gruppi sono di interesse primario: se un gruppo è abilitato alla posta e se è abilitato alla sicurezza:

• Un gruppo abilitato alla sicurezza può essere utilizzato per gestire l'accesso alle risorse in Microsoft Entra ID. Pertanto, qualsiasi gruppo abilitato alla sicurezza è potenzialmente pertinente nel contesto di Google Cloud.
• Un gruppo abilitato alla posta ha un indirizzo email, il che è importante perché Cloud Identity e Google Workspace richiedono che i gruppi siano identificati da un indirizzo email.

In Microsoft Entra ID, puoi creare gruppi di tipo Sicurezza o Office 365 (a volte chiamati gruppi unificati). Quando sincronizzi i gruppi da un Active Directory on-premise o quando utilizzi il tipo Office 365, puoi anche creare gruppi di tipo Elenco di distribuzione.

La seguente tabella riassume le differenze tra questi diversi tipi di gruppi in termini di abilitazione alla posta o alla sicurezza e la loro mappatura ai tipi di gruppi di Active Directory, presupponendo una configurazione predefinita di Microsoft Entra ID Connect:

Origine	Tipo di gruppo Active Directory	Tipo di gruppo Microsoft Entra ID	Abilitato alla posta	Con funzionalità di sicurezza
Microsoft Entra ID	-	Gruppo Office 365	Sempre	Facoltativo
Microsoft Entra ID	-	Gruppo di sicurezza	Facoltativo	Sempre
on-premise	Gruppo di sicurezza (con email)	Gruppo di sicurezza	Sì	Sì
on-premise	Gruppo di sicurezza (senza email)	Gruppo di sicurezza	No	Sì
on-premise	Lista di distribuzione (con email)	Lista di distribuzione	Sì	No
on-premise	Lista di distribuzione (senza email)	(ignorato da Microsoft Entra ID Connect)

A differenza degli utenti, Microsoft Entra ID richiede che gli indirizzi email assegnati ai gruppi utilizzino un dominio registrato come dominio personalizzato in Microsoft Entra ID. Questo requisito comporta il seguente comportamento predefinito:

• Se un gruppo in Active Directory utilizza un indirizzo email che utilizza un dominio registrato in precedenza in Microsoft Entra ID, l'indirizzo email viene gestito correttamente durante la sincronizzazione con Microsoft Entra ID.
• Se un gruppo in Active Directory utilizza un indirizzo email che non è stato registrato in Microsoft Entra ID, quest'ultimo genera automaticamente un nuovo indirizzo email durante la sincronizzazione. Questo indirizzo email utilizza il dominio predefinito del tenant. Se il tuo tenant utilizza il dominio iniziale come dominio predefinito, l'indirizzo email risultante avrà il formato [name]@[tenant].onmicrosoft.com.
• Se crei un gruppo Office 365 in Microsoft Entra ID, Microsoft Entra ID genera automaticamente anche un indirizzo email che utilizza il dominio predefinito del tenant.

Mappare le identità dei gruppi

La mappatura corretta dei gruppi Microsoft Entra ID ai gruppi Cloud Identity o Google Workspace richiede un identificatore comune e questo identificatore deve essere un indirizzo email. Sul lato Microsoft Entra ID, questo requisito ti lascia due opzioni:

• Puoi utilizzare l'indirizzo email di un gruppo in Microsoft Entra ID e mapparlo a un indirizzo email Cloud Identity o Google Workspace.
• Puoi derivare un indirizzo email dal nome del gruppo in Microsoft Entra ID e mappare l'indirizzo risultante a un indirizzo email in Cloud Identity o Google Workspace.

Mappa per indirizzo email

La mappatura dei gruppi per indirizzo email è la scelta più ovvia, ma richiede di soddisfare diversi requisiti:

• Tutti i gruppi soggetti alla sincronizzazione devono avere un indirizzo email. In pratica, puoi sincronizzare solo i gruppi abilitati alla posta. I gruppi senza indirizzo email vengono ignorati durante il provisioning.
• Gli indirizzi email devono essere univoci in tutto il tenant. Poiché Microsoft Entra ID non impone l'unicità, potresti dover implementare controlli o norme personalizzati.
• I domini utilizzati dagli indirizzi email devono essere registrati sia in Microsoft Entra ID che in Cloud Identity o Google Workspace. La sincronizzazione di tutti i gruppi con indirizzi email che utilizzano domini non registrati in Cloud Identity o Google Workspace, incluso il dominio tenant.onmicrosoft.com, non andrà a buon fine.

Se tutti i gruppi pertinenti soddisfano questi criteri, identifica i domini utilizzati da questi indirizzi email e assicurati che l'elenco dei domini DNS registrati in Cloud Identity o Google Workspace copra questi domini.

Mappa per nome

Soddisfare i criteri richiesti per mappare i gruppi in base all'indirizzo email può essere difficile, soprattutto se molti dei gruppi di sicurezza che intendi eseguire il provisioning in Cloud Identity o Google Workspace non sono abilitati alla posta. In questo caso, potrebbe essere meglio derivare automaticamente un indirizzo email dal nome visualizzato del gruppo.

Derivare un indirizzo email presenta due sfide:

1. Un indirizzo email derivato dal nome di un gruppo potrebbe entrare in conflitto con l'indirizzo email di un utente.
2. Microsoft Entra ID non impone l'unicità per i nomi dei gruppi. Se più gruppi nel tuo tenant Microsoft Entra ID condividono lo stesso nome, gli indirizzi email derivati da questo nome si scontreranno, causando la sincronizzazione corretta di un solo gruppo.

Puoi superare la prima sfida utilizzando un dominio per l'indirizzo email generato diverso da qualsiasi dominio utilizzato dagli utenti. Ad esempio, se tutti i tuoi utenti utilizzano indirizzi email con example.com come dominio, puoi utilizzare groups.example.com per tutti i gruppi. La registrazione di sottodomini in Cloud Identity o Google Workspace non richiede la verifica del dominio, quindi la zona DNS groups.example.com non deve nemmeno esistere.

Puoi superare la seconda sfida, i nomi dei gruppi duplicati, solo tecnicamente derivando l'indirizzo email del gruppo dall'ID oggetto. Poiché i nomi dei gruppi risultanti sono piuttosto criptici e difficili da gestire, è meglio identificare e rinominare i nomi dei gruppi duplicati in Microsoft Entra ID prima di configurare il provisioning in Cloud Identity o Google Workspace.

Mappare il ciclo di vita del gruppo

Dopo aver definito una mappatura tra i gruppi Microsoft Entra ID e i gruppi in Cloud Identity o Google Workspace, devi decidere quale insieme di gruppi vuoi eseguire il provisioning. Come per gli utenti, puoi attivare il provisioning per un sottoinsieme di gruppi utilizzando le assegnazioni di gruppo o i filtri di ambito.

La seguente tabella riassume il comportamento predefinito del provisioning di Microsoft Entra ID e mostra come l'attivazione o la disattivazione del provisioning per un gruppo controlla le azioni che Microsoft Entra ID eseguirà in Cloud Identity o Google Workspace.

Provisioning abilitato per il gruppo Microsoft Entra ID	Stato del gruppo in Cloud Identity o Google Workspace	Azione eseguita in Microsoft Entra ID	Azione eseguita in Cloud Identity o Google Workspace
No	(non esiste)	Attiva il provisioning	Crea nuovo gruppo
No	Esistente	Attiva il provisioning	Aggiungi un membro, mantieni tutti i membri esistenti
Sì	Esistente	Rinomina gruppo	Rinomina gruppo
Sì	Esistente	Modifica descrizione	Aggiorna la descrizione
Sì	Esistente	Aggiungi membro	Aggiungi un membro, mantieni tutti i membri esistenti
Sì	Esistente	Rimuovi membro	Rimuovi membro
Sì	Esistente	Disattivare il provisioning	Il gruppo è stato lasciato così com'è (inclusi i membri)
Sì	Esistente	Elimina gruppo	Il gruppo è stato lasciato così com'è (inclusi i membri)

Passaggi successivi

• Scopri le best practice per la pianificazione di account e organizzazioni e le best practice per la federazione Google Cloud con un provider di identità esterno.
• Scopri come configurare il provisioning e il Single Sign-On tra Microsoft Entra ID e Cloud Identity.
• Scopri di più sulle best practice per la gestione degli account super amministratore.