Federa 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 fonte autorevole.

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

In questo documento si presuppone che tu abbia familiarità 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. Di federare le identità degli utenti tra Google Cloud e la tua identità esistente di Google, puoi automatizzare la manutenzione delle identità Google il proprio ciclo di vita agli utenti esistenti in Active Directory.

Configurando la federazione tra Active Directory e Cloud Identity oppure Google Workspace è costituito da due elementi:

• Provisioning degli utenti: gli utenti e i gruppi pertinenti vengono sincronizzati. periodicamente da Active Directory a Cloud Identity oppure 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. Questa procedura assicura che le eliminazioni degli utenti vengano propagate.

  Il provisioning funziona in un modo, il che significa che le modifiche in Active Directory replicati in Google Cloud, ma non viceversa. Inoltre, il provisioning non include le password. In una configurazione federata, Active La 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, affinché l'accesso venga eseguito correttamente deve essere già stato eseguito il provisioning del rispettivo utente.

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 SSL (Secure Sockets Layer) e di solito viene eseguito nel computing completamente gestito di Google Cloud.
• 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 solitamente viene eseguito all'interno nell'ambiente di computing.

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 di 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 le foreste non siano unite usando le foreste incrociate trust, le foreste separate non si fidano degli altri per impostazione predefinita e gli utenti che autenticati in una foresta non possono accedere a risorse che si trovano in un'altra in una foresta.

I domini Active Directory sono container per la gestione delle risorse 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, quindi la gestione utenti e autenticazione sono collegate 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 Google Workspace per la gestione degli utenti.

R Account Cloud Identity o Google Workspace funge da directory privata per utenti e gruppi. Come amministratore dell'account, puoi controllare il ciclo di vita e la configurazione degli utenti e gruppi e definiranno le modalità di esecuzione dell'autenticazione.

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

Integra 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 usi Dominio directory per gestire le identità e l'accesso in tutta l'azienda. Quando stanno pianificando di federare Active Directory e Google Cloud, il primo il 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 con un solo dominio, controller di dominio e server di catalogo globale entrambi forniscono l'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 con un singolo account Cloud Identity o Google Workspace. Questo account fornisce quindi la base per un'unica organizzazione Google Cloud a cui per gestire le risorse Google Cloud.

In un ambiente multidominio, esiste una differenza tra le informazioni può essere recuperato da un controller di dominio e su cosa è possibile eseguire query da un come server di catalogo. Mentre i controller di dominio pubblicano i dati solo dai loro dominio, i server di catalogo globali forniscono accesso alle informazioni di tutti i domini della foresta. Fondamentalmente, i dati forniti dai server di catalogo globale parziale e non di determinati attributi LDAP. Questa limitazione può influire sul modo in cui per configurare GCDS sincronizzare gruppi.

A seconda di come intendi mappare i gruppi, federare una foresta multidominio con Google Cloud richiede una o più istanze GCDS, un solo parco risorse o una singola istanza AD FS per gestire il Single Sign-On.

Foreste multiple con fiducia tra le foreste

Nelle organizzazioni più grandi, non è raro avere più di un programma Foresta di directory, spesso a seguito di una fusione o acquisizione. Puoi combinare queste foreste utilizzando un sistema di fiducia a due vie tra foreste, in modo che gli utenti possano condividere e accedere alle risorse al di là dei confini di un'unica foresta.

Se tutte le foreste hanno una relazione di fiducia bidirezionale con un'altra, possono mappare l'intero ambiente a una singola Cloud Identity oppure Account 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 del catalogo globale offrano 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. Come risultato di questa limitazione, per federare 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 fiducia tra le foreste, Domini Active Directory pertinenti per la federazione con Google Cloud collegate tramite trust esterni, si applicano le stesse considerazioni.

Molteplici foreste senza fiducia tra le foreste

