Federa Google Cloud con Active Directory

Questo documento descrive come configurare Cloud Identity o Google Workspace per utilizzare Active Directory come IdP e origine autorevole.

Il documento confronta la struttura logica di Active Directory con la struttura utilizzata da Cloud Identity e Google Workspace e descrive come puoi mappare foreste, domini, utenti e gruppi di Active Directory. Il documento fornisce anche un diagramma di flusso che ti aiuta a determinare l'approccio di mappatura migliore per il tuo scenario.

Questo documento presuppone che tu abbia familiarità con Active Directory.

Implementare la federazione

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

La configurazione della federazione tra Active Directory e Cloud Identity o Google Workspace prevede due passaggi:

• Provisioning degli utenti: gli utenti e i gruppi pertinenti vengono sincronizzati periodicamente da Active Directory a Cloud Identity o Google Workspace. Questa procedura garantisce che quando crei un nuovo utente in Active Directory, 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 che le eliminazioni degli utenti vengano propagate.

  Il provisioning funziona in un solo modo, il che significa che le modifiche in Active Directory vengono replicate in Google Cloud , ma non viceversa. Inoltre, il provisioning non include le password. In una configurazione federata, Active Directory rimane l'unico sistema che gestisce queste credenziali.

• Single Sign-On: ogni volta che un utente deve autenticarsi, Google Cloud delega l'autenticazione ad Active Directory utilizzando il protocollo SAML (Security Assertion Markup Language). Questa delega garantisce che solo Active Directory gestisca le credenziali utente e che vengano applicati tutti i meccanismi di autenticazione a più fattori (MFA) o le norme applicabili. Tuttavia, per un accesso riuscito, l'utente rispettivo deve essere stato sottoposto al provisioning in precedenza.

Per implementare la federazione, puoi utilizzare i seguenti strumenti:

• Google Cloud Directory Sync (GCDS) è uno strumento gratuito fornito da Google che implementa il processo di sincronizzazione. GCDS comunica con Google Cloud tramite Secure Sockets Layer (SSL) e in genere viene eseguito nell'ambiente di computing esistente.
• Active Directory Federation Services (AD FS) è fornito da Microsoft come parte di Windows Server. Con AD FS, puoi utilizzare Active Directory per l'autenticazione federata. AD FS viene in genere eseguito all'interno dell'ambiente di computing esistente.

Poiché le API per Google Cloud sono disponibili pubblicamente e SAML è uno standard aperto, sono disponibili molti strumenti per implementare la federazione. Questo documento è incentrato sull'utilizzo di GCDS e AD FS.

Struttura logica di Active Directory

In un'infrastruttura Active Directory, il componente di primo livello è la foresta. La foresta funge da contenitore per uno o più domini e deriva il suo nome dal dominio radice della foresta. I domini di una foresta Active Directory si considerano attendibili a vicenda, consentendo agli utenti autenticati in un dominio di accedere alle risorse di un altro dominio. A meno che le foreste non siano connesse tramite trust tra foreste, le foreste separate non si considerano attendibili per impostazione predefinita e gli utenti autenticati in una foresta non possono accedere alle risorse che si trovano in un'altra foresta.

I domini Active Directory sono container per la gestione delle risorse e sono considerati limiti amministrativi. Avere più domini in una foresta è un modo per semplificare l'amministrazione o applicare una struttura aggiuntiva, ma i domini in una foresta non rappresentano limiti di sicurezza.

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. Pertanto, organizzazioni, cartelle e progetti hanno uno scopo simile ai domini Active Directory.

Active Directory considera gli utenti come risorse, pertanto la gestione e l'autenticazione degli utenti sono legate ai domini. Al contrario, Google Cloud non gestisce gli utenti di un'organizzazione, ad eccezione degli account di servizio. Google Cloud si basa su Cloud Identity o Google Workspace per gestire gli utenti.

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

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

Integrare Active Directory e Google Cloud

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

• Come mappare domini e foreste agli account Cloud Identity o Google Workspace
• Come mappare i domini DNS
• Come mappare gli utenti
• Come mappare i gruppi

Le sezioni seguenti esaminano ciascuno di questi fattori.

Mappa le foreste

