Realizar a federação do Google Cloud com o Active Directory

Neste artigo, descrevemos como configurar o Cloud Identity ou o Google Workspace para usar o Active Directory como IdP e fonte autoritativa.

O documento compara a estrutura lógica do Active Directory com a usada pelo Cloud Identity e pelo Google Workspace e descreve como mapear florestas, domínios, usuários e grupos do Active Directory. Ele também fornece um fluxograma que ajuda a determinar a melhor abordagem de mapeamento para seu cenário.

Este documento pressupõe que você já conhece o Active Directory.

Implementar a federação

No Google Cloud, as identidades do Google são usadas para autenticação e gerenciamento de acesso. A manutenção manual das identidades do Google para cada funcionário pode adicionar sobrecarga de gerenciamento desnecessária quando todos os funcionários já têm uma conta no Active Directory. Ao federar identidades de usuários entre o Google Cloud e o sistema de gerenciamento de identidades atual, é possível automatizar a manutenção das identidades do Google e vincular o ciclo de vida deles aos usuários atuais no Active Directory.

A configuração da federação entre o Active Directory e o Cloud Identity ou o Google Workspace envolve duas partes:

• Provisionamento de usuários: os usuários e grupos relevantes são sincronizados periodicamente do Active Directory para o Cloud Identity ou o Google Workspace. Esse processo garante que, ao criar um novo usuário no Active Directory, ele possa ser referenciado no Google Cloud antes mesmo de o usuário associado fazer login pela primeira vez. Esse processo também garante que as exclusões de usuários sejam propagadas.

  O provisionamento é unidirecional, o que significa que as alterações no Active Directory são replicadas no Google Cloud, mas o contrário não acontece. Além disso, o provisionamento não inclui senhas. Em uma configuração federada, o Active Directory continua sendo o único sistema que gerencia essas credenciais.

• Logon único: sempre que um usuário precisa autenticar, o Google Cloud delega a autenticação ao Active Directory usando o protocolo de Linguagem de marcação para autorização de segurança (SAML). Essa delegação garante que somente o Active Directory gerencie as credenciais do usuário e que as políticas ou os mecanismos de autenticação multifator (MFA) sejam aplicados. No entanto, para que um login seja bem-sucedido, o respectivo usuário precisa ter sido provisionado antes.

As seguintes ferramentas podem ser usadas para implementar a federação:

• O Google Cloud Directory Sync (GCDS) é uma ferramenta sem custo financeiro fornecida pelo Google que implementa o processo de sincronização. Ele se comunica com o Google Cloud por Secure Sockets Layer (SSL) e geralmente é executado no ambiente de computação atual.
• Os Serviços de Federação do Active Directory (AD FS, na sigla em inglês) são fornecidos pela Microsoft como parte do Windows Server. Essa ferramenta permite o uso do Active Directory para autenticação federada. O AD FS geralmente é executado no ambiente de computação atual.

Como as APIs do Google Cloud estão disponíveis publicamente e o SAML é um padrão aberto, muitas ferramentas estão disponíveis para implementar a federação. Este documento se concentra no uso do GCDS e do AD FS.

Estrutura lógica do Active Directory

Em uma infraestrutura do Active Directory, o componente de nível superior é a floresta. A floresta serve como um contêiner para um ou mais domínios e deriva o próprio nome do domínio raiz dela. Os domínios em uma floresta do Active Directory confiam uns nos outros, permitindo que usuários autenticados em um domínio acessem recursos que estão em outro domínio. A menos que as florestas estejam conectadas usando relações de confiança entre elas, florestas separadas não confiam umas nas outras por padrão, e usuários autenticados em uma não podem acessar recursos que estão em outra.

Os domínios do Active Directory são contêineres para o gerenciamento de recursos e são considerados limites administrativos. Ter vários domínios em uma floresta é uma maneira de simplificar a administração ou de aplicar estrutura extra, mas os domínios em uma floresta não representam limites de segurança.

Estrutura lógica do Google Cloud

No Google Cloud, as organizações servem como contêineres para todos os recursos e podem ser segmentadas usando pastas e projetos. Organizações, pastas e projetos, portanto, servem a um propósito semelhante aos domínios do Active Directory.

O Active Directory trata os usuários como recursos. Portanto, o gerenciamento e a autenticação de usuários estão vinculados aos domínios. Por outro lado, o Google Cloud não gerencia usuários em uma organização, exceto para contas de serviço. Em vez disso, o Google Cloud depende do Cloud Identity ou do Google Workspace para gerenciar usuários.

Uma conta do Cloud Identity ou do Google Workspace serve como um diretório particular para usuários e grupos. Como administrador da conta, é possível controlar o ciclo de vida e a configuração de usuários e grupos e definir como a autenticação pode ser realizada.

