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

Last reviewed 2023-02-27 UTC

Questo articolo descrive come configurare Cloud Identity o Google Workspace per l'utilizzo di Microsoft Entra ID (in precedenza Azure AD) come IdP e origine delle identità.

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

Implementazione della 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ò aggiungere un sovraccarico di gestione non necessario quando tutti i dipendenti hanno già un account in Microsoft Entra ID. Facendo fede le identità utente tra Google Cloud e il tuo sistema di gestione delle identità esistente, puoi automatizzare la manutenzione delle identità Google e associare 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, sia disponibile anche in Google Cloud in modo che sia possibile farvi riferimento 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 modo, il che significa che le modifiche in Microsoft Entra ID vengono replicate in Google Cloud e non viceversa. Inoltre, il provisioning non include le password.

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

  • Esegue l'autenticazione stessa.
  • Utilizza l'autenticazione passthrough o la sincronizzazione dell'hash delle 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 evita di dover sincronizzare le password su Google Cloud, ma garantisce anche che vengano applicati tutti i criteri o i meccanismi di autenticazione a più fattori (MFA) applicabili che hai configurato in Microsoft Entra ID o AD FS.

Nota: questo articolo fa riferimento all'app della galleria Google Cloud/G Suite Connector by Microsoft disponibile nel 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 Microsoft Entra ID sono una struttura di primo livello. Sono considerati confini amministrativi e fungono da container 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 entità utente o UPN), che assumono il formato name@domain, dove domain è uno dei domini DNS associati al tenant corrispondente.

Un'azienda potrebbe gestire più tenant Microsoft Entra ID. Le ragioni comuni per la presenza di più tenant includono la distinzione tra diverse parti dell'organizzazione, la separazione delle risorse di produzione dalle risorse 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 organizations fungono da container 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 dai 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 il modo in cui può essere eseguita l'autenticazione.

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

Integrazione di 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 altrettanto bene in tutti gli scenari. Invece, il giusto approccio all'integrazione dei due sistemi e alla mappatura della struttura dipende da diversi fattori:

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

Nelle sezioni che seguono vengono esaminati ciascuno di questi fattori.

Google Cloud interagisce solo con Microsoft Entra ID, non con la tua Active Directory on-premise. Quindi il modo in cui hai mappato foreste e domini della tua Active Directory on-premise a Microsoft Entra ID è di minore entità.

Mappatura dei tenant Microsoft Entra ID

Singolo 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 rappresenta quindi la base per una singola 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 e quelli di produzione o per distinguere le diverse parti di un'organizzazione.

Sebbene sia possibile eseguire il provisioning di utenti e gruppi da più di un tenant Microsoft Entra ID a un singolo account Cloud Identity o Google Workspace, al momento non è possibile configurare il Single Sign-On in un modo che funzioni per gli utenti di più tenant Microsoft Entra ID. Se utilizzi più tenant Microsoft Entra ID, dovrai creare un account Cloud Identity o Google Workspace separato per ogni tenant e impostare una 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 una singola organizzazione, avere più organizzazioni non è spesso pratico. Tuttavia, puoi selezionare una delle organizzazioni e associarla agli altri account Cloud Identity o Google Workspace, creando in modo efficace 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. 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 ospite a 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, è necessario mappare gli utenti utilizzando un attributo diverso da 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 che provengono da un altro tenant Microsoft Entra ID è creare più account Cloud Identity o Google Workspace come descritto nella sezione precedente, ciascuno federato con un diverso tenant Microsoft Entra ID. Per maggiori informazioni, consulta Provisioning degli utenti e Single Sign-On di Microsoft Entra ID B2B

Concedere a un utente esterno l'accesso a determinate risorse di Google Cloud non è un prerequisito per la creazione di 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 dei rispettivi progetti, cartelle o organizzazione, a condizione che l'utente abbia un'identità Google.

Mappatura dei 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 si pianifica la federazione di Microsoft Entra ID e Google Cloud è la condivisione o la mappatura dei domini DNS tra Microsoft Entra ID e Google Cloud.

Utilizzo di 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 sono 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 il @. Ad esempio, nel caso di un indirizzo email che utilizza il dominio gmail.com, Accedi con Google utilizza la directory degli utenti di Gmail per l'autenticazione.