Soprattutto nelle organizzazioni più grandi, spesso utilizzi più di un dominio Active Directory per gestire identità e accesso in tutta l'azienda. Quando prevedi di federare Active Directory e Google Cloud, il primo fattore da esaminare è la topologia dell'infrastruttura Active Directory.

Singola foresta, singolo dominio

Quando una foresta include un solo dominio, puoi mappare l'intera foresta Active Directory a un singolo account Cloud Identity o Google Workspace. Questo account fornisce quindi la base per una singola organizzazione Google Cloud che puoi utilizzare per gestire le tue risorse Google Cloud .

In un ambiente a dominio singolo, i domain controller e i server del catalogo globale forniscono entrambi l'accesso a tutti gli oggetti gestiti in Active Directory. Nella maggior parte dei casi, puoi eseguire una singola istanza di GCDS per sincronizzare account utente e gruppi con Google Cloude per gestire una singola istanza o flotta AD FS per gestire il Single Sign-On.

Una sola foresta, più domini

Quando una foresta contiene più domini Active Directory, puoi organizzarli in uno o più alberi di domini. In entrambi i casi, puoi mappare l'intera foresta a un unico account Cloud Identity o Google Workspace. Questo account fornisce quindi la base per una singola organizzazione Google Cloud che puoi utilizzare per gestire le tue risorse Google Cloud .

In un ambiente multi-dominio, esiste una differenza tra le informazioni che possono essere recuperate da un controller di dominio e quelle che possono essere interrogate da un server di catalogo globale. Mentre i controller di dominio forniscono dati solo dal proprio dominio locale, i server del catalogo globale forniscono l'accesso alle informazioni di tutti i domini della foresta. Fondamentalmente, i dati forniti dai server del catalogo globale sono parziali e non includono determinati attributi LDAP. Questa limitazione può influire sul modo in cui configuri GCDS per sincronizzare i gruppi.

A seconda di come prevedi di mappare i gruppi, la federazione di una foresta multidominio con Google Cloud richiede una o più istanze GCDS, ma solo una singola istanza o flotta AD FS per gestire il Single Sign-On.

Più foreste con trust tra foreste

Nelle organizzazioni più grandi, non è raro avere più foreste di Active Directory, spesso a seguito di una fusione o acquisizione. Puoi combinare queste foreste utilizzando una relazione di trust bidirezionale tra foreste in modo che gli utenti possano condividere e accedere alle risorse oltre i confini di una singola foresta.

Se tutte le foreste hanno una relazione di trust bidirezionale con un'altra foresta, puoi mappare l'intero ambiente a un singolo account Cloud Identity o Google Workspace. Questo account fornisce la base per una singola organizzazioneGoogle Cloud che puoi utilizzare per gestire le tue risorse Google Cloud.

Sebbene i server del catalogo globale forniscano l'accesso ai dati di più domini, il loro ambito è limitato a una singola foresta. Pertanto, in un ambiente con più foreste, devi interrogare più controller di dominio o server di catalogo globale per ottenere, ad esempio, un elenco completo di utenti. A causa di questa limitazione, la federazione di un ambiente multi-foresta con Google Cloud richiede almeno un'istanza GCDS per foresta. Le trust tra foreste consentono l'autenticazione degli utenti oltre i confini delle foreste, quindi una singola istanza o flotta AD FS è sufficiente per gestire il Single Sign-On.

Se il tuo ambiente si estende su più foreste senza trust tra foreste, ma tutti i domini Active Directory pertinenti per la federazione con Google Cloudsono connessi tramite trust esterni, si applicano le stesse considerazioni.

Più foreste senza trust tra foreste

Nell'ambiente illustrato qui, non è possibile autenticarsi o accedere alle risorse oltre i confini della foresta. Inoltre, non è possibile che una singola istanza o flotta di AD FS gestisca le richieste di Single Sign-On per gli utenti di tutte le foreste.

Pertanto, non è possibile mappare più foreste che non dispongono di trust tra foreste a un singolo account Cloud Identity o Google Workspace. Invece, ogni foresta deve essere mappata a un account Cloud Identity o Google Workspace separato, il che comporta l'esecuzione di almeno un'istanza GCDS e un server o una flotta AD FS per foresta.

