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 confronta 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 dimestichezza con Active Directory.

Implementazione della federazione

Google Cloud utilizza le identità Google per l'autenticazione e la gestione degli accessi. Gestire manualmente le identità Google ogni dipendente può sovraccaricare quando tutti i dipendenti hanno già un account in 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, è possibile farvi riferimento in Google Cloud ancora prima l'utente associato ha 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 Active Directory utilizzando SAML (Security Assertion Markup Language) protocollo. Questa delega garantisce che solo Active Directory gestisca gli utenti credenziali e che tutti i criteri applicabili o l'autenticazione a più fattori dell'applicazione dei meccanismi (MFA). 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 (ADFS) è 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 container per uno o più domini e trae il proprio nome dal dominio principale della foresta. Domini in un trust di una foresta di Active Directory altri, consentendo agli utenti autenticati in un dominio di accedere alle risorse che si trovano in un altro dominio. A meno che i forest non siano collegati tramite 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 è uno semplificare l'amministrazione o applicare una struttura aggiuntiva, ma i domini in un una foresta non rappresentano i confini di sicurezza.

Struttura logica di Google Cloud

In Google Cloud, organizzazioni fungono da container per tutte le risorse e possono essere ulteriormente segmentati tramite cartelle e progetti. Organizzazioni, cartelle e progetti hanno quindi uno scopo simile a quello degli Domini della directory.

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

R 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, Un'organizzazione Google Cloud vengono creati automaticamente. 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 mappatura tra le due strutture funziona altrettanto bene in tutti gli scenari. È invece il giusto approccio per integrare due sistemi e la mappatura della struttura dipende da più 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 prendono in esame 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 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, 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, più casi, puoi eseguire una singola istanza di GCDS sincronizzare account utente e gruppi in Google Cloud e mantenere un un singolo parco risorse o un'istanza AD FS per gestire il Single Sign-On.

Una 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 costituisce quindi la base di un'unica organizzazione Google Cloud che puoi utilizzare per gestire le tue 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 sul modo in cui per configurare GCDS sincronizzare 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.

Foreste multiple con fiducia tra le 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 la tua Google Cloud.

Sebbene i server di cataloghi globali forniscano l'accesso ai dati di più domini, il loro ambito è limitato a una singola foresta. Quindi, in un ambiente con più foreste, è necessario 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 multiforesta con Google Cloud richiede almeno un'istanza GCDS per foresta. I trust tra foreste consentono l'autenticazione degli utenti per lavorare al di là dei confini della foresta, quindi un singolo o parco risorse sono sufficienti 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 qui illustrato, non è possibile eseguire l'autenticazione 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 in assenza di foreste interforeste considera attendibile un singolo account Cloud Identity o Google Workspace. Ogni foresta deve essere invece mappata a un'istanza Cloud Identity o account Google Workspace, che richiede l'esecuzione di almeno un account un'istanza GCDS e un server ADFS o un parco risorse per foresta.

In Google Cloud viene creata un'organizzazione separata per ogni account Cloud Identity o Google Workspace. Nella maggior parte dei casi, non devi gestire più organizzazioni separate. Puoi selezionare una delle le organizzazioni associarlo con gli altri account Cloud Identity o Google Workspace, creando in modo efficace un'organizzazione federata con più Foreste directory. Le altre organizzazioni rimangono inutilizzate.

