Federare Google Cloud con Active Directory

Last reviewed 2024-06-26 UTC

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

Il documento mette a confronto la struttura logica di Active Directory con la struttura utilizzata da Cloud Identity e Google Workspace e descrive come 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 degli accessi. La gestione manuale delle identità Google per ogni dipendente può comportare un sovraccarico amministrativo non necessario se tutti i dipendenti hanno già un account in Active Directory. Con la federazione delle identità utente tra Google Cloud e il tuo sistema di gestione delle identità esistente, puoi automatizzare la manutenzione delle identità Google e associarne il ciclo di vita agli utenti esistenti in Active Directory.

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

• 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 fare riferimento a questo utente 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'unica direzione, 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 Security Assertion Markup Language (SAML). Questa delega garantisce che solo Active Directory gestisca le credenziali degli utenti e che vengano applicati eventuali criteri o meccanismi di autenticazione a più fattori (MFA) applicabili. Tuttavia, per un accesso riuscito, il provisioning del rispettivo utente deve essere stato eseguito 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 calcolo 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 solitamente 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 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 prende il nome dal dominio principale della foresta. I domini in una foresta di Active Directory si basano sulla reciproca attendibilità, consentendo agli utenti autenticati in un dominio di accedere alle risorse di un altro dominio. A meno che i forest non siano collegati utilizzando i trust tra forest, per impostazione predefinita i forest separati non si considerano attendibili tra loro e gli utenti autenticati in un forest non possono accedere alle risorse di un altro forest.

I domini Active Directory sono contenitori per la gestione delle risorse e sono considerati confini 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 confini 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 tratta 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 invece 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 la modalità di autenticazione.

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

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 allo stesso modo 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.

Mappare le foreste

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

Foresta singola, dominio singolo

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 le basi per una singola organizzazione Google Cloud che puoi utilizzare per gestire le tue risorse Google Cloud.

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

Foresta singola, 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 singolo account Cloud Identity o Google Workspace. Questo account costituisce quindi la base di un'unica organizzazione Google Cloud che puoi utilizzare per gestire le risorse Google Cloud.

In un ambiente multidominio, esiste una differenza tra le informazioni che possono essere recuperate da un controller di dominio e quelle su cui è possibile eseguire query da un server di cataloghi globali. I controller di dominio pubblicano i dati solo del loro dominio locale, mentre i server di cataloghi globali forniscono l'accesso alle informazioni di tutti i domini della foresta. È fondamentale sottolineare che i dati forniti dai server del catalogo globale sono parziali e mancano di determinati attributi LDAP. Questa limitazione può influire sulla configurazione di GCDS per la sincronizzazione dei 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 un singolo parco AD FS per gestire l'accesso singolo.

Più foreste con attendibilità tra foreste

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

Se tutti i forest hanno una relazione di attendibilità bidirezionale con un altro forest, 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 risorse Google Cloud.

Sebbene i server di cataloghi globali forniscano l'accesso ai dati di più domini, il loro ambito è limitato a una singola foresta. Pertanto, in un ambiente con più foreste, devi eseguire query su più controller di dominio o server di cataloghi globali per ottenere, ad esempio, un elenco completo di utenti. A causa di questa limitazione, la federazione di un ambiente multiforesta con Google Cloud richiede almeno un'istanza GCDS per foresta. Le relazioni di attendibilità tra foreste consentono di gestire l'autenticazione utente oltre i confini della foresta, pertanto è sufficiente una singola istanza o un singolo parco AD FS per gestire il Single Sign-On.

Se il tuo ambiente si estende su più foreste senza attendibilità tra foreste, ma tutti i domini Active Directory pertinenti per la federazione con Google Cloud sono collegati tramite attendibilità esterne, valgono le stesse considerazioni.

Più foreste senza relazione di 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 un singolo parco AD FS gestire le richieste di accesso singolo per gli utenti di tutte le foreste.

Pertanto, non è possibile mappare più foreste prive di relazioni di attendibilità tra foreste a un singolo account Cloud Identity o Google Workspace. Ogni foresta deve invece essere mappata a un account Cloud Identity o Google Workspace separato, il che comporta l'esecuzione di almeno un'istanza GCDS e di un server o un parco risorse 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 distinte. 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, ad esempio corp.example.com, oppure un nome di dominio locale, ad esempio corp.local o corp.internal.
• Domini Mail Exchange (MX): gli indirizzi email utilizzano un dominio DNS. In alcuni casi, questo dominio corrisponde a quello 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 con suffisso UPN: questi domini vengono utilizzati per i nomi principali 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 dominiocorp.example.com, l'UPN predefinito è quindi [e-mail]. Tuttavia, puoi configurare una foresta in modo che utilizzi domini DNS aggiuntivi come suffissi UPN che non corrispondono 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 rivolti al pubblico, come i server AD FS, viene solitamente assegnato un nome DNS, ad esempio login.external.example.com. Il dominio utilizzato per queste finalità può sovrapporsi al dominio DNS MX, al suffisso UPN o al dominio DNS Active Directory oppure può essere un dominio completamente diverso.