In Google Cloud, viene creata un'organizzazione separata per ogni account Cloud Identity o Google Workspace. Nella maggior parte dei casi, non è necessario gestire più organizzazioni separate. Puoi selezionare una delle organizzazioni e associarla agli altri account Cloud Identity o Google Workspace, creando di fatto un'organizzazione federata con più foreste Active Directory. Le altre organizzazioni rimangono inutilizzate.

Mappare i domini DNS

Il DNS svolge un ruolo fondamentale sia in Active Directory sia per Cloud Identity e Google Workspace. Il secondo fattore da considerare quando prevedi di federare Active Directory e Google Cloud è come condividere o mappare i domini DNS tra Active Directory e Google Cloud.

Utilizzo dei domini DNS in Active Directory

In una foresta Active Directory, i domini DNS vengono utilizzati in più posizioni:

• Domini DNS di Active Directory: ogni dominio Active Directory corrisponde a un dominio DNS. Questo dominio può essere globale, come corp.example.com, o può essere un nome di dominio locale come corp.local o corp.internal.
• Domini Mail Exchange (MX): gli indirizzi email utilizzano un dominio DNS. In alcuni casi, questo dominio è uguale al dominio DNS di Active Directory, ma in molti casi viene utilizzato un dominio diverso, spesso più breve, come example.com. Idealmente, gli utenti in Active Directory hanno l'indirizzo email associato all'attributo facoltativo mail.
• Domini suffisso UPN: questi domini vengono utilizzati per i User Principal Name (UPN). Per impostazione predefinita, il dominio DNS di Active Directory del dominio dell'utente viene utilizzato per creare un UPN. Per un utente john nel dominio corp.example.com, l'UPN predefinito è quindi john@corp.example.com. Tuttavia, puoi configurare una foresta in modo che utilizzi domini DNS aggiuntivi come suffissi UPN che non corrispondono né ai domini DNS di Active Directory né ai domini MX. I nomi UPN sono facoltativi e vengono memorizzati nel campo userPrincipalName dell'utente.
• Domini endpoint: ai server pubblici come i server AD FS viene di solito assegnato un nome DNS, ad esempio login.external.example.com. Il dominio utilizzato per questi scopi può sovrapporsi al suffisso MX, UPN o al dominio DNS di Active Directory oppure può essere un dominio completamente diverso.

Utilizzo dei domini DNS in Google Cloud

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

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

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

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

Tutti i domini devono soddisfare i seguenti requisiti:

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

Per attivare la sincronizzazione tra le directory, è necessaria una mappatura tra i domini Active Directory e i domini utilizzati da Cloud Identity o Google Workspace. La determinazione del mapping corretto dipende da come utilizzi Active Directory e richiede un'analisi più approfondita di come vengono identificati gli utenti in una foresta Active Directory e come possono essere mappati a Cloud Identity o Google Workspace.

Map users (Mappa gli utenti)

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

Identificare gli utenti in Active Directory

Internamente, Active Directory utilizza due identificatori per identificare in modo univoco gli utenti:

• objectGUID: questo ID univoco a livello globale viene generato quando viene creato un utente e non cambia mai.
• objectSID: l'SID, o identificatore di sicurezza, viene utilizzato per tutti i controlli di accesso. Sebbene questo ID sia univoco e stabile all'interno di un dominio, è possibile che, se spostato in un dominio diverso nella foresta, a un utente venga assegnato un nuovo SID.

Nessuno di questi ID è significativo per gli utenti, pertanto Active Directory offre due modi semplici per identificare gli utenti:

• UPN (userPrincipalName): il modo preferito per identificare un utente è tramite UPN. Gli UPN seguono il formato RFC 822 degli indirizzi email e vengono creati combinando il nome utente con un dominio suffisso UPN, come in johndoe@corp.example.com. Nonostante siano il modo preferito per identificare gli utenti, gli UPN sono facoltativi, quindi alcuni utenti nella foresta Active Directory potrebbero non averne uno.

  Sebbene sia considerata una best practice che gli UPN siano indirizzi email validi, Active Directory non applica questa pratica.

• Nome di accesso precedente a Windows 2000 (sAMAccountName): questo nome combina il nome di dominio NetBIOS e il nome utente utilizzando il formato domain<var>user, ad esempio corp\johndoe. Anche se questi nomi sono considerati legacy, sono ancora comunemente utilizzati e sono l'unico identificatore obbligatorio di un utente.