Quando você cria uma conta do Cloud Identity ou do Google Workspace, uma organização do Google Cloud é criada automaticamente. A conta do Cloud Identity ou do Google Workspace e a organização do Google Cloud associada a ela compartilham o mesmo nome e estão vinculadas entre si. No entanto, uma organização do Google Cloud pode fazer referência a usuários e grupos de outras contas do Cloud Identity ou do Google Workspace.

Integrar o Active Directory e o Google Cloud

Há certas semelhanças entre a estrutura lógica do Active Directory e do Google Cloud, mas nenhum mapeamento único entre as duas estruturas funciona igualmente bem em todos os cenários. Na verdade, a abordagem correta para integrar os dois sistemas e mapear a estrutura depende de vários fatores:

• Como mapear domínios e florestas para contas do Cloud Identity ou do Google Workspace
• Como mapear domínios DNS
• Como mapear usuários
• Como mapear grupos

As seções a seguir analisam cada um desses pontos.

Mapear florestas

É comum, especialmente em organizações maiores, o uso de mais de um domínio do Active Directory para gerenciar as identidades e os acessos de toda a empresa. Quando você planeja federar o Active Directory e o Google Cloud, o primeiro fator a ser considerado é a topologia da infraestrutura do Active Directory.

Floresta única, domínio único

Quando uma floresta inclui apenas um domínio, é possível mapear toda a floresta do Active Directory para uma única conta do Cloud Identity ou do Google Workspace. Essa conta fornece a base para uma organização do Google Cloud, que é possível usar para gerenciar seus recursos dessa plataforma.

Em um ambiente de domínio único, os controladores de domínio e os servidores de catálogo global fornecem acesso a todos os objetos gerenciados no Active Directory. Na maioria dos casos, é possível executar apenas uma instância do GCDS para sincronizar grupos e contas de usuário com o Google Cloud e manter uma única instância ou frota do AD FS para lidar com o Logon único.

Floresta única, vários domínios

Quando uma floresta contém vários domínios do Active Directory, é possível organizá-los em uma ou mais árvores de domínio. Em ambos os casos, é possível mapear toda a floresta para uma única conta do Cloud Identity ou do Google Workspace. Essa conta fornece a base para uma organização do Google Cloud, que é possível usar para gerenciar seus recursos dessa plataforma.

Em um ambiente com vários domínios, há uma diferença entre quais informações podem ser recuperadas de um controlador de domínio e quais podem ser consultadas em um servidor de catálogo global. Embora os controladores de domínio exibam dados apenas do domínio local, os servidores de catálogo global fornecem acesso a informações de todos os domínios da floresta. Os dados que são exibidos por servidores de catálogo global são parciais e não têm determinados atributos LDAP. Essa limitação pode afetar a forma como o GCDS é configurado para sincronizar grupos.

Dependendo de como você planeja mapear grupos, a federação de uma floresta de vários domínios com o Google Cloud requer uma ou mais instâncias do GCDS, mas apenas uma única instância ou frota do ADFS para lidar com o Logon único.

Várias florestas com relação de confiança entre si

Em organizações maiores, não é incomum haver mais de uma floresta do Active Directory, geralmente como resultado de uma fusão ou de uma aquisição. É possível combinar essas florestas usando uma confiança entre florestas bidirecional para que os usuários possam compartilhar e acessar recursos através dos limites de uma única floresta.

Se todas as florestas tiverem uma relação de confiança bidirecional com outra floresta, será possível mapear todo o ambiente para uma única conta do Cloud Identity ou do Google Workspace. Essa conta fornece a base para uma organização do Google Cloud, que pode ser usada para gerenciar seus recursos do Google Cloud.

Ainda que os servidores de catálogo global forneçam acesso a dados de vários domínios, o escopo deles é limitado a uma floresta. Portanto, em um ambiente de várias florestas, você precisa consultar vários controladores de domínio ou servidores de catálogo global para conseguir, por exemplo, uma lista completa de usuários. Como resultado dessa limitação, a federação de um ambiente com várias florestas com o Google Cloud exige pelo menos uma instância do GCDS por floresta. As relações de confiança entre florestas permitem que a autenticação do usuário funcione além dos limites da floresta. Portanto, uma instância ou frota do AD FS é suficiente para lidar com o Logon único.

Se o ambiente abranger várias florestas sem confiança entre florestas, mas todos os domínios do Active Directory relevantes para federação com o Google Cloud estiverem conectados por meio de relações de confiança externas, as mesmas considerações serão aplicáveis.

Várias florestas sem relação de confiança entre si

No ambiente ilustrado aqui, não é possível autenticar nem acessar recursos além dos limites da floresta. Também não é possível que uma única instância ou frota do AD FS processe solicitações de Logon único para usuários de todas as florestas.