Utilizzo dei domini DNS in Google Cloud

Accedi con Google, su cui si basa Google Cloud per l'autenticazione, utilizza gli indirizzi email per identificare gli utenti. L'utilizzo di indirizzi email non solo garantisce che siano unici a livello mondiale, 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 di dominio degli indirizzi email, che segue il @. Per un indirizzo email che utilizza il dominio gmail.com, ad esempio, Accedi con Google utilizza la directory degli utenti di Gmail per l'autenticazione.

Quando ti registri a un account Google Workspace o Cloud Identity, crei una directory privata che Accesso puó utilizzare per l'autenticazione. Come 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 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: oltre 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 distinti se example.com è il dominio principale e secondary.example.com è un dominio secondario.
• Alias dominio: un alias di dominio è un nome alternativo per un altro dominio. In altre parole, [e-mail] e [e-mail] fanno riferimento allo stesso utente se alias.example.com è configurato come dominio di alias per example.com.

Tutti i domini devono soddisfare i seguenti requisiti:

• Devono essere nomi di dominio DNS globali validi. Durante la configurazione, potresti dover avere 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 che utilizzano questo nome di dominio possano essere recapitati correttamente.

Per attivare 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 Active Directory e di come possono essere mappati a Cloud Identity o Google Workspace.

Map users (Mappa gli utenti)

Il terzo fattore da considerare quando prevedi 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: il SID, ovvero l'identificatore di sicurezza, viene utilizzato per tutti i controlli di accesso. Sebbene questo ID sia unico e stabile all'interno di un dominio, è possibile che, quando viene spostato in un altro dominio della foresta, a un utente venga assegnato un nuovo SID.

Nessuno di questi ID ha un significato per gli utenti, pertanto Active Directory offre due modi per identificare gli utenti che sono facili da ricordare:

• UPN (userPrincipalName): il modo migliore per identificare un utente è tramite UPN. Gli UPN rispettano il formato RFC 822 degli indirizzi email e vengono creati combinando il nome utente con un dominio del suffisso UPN, come [e-mail]. Sebbene siano il modo preferito per identificare gli utenti, i DN sono facoltativi, pertanto alcuni utenti della foresta Active Directory potrebbero non avere un DN.

  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 formatodomain<var>user, come in corp\johndoe. Anche se questi nomi sono considerati legacy, sono ancora di uso comune e rappresentano l'unico identificatore obbligatorio di un utente.

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

Tutti questi identificatori possono essere modificati in qualsiasi momento.

Mappa le identità degli utenti.

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

• Un ID univoco e stabile che puoi utilizzare durante la sincronizzazione per monitorare a quale utente di Active Directory corrisponde un utente di Cloud Identity o Google Workspace. Sul lato AD, objectGUID è perfettamente adatto a questo scopo.
• Un indirizzo email per cui la parte del dominio corrisponde a un dominio primario, secondario o alias del tuo account Cloud Identity o Google Workspace. Poiché questo indirizzo email verrà utilizzato in tutto Google Cloud, assicurati che sia significativo. È impraticabile ricavare un indirizzo dal objectGUID, così come per altri indirizzi email generati automaticamente.

Per un utente Active Directory, sono disponibili due campi per 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 di suffisso UPN devono essere anche domini MX e devono essere configurati in modo che un'email inviata all'UPN di un utente venga recapitata nella sua casella di posta.

• I compiti UPN devono essere completati. A tutti gli utenti soggetti alla sincronizzazione deve essere assegnato un UPN. Il seguente comando PowerShell può aiutarti a trovare gli utenti che non dispongono di un UPN:

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

Se questi due criteri sono soddisfatti, puoi mappare in sicurezza 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 eventuali altri domini con suffisso UPN come domini secondari.

Se uno dei criteri non è soddisfatto, puoi comunque mappare gli UPN agli indirizzi email di Cloud Identity o Google Workspace, ma valgono 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 in modo da sostituire il dominio del suffisso UPN con un altro dominio. Tuttavia, se utilizzi più domini con suffisso UPN in una foresta, questo approccio può creare duplicati perché tutti i domini con suffisso UPN verranno sostituiti da un singolo dominio. In caso di duplicati, puoi sincronizzare un solo utente.

Un vantaggio principale dell'utilizzo dei DNP per mappare gli utenti è che sono garantiti come univoci in una foresta e utilizzano un insieme selezionato 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 alla sincronizzazione:

• I compiti via email devono essere completi. Per tutti gli utenti soggetti alla sincronizzazione deve essere compilato il campo mail. 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 utenti utilizzano indirizzi email che fanno riferimento a società partner o provider email per i consumatori, questi indirizzi non possono essere utilizzati.

• Tutti gli indirizzi email devono essere univoci nella foresta. Poiché Active Directory non impone l'unicità, potrebbe essere necessario implementare criteri o controlli 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 è soddisfatto, puoi comunque mappare gli indirizzi email agli indirizzi email di Cloud Identity o Google Workspace, con le seguenti limitazioni:

• 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, verrà sincronizzato solo un utente.
• Puoi configurare la sincronizzazione in modo da sostituire il dominio degli indirizzi email con un altro dominio. Questa procedura può creare duplicati, in questo caso verrà sincronizzato un solo utente.

Gruppi di mappe

Il quarto fattore da considerare 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 spesso 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 insieme completo 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 sia i gruppi di distribuzione regolari che quelli 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. Dopo aver 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 dell'accesso. Per mantenere Active Directory come sistema centrale per la gestione delle identità e l'accesso, 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 dell'accesso di Active Directory. Questo ruolo è facilitato da tre diversi tipi di gruppi di Active Directory: gruppi locali di dominio, gruppi globali e gruppi universali.

Gruppi locali di dominio

Questi gruppi sono pertinenti solo nell'ambito di un singolo dominio e non è possibile fare riferimento ad altri domini. Poiché il loro elenco di membri non deve essere replicato nella foresta, i gruppi locali di dominio sono i più flessibili rispetto ai tipi di membri che possono includere.

Gruppi globali

Questi gruppi vengono visualizzati e possono essere richiamati in altri domini. Tuttavia, l'elenco dei membri non viene 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 ai relativi elenchi di membri, vengono replicati nella foresta. Pertanto, è possibile fare riferimento a questi gruppi in altri domini e includere non solo utenti e altri gruppi universali, ma anche gruppi globali di tutti i domini.

Se la foresta 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 un 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 al riguardo. Anche se questa limitazione è deliberata e contribuisce ad accelerare la replica della directory, rappresenta un ostacolo quando vuoi sincronizzare questi gruppi con Cloud Identity o Google Workspace. In particolare, se configuri GCDS per utilizzare un server del catalogo globale come origine, lo strumento potrà 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 di membri e saranno adatti alla replica. Per sincronizzare i gruppi di dominio locale o globali in una foresta multidominio, devi eseguire un'istanza GCDS distinta per dominio.

Poiché i gruppi universali sono completamente replicati nella foresta, non sono soggetti a questa limitazione. Una singola istanza GCDS può sincronizzare 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 potrebbe non essere necessario sincronizzare tutti i gruppi. Per questo motivo, vale la pena esaminare in che modo 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 gli utenti che hanno accesso. Le risorse e le ACL sono molto granulari, quindi ce ne sono molte. Per semplificare la manutenzione delle ACL, è comune creare gruppi di risorse per raggruppare le risorse che vengono utilizzate e a cui si accede frequentemente. Aggiungi il gruppo di risorse una volta a tutte le ACL interessate e gestisci ulteriori accessi modificando l'appartenenza al gruppo di risorse, non modificando le ACL.

Le risorse raggruppate in questo modo in genere si trovano in un unico dominio. Di conseguenza, anche un gruppo di risorse tende a essere fatto riferimento solo in un singolo dominio, nelle ACL o da altri gruppi di risorse. Poiché la maggior parte dei gruppi di risorse è locale, in genere vengono implementati utilizzando i gruppi locali di dominio in Active Directory.

Gruppi di ruoli e organizzazioni

I gruppi di risorse semplificano la gestione dell'accesso, 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 spesso integrati 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 tecnica potrebbe concedere ai membri l'accesso di sola lettura a tutta la documentazione tecnica. In pratica, lo implementeresti 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 di organizzazioni aggregano le autorizzazioni richieste dai reparti all'interno di un'organizzazione. Ad esempio, un gruppo dell'organizzazione chiamato Ingegneria potrebbe concedere l'accesso a tutte le risorse di solito richieste dai membri del reparto Ingegneria.

Tecnicamente, non c'è differenza tra gruppi di ruoli e gruppi di risorse e i due vengono spesso utilizzati insieme. Tuttavia, a differenza dei gruppi di risorse, i gruppi di ruoli e di organizzazioni possono avere rilevanza oltre i confini di un dominio. Per consentire il riferimento a questi gruppi da parte di gruppi di risorse in altri domini, i gruppi di ruoli e di organizzazioni vengono in genere implementati utilizzando gruppi globali, che sono limitati 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 multidominio.

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 essere nidificati in altri account e possono essere utilizzati in qualsiasi organizzazione Google Cloud.