In particolare, Active Directory non utilizza l'indirizzo email dell'utente (mail) per identificare gli utenti. Di conseguenza, questo campo non è obbligatorio né deve essere univoco in una foresta.

Tutti questi identificatori possono essere modificati in qualsiasi momento.

Mappa le identità degli utenti.

Per mappare gli utenti di Active Directory agli utenti di Cloud Identity o Google Workspace sono necessarie due informazioni per ogni utente:

• Un ID univoco e stabile che puoi utilizzare durante la sincronizzazione per monitorare quale utente di Active Directory corrisponde a quale utente in Cloud Identity o Google Workspace. Per quanto riguarda gli annunci, objectGUID è perfetto per questo scopo.
• Un indirizzo email la cui parte del dominio corrisponde a un dominio principale, secondario o alias del tuo account Cloud Identity o Google Workspace. Poiché questo indirizzo email verrà utilizzato in tutto Google Cloud, assicurati che l'indirizzo sia significativo. Derivare un indirizzo da objectGUID è impraticabile, così come altri indirizzi email generati automaticamente.

Per un utente Active Directory, due campi sono candidati a fornire un indirizzo email Cloud Identity o Google Workspace: userPrincipalName e mail.

Mappa per nome principale utente

L'utilizzo del campo userPrincipalName richiede che vengano soddisfatti due criteri per tutti gli utenti soggetti alla sincronizzazione:

• I nomi principali utente (UPN) devono essere indirizzi email validi. Tutti i domini utilizzati come domini suffisso UPN devono essere anche domini MX e devono essere configurati in modo che un'email inviata all'UPN di un utente venga recapitata alla sua casella di posta.

• Le assegnazioni UPN devono essere completate. Tutti gli utenti soggetti alla sincronizzazione devono avere un UPN assegnato. Il seguente comando PowerShell può aiutarti a trovare gli utenti che non hanno un UPN:

  Get-ADUser -LDAPFilter "(!userPrincipalName=*)"

Se questi due criteri sono soddisfatti, puoi mappare in modo sicuro gli UPN agli indirizzi email di Cloud Identity o Google Workspace. Puoi utilizzare uno dei domini con suffisso UPN come dominio principale in Cloud Identity o Google Workspace e aggiungere tutti gli altri domini con suffisso UPN come domini secondari.

Se uno dei criteri non viene soddisfatto, puoi comunque mappare gli UPN agli indirizzi email di Cloud Identity o Google Workspace, ma si applicano le seguenti limitazioni:

• Se gli UPN non sono indirizzi email validi, gli utenti potrebbero non ricevere le email di notifica inviate da Google Cloud, il che potrebbe causare la perdita di informazioni importanti.
• Gli utenti senza UPN vengono ignorati durante la sincronizzazione.
• Puoi configurare la sincronizzazione per sostituire il dominio del suffisso UPN con un dominio diverso. Quando utilizzi più domini suffisso UPN in una foresta, questo approccio può creare duplicati, tuttavia, perché tutti i domini suffisso UPN verranno sostituiti da un unico dominio. In caso di duplicati, può essere sincronizzato un solo utente.

Un vantaggio importante dell'utilizzo degli UPN per mappare gli utenti è che gli UPN sono garantiti per essere univoci in una foresta e utilizzano un insieme curato di domini, il che aiuta a evitare potenziali problemi di sincronizzazione.

Mappa per indirizzo email

L'utilizzo del campo mail richiede il rispetto dei seguenti criteri per tutti gli utenti soggetti a sincronizzazione:

• Le assegnazioni email devono essere complete. Tutti gli utenti soggetti alla sincronizzazione devono avere il campo mail compilato. Il seguente comando PowerShell può aiutarti a trovare gli utenti per i quali questo campo non è compilato:

  Get-ADUser -LDAPFilter "(!mail=*)"

• Gli indirizzi email devono utilizzare un insieme selezionato di domini, tutti di tua proprietà. Se alcuni dei tuoi utenti utilizzano indirizzi email che fanno riferimento a aziende partner o provider email per i consumatori, questi indirizzi email non possono essere utilizzati.

• Tutti gli indirizzi email devono essere univoci nella foresta. Poiché Active Directory non impone l'unicità, potresti dover implementare controlli o criteri personalizzati.

