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

Last reviewed 2024-06-26 UTC

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

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

Implementare la federazione

Google Cloud utilizza le identità Google per l'autenticazione e la gestione degli accessi. La gestione manuale delle identità Google per ogni dipendente può comportare un sovraccarico amministrativo non necessario se tutti i dipendenti hanno già un account in Microsoft Entra ID. Se federate le identità utente tra Google Cloud e il vostro sistema di gestione delle identità esistente, potete automatizzare la manutenzione delle identità Google e associarne il 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 componenti:

• 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 venga reso disponibile anche in Google Cloud in modo da potervi fare riferimento in Google Cloud anche prima che l'utente associato abbia eseguito l'accesso per la primeira volta. Questo processo garantisce inoltre che le eliminazioni degli utenti vengano propagate.

  Il provisioning funziona in un'unica direzione, il che significa che le modifiche apportate 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 Security Assertion Markup Language (SAML). A seconda della configurazione di Microsoft Entra ID, Microsoft Entra ID potrebbe eseguire una delle seguenti operazioni:

  • Eseguire l'autenticazione stessa.
  • Utilizza l'autenticazione passthrough 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 non devi sincronizzare le password con Google Cloud, ma garantisci anche l'applicazione di eventuali criteri o meccanismi di autenticazione a più fattori (MFA) che hai configurato in Microsoft Entra ID o AD FS.

Nota: questo documento fa riferimento all'app della galleria Google Cloud/G Suite Connector by Microsoft del marketplace Microsoft Azure. Questa app è un prodotto Microsoft e non è gestita o supportata da Google.

Struttura logica di Microsoft Entra ID

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

A ogni tenant Microsoft Entra ID è associato almeno un dominio DNS. Questo dominio DNS è riportato nei nomi utente (chiamati anche Nomi principali utente o UPN), che hanno la forma 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 il distinguere tra parti diverse dell'organizzazione, separare le risorse di produzione dalle risorse di sviluppo e test e utilizzare 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, ad eccezione degli account di servizio, le organizzazioni non vengono utilizzate per gestire utenti e gruppi, il che le rende diverse dagli tenant di 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 la modalità di autenticazione.

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

Integrare Microsoft Entra ID e Google Cloud

Nonostante alcune somiglianze tra la struttura logica di Microsoft Entra ID e Google Cloud, nessuna singola mappatura tra le due strutture funziona allo stesso modo 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 non è un problema.

Mappa i tenant Microsoft Entra ID

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

• Single-tenant
• Più tenant
• Utenti esterni

Single-tenant

Se utilizzi un solo tenant Microsoft Entra ID, puoi mapparlo a un singolo account Cloud Identity o Google Workspace e configurare la federazione tra i due. Questo account Cloud Identity o Google Workspace costituisce la base di un'unica organizzazione Google Cloud che puoi utilizzare per gestire tutte le risorse Google Cloud.

Più tenant

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

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

In genere, un approccio migliore per l'integrazione con più tenant Microsoft Entra ID è creare un account Cloud Identity o Google Workspace distinto 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 con gli altri account Cloud Identity o Google Workspace, creando in pratica un'organizzazione federata con più foreste Active Directory. Le altre organizzazioni rimangono inutilizzate.

Utenti esterni

Con Microsoft Entra ID B2B, puoi invitare utenti esterni come ospiti nel tuo tenant di Microsoft Entra ID. Viene creato un nuovo utente per ogni ospite 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 ospiti 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 principale, l'utente corrispondente in Cloud Identity o Google Workspace potrebbe rimanere attivo e l'accesso alle risorse Google Cloud potrebbe non essere revocato correttamente.

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

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

Mappare i domini DNS

Il DNS svolge un ruolo fondamentale sia per Microsoft Entra ID che per Cloud Identity e Google Workspace. Il secondo fattore da considerare 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, su cui si basa Google Cloud per l'autenticazione, utilizza gli 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 di dominio degli indirizzi email, che segue il @. Per un indirizzo email che utilizza il dominio gmail.com, ad esempio, Accedi con Google utilizza la directory degli utenti di Gmail per l'autenticazione.

Quando ti registri a un account Google Workspace o Cloud Identity, crei una directory privata che Accesso puó utilizzare per l'autenticazione. Come 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 diversi tipi 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: oltre 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, [e-mail] e [e-mail], sono considerati utenti distinti se example.com è il dominio principale e secondary.example.com è un dominio secondario.
• Alias dominio: un alias di dominio è un nome alternativo per un altro dominio. In altre parole, [e-mail] e [e-mail] fanno riferimento allo stesso utente se alias.example.com è configurato come dominio di alias per example.com.

Tutti i domini devono soddisfare i seguenti requisiti:

• Devono essere nomi di dominio DNS globali validi. Durante la configurazione, potresti dover avere 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 che utilizzano 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 al modo in cui 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 sostanziali:

