Google Cloud federato 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 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ò comportare un sovraccarico amministrativo non necessario se tutti i dipendenti hanno già un account in Microsoft Entra ID. Di federare le identità degli utenti tra Google Cloud e la tua identità esistente di Google, puoi automatizzare la manutenzione delle identità Google 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 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 Microsoft Entra ID mediante SAML (Security Assertion Markup Language) protocollo. A seconda della configurazione di Microsoft Entra ID, Microsoft Entra ID potrebbe eseguire una delle seguenti operazioni: le seguenti:

  • Eseguire l'autenticazione stessa.
  • Utilizzare l'autenticazione passthrough o la sincronizzazione di hash delle password.
  • Delegare l'autenticazione a un server AD FS on-premise.

Avere un delegato in Cloud Identity o Google Workspace in Microsoft Entra ID non solo evita di dover sincronizzare le password Google Cloud, garantisce inoltre che tutti i criteri applicabili o le API i meccanismi di autenticazione (MFA) configurati in Microsoft Entra ID o AD FS in modo forzato.

Nota: questo documento fa riferimento alle App della galleria Google Cloud/G Suite Connector di Microsoft disponibile in Microsoft Azure Marketplace. Questa app è un prodotto Microsoft e non è gestita né supportata da Google.

Struttura logica di Microsoft Entra ID

Quando utilizzi Azure, usi uno o più tenant Microsoft Entra ID (chiamati anche come 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 DNS dominio si riflette nei nomi utente (chiamati anche Nomi entità utente o UPN), che assumono il formato name@domain, dove domain è uno dei domini DNS associati il tenant corrispondente.

Un'azienda potrebbe mantenere più tenant di Microsoft Entra ID. Motivi comuni per avere più tenant include la distinzione tra diverse parti dell'organizzazione, separando le risorse di produzione da quelle di sviluppo e test e l'utilizzo di tenant separati per integrare più foreste da un l'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 dai tenant di Microsoft Entra ID.

Per la gestione di utenti e gruppi, Google Cloud si basa su Cloud Identity o Google Workspace. R Account Cloud Identity o Google Workspace funge da directory privata per utenti e gruppi. Come amministratore dell'account, puoi controllare il ciclo di vita e la configurazione degli utenti e gruppi e definiranno le modalità di esecuzione dell'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 L'organizzazione Google Cloud è autorizzata a fare riferimento a utenti e gruppi da e 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. Il giusto approccio per integrare i due aspetti sistemi e la mappatura della struttura dipende da più 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 prendono in esame ciascuno di questi fattori.

Google Cloud interagisce solo con Microsoft Entra ID, non con Active Directory on-premise. Quindi, il modo in cui avete mappato le foreste e i domini del vostro da Active Directory on-premise a Microsoft Entra ID.

Mappa i tenant di Microsoft Entra ID

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

• Singolo 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 tra test e ambienti di produzione o per distinguere le diverse parti dell'organizzazione.

È possibile mappare più tenant di 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 di questo tipo indebolire l'isolamento tra i tenant di Microsoft Entra ID: se concedi più autorizzazioni tenant Microsoft Entra ID per creare e modificare utenti in a un singolo account Cloud Identity o Google Workspace, i tenant possono interferire e manomettere le modifiche degli 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 configurerai la federazione tra ogni coppia.

In Google Cloud viene creata un'organizzazione separata per ogni un account Cloud Identity o Google Workspace. Poiché Google Cloud consente di organizzare le risorse progetti e cartelle all'interno di una singola organizzazione, spesso avere più organizzazioni non è attuabile. Tuttavia, puoi selezionare una delle organizzazioni e associarlo con gli altri account Cloud Identity o Google Workspace, creando in modo efficace un'organizzazione federata con più Foreste directory. Le altre organizzazioni rimangono inutilizzate.

Utenti esterni

Con Microsoft Entra ID B2B puoi invitare utenti esterni come ospiti del tenant di Microsoft Entra ID. Un nuovo utente viene creato per ogni ospite e Microsoft Entra ID assegna automaticamente un UPN a questi ospiti. L'UPN generato da Microsoft Entra ID utilizza un prefisso derivato dal 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 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 Google Workspace. Pertanto, è necessario mappa 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 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, 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 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.

Mappa 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 sono univoci a livello globale, ma consentono anche a Google Cloud di inviare i messaggi 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, segue @. Per un indirizzo email che utilizza il dominio gmail.com, per Ad esempio, Accedi con Google utilizza la directory degli utenti di Gmail per autenticazione.

Quando ti registri a un account Google Workspace o Cloud Identity, crei una directory privata che Accesso puó utilizzare per l'autenticazione. Nello stesso modo in cui la directory di Gmail associati al dominio gmail.com, a Google Workspace e Gli account 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 Google Workspace ed è 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. Ciascuna dell'utente nella directory è associato al dominio principale o 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 nel dominio secondario.
• Dominio alias: un dominio alias è un nome alternativo di 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, devi disporre dell'accesso amministrativo alle rispettive zone DNS per eseguire 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 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. Tuttavia, tieni presente due differenze sostanziali:

1. Domini iniziali: quando crei un tenant Microsoft Entra ID, quest'ultimo viene associata a un dominio iniziale, che è un sottodominio onmicrosoft.com. Questo dominio è diverso da qualsiasi nome dominio personalizzato che potreste registrare perché non siete i proprietari del dominio e non disporre dell'accesso amministrativo alla rispettiva zona DNS.

   Cloud Identity non dispone di un equivalente di un dominio iniziale e richiede invece 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 Addresses) e UPN. Entrambi seguono un formato RFC 822 (user@domain), ma pubblicano annunci diversi Finalità: dove gli UPN vengono utilizzati per identificare gli utenti e sono utilizzati solo i moduli MOERA vengono utilizzati per consegnare le email.

   Il suffisso di dominio utilizzato dagli UPN deve corrispondere a uno dei domini del tenant Microsoft Entra ID; lo stesso requisito non si applica .

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

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

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.