Se tutti gli utenti pertinenti soddisfano questi criteri, puoi identificare tutti i domini utilizzati da questi indirizzi email e utilizzarli come domini principali e secondari in Cloud Identity o Google Workspace.

Se uno dei criteri non viene soddisfatto, puoi comunque mappare gli indirizzi email agli indirizzi email Cloud Identity o Google Workspace, con le seguenti avvertenze:

• Durante la sincronizzazione, gli utenti senza indirizzi email verranno ignorati, così come gli utenti con indirizzi email che utilizzano domini non associati all'account Cloud Identity o Google Workspace.
• Quando due utenti condividono lo stesso indirizzo email, solo uno verrà sincronizzato.
• Puoi configurare la sincronizzazione in modo da sostituire il dominio degli indirizzi email con un dominio diverso. Questo processo può creare duplicati, nel qual caso verrà sincronizzato un solo utente.

Gruppi di mappe

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

In Google Cloud, i gruppi vengono comunemente utilizzati per gestire l'accesso in modo efficiente tra i progetti. Anziché assegnare singoli utenti ai ruoli IAM in ogni progetto, definisci un insieme di gruppi che modellano i ruoli comuni nella tua organizzazione e poi assegna 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.

Active Directory distingue tra due tipi di gruppi: gruppi di distribuzione e gruppi di sicurezza. I gruppi di distribuzione vengono utilizzati per gestire le mailing list. La sincronizzazione dei gruppi di distribuzione è pertinente quando esegui la migrazione da Microsoft Exchange a Google Workspace, in modo che GCDS possa gestire gruppi di distribuzione normali e dinamici. I gruppi di distribuzione non sono un problema nella gestione di identità e accessi per Google Cloud, pertanto questa discussione si concentra esclusivamente sui gruppi di sicurezza.

La mappatura dei gruppi tra Active Directory e Google Cloud è facoltativa. Una volta configurato il provisioning degli utenti, puoi creare e gestire i gruppi direttamente in Cloud Identity o Google Workspace, il che significa che Active Directory rimane il sistema centrale per la gestione delle identità, ma non per la gestione degli accessi. Per mantenere Active Directory come sistema centrale per la gestione delle identità e degli accessi, ti consigliamo di sincronizzare i gruppi di sicurezza da Active Directory anziché gestirli in Cloud Identity o Google Workspace. Con questo approccio, puoi configurare IAM in modo da utilizzare le appartenenze ai gruppi in Active Directory per controllare chi ha accesso a determinate risorse in Google Cloud.

Gruppi di sicurezza in Active Directory

I gruppi di sicurezza svolgono un ruolo fondamentale nella sicurezza di Windows e nella gestione dell'accesso ad Active Directory. Questo ruolo è facilitato da tre diversi tipi di gruppi Active Directory: gruppi locali del dominio, gruppi globali e gruppi universali.

Gruppi locali del dominio

Questi gruppi sono pertinenti solo nell'ambito di un singolo dominio e non possono essere referenziati in altri domini. Poiché l'elenco dei membri non deve essere replicato nella foresta, i gruppi locali del dominio sono i più flessibili per quanto riguarda i tipi di membri che possono includere.

Gruppi globali

Questi gruppi vengono visualizzati e possono essere citati in altri domini. Tuttavia, l'elenco dei membri non viene replicato. Questa limitazione restringe i tipi di membri che questi gruppi possono includere. Questi gruppi possono includere solo utenti e altri gruppi globali dello stesso dominio.

Gruppi universali

Questi gruppi, insieme ai relativi elenchi di membri, vengono replicati in tutta la foresta. Possono quindi essere referenziati in altri domini e possono includere non solo utenti e altri gruppi universali, ma anche gruppi globali di tutti i domini.

Se la foresta di Active Directory contiene un solo dominio, puoi sincronizzare tutti e tre i tipi di gruppi di sicurezza utilizzando GCDS. Se la foresta Active Directory utilizza più di un dominio, il tipo di gruppo determina se e come può essere sincronizzato con Cloud Identity o Google Workspace.