1. Domini iniziali:quando crei un tenant Microsoft Entra ID, questo viene associato a un dominio iniziale, che è un sottodominio di onmicrosoft.com. Questo dominio è diverso da qualsiasi nome di dominio personalizzato che potresti registrare perché non ne sei il proprietario e non hai accesso amministrativo alla rispettiva zona DNS.

   Cloud Identity non ha un equivalente di un dominio iniziale e richiede invece di possedere tutti i domini associati 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: se gli UPN vengono utilizzati per identificare gli utenti e vengono utilizzati nel formulario di accesso, per l'invio delle email vengono utilizzati solo i MOERA.

   Il suffisso del dominio utilizzato dagli 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 del dominio su come 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 ciascun utente:

1. Un ID univoco e stabile 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 cui la parte del dominio corrisponde a un dominio principale, secondario o alias Cloud Identity. Poiché questo indirizzo email verrà utilizzato in tutto Google Cloud, deve essere leggibile.

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

Se l'utente inserisce un indirizzo email che appartiene a un account Cloud Identity o Google Workspace configurato per l'utilizzo del 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 invita l'utente a fornire un UPN.

Se il tenant di Microsoft Entra ID è configurato per utilizzare AD FS per l'accesso, un altro reindirizzamento indirizza l'utente alla schermata di accesso di AD FS. AD FS può identificare gli utenti tramite il loro UPN di Active Directory o il 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 creare confusione per gli utenti finali. Al contrario, se tutti e tre gli identificatori sono uguali a quelli degli screenshot di esempio ([e-mail]), 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 degli 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 degli UPN è che Microsoft Entra ID garantisce l'unicità, in modo da evitare il rischio di conflitti di nomi.

Tuttavia, per mappare gli UPN di Microsoft Entra ID agli indirizzi email di Cloud Identity, devi soddisfare i seguenti requisiti:

• I 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 nella posta in arrivo dell'utente. Se non è già così, potresti essere in grado di configurare indirizzi email alias per assicurarti che l'utente riceva queste email.
• I DN degli utenti pertinenti in Microsoft Entra ID devono utilizzare un dominio personalizzato come suffisso (user@custom-domain). I DN che utilizzano il dominio iniziale di Microsoft Entra ID ([e-mail]) 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 eseguire l'override dei 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.

Mappa 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 archiviato nell'attributo mail del rispettivo oggetto user e Microsoft Entra ID Connect sincronizzerà il valore con l'attributo Mail in Microsoft Entra ID. Microsoft Entra ID rende inoltre disponibile l'attributo per il provisioning degli utenti, in modo da poterlo mappare all'indirizzo email in Cloud Identity o cloudid_name_short.

È fondamentale sottolineare che l'attributo Mail di Microsoft Entra ID non è attualmente visualizzato nel portale di Azure e può essere visualizzato e modificato solo tramite API o PowerShell. Anche se l'interfaccia utente consente 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, la mappatura degli utenti di un indirizzo email è praticabile solo se svolgi la maggior parte delle operazioni di creazione e modifica degli utenti in Active Directory, non in Microsoft Entra ID.

La mappatura degli utenti in base all'indirizzo email richiede di soddisfare i seguenti requisiti aggiuntivi:

• I compiti via email devono essere completi. A tutti gli utenti soggetti alla sincronizzazione deve essere assegnato un indirizzo email. Soprattutto quando gli utenti vengono sincronizzati da un Active Directory on-premise, questo potrebbe non essere il caso perché mail è un attributo utente facoltativo in Active Directory. Gli utenti che non dispongono di un indirizzo email nell'attributo Mail di Microsoft Entra ID vengono ignorati silenziosamente durante la sincronizzazione.
• Gli indirizzi email devono essere univoci nel tenant di Microsoft Entra ID. Anche se Active Directory non controlla l'unicità al momento della creazione degli utenti, Microsoft Entra ID Connect rileva le collisioni per impostazione predefinita, il che potrebbe causare l'interruzione 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 significa 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 sono di tua proprietà (come gmail.com).

Mappa il ciclo di vita dell'utente

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

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

La tabella seguente riassume il comportamento predefinito del provisioning di Microsoft Entra ID e mostra in che modo 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)	Attivare il provisioning	Crea nuovo utente (*)
No	Esiste (attivo)	Attivare il provisioning	Aggiornare un utente esistente
No	Esistente (sospeso)	Attivare il provisioning	Aggiorna utente esistente, mantieni la sospensione
Sì	Esistente	Modifica utente	Aggiornare un utente esistente
Sì	Esistente	Rinomina UPN/indirizzo email	Modificare l'indirizzo email principale, mantenere l'indirizzo 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, questo viene espulso.

Gruppi di mappe

Il quarto fattore da considerare 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 spesso 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 assegna questi gruppi a un insieme di ruoli IAM. Modificando l'appartenenza ai gruppi, puoi controllare l'accesso degli utenti a un insieme completo di risorse.

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

Per mantenere Active Directory o Microsoft Entra ID come sistema centrale per la gestione delle identità e l'accesso, 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 iscrizioni 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 essere nidificati in altri account e possono essere utilizzati in qualsiasi organizzazione Google Cloud.

