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

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

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

Implementazione della federazione

Google Cloud utilizza le identità Google per l'autenticazione e la gestione degli accessi. Gestire manualmente le identità Google ogni dipendente può sovraccaricare quando 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.

Configura la federazione tra Microsoft Entra ID e Cloud Identity Google Workspace è costituito da due elementi:

• Provisioning degli utenti: gli utenti e i gruppi pertinenti sono vengono sincronizzati periodicamente da Microsoft Entra ID a Cloud Identity oppure Google Workspace. Questa procedura garantisce che, quando crei un nuovo utente in Microsoft Entra ID o sincronizza un nuovo utente da Active Directory a Microsoft Entra ID, viene reso disponibile anche in Google Cloud in modo che possa essere usato come riferimento a Google Cloud anche prima che l'utente associato abbia eseguito l'accesso per la prima volta. Questo processo garantisce inoltre che le eliminazioni degli utenti siano propagati.

  Il provisioning funziona in un modo, il che significa che le modifiche in Microsoft Entra ID replicati 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.

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 container per utenti, gruppi nonché risorse e gruppi di risorse.

A ogni tenant di 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 la 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, organizzazioni fungono da container per tutte le risorse e possono essere ulteriormente segmentati tramite cartelle e progetti. Tuttavia, ad eccezione di account di servizio, le organizzazioni non vengono usate per gestire utenti e gruppi, rendendo 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, Un'organizzazione Google Cloud vengono creati automaticamente. L'account Cloud Identity o tra l'account Google Workspace e l'organizzazione Google Cloud associati hanno lo stesso nome e sono legati 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.

Integra Microsoft Entra ID e Google Cloud

Nonostante alcune somiglianze tra la struttura logica di Microsoft Entra ID e Google Cloud, nessuna mappatura tra le due strutture funziona allo stesso modo bene 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 a Cloud Identity Account 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 la tua rete on-premise Active Directory. 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 un account Cloud Identity o Google Workspace e configurare la federazione tra i due. Questo account Cloud Identity o Google Workspace fornisce quindi la base per un'unica organizzazione Google Cloud a cui per gestire tutte le risorse Google Cloud.

Più tenant

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

È possibile mappare più tenant Microsoft Entra ID a un singolo Cloud Identity o Google Workspace e configurare l'account il provisioning 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 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.

Eseguire il provisioning degli utenti ospiti da Microsoft Entra ID a Cloud Identity Google Workspace è soggetto ad alcune 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 suo tenant di casa, viene restituito un utente di Cloud Identity o Google Workspace potrebbe rimanere attivo e l'accesso alle risorse Google Cloud potrebbe non essere revocato.

Un modo migliore per trattare con gli utenti ospiti che provengono da un ID Microsoft Entra ID diverso tenant è creare più Cloud Identity o Google Workspace come descritto nella sezione precedente, ognuno federato con un Tenant 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, è necessario non è un prerequisito perché l'utente abbia un account utente in Cloud Identity o Google Workspace. A meno che limitato in base alle norme, puoi anche aggiungere l'utente esterno direttamente in qualità di membro dei rispettivi progetti, cartelle o organizzazioni, 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 si pianifica la federazione Microsoft Entra ID e Google Cloud consentono di condividere o mappare i domini DNS tra Microsoft Entra ID e Google Cloud.

Utilizzo di domini DNS in Google Cloud

Accedi con Google, su cui Google Cloud si basa per l'autenticazione, utilizza le 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 per un Google Workspace o Cloud Identity di fatturazione, stai creando una directory privata che utilizzabili 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 con Cloud Identity Account Google Workspace. Ciascuna dell'utente nella directory sia associato al dominio principale uno dei domini secondari. Due utenti, johndoe@example.com e johndoe@secondary.example.com 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. Vale a dire johndoe@example.com e johndoe@alias.example.com si riferiscono allo stesso utente se alias.example.com è stato 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, 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 principale e secondario devono avere un record MX valido in modo che messaggi inviati a indirizzi email creati utilizzando questo nome di dominio possono essere inviati correttamente.

Utilizzo di domini DNS in Microsoft Entra ID

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

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.

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

Map users (Mappa gli utenti)