Poiché i gruppi locali e globali del dominio non vengono replicati completamente in una foresta, i server del catalogo globale contengono informazioni incomplete. Sebbene questa limitazione sia intenzionale e contribuisca ad accelerare la replica della directory, è un ostacolo quando vuoi sincronizzare questi gruppi con Cloud Identity o Google Workspace. In particolare, se configuri GCDS in modo che utilizzi un server di catalogo globale come origine, lo strumento sarà in grado di trovare i gruppi di tutti i domini della foresta. Tuttavia, solo i gruppi che si trovano nello stesso dominio del server del catalogo globale conterranno un elenco dei membri e saranno adatti alla replica. Per sincronizzare i gruppi locali o globali di un dominio in una foresta multidominio, devi eseguire un'istanza GCDS separata per ogni dominio.

Poiché i gruppi universali vengono replicati completamente nella foresta, non hanno questa limitazione. Una singola istanza di GCDS può sincronizzare i gruppi universali di più domini.

Prima di concludere che hai bisogno di più istanze GCDS per sincronizzare più domini Active Directory con Cloud Identity o Google Workspace, tieni presente che non tutti i gruppi potrebbero dover essere sincronizzati. Per questo motivo, è utile esaminare il modo in cui i diversi tipi di gruppi di sicurezza vengono in genere utilizzati nella foresta Active Directory.

Utilizzo dei gruppi di sicurezza in Active Directory

Le sezioni seguenti descrivono i tipi di gruppi di sicurezza utilizzati in Active Directory.

Gruppi di risorse

Windows utilizza un modello di accesso basato su elenchi di controllo dell'accesso (ACL). Ogni risorsa, come un file o un oggetto LDAP, ha un ACL associato che controlla a quali utenti è consentito l'accesso. Le risorse e gli ACL sono molto granulari, quindi ce ne sono molti. Per semplificare la manutenzione degli elenchi di controllo degli accessi, è prassi comune creare gruppi di risorse per raggruppare le risorse utilizzate e a cui si accede di frequente insieme. Aggiungi il gruppo di risorse a tutte le ACL interessate una sola volta e gestisci l'accesso successivo modificando l'appartenenza al gruppo di risorse, non modificando le ACL.

Le risorse raggruppate in questo modo si trovano in genere in un unico dominio. Di conseguenza, un gruppo di risorse tende a essere referenziato anche in un singolo dominio, negli elenchi di controllo dell'accesso o da altri gruppi di risorse. Poiché la maggior parte dei gruppi di risorse sono locali, di solito vengono implementati utilizzando gruppi locali del dominio in Active Directory.

Gruppi di ruoli e organizzazioni

I gruppi di risorse semplificano la gestione degli accessi, ma in un ambiente di grandi dimensioni potresti dover aggiungere un nuovo utente a un numero elevato di gruppi di risorse. Per questo motivo, i gruppi di risorse sono spesso integrati da gruppi di ruoli o gruppi dell'organizzazione.

I gruppi di ruoli aggregano le autorizzazioni richieste da un ruolo specifico nell'organizzazione. Un gruppo di ruoli denominato Visualizzatore documentazione ingegneristica, ad esempio, potrebbe concedere ai membri l'accesso di sola lettura a tutta la documentazione ingegneristica. In pratica, puoi implementare questa funzionalità creando un gruppo di ruoli e rendendolo membro di tutti i gruppi di risorse utilizzati per controllare l'accesso a vari tipi di documentazione.

In modo simile, i gruppi dell'organizzazione aggregano le autorizzazioni richieste dai reparti all'interno di un'organizzazione. Ad esempio, un gruppo dell'organizzazione denominato Ingegneria potrebbe concedere l'accesso a tutte le risorse che i membri del reparto di ingegneria richiedono comunemente.

Tecnicamente, non esiste alcuna differenza tra i gruppi di ruoli e i gruppi di risorse e i due vengono comunemente utilizzati insieme. A differenza dei gruppi di risorse, tuttavia, i gruppi di ruoli e dell'organizzazione possono avere rilevanza oltre i confini di un dominio. Per consentire a questi gruppi di essere referenziati da gruppi di risorse in altri domini, i gruppi di ruoli e organizzazioni vengono in genere implementati utilizzando gruppi globali, che sono limitati ai membri di un singolo dominio e a volte integrati da gruppi universali, che consentono membri di domini diversi.

Il seguente diagramma mostra un pattern di nidificazione comunemente utilizzato negli ambienti Active Directory multi-dominio.

