Federazione di Google Cloud con Active Directory

Last reviewed 2023-02-27 UTC

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

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

Questo articolo presuppone che tu conosca Active Directory.

Implementazione della federazione

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

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

• Provisioning utenti: gli utenti e i gruppi pertinenti vengono sincronizzati periodicamente da Active Directory a Cloud Identity o Google Workspace. Questo processo garantisce che quando si crea un nuovo utente in Active Directory, è possibile farvi riferimento in 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 vengano propagate.

  Il provisioning funziona in un modo, il che significa che le modifiche in Active Directory vengono replicate in Google Cloud e 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 eseguire l'autenticazione, 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 criteri o i meccanismi di autenticazione a più fattori (MFA) applicabili. Tuttavia, affinché l'accesso vada a buon fine, è necessario che il provisioning del rispettivo utente sia già stato eseguito in precedenza.

Per implementare la federazione, puoi utilizzare i seguenti strumenti:

• Google Cloud Directory Sync è uno strumento gratuito fornito da Google che implementa il processo di sincronizzazione. Google Cloud Directory Sync comunica con Google Cloud tramite SSL (Secure Sockets Layer) e di solito viene eseguito nell'ambiente di elaborazione 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 solitamente viene eseguito nell'ambiente di calcolo esistente.

Poiché le API per Google Cloud sono disponibili pubblicamente e SAML è uno standard aperto, sono disponibili molti strumenti per implementare la federazione. Questo articolo spiega come utilizzare Google Cloud Directory Sync e AD FS.

Struttura logica di Active Directory

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

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

Struttura logica di Google Cloud

In Google Cloud, le organizations fungono da container per tutte le risorse e possono essere ulteriormente segmentate utilizzando cartelle e progetti. Di conseguenza, organizzazioni, cartelle e progetti hanno uno scopo simile ai domini Active Directory.

Active Directory tratta gli utenti come risorse, quindi la gestione e l'autenticazione degli utenti sono legate ai domini. Al contrario, Google Cloud non gestisce gli utenti in un'organizzazione, ad eccezione degli account di servizio. Google Cloud si affida invece a Cloud Identity o Google Workspace per la gestione degli 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 il modo in cui può essere eseguita l'autenticazione.

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

Integrazione di 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. Al contrario, il giusto approccio all'integrazione dei due sistemi e alla mappatura della struttura dipende da diversi fattori:

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

Nelle sezioni che seguono vengono esaminati ciascuno di questi fattori.

Mappatura di foreste

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

Foresta singola, dominio singolo

Quando una foresta include un solo dominio, puoi mappare l'intera foresta di 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 con singolo dominio, i controller di dominio e i server di catalogo globali forniscono entrambi l'accesso a tutti gli oggetti gestiti in Active Directory. Nella maggior parte dei casi, puoi eseguire una singola istanza di Google Cloud Directory Sync per sincronizzare gli account utente e i gruppi con Google Cloud e per gestire una singola istanza o parco risorse ADFS per gestire il Single Sign-On.

Foresta singola, più domini

Quando una foresta contiene più domini Active Directory, puoi organizzarli in una o più strutture di domini. In entrambi i casi, puoi mappare l'intera foresta 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 con più domini, esiste una differenza tra le informazioni che è possibile recuperare da un controller di dominio e quelle che è possibile interrogare da un server di catalogo globale. Mentre i controller di dominio gestiscono i dati solo dal proprio dominio locale, i server di catalogo globali forniscono l'accesso alle informazioni di tutti i domini della foresta. Essenzialmente, i dati forniti dai server di catalogo globali sono parziali e non dispongono di alcuni attributi LDAP. Questa limitazione può influire sulla configurazione di Google Cloud Directory Sync per la sincronizzazione dei gruppi.

A seconda di come prevedi di mappare i gruppi, la federazione di una foresta multi-dominio con Google Cloud richiede una o più istanze di Google Cloud Directory Sync, ma solo una singola istanza o parco risorse ADFS per gestire il Single Sign-On.

Più foreste con fiducia tra foreste

Nelle organizzazioni più grandi, non è raro che esista più di una foresta di Active Directory, spesso a seguito di una fusione o acquisizione. Puoi combinare queste foreste utilizzando un 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 attendibilità 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 organizzazione Google Cloud che puoi utilizzare per gestire le tue risorse Google Cloud.