Come per gli utenti, Cloud Identity e Google Workspace identificano i gruppi tramite indirizzo email. L'indirizzo email non deve 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 per elencare altri membri dello stesso gruppo. Al contrario, le query sull'appartenenza al gruppo generalmente richiedono l'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 determinato tipo che rientrano in un determinato ambito. Ad esempio, il ruolo Sviluppatore Kubernetes Engine ha accesso completo agli oggetti dell'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 sincronizzarli con Google Cloud.

I gruppi di ruoli e i gruppi di organizzazioni sono 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 di organizzazioni consente di mantenere Active Directory come luogo principale per la gestione dell'accesso.

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

La domanda se sia sufficiente eseguire una singola istanza GCDS per foresta multidominio o se hai bisogno di più istanze GCDS diventa la domanda se utilizzi gruppi globali. Se implementi tutti i gruppi di ruoli e di organizzazioni utilizzando i gruppi universali, è sufficiente una singola istanza GCDS. In caso contrario, è necessaria un'istanza GCDS per dominio.

Mappa le identità dei gruppi

La mappatura dei gruppi di sicurezza di Active Directory ai gruppi di Cloud Identity o Google Workspace richiede un identificatore comune. In Cloud Identity e Google Workspace, questo identificatore deve essere un indirizzo email per il quale la parte del dominio corrisponde a un dominio principale, secondario o alias dell'account Cloud Identity o Google Workspace. Poiché questo indirizzo email verrà utilizzato in tutta Google Cloud, deve essere leggibile da una persona. L'indirizzo email non deve necessariamente corrispondere a una cassetta postale.

In Active Directory, i gruppi vengono identificati dal nome comune (cn) o da un nome di accesso precedente a Windows 2000 (sAMAccountName). Come per gli account utente, i gruppi possono avere anche un indirizzo email (mail), ma gli indirizzi email sono un attributo facoltativo per i gruppi e Active Directory non ne 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 dell'utilizzo del nome comune (cn) è che è garantito essere disponibile e, almeno all'interno di un'unità organizzativa, univoco. Tuttavia, il nome comune non è un indirizzo email, quindi è necessario 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 di gruppo e di utente non siano in conflitto, è improbabile che un indirizzo email ottenuto in questo modo causi conflitti.

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

• Se due gruppi in domini diversi condividono un nome comune, l'indirizzo email derivato sarà in conflitto e un gruppo verrà ignorato durante la sincronizzazione.
• Puoi sincronizzare i gruppi solo dai domini di un'unica foresta. Se sincronizzi i gruppi da più foreste utilizzando istanze GCDS separate, gli indirizzi email ricavati dal nome comune non riflettono la foresta a cui corrispondono. Questa ambiguità causerà l'eliminazione da parte di un'istanza GCDS di qualsiasi gruppo creato in precedenza da un'altra istanza GCDS in una foresta diversa.
• Non puoi mappare i gruppi in base al nome comune se utilizzi la sostituzione del dominio per mappare gli utenti.

Mappa per indirizzo email

Se utilizzi l'indirizzo email (mail) per mappare le identità di gruppo, devi soddisfare gli stessi criteri previsti per l'utilizzo dell'indirizzo email per mappare gli utenti:

• I compiti via email devono essere completi. Sebbene sia comune che i gruppi di distribuzione abbiano un indirizzo email, spesso i gruppi di sicurezza mancano di questo attributo. Per utilizzare l'indirizzo email per la mappatura delle 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 fornitori di servizi email per i consumatori, non puoi utilizzare questi indirizzi.

• Tutti gli indirizzi email devono essere univoci nella foresta. Poiché Active Directory non impone l'unicità, potrebbe essere necessario implementare criteri o controlli 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 li includa.

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

• 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 in base all'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 fa un uso intensivo delle 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 una 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 notevolmente dalla struttura delle unità organizzative in Active Directory. La mappatura automatica delle unità organizzative a cartelle e progetti è quindi raramente pratica e non supportata da GCDS.

A prescindere 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, in genere non è necessaria la mappatura delle unità organizzative.

Scegli 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 corretta per il tuo scenario, i seguenti grafici di decisione riepilogano i criteri discussi nelle sezioni precedenti.

Innanzitutto, consulta il seguente grafico per identificare quanti account Cloud Identity o Google Workspace, istanze GCDS e istanze o parchi AD FS avrai bisogno.

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

Passaggi successivi

• Consulta 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 GCDS per sincronizzare gli utenti e i gruppi di Active Directory con Cloud Identity.
• Configura Single Sign-On tra Active Directory e Google Cloud.
• Scopri le best practice per la gestione degli account super amministratore