Gruppi in Cloud Identity e Google Workspace

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

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

A differenza dei gruppi Active Directory, ai membri di un gruppo Cloud Identity o Google Workspace non viene concessa implicitamente l'autorizzazione a elencare altri membri dello stesso gruppo. Al contrario, l'interrogazione dell'appartenenza al gruppo in genere richiede un'autorizzazione esplicita.

Utilizzo dei gruppi in Google Cloud

Google Cloud utilizza un modello di accesso basato sui ruoli anziché un modello di accesso basato sulle ACL. I ruoli vengono applicati a tutte le risorse di un determinato tipo che rientrano in un determinato ambito. Ad esempio, il ruolo Sviluppatore Kubernetes Engine ha accesso completo agli oggetti API Kubernetes all'interno di tutti i cluster di un determinato progetto. A causa della natura dei ruoli, non è necessario gestire i gruppi di risorse su Google Cloud e raramente è necessario sincronizzare i gruppi di risorse con Google Cloud.

I gruppi di ruoli e i gruppi dell'organizzazione sono altrettanto importanti in Google Cloud come in Active Directory, perché semplificano la gestione dell'accesso per un numero elevato di utenti. La sincronizzazione dei gruppi di ruoli e organizzazioni consente di mantenere Active Directory come posizione principale per la gestione dell'accesso.

Se implementi in modo coerente i gruppi di risorse come gruppi locali del dominio e i gruppi di ruoli e organizzazione come gruppi globali o universali, puoi utilizzare il tipo di gruppo per assicurarti che vengano sincronizzati solo i gruppi di ruoli e organizzazione.

La questione se sia sufficiente eseguire una singola istanza di GCDS per foresta multidominio o se siano necessarie più istanze di GCDS diventa la questione se utilizzi gruppi globali. Se implementi tutti i gruppi di ruoli e organizzazione utilizzando i gruppi universali, è sufficiente una sola istanza di GCDS; in caso contrario, avrai bisogno di un'istanza di GCDS per dominio.

Mappare le identità dei gruppi

La mappatura dei gruppi di sicurezza di Active Directory ai gruppi Cloud Identity o Google Workspace richiede un identificatore comune. In Cloud Identity e Google Workspace, questo identificatore deve essere un indirizzo email la cui parte del dominio corrisponde a un dominio principale, secondario o alias dell'account Cloud Identity o Google Workspace. Poiché questo indirizzo email verrà utilizzato ovunque Google Cloud, deve essere leggibile. L'indirizzo email non deve corrispondere a una casella di posta.

In Active Directory, i gruppi vengono identificati dal nome comune (cn) o da un nome di accesso precedente a Windows 2000 (sAMAccountName). Come gli account utente, anche i gruppi possono avere un indirizzo email (mail), ma gli indirizzi email sono un attributo facoltativo per i gruppi e Active Directory non verifica l'unicità.

Hai due opzioni per mappare le identità di gruppo tra Active Directory e Cloud Identity o Google Workspace.

Mappa per nome comune

Il vantaggio di utilizzare il nome comune (cn) è che è garantito che sia disponibile e, almeno all'interno di un'unità organizzativa, univoco. Tuttavia, il nome comune non è un indirizzo email, quindi deve essere aggiunto un suffisso @DOMAIN per trasformarlo in un indirizzo email.

Puoi configurare GCDS in modo che si occupi automaticamente di aggiungere un suffisso al nome del gruppo. Poiché Active Directory garantisce che i nomi dei gruppi e degli utenti non siano in conflitto, è improbabile che un indirizzo email derivato in questo modo causi conflitti.

Se la foresta Active Directory contiene più di un dominio, si applicano le seguenti avvertenze:

• Se due gruppi in domini diversi condividono un nome comune, l'indirizzo email derivato sarà in conflitto, causando l'ignoramento di un gruppo durante la sincronizzazione.
• Puoi sincronizzare i gruppi solo dai domini di una singola foresta. Se sincronizzi i gruppi di più foreste utilizzando istanze GCDS separate, gli indirizzi email derivati dal nome comune non riflettono la foresta a cui corrispondono. Questa ambiguità farà sì che un'istanza GCDS elimini qualsiasi gruppo creato in precedenza da un'altra foresta da un'altra istanza GCDS.
• Non puoi mappare i gruppi in base al nome comune se utilizzi la sostituzione del dominio per mappare gli utenti.