Sebbene i server di catalogo globali forniscano l'accesso ai dati di più domini, il loro ambito è limitato a una singola foresta. Quindi, in un ambiente multi-foresta, devi eseguire query su più controller di dominio o server di catalogo globali per ottenere, ad esempio, un elenco completo di utenti. Come conseguenza di questa limitazione, la fede a un ambiente multi-foresta con Google Cloud richiede almeno un'istanza di Google Cloud Directory Sync per ogni foresta. I trust tra foreste consentono il funzionamento dell'autenticazione utente oltre i confini delle foreste, quindi una singola istanza o parco risorse di ADFS è 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 Cloud sono connessi tramite trust esterni, si applicano le stesse considerazioni.

Più foreste senza trust tra foreste

Nell'ambiente illustrato qui, non è possibile autenticare o accedere alle risorse oltre i confini della foresta. Inoltre, non è possibile per una singola istanza o parco risorse ADFS gestire le richieste Single Sign-On per gli utenti di tutte le foreste.

Pertanto, non è possibile mappare più foreste in cui mancano trust tra foreste a un singolo account Cloud Identity o Google Workspace. Ogni foresta deve essere mappata a un account Cloud Identity o Google Workspace separato, il che prevede l'esecuzione di almeno un'istanza di Google Cloud Directory Sync e un server o un parco risorse ADFS per ogni 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 in modo efficace un'organizzazione federata con più foreste di Active Directory. Le altre organizzazioni rimangono inutilizzate.

Mappatura dei domini DNS

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

Utilizzo di domini DNS in Active Directory