Mappa 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 pianifichi federate Active Directory e Google Cloud sono le modalità di condivisione o mappatura del 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 potrebbe essere globale, ad esempio corp.example.com, oppure può essere un nome di dominio locale come corp.local o corp.internal.
• Domini MX (Mail Exchange): gli indirizzi email utilizzano un dominio DNS. Nella in alcuni casi, questo dominio è uguale al dominio DNS di Active Directory, in molti casi viene utilizzato un dominio diverso e spesso più corto, come example.com in uso. Idealmente, gli utenti in Active Directory hanno l'indirizzo email associato all'attributo facoltativo mail.
• Domini con suffissi UPN: questi domini vengono utilizzati per i nomi delle 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 dominiocorp.example.com, l'UPN predefinito è quindi [e-mail]. Tuttavia, puoi configurare una foresta in modo da utilizzare domini DNS aggiuntivi come UPN suffissi che non corrispondono né a domini DNS di Active Directory né a MX domini. Gli UPN sono facoltativi e sono memorizzati nel campo userPrincipalName dell'utente.
• Domini endpoint: i server rivolti al pubblico, come i server AD FS viene generalmente 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 Google Cloud fa affidamento per l'autenticazione, utilizza gli indirizzi email per identificare gli utenti. L'uso di indirizzi email non solo garantisce che siano globali univoco, ma consente anche a Google Cloud di inviare messaggi di notifica indirizzi IP esterni.

Accedi con Google determina la directory o il provider di identità da utilizzare per autenticare un utente in base alla parte del dominio degli indirizzi email, segue @. Per un indirizzo email che utilizza il dominio gmail.com, 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 l'account Google Workspace ed è utilizzato come nome dell'organizzazione in Google Cloud. Quando ti registri a Cloud Identity o Google Workspace, devi specificare questo nome di dominio.
• Dominio secondario: oltre al dominio principale, puoi associare altri domini secondari a un account Cloud Identity o Google Workspace. 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.
• Dominio alias: un dominio alias è un nome alternativo di un altro dominio. Vale a dire [e-mail] e [e-mail] si riferiscono allo stesso utente se alias.example.com è stato configurato come dominio alias per example.com.

Tutti i domini devono soddisfare i seguenti requisiti:

• Devono essere nomi di dominio DNS globali validi. Durante la configurazione, devi disporre dell'accesso amministrativo alle rispettive zone DNS per eseguire la proprietà del dominio.
• Un dominio, ad esempio example.com, può fare riferimento a una sola directory. Tuttavia, puoi utilizzare sottodomini diversi, ad esempio subdomain.example.com, per fare riferimento a directory diverse.
• I domini 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 i domini utilizzati da Cloud Identity o Google Workspace. Stabilire il giusto il mapping dipende da come si utilizza Active Directory e richiede un'analisi più approfondita la modalità di identificazione degli utenti in una foresta di Active Directory e la loro possibile mappate 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 un utente viene vengono creati e non vengono mai modificati.
• objectSID: il SID, o identificatore di sicurezza, viene usato per tutti i controlli di accesso. Anche se questo ID è univoci e stabili all'interno di un dominio, è possibile che, a un altro dominio della foresta, a un utente potrebbe essere 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 preferito per identificare un utente. è di UPN. Gli UPN seguono il formato RFC 822 degli indirizzi email e sono creato combinando il nome utente con un dominio con 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 indirizzi IP esterni, Active Directory non applica questa prassi.

• 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 comunemente usati e sono 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 è né obbligatorio né obbligatorio unici in una foresta.

Tutti questi identificatori possono essere modificati in qualsiasi momento.

Mappa le identità degli utenti.

Mappare gli utenti di Active Directory a Cloud Identity Gli utenti di Google Workspace richiedono due informazioni per ogni utente:

• Un ID univoco stabile che puoi utilizzare durante la sincronizzazione per monitorare quale utente Active Directory corrisponde a quale utente Cloud Identity o Google Workspace. Sul lato AD, objectGUID è la soluzione perfetta per 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 verrà utilizzato in tutto Google Cloud, assicurati che sia significativo. La ricavazione di un indirizzo da objectGUID è così come 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 la soddisfazione di due criteri per tutti Utenti soggetti a sincronizzazione:

• I nomi delle entità utente (UPN) devono essere indirizzi email validi. Tutti i domini che vengono utilizzate come UPN domini con suffisso anch'esso devono essere domini MX e devono essere configurati in modo che le email inviate all'UPN di un utente vengono recapitate alla loro posta in arrivo.

• I compiti UPN devono essere completati. Tutti gli utenti soggetti a di sincronizzazione deve avere un UPN assegnato. 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, è possibile sincronizzare un solo utente.