Mappa per indirizzo email

L'utilizzo dell'indirizzo email (mail) per mappare le identità dei gruppi significa che devi soddisfare gli stessi criteri di quando utilizzi l'indirizzo email per mappare gli utenti:

• Le assegnazioni email devono essere complete. Sebbene sia comune che i gruppi di distribuzione abbiano un indirizzo email, spesso i gruppi di sicurezza non dispongono di questo attributo. Per utilizzare l'indirizzo email per mappare le identità, i gruppi di sicurezza soggetti alla sincronizzazione devono avere il campo mail compilato. Il seguente comando PowerShell può aiutarti a trovare gli account per i quali questo campo non è compilato:

  Get-ADGroup -LDAPFilter "(!mail=*)"

• Gli indirizzi email devono utilizzare un insieme selezionato di domini, tutti di tua proprietà. Se alcuni dei tuoi utenti utilizzano indirizzi email che fanno riferimento a società partner o provider di posta elettronica per i consumatori, non puoi utilizzare questi indirizzi.

• Tutti gli indirizzi email devono essere univoci nella foresta. Poiché Active Directory non impone l'unicità, potresti dover implementare controlli o criteri personalizzati.

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

Se uno dei criteri non viene soddisfatto, puoi comunque mappare gli UPN agli indirizzi email di Cloud Identity o Google Workspace, con le seguenti avvertenze:

• I gruppi senza indirizzi email verranno ignorati durante la sincronizzazione, così come gli indirizzi email che utilizzano domini non associati all'account Cloud Identity o Google Workspace.
• Quando due gruppi condividono lo stesso indirizzo email, solo uno di questi verrà sincronizzato.

La mappatura dei gruppi per indirizzo email non è supportata se la foresta Active Directory contiene più di un dominio e utilizzi la sostituzione del dominio per mappare gli utenti.

Mappare le unità organizzative

La maggior parte dei domini Active Directory utilizza ampiamente le unità organizzative per raggruppare e organizzare le risorse in modo gerarchico, controllare l'accesso e applicare i criteri.

In Google Cloud, cartelle e progetti hanno uno scopo simile, anche se i tipi di risorse gestite all'interno di un'organizzazione Google Cloud sono molto diversi da quelli gestiti in Active Directory. Di conseguenza, una gerarchia di cartelle Google Cloud appropriata per un'azienda tende a differire in modo significativo dalla struttura delle unità organizzative in Active Directory. Il mapping automatico delle unità organizzative a cartelle e progetti è quindi raramente pratico e non è supportato da GCDS.

Indipendentemente dalle cartelle, Cloud Identity e Google Workspace supportano il concetto di unità organizzative. Le unità organizzative vengono create per raggruppare e organizzare gli utenti, in modo simile ad Active Directory. Tuttavia, a differenza di Active Directory, si applicano solo agli utenti, non ai gruppi.

GCDS offre la possibilità di sincronizzare le unità organizzative di Active Directory con Cloud Identity o Google Workspace. In una configurazione in cui Cloud Identity viene utilizzato solo per estendere la gestione delle identità di Active Directory a Google Cloud, la mappatura delle unità organizzative di solito non è necessaria.

Scegliere la mappatura giusta

Come indicato all'inizio di questo documento, non esiste un unico modo migliore per mappare le strutture di Active Directory e Google Cloud. Per aiutarti a scegliere la mappatura giusta per il tuo scenario, i seguenti grafici decisionali riepilogano i criteri discussi nelle sezioni precedenti.

Innanzitutto, consulta il seguente grafico per identificare il numero di account Cloud Identity o Google Workspace, istanze GCDS e istanze o flotte AD FS di cui avrai bisogno.

Poi, consulta il secondo grafico per identificare i domini da configurare nel tuo account Cloud Identity o Google Workspace.

Passaggi successivi

• Scopri le best practice per la pianificazione di account e organizzazioni e le best practice per la federazione Google Cloud con un provider di identità esterno.
• Configura GCDS per sincronizzare gli utenti e i gruppi di Active Directory con Cloud Identity.
• Configura il Single Sign-On tra Active Directory e Google Cloud.
• Scopri le best practice per la gestione degli account super amministratore