Portanto, não é possível mapear várias florestas que não têm confiança entre florestas para uma única conta do Cloud Identity ou do Google Workspace. Em vez disso, cada floresta precisa ser mapeada para uma conta separada do Cloud Identity ou do Google Workspace, o que envolve a execução de pelo menos uma instância do GCDS e um servidor ou frota do AD FS por floresta.

No Google Cloud, é criada uma organização separada para cada conta do Cloud Identity ou do Google Workspace. Na maioria dos casos, não é preciso manter várias organizações independentes. Uma das organizações pode ser selecionada e associada a outras contas do Cloud Identity ou do Google Workspace, o que cria efetivamente uma organização federada com várias florestas do Active Directory. As outras organizações continuam sem uso.

Mapear domínios DNS

O DNS desempenha um papel fundamental no Active Directory, no Cloud Identity e no Google Workspace. O segundo fator a ser analisado quando você planeja federar o Active Directory e o Google Cloud é como compartilhar ou mapear domínios DNS entre o Active Directory e o Google Cloud.

Uso de domínios DNS no Active Directory

Em uma floresta do Active Directory, os domínios DNS são usados em vários lugares:

• Domínios DNS do Active Directory: cada domínio do Active Directory corresponde a um domínio DNS. Esse domínio pode ser global, como corp.example.com, ou pode ser um nome de domínio local, como corp.local ou corp.internal.
• Domínios de troca de e-mails (MX, na sigla em inglês): os endereços de e-mail usam um domínio DNS. Em alguns casos, esse domínio é igual ao domínio DNS do Active Directory, mas, em muitos casos, é usado um domínio diferente, geralmente mais curto, como example.com. O ideal é que os usuários no Active Directory tenham o endereço de e-mail associado ao atributo opcional mail.
• Domínios de sufixo UPN: esses domínios são usados para Nomes principais do usuário (UPN, na sigla em inglês). Por padrão, o domínio DNS do Active Directory do domínio do usuário é usado para criar um UPN. Portanto, para um usuário john no domínio corp.example.com, o UPN padrão seria john@corp.example.com. No entanto, é possível configurar uma floresta para usar outros domínios DNS como sufixos UPN que não correspondam aos domínios DNS do Active Directory nem aos domínios MX. Os UPNs são opcionais e são armazenados no campo userPrincipalName do usuário.
• Domínios de endpoint: servidores públicos, como os servidores do AD FS, geralmente recebem um nome DNS, como login.external.example.com. O domínio usado para essas finalidades pode se sobrepor ao MX, ao sufixo UPN ou ao domínio DNS do Active Directory ou pode ser um domínio totalmente diferente.

Uso de domínios DNS no Google Cloud

O Login do Google, do qual o Google Cloud depende para autenticação, usa endereços de e-mail para identificar usuários. O uso de endereços de e-mail não só garante que eles sejam exclusivos globalmente, como também permite que o Google Cloud envie mensagens de notificação para os endereços.

O Login do Google determina o diretório ou o provedor de identidade a ser usado para autenticar um usuário com base na parte do domínio dos endereços de e-mail, que segue o caractere @. Para um endereço de e-mail que usa o domínio gmail.com, por exemplo, o Login do Google usa o diretório de contas de usuário do Gmail para autenticação.

Ao se inscrever em uma conta do Google Workspace ou do Cloud Identity, você cria um diretório privado que pode ser usado para autenticação do login. Da mesma forma que o diretório do Gmail está associado ao domínio gmail.com, as contas do Google Workspace e do Cloud Identity precisam estar associadas a um domínio personalizado. Três tipos diferentes de domínios são usados:

• Domínio principal: esse domínio identifica a conta do Cloud Identity ou do Google Workspace e é usado como o nome da organização no Google Cloud. Ao se inscrever no Cloud Identity ou no Google Workspace, é necessário especificar esse nome de domínio.
• Domínio secundário: além do domínio principal, é possível associar outros domínios secundários a uma conta do Cloud Identity ou do Google Workspace. Cada usuário no diretório está associado ao domínio principal ou a um dos domínios secundários. Dois usuários, johndoe@example.com e johndoe@secondary.example.com, serão considerados usuários separados se example.com for o domínio principal e secondary.example.com for um domínio secundário.
• Domínio de alias: é um nome alternativo para outro domínio. Ou seja, johndoe@example.com e johndoe@alias.example.com se referem ao mesmo usuário quando alias.example.com está configurado como um domínio de alias para example.com.

Todos os domínios precisam atender aos seguintes requisitos:

• Precisam ser nomes de domínio DNS válidos e globais. Durante a configuração, pode ser necessário acesso administrativo às respectivas zonas DNS para verificar a propriedade do domínio.
• Um domínio, como example.com, só pode se referir a um único diretório. No entanto, é possível usar subdomínios diferentes, como subdomain.example.com, para referenciar diferentes diretórios.
• Os domínios principal e secundário precisam ter um registro MX válido para que as mensagens enviadas para os endereços de e-mail formados usando esse nome de domínio possam ser entregues corretamente.

Para ativar a sincronização entre os diretórios, é necessário mapeamento entre os domínios do Active Directory e os domínios que o Cloud Identity ou o Google Workspace usa. Determinar o mapeamento certo depende de como você usa o Active Directory e requer uma análise mais detalhada de como os usuários são identificados em uma floresta do Active Directory e como eles podem ser mapeados para o Cloud Identity ou o Google Workspace.

Map users (Mapear usuários)

O terceiro fator a ser considerado ao planejar a federação do Active Directory e do Google Cloud é como mapear usuários entre o Active Directory e o Cloud Identity ou o Google Workspace.

Identificar usuários no Active Directory

Internamente, o Active Directory usa dois identificadores para identificar os usuários de maneira exclusiva:

• objectGUID: esse ID globalmente exclusivo é gerado quando um usuário é criado e nunca é alterado.
• objectSID: o SID, ou identificador de segurança, é usado para todas as verificações de acesso. Mesmo que esse ID seja exclusivo e estável dentro de um domínio, é possível que, quando movido para um domínio diferente na floresta, um usuário receba um novo SID.

Nenhum desses IDs é significativo para os usuários. Portanto, o Active Directory oferece duas maneiras de identificação de usuários:

• UPN (userPrincipalName): a maneira preferencial de identificar um usuário é por UPN. Os UPNs seguem o formato RFC 822 de endereços de e-mail e são criados pela combinação do nome do usuário com um domínio de sufixo UPN, como em johndoe@corp.example.com. Mesmo sendo a maneira preferida de identificar usuários, os UPNs são opcionais. Portanto, alguns usuários na floresta do Active Directory podem não ter um UPN.

  Mesmo que seja considerado uma prática recomendada que os UPNs sejam endereços de e-mail válidos, o Active Directory não impõe essa prática.

• Nome de logon anterior ao Windows 2000 (sAMAccountName): esse nome combina o nome de domínio NetBIOS e o nome de usuário usando o formato domain<var>user, como em corp\johndoe. Mesmo que esses nomes sejam considerados legados, eles ainda são comumente usados e são o único identificador obrigatório de um usuário.

O Active Directory não usa o endereço de e-mail do usuário (mail) para identificar usuários. Consequentemente, esse campo não é obrigatório nem precisa ser exclusivo em uma floresta.

Todos esses identificadores podem ser alterados a qualquer momento.

Mapeie identidades de usuários

O mapeamento de usuários do Active Directory para usuários do Cloud Identity ou do Google Workspace requer duas informações para cada usuário:

• Um ID único e estável que pode ser usado durante a sincronização para rastrear qual usuário do Active Directory corresponde a qual usuário no Cloud Identity ou no Google Workspace. No lado do AD, o objectGUID é perfeitamente adequado para essa finalidade.
• Um endereço de e-mail para o qual a parte do domínio corresponde a um domínio principal, secundário ou de alias da sua conta do Cloud Identity ou do Google Workspace. Como esse endereço de e-mail será usado em todo o Google Cloud, ele precisa ser significativo. Não é prático derivar um endereço de objectGUID como é o caso com outros endereços de e-mail gerados automaticamente.

Para um usuário do Active Directory, dois campos são candidatos a fornecer um endereço de e-mail do Cloud Identity ou do Google Workspace: userPrincipalName e mail.

Mapear por nome principal do usuário

O uso do campo userPrincipalName requer que dois critérios sejam atendidos para todos os usuários sujeitos à sincronização:

• Os nomes principais de usuários (UPNs) precisam ser endereços de e-mail válidos. Todos os domínios usados como domínios de sufixo UPN também precisam ser domínios MX e precisam ser configurados para que um e-mail enviado ao UPN de um usuário seja entregue em sua caixa de entrada.

• As atribuições UPN precisam estar completas. Todos os usuários sujeitos à sincronização precisam ter um UPN atribuído. Com o seguinte comando do PowerShell, você encontra usuários que não têm um UPN:

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

Se esses dois critérios forem atendidos, será possível mapear os UPNs com segurança para os endereços de e-mail do Cloud Identity ou do Google Workspace. É possível usar um dos domínios de sufixo UPN como domínio principal no Cloud Identity ou no Google Workspace e adicionar outros domínios de sufixo UPN como domínios secundários.

Se um dos critérios não for atendido, ainda será possível mapear os UPNs para os endereços de e-mail do Cloud Identity ou do Google Workspace, mas as seguintes condições se aplicam:

• Se os UPNs não forem endereços de e-mail válidos, os usuários talvez não recebam e-mails de notificação enviados pelo Google Cloud, o que pode fazer com que eles percam informações importantes.
• Os usuários sem UPNs são ignorados durante a sincronização.
• É possível configurar a sincronização para que o domínio de sufixo UPN seja substituído por um domínio diferente. Quando vários domínios de sufixo UPN estão sendo usados em uma floresta, isso pode criar duplicatas, porque todos os domínios de sufixo UPN serão substituídos por um único domínio. No caso de duplicatas, apenas um usuário pode ser sincronizado.

Uma grande vantagem do uso de UPNs para mapear usuários é que eles têm a garantia de serem exclusivos em uma floresta e usam um conjunto selecionado de domínios, o que evita possíveis problemas de sincronização.

Mapear por endereço de e-mail

Para usar o campo mail, é necessário atender aos seguintes critérios para todos os usuários sujeitos à sincronização:

• As atribuições de e-mail precisam estar completas. Todos os usuários sujeitos à sincronização precisam ter o campo mail preenchido. Com o seguinte comando do PowerShell, encontre usuários para os quais esse campo não está preenchido:

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

• Os endereços de e-mail precisam usar um conjunto selecionado de domínios, todos pertencentes a você. Se alguns de seus usuários usarem endereços de e-mail que se referem a empresas parceiras ou provedores de e-mail de consumidores, esses endereços de e-mail não poderão ser usados.

• Todos os endereços de e-mail precisam ser exclusivos na floresta. Como o Active Directory não impõe exclusividade, talvez seja preciso implementar verificações ou políticas personalizadas.

Se todos os usuários relevantes atenderem a esses critérios, será possível identificar todos os domínios usados por esses endereços de e-mail e usá-los como domínios principais e secundários no Cloud Identity ou no Google Workspace.

Se um dos critérios não for atendido, ainda será possível mapear endereços de e-mail para os endereços de e-mail do Cloud Identity ou do Google Workspace, com as seguintes ressalvas:

• Durante a sincronização, os usuários sem endereços de e-mail serão ignorados, assim como os usuários com endereços de e-mail que usam domínios não associados à conta do Cloud Identity ou do Google Workspace.
• Quando dois usuários compartilham o mesmo endereço de e-mail, apenas um usuário é sincronizado.
• É possível configurar a sincronização para substituir o domínio de endereços de e-mail por um domínio diferente. Esse processo pode criar duplicatas. Nesse caso, apenas um usuário será sincronizado.

Mapear grupos

O quarto fator a ser analisado quando você planeja federar o Active Directory e o Google Cloud é se os grupos serão sincronizados entre o Active Directory e o Google Cloud.

No Google Cloud, os grupos são normalmente usados como uma maneira de gerenciar o acesso de maneira eficiente em projetos. Em vez de atribuir usuários individuais a papéis de IAM em cada projeto, defina um conjunto de grupos que modelam papéis comuns na sua organização e, em seguida, atribua esses grupos a um conjunto de papéis de IAM. Ao modificar a adesão dos grupos, é possível controlar o acesso dos usuários a todo um conjunto de recursos.

O Active Directory diferencia dois tipos de grupos: grupos de distribuição e grupos de segurança. Grupos de distribuição são usados para gerenciar listas de e-mail. A sincronização de grupos de distribuição é relevante na migração do Microsoft Exchange para o Google Workspace. Assim, o GCDS pode lidar com grupos de distribuição regulares e dinâmicos. No entanto, os grupos de distribuição não são uma preocupação em gerenciamento de identidade e acesso do Google Cloud. Portanto, essa discussão se concentra exclusivamente em grupos de segurança.

O mapeamento de grupos entre o Active Directory e o Google Cloud é opcional. Depois de configurar o provisionamento de usuários, é possível criar e gerenciar grupos diretamente no Cloud Identity ou no Google Workspace, o que significa que o Active Directory continua sendo o sistema central para o gerenciamento de identidades, mas não para gerenciamento de acesso. Para manter o Active Directory como o sistema central de gerenciamento de identidades e gerenciamento de acesso, recomendamos que você sincronize grupos do Active Directory em vez de gerenciá-los no Cloud Identity ou no Google Workspace. Com essa abordagem, você configura o IAM para poder usar assinaturas de grupos no Active Directory para controlar quem tem acesso a determinados recursos no Google Cloud.

Grupos de segurança no Active Directory

Os grupos de segurança desempenham um papel fundamental na segurança do Windows e no gerenciamento de acesso ao Active Directory. Esse papel é facilitado por três tipos diferentes de grupos do Active Directory: grupos de domínio local, grupos globais e grupos universais.