Il terzo fattore da considerare quando si pianifica la federazione di Microsoft Entra ID e Google Cloud spiega 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 stabile che puoi utilizzare durante la sincronizzazione per monitorare quale utente Microsoft Entra ID corrisponde a quale utente in Cloud Identity oppure 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 di richiesta 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 al proprio 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 usato da Microsoft Entra ID e l'UPN usato da Active Directory sono tutti diversi, la sequenza di schermate di accesso può facilmente creare confusione per gli utenti finali. Nella se tutti e tre gli identificatori sono gli stessi degli screenshot di esempio (johndoe@example.com), gli utenti non sono esposti alle differenze tecniche tra UPN e indirizzi email, riducendo al minimo la confusione 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 Microsoft Entra ID all'indirizzo email di Cloud Identity indirizzi IP, devi soddisfare i seguenti requisiti:

• Gli UPN di Microsoft Entra ID devono essere indirizzi email validi le email di notifica inviate da Google Cloud vengono recapitate correttamente la casella di posta dell'utente. Se non è già così, potresti essere in grado di configurare indirizzi email alias per garantire che l'utente riceva tali email.
• Gli UPN di tutti gli utenti pertinenti in Microsoft Entra ID devono utilizzare un dominio personalizzato come (user@custom-domain). UPN che utilizza il dominio iniziale Microsoft Entra ID (user@tenant.onmicrosoft.com) non può essere mappati a indirizzi email in Cloud Identity, in quanto l'iniziale dominio non è di tua proprietà, ma di Microsoft.
• Tutti i domini personalizzati utilizzati da Microsoft Entra ID per gli UPN devono essere registrati 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 verifica la proprietà del dominio in Microsoft Entra ID, puoi utilizzare un record CNAME verificare la proprietà del dominio in Cloud Identity.

Mappa gli utenti in base all'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 nella L'attributo mail del rispettivo oggetto user e Microsoft Entra ID Connect sincronizza il valore con l'attributo Mail in Microsoft Entra ID. Microsoft Entra ID migliora anche l'attributo disponibile per il provisioning degli utenti, in modo da poterlo mappare 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 è pratica solo quando si esegue 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:

• Le assegnazioni email devono essere completate. Tutti gli utenti interessati di sincronizzazione deve essere assegnato un indirizzo email. Soprattutto quando gli utenti vengono sincronizzate da un'Active Directory on-premise, della richiesta 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. Sebbene Active Directory non controlla l'univocità nella creazione di utenti. Microsoft Entra ID Connect rileva delle collisioni per impostazione predefinita, che potrebbero causare la sincronizzazione degli utenti interessati non riuscirà.
• I domini utilizzati dagli indirizzi email non devono essere registrati in Microsoft Entra ID. ma devono essere registrati in Cloud Identity Google Workspace. Questo implica che devi avere accesso alle rispettive zone DNS in eseguire la convalida del dominio ed esclude l'uso di email indirizzi con domini che non sono di tua proprietà (ad esempio 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 dei set di identità per indicazioni su come prendere questa decisione.

Se non vuoi eseguire il provisioning di tutti gli utenti del tenant Microsoft Entra ID, puoi 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 determina quale azioni eseguite da Microsoft Entra ID in Cloud Identity o Google Workspace.

Provisioning abilitato per l'utente Microsoft Entra ID	Stato utente in Cloud Identity o Google Workspace	Azione eseguita in Microsoft Entra ID	Azione eseguita in Cloud Identity o Google Workspace
No	(inesistente)	Abilita provisioning	Crea nuovo utente (*)
No	Esiste (attivo)	Abilita provisioning	Aggiorna utente esistente
No	Esiste (sospeso)	Abilita provisioning	Aggiorna un utente esistente, mantieni sospeso
Sì	Esistente	Modifica utente	Aggiorna utente esistente
Sì	Esistente	Rinomina l'indirizzo UPN/email	Cambia l'indirizzo email principale, mantieni l'indirizzo precedente come alias
Sì	Esistente	Disabilita provisioning	Utente lasciato così com'è
Sì	Esistente	Elimina utente temporaneamente	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 è stato eliminato.