Mappatura degli utenti Microsoft Entra ID agli utenti in Cloud Identity oppure Google Workspace richiede due informazioni per ogni 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 il quale la parte del dominio corrisponde a un Dominio principale, secondario o alias di Cloud Identity. Poiché questo verrà utilizzato in tutto Google Cloud, l'indirizzo dovrebbe siano leggibili da una persona.

Internamente, Microsoft Entra ID identifica gli utenti in base a ObjectId, un sistema di gestione univoco a livello globale generato. Sebbene questo ID sia stabile e quindi soddisfi i requisiti primo requisito, è privo di significato per gli esseri umani e non segue il formato un indirizzo email. Per mappare gli utenti, le uniche opzioni pratiche sono la mappatura tramite UPN o tramite l'indirizzo email.

Se l'utente inserisce un indirizzo email che appartiene a Cloud Identity o Account Google Workspace configurato per l'utilizzo del servizio Single Sign-On con Microsoft Entra ID, l'utente viene quindi reindirizzato alla schermata di accesso di Microsoft Entra ID.

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

Se il tenant Microsoft Entra ID è configurato in modo da utilizzare AD FS per l'accesso, l'utente viene indirizzato alla schermata di accesso ad 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 Gli indirizzi email di Cloud Identity o Google Workspace potrebbero essere considerata l'opzione migliore. Un altro vantaggio di affidarsi agli UPN è che Microsoft Entra ID garantisce l'univocità per 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:

• I UPN di Microsoft Entra ID devono essere indirizzi email validi in modo che 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 garantire che l'utente riceva tali 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 l'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 per indirizzo email

Se si mappano gli UPN Microsoft Entra ID a Cloud Identity o Google Workspace gli indirizzi email non sono disponibili, 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.

Fondamentalmente, l'attributo Microsoft Entra ID Mail attualmente non viene mostrato in Azure e possono essere visualizzati e modificati solo tramite API o PowerShell. Sebbene l'interfaccia utente consente di specificare un indirizzo email e un indirizzo alternativo , nessuno di questi valori è memorizzato nell'attributo Mail, quindi non possono essere utilizzate per il provisioning su 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.