Quando ti registri per un account Google Workspace o Cloud Identity, crei una directory privata che Accedi può utilizzare per l'autenticazione. Allo stesso modo in cui la directory di 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: 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, [e-mail] e [e-mail], sono considerati utenti separati se example.com è il dominio principale e secondary.example.com è un dominio secondario.
• Dominio alias: un dominio alias è un nome alternativo di un altro dominio. In altre parole, [e-mail] e [e-mail] 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, potrebbe essere necessario l'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 principale e secondario devono avere un record MX valido in modo che i messaggi inviati agli indirizzi email creati utilizzando questo nome di dominio possano essere recapitati correttamente.

Utilizzo di 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. Tieni presente, però, che ci sono due differenze importanti:

1. Domini iniziali: quando crei un tenant Microsoft Entra ID, il tenant viene associato a un dominio iniziale, ovvero 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 disponi dell'accesso amministrativo alla rispettiva zona DNS.

   Cloud Identity non ha un equivalente di un dominio iniziale, pertanto richiede la proprietà 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 Address) e UPN. Entrambi sono conformi al formato RFC 822 (user@domain), ma hanno scopi diversi: laddove gli UPN vengono utilizzati per identificare gli utenti e sono utilizzati nel modulo di accesso, solo le MOERA vengono utilizzate per il recapito delle email.

   Il suffisso di dominio utilizzato dagli UPN deve corrispondere a uno dei domini registrati del 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, ma utilizzano 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.

Considerando le due differenze descritte sopra, dovresti basare la mappatura del tuo dominio su come prevedi di mappare gli utenti tra Microsoft Entra ID e Cloud Identity o Google Workspace.

Mappatura degli utenti

Il terzo fattore da considerare quando si pianifica la federazione di 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 in Cloud Identity o Google Workspace sono necessarie due informazioni per ogni utente:

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

Internamente, Microsoft Entra ID identifica gli utenti in base a ObjectId, ovvero 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 gli utenti e non segue il formato di un indirizzo email. Per mappare gli utenti, le uniche opzioni pratiche sono la mappatura tramite UPN o tramite 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, l'utente viene reindirizzato alla schermata di accesso di Microsoft Entra ID.

Microsoft Entra ID utilizza UPN, non indirizzi email, per identificare gli utenti, quindi 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 di AD FS. AD FS può identificare gli utenti in base al loro UPN di Active Directory o al nome di accesso pre-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 tutti diversi, la sequenza delle schermate di accesso può facilmente creare confusione per gli utenti finali. Al contrario, se tutti e tre gli identificatori sono uguali negli 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.

Mappatura di UPN

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

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

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

Mappare gli utenti per indirizzo email

Se la mappatura degli UPN di Microsoft Entra ID agli indirizzi email di Cloud Identity o Google Workspace non è disponibile, puoi mappare gli utenti per 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 l'attributo disponibile anche per il provisioning degli utenti in modo che tu possa mapparlo all'indirizzo email in Cloud Identity o cloudid_name_short.

Fondamentalmente, l'attributo Microsoft Entra ID Mail al momento non è mostrato nel portale Azure e può essere visualizzato e modificato solo tramite API o PowerShell. Sebbene l'interfaccia utente consenta di specificare un indirizzo email e un indirizzo email alternativo, nessuno di questi valori è archiviato nell'attributo Mail, pertanto non può essere utilizzato per il provisioning in Cloud Identity o cloudid_name_short. Di conseguenza, mappare gli utenti di un indirizzo email è pratico solo quando esegui la maggior parte della creazione e modifica degli utenti in Active Directory, non in Microsoft Entra ID.

La mappatura degli utenti in base all'indirizzo email richiede che siano soddisfatti i seguenti requisiti aggiuntivi:

• Le assegnazioni degli indirizzi email devono essere completate. A tutti gli utenti soggetti a sincronizzazione deve essere assegnato un indirizzo email. Soprattutto quando gli utenti vengono sincronizzati da una Active Directory on-premise, questo potrebbe non verificarsi perché mail è un attributo utente facoltativo in Active Directory. Gli utenti che non dispongono di un indirizzo email nell'attributo Microsoft Entra ID Mail vengono ignorati automaticamente durante la sincronizzazione.
• Gli indirizzi email devono essere univoci nel tenant Microsoft Entra ID. Sebbene Active Directory non verifichi l'unicità della creazione degli utenti, Microsoft Entra ID Connect rileva le collisioni per impostazione predefinita, il che potrebbe causare la mancata 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 indica che devi avere accesso alle rispettive zone DNS per poter eseguire la convalida del dominio ed esclude l'utilizzo di indirizzi email con domini che non sono di tua proprietà (come gmail.com).