Gruppi sulla mappa

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. Piuttosto rispetto all'assegnazione di singoli utenti a ruoli IAM in ogni devi definire un insieme di gruppi che modellano ruoli comuni nei tuoi dell'organizzazione. Successivamente, potrai assegnare questi gruppi a un insieme di ruoli IAM. Modificando l'appartenenza ai gruppi, puoi controllare le un accesso a un l'intero set di risorse.

La mappatura dei gruppi tra Microsoft Entra ID e Google Cloud è facoltativa. Dopo aver configurare il provisioning degli utenti, puoi creare e gestire i gruppi direttamente Cloud Identity o Google Workspace, che significa che lo stato Directory o Microsoft Entra ID rimane il sistema centrale per la gestione delle identità, ma non per la gestione degli accessi di 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 che che puoi utilizzare le appartenenze ai gruppi in Active Directory o Microsoft Entra ID per controllare che 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. Gruppi in Cloud Identity e Google Workspace non sono confinati nell'ambito di Cloud Identity l'account Google Workspace in cui sono stati definiti. Possono invece includi utenti di diversi account Cloud Identity o Google Workspace account, il supporto della necessità di fare riferimento e di nidificarli in altri account, e di usare in qualsiasi organizzazione Google Cloud.

Come fanno con gli utenti, Cloud Identity e Google Workspace identificare i gruppi in base all'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 specificare i gruppi 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 hanno come ambito un singolo tenant identificato da un ID oggetto, ovvero un ID univoco a livello globale generato casualmente. 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 le creatività dinamiche gruppi, i cui membri vengono determinati automaticamente in base a una query.

Nel contesto dell'integrazione di Microsoft Entra ID con Cloud Identity oppure 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 alla 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 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 relativi all'abilitazione per la posta o la sicurezza e come vengono mappati Tipi di gruppi di Active Directory, presupponendo un valore predefinito di Microsoft Entra ID Connect configurazione:

Origine	Tipo di gruppo Active Directory	Tipo di gruppo Microsoft Entra ID	Abilitato per la posta	Sicurezza abilitata
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 si avvale di un dominio registrato in Microsoft Entra ID, l'indirizzo email mantenuta 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 valore predefinito del tenant dominio. Se il tenant utilizza il dominio iniziale come dominio predefinito, l'indirizzo email risultante sarà sotto forma di [name]@[tenant].onmicrosoft.com.
• Se crei un gruppo di Office 365 in Microsoft Entra ID, anche Microsoft Entra ID Genera automaticamente un indirizzo email che utilizza il dominio predefinito del tenant.

Mappa le identità di gruppo

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 per soddisfare diversi requisiti:

• Tutti i gruppi soggetti a sincronizzazione devono avere un indirizzo email . In pratica, questo significa che è possibile sincronizzare solo gruppi. I gruppi privi di un indirizzo email vengono ignorati durante il provisioning.
• Gli indirizzi email devono essere univoci nel tenant. Poiché Microsoft Entra ID non applica l'univocità, potresti dover implementare controlli personalizzati criteri.
• I domini utilizzati dagli indirizzi email devono essere registrati in Microsoft Entra ID e Cloud Identity o Google Workspace. Tutti i gruppi con email indirizzi che utilizzano domini non registrati in Cloud Identity o Google Workspace, incluse le dominio tenant.onmicrosoft.com, non riuscirà a sincronizzare.

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 Cloud Identity o Google Workspace coprono questi domini.

Mappa per nome

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

La creazione 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 applica l'univocità per i nomi dei gruppi. Se più gruppi nel tuo tenant Microsoft Entra ID condividono lo stesso nome, ovvero gli indirizzi email derivati questo nome virà in conflitto, causando la corretta 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. Registrazione di sottodomini in Cloud Identity o Google Workspace non richiede un dominio verifica, perciò la zona DNS groups.example.com non deve neanche esistere.

La seconda sfida è la duplicazione dei nomi dei gruppi, ma solo tecnicamente ricavando l'indirizzo email del gruppo dall'ID oggetto. Poiché il risultato 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.

Mappa 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 gruppo di gruppi di cui vuoi eseguire il provisioning. Come per gli utenti, puoi attivare il provisioning per un sottoinsieme di gruppi compiti di gruppo 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 gruppo determina quale azioni eseguite da Microsoft Entra ID 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	(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)

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.
• Informazioni su best practice per la gestione degli account super amministratore.