Uno dei principali vantaggi dell'utilizzo delle UPN per mappare gli utenti è che garantiscono unici in una foresta e utilizzano un insieme selezionato di domini, 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:

• Le assegnazioni email devono essere completate. Tutti gli utenti interessati alla sincronizzazione deve avere il campo mail compilato. Le seguenti Il comando PowerShell può aiutarti a trovare gli utenti per cui questo campo non è compilata:

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

• Gli indirizzi email devono utilizzare un insieme selezionato di domini, che sono tutti di tua proprietà. Se alcuni dei tuoi 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. Perché attivi La directory non applica l'univocità, potrebbe essere necessario implementare di Google Cloud.

Se tutti gli utenti pertinenti soddisfano questi criteri, puoi identificare tutti i domini utilizzati da questi indirizzi email e li utilizzano come indirizzi 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, solo uno riceverà sincronizzati.
• 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 sulla mappa

Il quarto fattore da considerare quando si pianifica 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 le un accesso a un l'intero set di risorse.

Active Directory distingue due tipi di gruppi: i 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, in modo che GCDS possa gestire sia i gruppi di distribuzione regolari che quelli dinamici. Gruppi di distribuzione la gestione di identità e accessi per Google Cloud, tuttavia, questa discussione si concentra esclusivamente sui gruppi di sicurezza.

La mappatura dei gruppi tra Active Directory e Google Cloud è facoltativa. Dopo aver configurare il provisioning degli utenti, puoi creare e gestire i gruppi direttamente Cloud Identity o Google Workspace, che significa che lo stato La directory rimane il sistema centrale per la gestione delle identità ma non per l'accesso gestione dei dispositivi. mantenere Active Directory come sistema centrale per le identità. e alla gestione degli accessi, ti consigliamo di sincronizzare gruppi 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 Gestione dell'accesso alla directory. Questo ruolo è facilitato da tre diversi tipi di gruppi di Active Directory: gruppi locali di 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 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 consultati 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 in una foresta. Di conseguenza, è 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 di Active Directory contiene un solo dominio, puoi sincronizza 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 sono completamente replicati in una foresta, i server di catalogo globale contengono informazioni incomplete. 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 nello stesso dominio del server del catalogo globale conterranno un elenco di membri e saranno adatti alla replica. Per sincronizzare il dominio locale gruppi globali in una foresta multidominio, devi eseguire Istanza GCDS 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 sono necessarie più istanze GCDS sincronizzare più domini Active Directory con Cloud Identity Google Workspace, tieni presente che non per tutti i gruppi potrebbe essere necessario sincronizzati. Per questo motivo, vale la pena esaminare in che modo i diversi tipi di i gruppi di sicurezza vengono in genere utilizzati in tutta la foresta di 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 degli ACL, è prassi comune creare gruppi di risorse per raggruppare le risorse utilizzate e a cui si accede di frequente in sinergia. Puoi aggiungere il gruppo di risorse a tutti gli ACL interessati una volta e gestire un ulteriore accesso modificando l'appartenenza al gruppo di risorse, non modificando 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 aiutano a semplificare la gestione degli accessi, ma in un ambiente di grandi dimensioni potresti dover aggiungere un nuovo utente a molti 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. Un gruppo di ruoli denominato Visualizzatore documentazione tecnica, per potrebbe concedere ai membri l'accesso di sola lettura a tutta la documentazione tecnica. In pratica, dovresti implementare questa procedura creando un gruppo di ruolo e creando un membro di tutti i gruppi di risorse utilizzati per controllare l'accesso a vari tipi della documentazione.

In modo simile, i gruppi di organizzazioni aggregano le autorizzazioni richiesta dai reparti all'interno di un'organizzazione. Ad esempio, un'organizzazione denominato Ingegneria potrebbe concedere l'accesso a tutte le risorse di cui i membri come richiesto dal dipartimento di 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 solitamente 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 modello di annidamento comunemente utilizzato in ambienti Active Directory multidominio.

Gruppi in Cloud Identity e Google Workspace