Mappatura del ciclo di vita dell'utente

Dopo aver definito una mappatura tra gli utenti di Microsoft Entra ID e gli utenti in Cloud Identity o Google Workspace, devi decidere di quale insieme di utenti eseguire il provisioning. Per istruzioni su come prendere questa decisione, consulta le nostre best practice sulla mappatura dei set di identità.

Se non vuoi eseguire il provisioning di tutti gli utenti del tenant di Microsoft Entra ID, puoi abilitare 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 come l'attivazione o la disattivazione del provisioning per un utente controlla quali azioni verranno eseguite da Microsoft Entra ID in Cloud Identity o Google Workspace.

Provisioning abilitato per l'utente Microsoft Entra ID	Stato dell'utente in Cloud Identity/Google Workspace	Azione eseguita in Microsoft Entra ID	Azione eseguita in Cloud Identity/Google Workspace
No	(inesistente)	Abilita provisioning	Crea nuovo utente (*)
No	Esiste (attivo)	Abilita provisioning	Aggiorna utente esistente
No	Esiste (sospeso)	Abilita provisioning	Aggiorna utente esistente, mantieni sospeso
Sì	Esistente	Modifica utente	Aggiorna utente esistente
Sì	Esistente	Rinomina l'indirizzo email/UPN	Cambia l'indirizzo email principale, mantieni l'indirizzo precedente come alias
Sì	Esistente	Disabilita provisioning	L'utente ha lasciato così com'è
Sì	Esistente	Elimina temporaneamente utente	Sospendi utente
Sì	Esistente	Elimina utente definitivamente	Sospendi utente, aggiungi il prefisso del_ all'indirizzo email

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

Nota: se abiliti il provisioning per un utente e in seguito disattivi il provisioning, l'utente corrispondente in Cloud Identity o Google Workspace rimarrà attivo. Per revocare l'autorizzazione dell'utente ad accedere ai servizi Google, devi eliminare l'utente in Microsoft Entra ID o disattivarlo manualmente in Cloud Identity o Google Workspace.

Gruppi di mappatura

Il quarto fattore da considerare quando si pianifica la federazione di 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 come un modo per gestire in modo efficiente l'accesso tra progetti. Anziché assegnare singoli utenti ai ruoli IAM in ogni progetto, puoi definire un insieme di gruppi che modellano i ruoli comuni nella tua organizzazione. Successivamente, assegnerai 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. Ciò significa che Active Directory o Microsoft Entra ID rimangono il sistema centrale per la gestione delle identità, ma non per la gestione degli accessi di 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 poter 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 account Cloud Identity o Google Workspace diversi, supporto a cui viene fatto riferimento e nidificato in altri account e possono essere utilizzati in qualsiasi organizzazione Google Cloud.

Come per gli utenti, Cloud Identity e Google Workspace identificano i gruppi per 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 tramite l'indirizzo email anziché per nome. Per questo motivo è preferibile che i gruppi abbiano non solo un nome significativo, ma 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 hanno come ambito un singolo tenant e identificati da un ID oggetto, ovvero un ID univoco a livello globale generato in modo casuale. I gruppi possono essere nidificati e possono contenere utenti dello stesso tenant o utenti 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.

Nel contesto 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 e se è abilitato per la sicurezza:

• Un gruppo abilitato per la sicurezza può essere utilizzato per gestire l'accesso alle risorse in Microsoft Entra ID. Qualsiasi gruppo abilitato per la sicurezza è quindi potenzialmente pertinente nel contesto di Google Cloud.
• Un gruppo abilitato per la posta ha un indirizzo email, il che è pertinente perché Cloud Identity e Google Workspace richiedono l'identificazione dei gruppi tramite un indirizzo email.

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

La seguente tabella riassume le differenze tra questi diversi tipi di gruppi relativi all'abilitazione per la posta o per la sicurezza e la relativa mappatura ai tipi di gruppi di Active Directory, assumendo una configurazione Microsoft Entra ID Connect predefinita:

Origine	Tipo di gruppo Active Directory	Tipo di gruppo ID Microsoft Entra	Abilitato per la posta	Sicurezza abilitata
ID Microsoft Entra	-	Gruppo Office 365	Sempre	Facoltativo
ID Microsoft Entra	-	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)	Elenco 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 include 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 tenant utilizza il dominio iniziale come dominio predefinito, l'indirizzo email risultante sarà [name]@[tenant].onmicrosoft.com.
• Se crei un gruppo Office 365 in Microsoft Entra ID, anche Microsoft Entra ID genera automaticamente un indirizzo email che utilizza il dominio predefinito del tenant.

Mappatura delle identità dei gruppi

La mappatura dei gruppi Microsoft Entra ID a gruppi di Cloud Identity o Google Workspace richiede un identificatore comune, che deve essere un indirizzo email. Per quanto riguarda Microsoft Entra ID, questo requisito ti lascia con due opzioni:

• Puoi utilizzare l'indirizzo email di un gruppo in Microsoft Entra ID e mapparlo a un indirizzo email di 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.

Mappatura per indirizzo email

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

• Tutti i gruppi soggetti a sincronizzazione devono avere un indirizzo email. In pratica, ciò significa che puoi sincronizzare solo i gruppi abilitati alla posta. I gruppi che non hanno un indirizzo email vengono ignorati durante il provisioning.
• Gli indirizzi email devono essere univoci in tutto il tenant. Poiché Microsoft Entra ID non impone l'univocità, potrebbe essere necessario implementare controlli o criteri personalizzati.
• I domini utilizzati dagli indirizzi email devono essere registrati sia in Microsoft Entra ID sia in Cloud Identity/Google Workspace. I gruppi con indirizzi email che utilizzano domini non registrati in Cloud Identity/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 copra questi domini.

Mappatura per nome

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

Il recupero 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 applica l'univocità per i nomi dei gruppi. Se più gruppi nel tenant Microsoft Entra ID condividono lo stesso nome, gli indirizzi email derivati da questo nome entreranno in conflitto causando la corretta sincronizzazione di un solo gruppo.

Puoi superare la prima sfida utilizzando un dominio per l'indirizzo email generato che sia diverso da qualsiasi altro 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 non deve nemmeno esistere la zona DNS groups.example.com.

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

Mappare il ciclo di vita di un gruppo

Dopo aver definito una mappatura tra gruppi e gruppi Microsoft Entra ID in Cloud Identity o Google Workspace, devi decidere di quale insieme di gruppi 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 tabella seguente riassume il comportamento predefinito del provisioning di Microsoft Entra ID e mostra come l'attivazione o la disattivazione del provisioning per un gruppo controlla quali azioni Microsoft Entra ID eseguirà in Cloud Identity o Google Workspace.

Provisioning abilitato per il gruppo Microsoft Entra ID	Stato del gruppo in Cloud Identity/Google Workspace	Azione eseguita in Microsoft Entra ID	Azione eseguita in Cloud Identity/Google Workspace
No	(inesistente)	Abilita provisioning	Crea nuovo gruppo
No	Esistente	Abilita provisioning	Aggiungi membro, mantieni tutti i membri esistenti
Sì	Esistente	Rinomina gruppo	Rinomina gruppo
Sì	Esistente	Modifica descrizione	Aggiorna la descrizione
Sì	Esistente	Aggiungi membro	Aggiungi membro, mantieni tutti i membri esistenti
Sì	Esistente	Rimuovi membro	Rimuovi membro
Sì	Esistente	Disabilita provisioning	Gruppo lasciato così com'è (inclusi i membri)
Sì	Esistente	Elimina gruppo	Gruppo lasciato così com'è (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. Allo stesso modo, se abiliti il provisioning per un gruppo e in seguito disattivi il provisioning, il gruppo in Cloud Identity o Google Workspace rimane attivo. Questo comportamento può portare gli utenti a conservare inavvertitamente i diritti di accesso in Google Cloud. Per evitare che ciò accada, rimuovi prima tutti i membri da un gruppo, attendi che le modifiche vengano propagate, quindi elimina il gruppo in Microsoft Entra ID o disattiva il provisioning per il gruppo in Microsoft Entra ID.

Passaggi successivi

• Leggi 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.