Grupos de domínio local

Esses grupos são relevantes apenas no escopo de um domínio e não podem ser referenciados em outros domínios. Como a lista de membros não precisa ser replicada na floresta, os grupos de domínio local são os mais flexíveis em relação aos tipos de membros que podem incluir.

Grupos globais

Esses grupos são exibidos em outros domínios e podem ser referenciados nesses domínios. No entanto, a lista de membros desses grupos não é replicada. Essa limitação restringe os tipos de membros que podem ser incluídos nesses grupos. Esses grupos só podem incluir usuários e outros grupos globais do mesmo domínio.

Grupos universais

Esses grupos, assim como as listas de membros deles, são replicados na floresta. Eles podem, portanto, ser referenciados em outros domínios e podem incluir não apenas contas de usuários e outros grupos universais, mas também grupos globais de todos os domínios.

Se a floresta do Active Directory tiver apenas um domínio, será possível sincronizar os três tipos de grupos de segurança usando o GCDS. Se a floresta do Active Directory usa mais de um domínio, o tipo de grupo determina se e como ele pode ser sincronizado com o Cloud Identity ou o Google Workspace.

Como os grupos de domínio local e os grupos globais não são totalmente replicados na floresta, os servidores de catálogo global contêm informações incompletas sobre eles. Essa limitação é intencional e acelera a replicação do diretório, mas é um problema quando você quer sincronizar esses grupos com o Cloud Identity ou o Google Workspace. Especificamente, se você configurar o GCDS para usar um servidor de catálogo global como origem, a ferramenta poderá encontrar grupos de todos os domínios em toda a floresta. Porém, apenas os grupos que estiverem no mesmo domínio que o servidor de catálogo global conterão uma lista de associação e serão adequados para replicação. Para sincronizar grupos locais ou globais de domínio em uma floresta com vários domínios, execute uma instância separada do GCDS por domínio.

Como os grupos universais são totalmente replicados na floresta, eles não têm essa restrição. Uma única instância do GCDS pode sincronizar grupos universais de vários domínios.

Antes de concluir que você precisa de várias instâncias do GCDS para sincronizar diversos domínios do Active Directory com o Cloud Identity ou o Google Workspace, lembre-se de que nem todos os grupos precisam ser sincronizados. Por esse motivo, vale a pena observar como tipos diferentes de grupos de segurança são normalmente usados na floresta do Active Directory.

Uso de grupos de segurança no Active Directory

As seções a seguir descrevem os tipos de grupos de segurança usados no Active Directory.

Grupos de recursos

O Windows usa um modelo de acesso baseado em listas de controle de acesso (ACLs, na sigla em inglês). Cada recurso, como um arquivo ou objeto LDAP, tem uma ACL associada que controla quais usuários têm acesso a ele. Recursos e ACLs são muito detalhados, então existem muitos deles. Para simplificar a manutenção de ACLs, é comum criar grupos de recursos para reunir recursos que costumam ser usados e acessados juntos. O grupo de recursos é adicionado uma vez a todas as ACLs afetadas e isso permite gerenciar o acesso extra ao alterar a associação do grupo de recursos, e não ao alterar as ACLs.

Os recursos que são agrupados dessa forma normalmente residem em um único domínio. Consequentemente, um grupo de recursos também tende a ser referenciado apenas em um único domínio, seja em ACLs ou por outros grupos de recursos. Como a maioria dos grupos de recursos é local, eles geralmente são implementados usando grupos de domínio local no Active Directory.

Grupos de papéis e de organizações

Grupos de recursos ajudam a simplificar o gerenciamento de acesso, mas em um ambiente grande pode ser preciso adicionar um novo usuário a um grande número de grupos de recursos. Por esse motivo, os grupos de recursos geralmente são complementados por grupos de papéis ou por grupos de organizações.

Os grupos de papéis agregam as permissões que um papel específico exige na organização. Um grupo de papéis denominado Leitor de Documentação de Engenharia, por exemplo, pode conceder aos membros acesso somente leitura a toda documentação de engenharia. Na prática, isso seria implementado criando um grupo de papéis e tornando esse grupo membro de todos os grupos de recursos usados para controlar o acesso a vários tipos de documentação.

De maneira semelhante, os grupos de organizações agregam as permissões exigidas pelos departamentos de uma organização. Por exemplo, um grupo de organizações denominado Engenharia pode conceder acesso a todos os recursos que os membros do departamento de engenharia normalmente exigem.

Tecnicamente, não há diferença entre grupos de papéis e grupos de recursos, e ambos são geralmente usados em conjunto. Diferentemente dos grupos de recursos, no entanto, grupos de papéis e de organizações podem ter relevância além dos limites de um domínio. Para permitir que esses grupos sejam referenciados por grupos de recursos em outros domínios, grupos de papéis e de organizações geralmente são implementados usando grupos globais, que são restritos a membros de um único domínio e, às vezes, complementados por grupos universais, que permitem membros de domínios diferentes.