Nell'ambiente qui illustrato, non è possibile eseguire l'autenticazione o accedere alle risorse oltre i confini della foresta. Inoltre, non è possibile un singolo parco risorse o una singola istanza AD FS per gestire le richieste Single Sign-On per gli utenti da 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 un 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 cruciale 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 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 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 di 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 per creare un UPN. Per un utente mario nel dominio corp.example.com, pertanto, il valore UPN predefinito è [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. La utilizzato a questi scopi può sovrapporsi al suffisso MX, UPN o un dominio DNS di Active Directory oppure può essere un dominio completamente diverso.

Utilizzo di 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, per Ad esempio, Accedi con Google utilizza la directory degli utenti di Gmail per autenticazione.

Quando ti registri per un Google Workspace o Cloud Identity di fatturazione, stai creando una directory privata che utilizzabili per l'autenticazione. Nello stesso modo in cui la directory di Gmail associati al dominio gmail.com, a Google Workspace e Gli account Cloud Identity devono essere associati a un dominio personalizzato. Vengono utilizzati tre diversi tipi di domini:

• Dominio principale: questo dominio identifica l'account Cloud Identity 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 con Cloud Identity Account Google Workspace. Ciascuna dell'utente nella directory sia associato al dominio principale 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 nel 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 principale e secondario devono avere un record MX valido in modo che messaggi inviati a indirizzi email creati utilizzando questo nome di dominio possono essere inviati correttamente.

Per abilitare la sincronizzazione tra le directory, è necessario eseguire una mappatura richiesti tra i domini Active Directory e i domini utilizzi di 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 si pianifica la federazione di Active Directory Google Cloud spiega 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 è significativo per gli utenti, quindi Active Directory offre metodi semplici per identificare gli utenti:

• 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]. Pur essendo il modo migliore per identificare gli utenti, gli UPN sono facoltativi, quindi alcuni utenti La foresta di directory potrebbe non disporre di un UPN.

  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 alle versioni precedenti a Windows 2000 (sAMAccountName): questo nome combina la classe nome utente e nome di dominio NetBIOS utilizzando il formato domain<var>user, come in corp\johndoe. Sebbene questi nomi siano 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: identificare gli utenti. 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 il quale la parte del dominio corrisponde a un principale, secondario o alias di Cloud Identity Account 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 di Active Directory, due campi sono candidati per fornire un Indirizzo email di Cloud Identity o Google Workspace: userPrincipalName e mail.

Mappa per nome entità 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.

• Le assegnazioni UPN devono essere completate. Tutti gli utenti soggetti a di sincronizzazione deve avere un UPN assegnato. Il seguente comando PowerShell Può aiutarti a individuare gli utenti che non dispongono di un UPN:

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

Se questi due criteri sono soddisfatti, puoi mappare in sicurezza gli UPN a Cloud Identity o indirizzi email di Google Workspace. Puoi utilizzare uno dei suffissi UPN domini come dominio principale in Cloud Identity oppure Google Workspace e aggiungere qualsiasi altro dominio con suffisso UPN come secondario domini.

Se uno dei criteri non è soddisfatto, puoi comunque mappare gli UPN a gli 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 la notifica le email inviate da Google Cloud, con potenziali errori agli utenti 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. Quando utilizzi più domini di suffissi UPN in in una foresta, questo approccio può però creare duplicati, dato che tutti i domini con suffisso saranno 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

Per utilizzare il campo mail è necessario soddisfare i seguenti criteri per tutti gli utenti soggetti a 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 aziende partner o provider email di tipo consumer, tali indirizzi non possono .

• Tutti gli indirizzi email devono essere univoci nell'intera foresta. Perché gli utenti 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 a gli indirizzi email di Cloud Identity o Google Workspace, con con le seguenti avvertenze:

• Durante la sincronizzazione, gli utenti senza indirizzo email verranno ignorati, come gli utenti con indirizzi email che utilizzano domini non associati con l'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 dell'email indirizzi IP con un dominio diverso. 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, gruppi sono comunemente utilizzati per gestire l'accesso in modo efficiente tra progetti. Piuttosto rispetto all'assegnazione di singoli utenti a ruoli IAM in ogni devi definire un insieme di gruppi che modellano ruoli comuni nei tuoi dell'organizzazione, per poi assegnare questi gruppi a un insieme di ruoli IAM. Modificando l'appartenenza ai gruppi, puoi controllare le un accesso a un l'intero set di risorse.

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 da Microsoft Exchange a Google Workspace, quindi GCDS è in grado di gestire gruppi di distribuzione regolari e 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 poter utilizzare le appartenenze ai gruppi in Active Directory per controllare chi ha 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 Active Directory: gruppi locali del dominio, gruppi globali e gruppi universali.

Gruppi locali del dominio

Questi gruppi sono pertinenti solo nell'ambito di una singola dominio e non possono essere referenziati in altri domini. Poiché l'elenco di i membri non devono essere replicati nella foresta, nel dominio locale gruppi sono i più flessibili per quanto riguarda i tipi di membri che che possono includere.

Gruppi globali

Questi gruppi vengono visualizzati e possono essere consultati in altri domini. Loro dell'elenco dei membri non viene replicato. Questa limitazione limita i tipi dei 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. Possono quindi essere referenziati in altri domini e possono includere non solo utenti e altri gruppi universali, ma anche gruppi globali da tutti 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 di Active Directory utilizza più di una dominio, il tipo di gruppo determina se e come può essere sincronizzato 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 questo limitazione è intenzionale e aiuta a velocizzare la replica della directory, ostacolo quando vuoi sincronizzare questi gruppi con Cloud Identity Google Workspace. In particolare, se configuri GCDS di utilizzare un server di catalogo globale come origine, quindi potrà trovare i gruppi di tutti i domini nella foresta. Ma solo che si trovano nello stesso dominio del server di catalogo globale conterranno un'etichetta ed essere idoneo 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 possono questa restrizione. È possibile sincronizzare una singola istanza GCDS gruppi universali da 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 di gruppi di sicurezza in Active Directory

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

Gruppi di risorse

Windows utilizza un modello di accesso basato sugli elenchi di controllo dell'accesso (ACL). Ciascuna risorsa come un file o un oggetto LDAP è associato a un ACL che controlla quale vi hanno accesso. Risorse e ACL sono molto granulari, quindi ci sono molti di questi. 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 solitamente risiedono in un unico dominio. Di conseguenza, a un gruppo di risorse tendenzialmente si fa riferimento solo in in ACL o in altri gruppi di risorse. Poiché la maggior parte dei gruppi di risorse sono locali, di solito vengono implementati utilizzando gruppi locali del dominio in Active Directory.

Gruppi di ruoli e organizzazioni

I gruppi di risorse 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 generalmente completati dai gruppi di ruoli gruppi dell'organizzazione.

I gruppi di ruoli aggregano le autorizzazioni richieste da un ruolo specifico nel dell'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'è alcuna differenza tra gruppi di ruoli e gruppi di risorse, e i due sono comunemente usati insieme. Tuttavia, a differenza dei gruppi di risorse, e gruppi organizzativi possono avere una pertinenza che va oltre i confini di un dominio. A consentire ai gruppi di risorse di fare riferimento a questi gruppi in altri domini, ruoli I gruppi organizzativi vengono in genere implementati utilizzando gruppi globali, vincolati ai membri di un singolo dominio e talvolta integrati da gruppi universali, che consentono l'accesso a 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, esiste un solo tipo di gruppo. Gruppi in Cloud Identity e Google Workspace non sono confinati nell'ambito di Cloud Identity l'account Google Workspace in cui sono stati definiti. Possono invece includi utenti di diversi account Cloud Identity o Google Workspace account, il supporto della necessità di fare riferimento e di nidificarli in altri account, e di usare in qualsiasi organizzazione Google Cloud.