Per mappare gli utenti in base all'indirizzo email, devi soddisfare i seguenti requisiti aggiuntivi requisiti:

• 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 privi di un indirizzo email nell'attributo Microsoft Entra ID Mail ignorati automaticamente 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 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 Microsoft Entra ID e gli utenti in in Cloud Identity o Google Workspace, devi decidere quale l'insieme di utenti di cui 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 tenant Microsoft Entra ID, puoi abilitare il provisioning per un sottoinsieme di utenti assegnazioni utente o i filtri dell'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	Esiste (sospeso)	Abilita provisioning	Aggiorna utente esistente, mantieni la sospensione
Sì	Esistente	Modifica utente	Aggiorna utente esistente
Sì	Esistente	Rinomina indirizzo UPN/email	Cambia l'indirizzo email principale, mantieni l'indirizzo precedente come alias
Sì	Esistente	Disattivare il provisioning	Utente lasciato così com'è
Sì	Esistente	Eliminare temporaneamente un utente	Sospendi utente
Sì	Esistente	Eliminare definitivamente un utente	Sospendi utente, aggiungi il prefisso del_ all'indirizzo email

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

Nota: se attivi il provisioning per un utente e in un secondo momento lo disattivi, l'utente corrispondente in Cloud Identity o Google Workspace rimane attivo. Revocare l'autorizzazione di accesso dell'utente a Google devi eliminare l'utente in Microsoft Entra ID o disattivarlo manualmente l'utente in Cloud Identity o Google Workspace.

Gruppi di mappe

Il quarto fattore da considerare quando si pianifica 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, gruppi sono comunemente utilizzati per gestire l'accesso in modo efficiente tra 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.

mantenere Active Directory o Microsoft Entra ID come sistema centrale per l'identità. e alla gestione degli accessi, ti consigliamo di sincronizzare i gruppi Microsoft Entra ID anziché la gestione 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, c'è 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 necessariamente corrispondere a una casella postale 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. Quindi è meglio che i gruppi non debbano solo un nome significativo, ma un indirizzo email significativo e riconoscibile.

Gruppi in Microsoft Entra ID

Microsoft Entra ID supporta più tipi di gruppi, ognuna adatta a diversi casi d'uso. 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 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 principale: se un gruppo è abilitato alla posta ed è 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 mail-enabled 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). Durante la sincronizzazione dei gruppi da un ambiente attivo on-premise Directory o quando si utilizza il tipo di Office 365, è anche possibile creare gruppi di tipo Lista 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 di 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 che è stato registrato come dominio personalizzato in Microsoft Entra ID. Questo 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

Mappatura dei gruppi Microsoft Entra ID a Cloud Identity o I gruppi di Google Workspace richiedono un identificatore comune, deve essere un indirizzo email. Per quanto riguarda 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 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.

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, questo significa che è possibile sincronizzare solo gruppi. 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 in Microsoft Entra ID e 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 essere in conflitto con un'email l'indirizzo email di un utente.
2. Microsoft Entra ID non impone l'univocità 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'email generata diverso da uno qualsiasi dei domini utilizzati dagli utenti. Ad esempio, se tutti i tuoi utenti utilizzeranno indirizzi email con example.com come dominio, allora potresti utilizzare groups.example.com per tutti i gruppi. 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.

La seconda sfida è la duplicazione dei nomi dei gruppi, ma solo tecnicamente ricavando l'indirizzo email del gruppo dall'ID oggetto. Poiché l'output i nomi dei gruppi sono piuttosto criptici e difficili da usare, è meglio identificare e rinominare i nomi dei gruppi duplicati in Microsoft Entra ID prima di configurare il provisioning su 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 in Cloud Identity o Google Workspace, devi decidere quale gruppi di cui 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.

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)	Abilita 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 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 attivare il provisioning per un gruppo e, in un secondo momento, disattivare il provisioning, il gruppo Cloud Identity o Google Workspace rimangono attivi. 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 e attendi modifiche da propagare ed eliminare il gruppo in Microsoft Entra ID oppure disabilitare per il gruppo in Microsoft Entra ID.

Passaggi successivi

• Informazioni best practice per la pianificazione di account e organizzazioni e 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.