O diagrama a seguir mostra um padrão de aninhamento usado com frequência em ambientes do Active Directory com vários domínios.

Grupos no Cloud Identity e no Google Workspace

No Cloud Identity e no Google Workspace, há apenas um único tipo de grupo. Os grupos no Cloud Identity e no Google Workspace não se limitam ao escopo da conta do Cloud Identity ou do Google Workspace onde eles foram definidos. Em vez disso, eles podem incluir usuários de diferentes contas do Cloud Identity ou do Google Workspace, além de serem referenciados e aninhados em outras contas e serem usados em qualquer organização do Google Cloud.

Assim como acontece com os usuários, o Cloud Identity e o Google Workspace identificam grupos por endereço de e-mail. O endereço de e-mail não precisa corresponder a uma caixa de correio real, mas precisa usar um dos domínios registrados para a respectiva conta do Cloud Identity.

Ao contrário dos grupos do Active Directory, os membros de um grupo do Cloud Identity ou do Google Workspace não têm permissão implícita para listar outros membros do mesmo grupo. Em vez disso, consultar a associação a um grupo geralmente exige autorização explícita.

Uso de grupos no Google Cloud

O Google Cloud usa um modelo de acesso baseado em papéis em vez de um modelo de acesso baseado em ACL. Os papéis se aplicam a todos os recursos de um determinado tipo que se enquadram em um determinado escopo. Por exemplo, o papel de Desenvolvedor do Kubernetes Engine tem acesso total aos objetos da API Kubernetes dentro de todos os clusters em um determinado projeto. Devido à natureza dos papéis, há pouca necessidade de manter grupos de recursos no Google Cloud, e raramente é necessário sincronizar grupos de recursos com o Google Cloud.

Grupos de papéis e grupos de organizações são tão relevantes no Google Cloud quanto no Active Directory porque facilitam o gerenciamento do acesso para um grande número de usuários. A sincronização de grupos de papéis e de organizações ajuda a manter o Active Directory como o local principal para gerenciar o acesso.

Se grupos de recursos forem consistentemente implementados como grupos de domínio local e se grupos de papéis e de organizações forem implementados como grupos globais ou universais, será possível usar o tipo de grupo para garantir que apenas grupos de papéis e de organizações sejam sincronizados.

Para decidir se é suficiente executar uma única instância do GCDS por floresta de vários domínios ou se você precisa de várias instâncias do GCDS, também é preciso decidir se você vai usar ou não grupos globais. Se você implementar todos os grupos de papéis e organizações usando grupos universais, uma única instância do GCDS será suficiente. Caso contrário, você precisará de uma instância do GCDS por domínio.

Mapear identidades de grupos

O mapeamento de grupos de segurança do Active Directory para grupos do Cloud Identity ou do Google Workspace requer um identificador comum. No Cloud Identity e no Google Workspace, esse identificador precisa ser um endereço de e-mail para o qual a parte do domínio corresponda a um domínio principal, secundário ou de alias da conta do Cloud Identity ou do Google Workspace. Como esse endereço de e-mail será usado em todo o Google Cloud, ele precisa ser legível. O endereço de e-mail não precisa corresponder a uma caixa de correio.

No Active Directory, os grupos são identificados pelo nome comum (cn) ou por um nome de logon anterior ao Windows 2000 (sAMAccountName). Assim como contas de usuário, grupos também podem ter endereços de e-mail (mail), mas estes são um atributo opcional para grupos, e o Active Directory não verifica a exclusividade.

Você tem duas opções para mapear identidades de grupo entre o Active Directory e o Cloud Identity ou o Google Workspace.

Mapear por nome comum

A vantagem de usar o nome comum (cn) é que ele está disponível e, pelo menos, dentro de uma unidade organizacional, é exclusivo. No entanto, o nome comum não é um endereço de e-mail. Portanto, ele precisa de um sufixo @DOMAIN para se transformar em um endereço de e-mail.

Você pode configurar o GCDS para anexar automaticamente um sufixo ao nome do grupo. Como o Active Directory garante que os nomes de grupos e de usuários não entrem em conflito, um endereço de e-mail derivado dessa maneira provavelmente não causará conflitos.

Se uma floresta do Active Directory contiver mais de um domínio, as seguintes advertências se aplicarão:

• Se dois grupos em domínios diferentes compartilharem um nome comum, haverá um conflito com o endereço de e-mail derivado, fazendo com que um grupo seja ignorado durante a sincronização.
• Só é possível sincronizar grupos de domínios de uma floresta. Se você sincronizar grupos de várias florestas usando instâncias separadas do GCDS, os endereços de e-mail derivados do nome comum não refletirão a qual floresta eles correspondem. Essa ambiguidade fará com que uma instância do GCDS exclua qualquer grupo criado anteriormente em uma floresta diferente por outra instância do GCDS.
• Não é possível mapear grupos por nome comum se você usar a substituição de domínio para mapear usuários.

Mapear por endereço de e-mail

Usar o endereço de e-mail (mail) para mapear identidades de grupo significa que você precisa atender aos mesmos critérios de uso do endereço de e-mail para mapear usuários:

• As atribuições de e-mail precisam estar completas. Embora seja comum que os grupos de distribuição tenham um endereço de e-mail, os grupos de segurança geralmente não têm esse atributo. Para usar o endereço de e-mail para mapear identidades, os grupos de segurança sujeitos a sincronização precisam ter o campo mail preenchido. O seguinte comando do PowerShell pode ser útil para encontrar contas em que esse campo não esteja preenchido:

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

• Os endereços de e-mail precisam usar um conjunto selecionado de domínios, todos de sua propriedade. Se alguns de seus usuários usarem endereços de e-mail que se referem a empresas parceiras ou provedores de e-mail de consumidores, não será possível usar esses endereços.

• Todos os endereços de e-mail precisam ser exclusivos na floresta. Como o Active Directory não impõe exclusividade, talvez seja preciso implementar verificações ou políticas personalizadas.

Se todos os grupos relevantes atenderem a esses critérios, identifique os domínios usados por esses endereços de e-mail e garanta que a lista de domínios DNS registrados no Cloud Identity ou no Google Workspace cubra esses domínios.

Se um dos critérios não for atendido, ainda será possível mapear os UPNs para os endereços de e-mail do Cloud Identity ou do Google Workspace, com as seguintes condições:

• Os grupos sem endereços de e-mail serão ignorados durante a sincronização, assim como os endereços de e-mail que usam domínios não associados à conta do Cloud Identity ou do Google Workspace.
• Quando dois grupos compartilharem o mesmo endereço de e-mail, apenas um deles será sincronizado.

O mapeamento de grupos por endereço de e-mail não será compatível se a floresta do Active Directory contiver mais de um domínio e você usar a substituição de domínio para mapear usuários.

Mapear unidades organizacionais

A maioria dos domínios do Active Directory faz uso muito frequente de unidades organizacionais para agrupar e organizar recursos hierarquicamente, controlar o acesso e aplicar políticas.

No Google Cloud, pastas e projetos têm uma finalidade semelhante, embora os tipos de recursos gerenciados em uma organização do Google Cloud sejam muito diferentes dos recursos gerenciados no Active Directory. Como resultado, uma hierarquia de pastas apropriada do Google Cloud para uma empresa tende a ser significativamente diferente da estrutura das unidades organizacionais no Active Directory. Portanto, o mapeamento automático de unidades organizacionais para pastas e projetos raramente é prático e não é aceito pelo GCDS.

O Cloud Identity e o Google Workspace são compatíveis com o conceito de unidades organizacionais, que não tem relação com as pastas. As unidades organizacionais são criadas para agrupar e organizar usuários, semelhante ao Active Directory. Mas, ao contrário do Active Directory, eles se aplicam apenas aos usuários, não aos grupos.

O GCDS oferece a opção de sincronizar unidades organizacionais do Active Directory com o Cloud Identity ou o Google Workspace. Em uma configuração em que o Cloud Identity é usado apenas para estender o gerenciamento de identidade do Active Directory para o Google Cloud, o mapeamento de unidades organizacionais geralmente não é necessário.

Escolher o mapeamento ideal

Conforme observado no início deste documento, não há uma única maneira ideal de mapear as estruturas do Active Directory e do Google Cloud. Para ajudar na escolha do mapeamento certo para seu cenário, os gráficos de decisão a seguir resumem os critérios discutidos nas seções anteriores.

Primeiro, consulte o gráfico a seguir para identificar quantas contas do Cloud Identity ou do Google Workspace, instâncias do GCDS e instâncias ou frotas do AD FS serão necessárias.

Em seguida, consulte o segundo gráfico para identificar os domínios a serem configurados na sua conta do Cloud Identity ou do Google Workspace.

A seguir

• Leia sobre as práticas recomendadas para o planejamento de contas e organizações e as práticas recomendadas para federar o Google Cloud com um provedor de identidade externo.
• Configure o GCDS para sincronizar usuários e grupos do Active Directory com o Cloud Identity.
• Configure o Logon único entre o Active Directory e o Google Cloud.
• Saiba mais sobre as práticas recomendadas para gerenciar contas de superadministradores