In Cloud Identity e Google Workspace, c'è un solo tipo di gruppo. Gruppi in Cloud Identity e Google Workspace non sono confinati nell'ambito di Cloud Identity l'account Google Workspace in cui sono stati definiti. Possono invece 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 di Active Directory, dei membri di un'istanza A un gruppo Google Workspace non è stata implicitamente concessa l'autorizzazione a elencare altri membri dello stesso gruppo. Al contrario, in genere la query sull'appartenenza al gruppo richiede l'autorizzazione esplicita.

Utilizzo di gruppi in Google Cloud

Google Cloud utilizza un modello di accesso basato su ruoli anziché un accesso basato su ACL un modello di machine learning. 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 Oggetti API Kubernetes all'interno di tutti i cluster in 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 organizzazioni sono altrettanto pertinenti in Google Cloud come in Active Directory, perché permettono di gestire più facilmente l'accesso per un gran numero 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 questione se sia sufficiente eseguire un singolo un'istanza GCDS per foresta multidominio o se ti servono di più istanze di GCDS diventa quindi la questione se usi i 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à di gruppo

La mappatura dei gruppi di sicurezza di Active Directory ai gruppi di Cloud Identity o Google Workspace richiede un identificatore comune. Nella Cloud Identity e Google Workspace, questo identificatore deve essere un per il quale la parte del dominio corrisponde a un indirizzo email o il dominio alias dell'account Cloud Identity o Google Workspace. Poiché questo indirizzo email verrà utilizzato in tutto Google Cloud, la classe deve essere leggibile. Non è necessario che l'indirizzo email corrisponda 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). Simile all'utente , i gruppi possono avere anche un indirizzo email (mail), mentre gli indirizzi email sono un attributo facoltativo per i gruppi, e Active Directory non verifica 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, nome comune non è un indirizzo email, quindi ha bisogno di un suffisso @DOMAIN aggiunto per trasformare in un indirizzo email.

Puoi configurare GCDS in modo che aggiunga automaticamente un suffisso al nome del gruppo. Poiché Active Directory assicura che nomi di gruppi e nomi utente non sono in conflitto, un indirizzo email che deriva questo è improbabile che causino 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 da domini di una singola foresta. Se sincronizza gruppi da più foreste utilizzando le istanze GCDS, gli indirizzi email derivati del nome comune non rispecchiano la foresta a cui corrispondono. Questo ambiguità farà sì che un'istanza GCDS elimini qualsiasi creato in precedenza da una foresta diversa da un altro GCDS.
• Non puoi mappare gruppi con nome comune se utilizzi la sostituzione del dominio per per gli utenti di mappatura.

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 non dispongono di questo attributo. Per utilizzare l'indirizzo email per la mappatura delle identità, i gruppi soggetti a sincronizzazione devono avere il campo mail compilate. 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 nell'intera foresta. Perché attivi La directory non applica l'univocità, potrebbe essere necessario implementare di Google Cloud.

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

Se uno dei criteri non è soddisfatto, puoi comunque mappare gli UPN a gli indirizzi email di Cloud Identity o Google Workspace, con 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 in base all'indirizzo email non è supportata se la tua Active Directory foresta contiene più di un singolo dominio e per i quali si utilizza la sostituzione per gli utenti di mappatura.

Mappa 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. Mappatura automatica a cartelle e progetti è quindi raramente una pratica ed è non supportato da GCDS.

Non correlato alle cartelle, assistenza di Cloud Identity e Google Workspace il concetto di unità organizzative. Le unità organizzative vengono create per raggruppare e organizzare gli utenti, in 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 più adatta al tuo scenario, i seguenti grafici decisionali riassumono le descritti nelle sezioni precedenti.

Innanzitutto, consulta il grafico seguente per identificare il numero di Cloud Identity o Google Workspace, le istanze GCDS I parchi risorse o le istanze AD FS di cui avrai bisogno.

Poi, fai riferimento al secondo grafico per identificare i domini da configurare nel tuo un 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 il Single Sign-On tra Active Directory e Google Cloud.
• Scopri le best practice per la gestione degli account super amministratore