Così come accade con gli utenti, Cloud Identity e Google Workspace identifica i gruppi in base all'indirizzo email. L'indirizzo email non deve necessariamente corrispondere a una casella postale effettiva, ma deve utilizzare uno dei domini registrati per il rispettivo account Cloud Identity.

A differenza dei gruppi di Active Directory, dei membri di un'istanza Al gruppo Google Workspace non è stata implicitamente concessa l'autorizzazione a elencare altri membri dello stesso gruppo. ma l'invio di query sull'appartenenza al gruppo in generale richiede un'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 l'ambito di attività. Ad esempio, il ruolo Sviluppatore Kubernetes Engine ha accesso completo Oggetti API Kubernetes all'interno di tutti i cluster in un determinato progetto. Data la natura di ruoli, c'è poca necessità di gestire gruppi di risorse su Google Cloud, e raramente si rende necessario sincronizzare i gruppi di risorse 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 dei ruoli e dell'organizzazione consente che mantengono Active Directory come piattaforma principale per la gestione degli accessi.

Se implementi costantemente gruppi di risorse come gruppi locali del dominio, e gruppi dell'organizzazione come gruppi globali o universali, puoi utilizzare per garantire che vengano sincronizzati solo i gruppi di ruoli e organizzazioni.

La questione se sia sufficiente eseguire un singolo di GCDS per foresta multidominio o se ti servono di più istanze GCDS diventa quindi la questione se usi i gruppi globali. Se implementi tutto il tuo ruolo e la tua organizzazione utilizzando gruppi universali, una singola istanza GCDS è sufficiente; altrimenti ti servirà un'istanza GCDS dominio.

Mappa le identità di gruppo

Mappare i gruppi di sicurezza di Active Directory a Cloud Identity I gruppi di Google Workspace richiedono 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à.

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

Mappa con nome comune

Il vantaggio di usare il nome comune (cn) è che è garantito disponibili e, almeno all'interno di un'unità organizzativa, univoci. 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 si occupi automaticamente aggiungendo un suffisso al nome del gruppo. Poiché Active Directory assicura che nomi di gruppi e nomi utente non sono in conflitto, un indirizzo email derivato è improbabile che provochino conflitti.

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

• Se due gruppi in domini diversi condividono lo stesso nome, il l'indirizzo email derivato sarà in conflitto, di conseguenza un gruppo verrà ignorato durante la sincronizzazione dei dati.
• 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

Utilizzare l'indirizzo email (mail) per mappare le identità di gruppo significa che devi soddisfare gli stessi criteri applicati quando utilizzi l'indirizzo email per mappare gli utenti:

• Le assegnazioni email devono essere completate. Sebbene sia comune ai gruppi di distribuzione di avere un indirizzo email, i gruppi di sicurezza spesso non dispongono 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 che 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 di tipo consumer, non puoi utilizzarli.

• Tutti gli indirizzi email devono essere univoci nell'intera foresta. Perché gli utenti 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 un account Cloud Identity o Google Workspace.
• Quando due gruppi condividono lo stesso indirizzo email, solo uno di loro verrà sincronizzati.

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 ampio uso delle unità organizzative per cluster e organizzare le risorse in modo gerarchico, controllare l'accesso applicare i criteri.

In Google Cloud, cartelle e progetti hanno uno scopo simile, anche se i tipi di risorse che vengono gestiti in un'organizzazione Google Cloud sono molto diverse dalle risorse gestite in Active Directory. Di conseguenza, un'applicazione Google Cloud la gerarchia di cartelle di un'azienda tende a differire significativamente 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. A differenza di Active Directory, si applicano solo agli utenti, non ai gruppi.

GCDS offre la possibilità di sincronizzare Active Directory unità organizzative a Cloud Identity o Google Workspace. In un in cui Cloud Identity viene utilizzato solo per estendere Active Directory la gestione delle identità a Google Cloud, la mappatura delle unità organizzative solitamente non è necessario.

Scegli la mappatura giusta

Come indicato all'inizio del documento, non esiste un unico modo migliore per 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

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