In una foresta di 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 essere un nome di dominio locale come corp.local o corp.internal.
• Domini MX (Mail Exchange): 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 di Active Directory dispongono dell'indirizzo email associato all'attributo facoltativo mail.
• Domini suffisso UPN: questi domini vengono utilizzati per i nomi entità utente (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, il valore UPN predefinito è quindi [e-mail]. Tuttavia, puoi configurare una foresta in modo che utilizzi domini DNS aggiuntivi come suffissi UPN che non corrispondono né a domini DNS di Active Directory né a domini MX. Gli UPN sono facoltativi e vengono memorizzati nel campo userPrincipalName dell'utente.
• Domini endpoint: ai server rivolti al pubblico, come i server AD FS, viene solitamente assegnato un nome DNS, ad esempio login.external.example.com. Il dominio utilizzato per questi scopi può sovrapporsi al dominio MX, al suffisso UPN o al dominio DNS di Active Directory oppure può essere un dominio completamente diverso.

Utilizzo di domini DNS in Google Cloud

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

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

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

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

Tutti i domini devono soddisfare i seguenti requisiti:

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

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

Mappatura degli utenti

Il terzo fattore da considerare quando si pianifica la federazione di Active Directory e Google Cloud è la modalità di mappatura degli 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 globale viene generato quando viene creato un utente e non cambia mai.
• objectSID: il 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, quando viene spostato in un dominio diverso nella foresta, a un utente venga assegnato un nuovo SID.

Nessuno di questi ID è significativo per gli utenti, quindi Active Directory offre due modalità di identificazione intuitive:

• UPN (userPrincipalName): il modo migliore 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 con suffisso UPN, ad esempio [e-mail]. Pur essendo il metodo preferito per identificare gli utenti, gli UPN sono facoltativi, quindi alcuni utenti nella foresta di Active Directory potrebbero non disporre di un UPN.

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

• Nome di accesso pre-Windows 2000 (sAMAccountName): questo nome combina il nome di dominio e il nome utente NetBIOS utilizzando il formato domain<var>user, come in corp\johndoe. Anche se sono considerati legacy, questi nomi sono ancora di uso comune 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.

Mappatura delle identità degli utenti

La mappatura degli utenti di Active Directory agli utenti di Cloud Identity o Google Workspace richiede due informazioni per ogni utente:

• Un ID univoco e stabile che puoi utilizzare durante la sincronizzazione per tenere traccia di quale utente di Active Directory corrisponde a quale utente in Cloud Identity o Google Workspace. Per quanto riguarda AD, objectGUID è perfettamente adatto a questo scopo.
• Un indirizzo email il cui dominio corrisponde a un dominio principale, secondario o alias del tuo account Cloud Identity o Google Workspace. Poiché questo indirizzo email verrà utilizzato in Google Cloud, assicurati che sia significativo. Non è facile ottenere un indirizzo da objectGUID, così come lo sono altri indirizzi email generati automaticamente.

Per un utente di Active Directory, possono essere forniti due campi per fornire un indirizzo email di Cloud Identity o Google Workspace: userPrincipalName e mail.

Mappatura per nome entità utente

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

• Gli UPN devono essere indirizzi email validi. Anche tutti i domini utilizzati come domini suffisso UPN devono essere domini MX e devono essere configurati in modo che l'email inviata all'UPN di un utente venga recapitata alla sua posta in arrivo.

• Le assegnazioni UPN devono essere completate. A tutti gli utenti soggetti alla sincronizzazione deve essere assegnato un UPN. Il seguente comando PowerShell può aiutarti a trovare gli utenti privi di un UPN:

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

Se questi due criteri vengono soddisfatti, puoi mappare in sicurezza gli UPN agli indirizzi email di Cloud Identity o Google Workspace. Puoi utilizzare uno dei domini dei suffissi UPN come dominio principale in Cloud Identity o Google Workspace e aggiungere eventuali 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 avvertenze:

• Se gli UPN non sono indirizzi email validi, gli utenti potrebbero non ricevere le email di notifica inviate da Google Cloud e questo potrebbe portare alla 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. Tuttavia, quando utilizzi più domini di suffissi UPN in una foresta, questo approccio può creare duplicati, poiché tutti i domini dei suffissi UPN verranno sostituiti da un singolo dominio. In caso di duplicati, è possibile sincronizzare un solo utente.

Uno dei principali vantaggi dell'utilizzo degli UPN per mappare gli utenti è che gli UPN sono garantiti per essere univoci in una foresta e utilizzano un insieme selezionato di domini, che consente di evitare potenziali problemi di sincronizzazione.

Mappatura per indirizzo email

L'utilizzo del campo mail richiede che vengano soddisfatti i seguenti criteri per tutti gli utenti soggetti a sincronizzazione:

• Le assegnazioni degli indirizzi email devono essere completate. Il campo mail di tutti gli utenti soggetti a sincronizzazione deve essere compilato. Il seguente comando di 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 ad aziende partner o provider email di tipo consumer, questi non possono essere utilizzati.

• Tutti gli indirizzi email devono essere univoci all'interno della foresta. Poiché Active Directory non applica l'univocità, potrebbe essere necessario 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 di Cloud Identity o Google Workspace, tenendo presenti le seguenti avvertenze:

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

Gruppi di mappatura

Il quarto fattore da considerare quando si pianifica la federazione di 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 come un modo per gestire in modo efficiente l'accesso tra progetti. Invece di assegnare singoli utenti ai ruoli IAM in ogni progetto, puoi definire un insieme di gruppi che modellano i ruoli comuni nella tua organizzazione e assegnare 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 è importante quando esegui la migrazione da Microsoft Exchange a Google Workspace, pertanto Google Cloud Directory Sync può gestire gruppi di distribuzione normali e dinamici. Tuttavia, i gruppi di distribuzione non sono un problema nella gestione di identità e accessi per Google Cloud, quindi questa discussione è incentrata 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 iscrizioni 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 degli accessi di 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 è possibile fare riferimento in altri domini. Poiché il loro 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 mostrati e possono essere utilizzati come riferimento in altri domini. Tuttavia, l'elenco dei membri non è replicato. Questa limitazione limita 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 agli elenchi dei membri, vengono replicati nella foresta. Pertanto, possono essere utilizzati come riferimento 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 Google Cloud Directory Sync. Se la foresta di 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 di catalogo globali contengono informazioni incomplete su di essi. Sebbene questa limitazione sia intenzionale e contribuisca a velocizzare la replica delle directory, rappresenta un ostacolo quando vuoi sincronizzare questi gruppi con Cloud Identity o Google Workspace. In particolare, se configuri Google Cloud Directory Sync in modo da utilizzare un server di catalogo globale come origine, lo strumento sarà in grado di trovare gruppi di tutti i domini nella foresta. Tuttavia, solo i gruppi che si trovano nello stesso dominio del server di catalogo globale conterranno un elenco di appartenenza e saranno idonei alla replica. Per sincronizzare gruppi locali o globali del dominio in una foresta di più domini, devi eseguire un'istanza di Google Cloud Directory Sync separata per dominio.

Poiché i gruppi universali sono completamente replicati nella foresta, non hanno questa limitazione. Una singola istanza di Google Cloud Directory Sync può sincronizzare gruppi universali da più domini.

Prima di concludere che sono necessarie più istanze di Google Cloud Directory Sync per sincronizzare più domini Active Directory con Cloud Identity o Google Workspace, tieni presente che potrebbe non essere necessario sincronizzare tutti i gruppi. Per questo motivo, è utile osservare come vengono generalmente utilizzati diversi tipi di gruppi di sicurezza nella foresta di Active Directory.

Utilizzo dei gruppi di sicurezza in Active Directory

Gruppi di risorse

Windows utilizza un modello di accesso basato su elenchi di controllo dell'accesso (ACL). A ogni risorsa, ad esempio un file o un oggetto LDAP, è associato un ACL che controlla quali utenti possono accedervi. Le risorse e gli ACL sono molto granulari, perciò ce ne sono molti. Per semplificare la manutenzione degli ACL, è comune creare gruppi di risorse per raggruppare le risorse utilizzate e a cui si accede di frequente insieme. Puoi aggiungere il gruppo di risorse a tutti gli ACL interessati una sola volta e gestire ulteriormente l'accesso modificando l'appartenenza al gruppo di risorse, non modificando gli ACL.

Le risorse raggruppate in questo modo di solito risiedono in un solo dominio. Di conseguenza, un gruppo di risorse tende a essere indicato solo in un singolo dominio, negli ACL o in altri gruppi di risorse. Poiché la maggior parte dei gruppi di risorse è locale, di solito viene implementata 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 potrebbe essere necessario aggiungere un nuovo utente a un numero elevato di gruppi di risorse. Per questo motivo, i gruppi di risorse sono in genere completati da gruppi di ruoli o gruppi di organizzazioni.

I gruppi di ruoli aggregano le autorizzazioni richieste da un ruolo specifico nell'organizzazione. Ad esempio, un gruppo di ruoli denominato Visualizzatore della documentazione di progettazione potrebbe concedere ai membri l'accesso di sola lettura a tutta la documentazione di progettazione. In pratica, dovresti 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 di organizzazioni denominato Ingegneria potrebbe concedere l'accesso a tutte le risorse generalmente richieste dai membri del dipartimento di ingegneria.

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 organizzazioni possono avere pertinenza oltre i confini di un dominio. Per consentire a gruppi di risorse di altri domini di fare riferimento a questi gruppi, i gruppi di ruoli e organizzazioni vengono in genere implementati utilizzando gruppi globali, vincolati ai membri di un singolo dominio, e talvolta integrati da gruppi universali, che consentono membri di domini diversi.

Il seguente diagramma mostra un pattern di nidificazione comunemente utilizzato negli ambienti Active Directory a più domini.

Gruppi in Cloud Identity e Google Workspace

In Cloud Identity e Google Workspace esiste un solo tipo di gruppo. I gruppi in Cloud Identity e Google Workspace non sono limitati all'ambito dell'account Cloud Identity o Google Workspace in cui sono stati definiti. Possono invece includere utenti di account Cloud Identity o Google Workspace diversi, supporto a cui viene fatto riferimento e nidificato in altri account e possono essere utilizzati in qualsiasi organizzazione Google Cloud.

Come per gli utenti, Cloud Identity e Google Workspace identificano i gruppi 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 di Active Directory, ai membri di un gruppo Cloud Identity o Google Workspace non viene concessa implicitamente l'autorizzazione per elencare altri membri dello stesso gruppo. Invece, l'esecuzione di query sull'appartenenza ai gruppi generalmente 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 su ACL. I ruoli si applicano a tutte le risorse di un certo 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 in un determinato progetto. A causa della natura dei ruoli, non è necessario gestire gruppi di risorse su Google Cloud e raramente è necessario sincronizzare i gruppi di risorse con Google Cloud.

I gruppi di ruoli e i gruppi delle organizzazioni sono pertinenti in Google Cloud quanto lo sono 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 luogo principale per la gestione degli accessi.

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

La domanda se sia sufficiente eseguire una singola istanza di Google Cloud Directory Sync per ogni foresta di più domini o se hai bisogno di più istanze di Google Cloud Directory Sync diventa il problema se utilizzi o meno i gruppi globali. Se implementi tutti i ruoli e i gruppi dell'organizzazione utilizzando i gruppi universali, è sufficiente una singola istanza di Google Cloud Directory Sync; in caso contrario, avrai bisogno di un'istanza di Google Cloud Directory Sync per ogni dominio.

Mappatura delle identità dei gruppi

La mappatura dei gruppi di sicurezza di Active Directory a gruppi di 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 al dominio principale, secondario o alias dell'account Cloud Identity o Google Workspace. Poiché questo indirizzo email verrà utilizzato in Google Cloud, l'indirizzo deve essere leggibile. L'indirizzo email non deve necessariamente corrispondere a una casella di posta.

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

Hai a disposizione due opzioni per mappare le identità dei gruppi tra Active Directory e Cloud Identity o Google Workspace.

Mappatura per nome comune

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

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

Se la foresta di 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 la mancanza 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 separate di Google Cloud Directory Sync, gli indirizzi email derivati dal nome comune non riflettono la foresta a cui corrispondono. Questa ambiguità porterà un'istanza di Google Cloud Directory Sync a eliminare qualsiasi gruppo che è stato precedentemente creato da una foresta diversa da un'altra istanza di Google Cloud Directory Sync.
• Non puoi mappare i gruppi in base al nome comune se utilizzi la sostituzione del dominio per la mappatura degli utenti.

Mappatura per indirizzo email

Utilizzare l'indirizzo email (mail) per mappare le identità dei gruppi significa che devi soddisfare gli stessi criteri utilizzati per mappare gli utenti:

• Le assegnazioni degli indirizzi email devono essere completate. Sebbene sia comune per i gruppi di distribuzione avere un indirizzo email, i gruppi di sicurezza spesso non dispongono di questo attributo. Per utilizzare l'indirizzo email per la mappatura delle identità, i gruppi di sicurezza soggetti a sincronizzazione devono avere il campo mail compilato. Il seguente comando PowerShell può aiutarti a trovare gli account per i quali questo campo non viene 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 ad aziende partner o provider email per consumatori, non puoi utilizzare questi indirizzi.

• Tutti gli indirizzi email devono essere univoci all'interno della foresta. Poiché Active Directory non applica l'univocità, potrebbe essere necessario 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, tenendo conto delle 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, verrà sincronizzato solo uno.

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

Mappatura delle unità organizzative

La maggior parte dei domini Active Directory fa un uso ampio delle unità organizzative per raggruppare e organizzare le risorse in modo gerarchico, controllare gli accessi e applicare i criteri.

In Google Cloud, cartelle e progetti hanno uno scopo simile, anche se i tipi di risorse che vengono gestite all'interno di un'organizzazione Google Cloud sono molto diversi dalle risorse gestite 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. La mappatura automatica delle unità organizzative a cartelle e progetti è pertanto raramente pratica e non supportata da Google Cloud Directory Sync.

Non relativamente alle 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. Ma, a differenza di Active Directory, si applicano solo agli utenti, non ai gruppi.

Google Cloud Directory Sync 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 unicamente per estendere la gestione delle identità di Active Directory a Google Cloud, la mappatura delle unità organizzative non è di solito necessaria.

Scegliere la mappatura giusta

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

Innanzitutto, fai riferimento al grafico seguente per identificare il numero di account Cloud Identity o Google Workspace, istanze di Google Cloud Directory Sync e istanze o parchi risorse di ADFS di cui hai bisogno.

Quindi, fai riferimento al secondo grafico per identificare i domini da configurare nel tuo account Cloud Identity o Google Workspace.

Passaggi successivi

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