Come per gli utenti, Cloud Identity e Google Workspace identificano i gruppi tramite 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 specificarli 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, ciascuno adatto a casi d'uso diversi. I gruppi sono limitati a un singolo tenant e identificati da un ID oggetto, ovvero un ID univoco globale generato in modo casuale. I gruppi possono essere nidificati e possono contenere utenti dello stesso tenant o invitati da altri tenant che utilizzano 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 principale: se un gruppo è abilitato per la posta ed è abilitato per la 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, che è pertinente perché Cloud Identity e Google Workspace richiedono che i gruppi vengano 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 di Office 365, puoi anche creare gruppi di tipo elenco di distribuzione.

La seguente tabella riassume le differenze tra questi diversi tipi di gruppi per quanto riguarda l'attivazione della posta o della sicurezza e la loro mappatura ai tipi di gruppi Active Directory, supponendo una configurazione predefinita di Microsoft Entra ID Connect:

Origine	Tipo di gruppo Active Directory	Tipo di gruppo Microsoft Entra ID	Con posta elettronica	Con funzionalità di sicurezza abilitate
Microsoft Entra ID	-	Gruppo Office 365	Sempre	Facoltativo
Microsoft Entra ID	-	Gruppo di sicurezza	Facoltativo	Sempre
on-premise	Gruppo di sicurezza (con indirizzo email)	Gruppo di sicurezza	Sì	Sì
on-premise	Gruppo di sicurezza (senza email)	Gruppo di sicurezza	No	Sì
on-premise	Elenco di distribuzione (con email)	Elenco di distribuzione	Sì	No
on-premise	Elenco 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 che è stato precedentemente registrato in Microsoft Entra ID, l'indirizzo email viene mantenuto 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, Microsoft Entra ID 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à la forma[name]@[tenant].onmicrosoft.com.
• Se crei un gruppo Office 365 in Microsoft Entra ID, quest'ultimo genera automaticamente anche un indirizzo email che utilizza il dominio predefinito del tenant.

Mappa le identità dei gruppi

La mappatura dei gruppi Microsoft Entra ID ai gruppi Cloud Identity o Google Workspace richiede un identificatore comune, che deve essere un indirizzo email. Per quanto riguarda Microsoft Entra ID, questo requisito ti offre 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 ricavare 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 in base all'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, significa che puoi sincronizzare solo i gruppi abilitati per la posta. I gruppi che non dispongono di un indirizzo email vengono ignorati durante il provisioning.
• Gli indirizzi email devono essere univoci nel tenant. Poiché Microsoft Entra ID non impone l'unicità, potresti dover implementare controlli o criteri personalizzati.
• I domini utilizzati dagli indirizzi email devono essere registrati sia in Microsoft Entra ID sia in Cloud Identity o Google Workspace. I gruppi con indirizzi email che utilizzano domini non registrati in Cloud Identity o Google Workspace, incluso il dominio tenant.onmicrosoft.com, non verranno sincronizzati.

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 li includa.

Mappa per nome

Soddisfare i criteri richiesti per mappare i gruppi in base all'indirizzo email può essere complicato, 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 ricavare automaticamente un indirizzo email dal nome visualizzato del gruppo.

L'ottenimento di un indirizzo email presenta due sfide:

1. Un indirizzo email derivato dal nome di un gruppo potrebbe entrare in conflitto con un indirizzo email di un utente.
2. Microsoft Entra ID non impone l'unicità dei nomi dei gruppi. Se più gruppi nel tuo tenant Microsoft Entra ID condividono lo stesso nome, gli indirizzi email derivati da questo nome entreranno in conflitto, causando la sincronizzazione 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 example.com per tutti i gruppi.groups.example.com La registrazione dei sottodomini in Cloud Identity o Google Workspace non richiede la verifica del dominio, pertanto la zona DNS groups.example.com non deve nemmeno esistere.

Puoi superare la seconda sfida, i nomi dei gruppi duplicati, solo tecnicamente traendo l'indirizzo email del gruppo dall'ID oggetto. Poiché i nomi dei gruppi risultanti sono piuttosto criptico 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 di 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 ai gruppi o i filtri di ambito.

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

Il provisioning è stato attivato 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)	Attivare il provisioning	Crea nuovo gruppo
No	Esistente	Attivare 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	Gruppo lasciato invariato (inclusi i membri)
Sì	Esistente	Elimina gruppo	Gruppo lasciato invariato (inclusi i membri)

Nota: quando elimini un gruppo in Microsoft Entra ID, Microsoft Entra ID non propaga l'eliminazione a Cloud Identity o Google Workspace. Analogamente, se attivi il provisioning per un gruppo e in un secondo momento lo disattivi, il gruppo in Cloud Identity o Google Workspace rimane attivo. Questo comportamento può comportare il mantenimento inavvertito dei diritti di accesso in Google Cloud da parte degli utenti. Per evitare che ciò accada, rimuovi prima tutti i membri da un gruppo, attendi che le modifiche vengano propagate e solo dopo elimina il gruppo in Microsoft Entra ID o disattiva il provisioning per il gruppo in Microsoft Entra ID.

Passaggi successivi

• Consulta le best practice per la pianificazione di account e organizzazioni e le best practice per la federazione di 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 le best practice per la gestione degli account super amministratore.