Como federar o Google Cloud com o Microsoft Entra ID (antigo Azure AD)

Last reviewed 2024-06-26 UTC

Este documento descreve como configurar o Cloud Identity ou o Google Workspace para usar o Microsoft Entra ID (antigo Azure AD) como IdP e origem para identidades.

Ele compara a estrutura lógica do Microsoft Entra ID com a estrutura usada pelo Cloud Identity e pelo Google Workspace e descreve como mapear locatários, domínios, usuários e grupos do Microsoft Entra ID.

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 sobrecarregar desnecessariamente o gerenciamento quando todos os funcionários já tiverem uma conta no Microsoft Entra ID. Ao federar identidades de usuários entre o Google Cloud e o sistema de gerenciamento de identidades, é possível automatizar a manutenção das identidades do Google e vincular o ciclo de vida deles aos usuários No Microsoft Entra ID.

A configuração da federação entre o Microsoft Entra ID e o Cloud Identity ou o Google Workspace envolve duas partes:

• Provisionamento de usuários: usuários e grupos relevantes são sincronizados periodicamente do Microsoft Entra ID para o Cloud Identity ou o Google Workspace. Esse processo garante que, quando você cria um novo usuário no Microsoft Entra ID ou sincroniza um novo usuário do Active Directory com o Microsoft Entra ID, ele também é disponibilizado no Google Cloud para que 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 Microsoft Entra ID são replicadas para o Google Cloud, mas não vice-versa. Além disso, o provisionamento não inclui senhas.

• Logon único: sempre que um usuário precisa fazer a autenticação, o Google Cloud delega a autenticação ao Microsoft Entra ID usando o protocolo Linguagem de marcação para autorização de segurança (SAML). Dependendo da configuração do seu Microsoft Entra ID, ele pode realizar uma das seguintes ações:

  • Desempenhar a autenticação em si.
  • Usar a autenticação de passagem ou a sincronização de hash de senha.
  • Delegar a autenticação a um servidor AD FS no local.

Ter a autenticação delegada do Cloud Identity ou do Google Workspace para o Microsoft Entra ID não só evita a sincronização de senhas com o Google Cloud, como também garante que quaisquer políticas aplicáveis ou mecanismos de autenticação multifator (MFA) que você tenha configurados no Microsoft Entra ID ou no AD FS sejam aplicadas.

Observação: este documento refere-se ao app da galeria Google Cloud/G Suite Connector by Microsoft no marketplace do Microsoft Azure. Este aplicativo é um produto da Microsoft. O Google não oferece manutenção nem suporte a ele.

Estrutura lógica do Microsoft Entra ID

Com o Azure, você utiliza um ou mais locatários do Microsoft Entra ID, também chamados de diretórios. Os locatários do Microsoft Entra ID são uma estrutura de nível superior. Eles são considerados limites administrativos e servem como contêineres para usuários e grupos, além de recursos e grupos de recursos.

Cada locatário do Microsoft Entra ID tem pelo menos um domínio DNS associado a ele. Esse domínio DNS é refletido em nomes de usuários (também chamados de Nomes principais do usuário ou UPNs), que assumem a forma de name@domain, em que domain é um dos domínios DNS associados ao locatário correspondente.

Uma empresa pode manter vários locatários do Microsoft Entra ID. Os motivos mais comuns para ter vários locatários incluem: a distinção entre diferentes partes da organização, a separação dos recursos de produção dos recursos de desenvolvimento e de teste, e o uso de locatários separados para integrar várias florestas de um Active Directory local.

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. No entanto, com exceção das contas de serviço, as organizações não são usadas para gerenciar usuários e grupos, o que as torna diferentes dos locatários do Microsoft Entra ID.

Para gerenciar usuários e grupos, o Google Cloud depende do Cloud Identity ou do Google Workspace. 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 referenciar usuários e grupos de outras contas do Cloud Identity ou do Google Workspace.

Integrar o Microsoft Entra ID ao Google Cloud

Apesar de certas semelhanças entre a estrutura lógica do Microsoft Entra ID e do Google Cloud, nenhum mapeamento 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 locatários do Microsoft Entra ID 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.

O Google Cloud interage apenas com o Microsoft Entra ID, não com o Active Directory local. Portanto, a maneira como você mapeou florestas e domínios do Active Directory local para o Microsoft Entra ID é uma preocupação pequena.

Mapear locatários do Microsoft Entra ID

As seguintes seções descrevem como mapear locatários do Microsoft Entra ID para esses cenários:

• Locatário único
• Vários locatários
• Usuários externos

Locatário único

Se você usa apenas um único locatário do Microsoft Entra ID, pode mapear o locatário para uma única conta do Cloud Identity ou do Google Workspace e configurar a federação entre os dois. Essa conta do Cloud Identity ou do Google Workspace fornece a base para uma única organização do Google Cloud que é possível usar para gerenciar todos os recursos do Google Cloud.

Vários locatários

Em organizações maiores, é comum ter mais de um locatário do Microsoft Entra ID. Vários locatários podem ser usados para diferenciar ambientes de teste e produção ou para diferenciar partes de uma organização.

É possível mapear vários locatários do Microsoft Entra ID para uma única conta do Cloud Identity ou do Google Workspace e configurar o provisionamento de usuários e o logon único adequadamente. No entanto, um mapeamento N:1 pode enfraquecer o isolamento entre os locatários do Microsoft Entra ID: se você conceder permissão a vários locatários do Microsoft Entra ID para criar e modificar usuários em uma única conta do Cloud Identity ou do Google Workspace, eles poderão interferir e adulterar as alterações uns dos outros.

Normalmente, uma abordagem melhor de integração com vários locatários do Microsoft Entra ID é criar uma conta separada do Cloud Identity ou do Google Workspace para cada locatário e configurar a federação entre cada par.

No Google Cloud, é criada uma organização separada para cada conta do Cloud Identity ou do Google Workspace. Ter mais de uma organização geralmente é impraticável porque o Google Cloud permite a organização dos recursos por meio de projetos e de pastas em uma única organização. No entanto, 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.

Usuários externos

Com o Microsoft Entra ID B2B, é possível convidar usuários externos como convidados para seu locatário do Microsoft Entra ID. Um novo usuário é criado para cada convidado, e o Microsoft Entra ID atribui automaticamente um PRIMARY a esses usuários convidados. O UPN que o Microsoft Entra ID gera usa um prefixo derivado do endereço de e-mail do convidado, combinado com o domínio inicial do locatário: prefix#EXT#@tenant.onmicrosoft.com.

O provisionamento de usuários convidados usando o Microsoft Entra ID para o Cloud Identity ou o Google Workspace está sujeito a algumas limitações:

• Não é possível mapear o UPN de usuários convidados para endereços de e-mail no Cloud Identity ou no Google Workspace porque onmicrosoft.com é um domínio que não pode ser adicionado e verificado no Cloud Identity ou no Google Workspace. Portanto, você precisa mapear usuários usando um atributo diferente do UPN.
• Se um usuário convidado estiver suspenso no seu locatário inicial, o usuário correspondente no Cloud Identity ou no Google Workspace poderá permanecer ativo e o acesso aos recursos do Google Cloud poderá não ser revogado adequadamente.

Uma maneira melhor de lidar com usuários convidados provenientes de um locatário diferente do Microsoft Entra ID é criar várias contas do Cloud Identity ou do Google Workspace, conforme descrito na seção anterior, cada uma federada com um locatário diferente do Microsoft Entra ID. Para mais informações, consulte Provisionamento e Logon único de usuários do Microsoft Entra ID B2B.

Para conceder a um usuário externo acesso a determinados recursos do Google Cloud, não é pré-requisito para o usuário ter uma conta de usuário no Cloud Identity ou no Google Workspace. A menos que haja uma política de restrição, também será possível adicionar o usuário externo diretamente como membro aos respectivos projetos, pastas ou organização, se ele tiver uma identidade do Google.

Mapear domínios DNS

O DNS desempenha um papel crucial, tanto para o Microsoft Entra ID quanto para o Cloud Identity e o Google Workspace. O segundo fator a ser considerado ao planejar a federação do Microsoft Entra ID e o Google Cloud é como compartilhar ou mapear domínios DNS entre o Microsoft Entra ID e o Google Cloud.

Uso de domínios DNS no Google Cloud

O Login do Google (em inglês), que é usado pelo Google Cloud para autenticação, usa endereços de e-mail para identificar usuários. O uso de endereços de e-mail não apenas garante que eles sejam exclusivos globalmente, mas 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, [e-mail] e [e-mail], 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, [e-mail] e [e-mail] 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.

Uso de domínios DNS no Microsoft Entra ID

A maneira como o Cloud Identity e o Google Workspace usam o DNS é semelhante à maneira como o Microsoft Entra ID depende do DNS para distinguir os locatários do Microsoft Entra ID e associar nomes de usuário aos locatários. Mas esteja ciente de duas diferenças notáveis:

1. Domínios iniciais: quando você cria um locatário do Microsoft Entra ID, ele é associado a um domínio inicial, que é um subdomínio de onmicrosoft.com. Esse domínio é diferente de qualquer nome de domínio personalizado que possa ser registrado, já que você não é o proprietário do domínio e não tem acesso administrativo à respectiva zona DNS.

   O Cloud Identity não tem um equivalente de um domínio inicial e, em vez disso, exige que você seja proprietário de todos os domínios associados a uma conta do Cloud Identity. Esse requisito significa que não é possível registrar um subdomínio onmicrosoft.com como um domínio do Cloud Identity.

2. Domínios usados em identificadores de usuários: o Microsoft Entra ID diferencia os endereços de e-mail MOERAs (endereços de roteamento de e-mail on-line da Microsoft) e UPNs. Ambos seguem um formato RFC 822 (user@domain), mas têm finalidades diferentes: enquanto os UPNs são usados para identificar usuários e são usados no formulário de logon, apenas MOERAs são usados para entregar e-mails.

   O sufixo de domínio usado pelos UPNs é necessário para corresponder a um dos domínios registrados do locatário do Microsoft Entra ID. O mesmo requisito não se aplica aos endereços de e-mail.

   O Cloud Identity e o Google Workspace não dependem do conceito de um UPN e, em vez disso, usam o endereço de e-mail de um usuário como identificador. Consequentemente, o domínio usado pelo endereço de e-mail precisa corresponder a um dos domínios registrados do Cloud Identity ou do Google Workspace.

Um locatário do Microsoft Entra ID e uma conta do Cloud Identity ou do Google Workspace podem usar os mesmos domínios DNS. Se não for possível usar os mesmos domínios, configure o provisionamento de usuários e o Logon único para substituir nomes de domínio.

Considerando as duas diferenças descritas acima, você precisa basear seu mapeamento de domínio na forma como planeja mapear usuários entre o Microsoft Entra ID e o Cloud Identity ou o Google Workspace.

Map users (Mapear usuários)

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

O mapeamento de usuários do Microsoft Entra ID para usuários no Cloud Identity ou no Google Workspace requer duas informações para cada usuário:

1. Um ID estável e exclusivo que pode ser usado durante a sincronização para rastrear qual usuário do Microsoft Entra ID corresponde a qual usuário no Cloud Identity ou no Google Workspace.
2. Um endereço de e-mail em que a parte do domínio corresponde a um domínio principal, secundário ou de alias do Cloud Identity. Como esse endereço de e-mail será usado em todo o Google Cloud, o endereço precisa ser legível.

Internamente, o Microsoft Entra ID identifica usuários por ObjectId, que é um ID globalmente exclusivo gerado aleatoriamente. Ainda que esse ID seja estável e, portanto, atenda ao primeiro requisito, ele não faz sentido para os humanos e não segue o formato de um endereço de e-mail. Para mapear usuários, as únicas opções práticas são mapear por UPN ou por endereço de e-mail.

Se o usuário inserir um endereço de e-mail que pertença a uma conta do Cloud Identity ou do Google Workspace configurada para usar o Logon único com o Microsoft Entra ID, ele será redirecionado para a tela de logon do Microsoft Entra ID.

O Microsoft Entra ID usa UPNs, não endereços de e-mail, para identificar usuários, portanto, a tela de logon solicita que o usuário forneça um UPN.

Se o locatário do Microsoft Entra ID estiver configurado para usar o AD FS para logon, outro redirecionamento levará o usuário à tela de logon do AD FS. O AD FS pode identificar usuários pelo UPN do Active Directory ou pelo nome de logon anterior ao Windows 2000 (domain\user).

Se o endereço de e-mail usado para o Cloud Identity ou o Google Workspace, o UPN usado pelo Microsoft Entra ID e o UPN usado pelo Active Directory for diferente, a sequência de telas de logon poderá se tornar facilmente confusa para os usuários finais. Por outro lado, se todos os três identificadores forem os mesmos nas capturas de tela de exemplo ([e-mail]), os usuários não serão expostos às diferenças técnicas entre UPNs e endereços de e-mail, minimizando possíveis confusões entre seus usuários.

Mapear por UPN

Do ponto de vista da experiência do usuário, o mapeamento de UPNs do Microsoft Entra ID para os endereços de e-mail do Cloud Identity ou do Google Workspace pode ser considerado a melhor opção. Outro benefício de confiar em UPNs é que o Microsoft Entra ID garante exclusividade para evitar o risco de conflitos de nomenclatura.

No entanto, para mapear os UPNs do Microsoft Entra ID para endereços de e-mail do Cloud Identity, é necessário atender a estes requisitos:

• Os UPNs do Microsoft Entra ID precisam ser endereços de e-mail válidos para que todos os e-mails de notificação enviados pelo Google Cloud sejam entregues corretamente na caixa de e-mails do usuário. Se esse não for o caso, será possível configurar endereços de e-mail de alias para garantir que o usuário receba esse e-mail.
• Os UPs de todos os usuários relevantes no Microsoft Entra ID precisam usar um domínio personalizado como sufixo (user@custom-domain). Os UPNs que usam o domínio inicial do Microsoft Entra ID ([e-mail]) não podem ser mapeados para endereços de e-mail no Cloud Identity porque o domínio inicial não pertence a você, mas sim ao Microsoft.
• Todos os domínios personalizados usados pelo Microsoft Entra ID para UPNs também precisam ser registrados no Cloud Identity. Esse requisito significa que você precisa ter acesso às respectivas zonas DNS para realizar a validação do domínio. Para evitar a substituição de registros DNS TXT atuais que você possa ter criado para verificar a propriedade de domínio no Microsoft Entra ID, use um registro CNAME para confirmar a propriedade do domínio no Cloud Identity.

Mapear usuários por endereço de e-mail

Se o mapeamento de UPNs do Microsoft Entra ID para endereços de e-mail do Cloud Identity ou do Google Workspace não for uma opção, será possível mapear usuários por endereço de e-mail.

Quando você especifica um endereço de e-mail no Active Directory, ele é armazenado no atributo mail do respectivo objeto user, e o Microsoft Entra ID Connect vai sincronizar o valor com o atributo Mail no Microsoft Entra ID. O Microsoft Entra ID também disponibiliza o atributo para provisionamento de usuários, para que você possa mapeá-lo para o endereço de e-mail no Cloud Identity ou cloudid_name_short.

O atributo Mail do Microsoft Entra ID atualmente não é mostrado no portal do Azure e só pode ser visualizado e editado por meio de APIs ou do PowerShell. A interface do usuário permite que você especifique um endereço de e-mail padrão e um alternativo, mas nenhum desses valores é armazenado no atributo Mail. Portanto, eles não podem ser usados para provisionamento no Cloud Identity ou cloudid_name_short. Como resultado, o mapeamento de usuários de um endereço de e-mail é prático somente quando você faz a maior parte da criação e edição de usuários no Active Directory, não no Microsoft Entra ID.

O mapeamento de usuários por endereço de e-mail exige que você atenda aos seguintes requisitos adicionais:

• As atribuições de e-mail precisam estar completas. Todos os usuários sujeitos à sincronização precisam receber um endereço de e-mail. Quando os usuários são sincronizados com base em um Active Directory no local, esse pode não ser o caso porque mail é um atributo de usuário opcional no Active Directory. Os usuários que não têm um endereço de e-mail no atributo Mail do Microsoft Entra ID são ignorados silenciosamente durante a sincronização.
• Os endereços de e-mail precisam ser exclusivos no locatário do Microsoft Entra ID. Embora o Active Directory não verifique a exclusividade na criação do usuário, o Microsoft Entra ID Connect detecta colisões por padrão, o que pode causar falha na sincronização dos usuários afetados.
• Os domínios usados pelos endereços de e-mail não precisam ser registrados no Microsoft Entra ID, mas precisam ser registrados no Cloud Identity ou no Google Workspace. Esse requisito significa que você precisa ter acesso às respectivas zonas DNS para realizar a validação do domínio e excluir o uso de endereços de e-mail com domínios que não são seus (como gmail.com).

Mapear o ciclo de vida do usuário

Depois de definir um mapeamento entre os usuários do Microsoft Entra ID e os usuários no Cloud Identity ou no Google Workspace, decida qual conjunto de usuários você quer provisionar. Consulte nossas práticas recomendadas sobre o mapeamento de conjuntos de identidade para conferir orientações sobre como tomar essa decisão.

Se você não quiser provisionar todos os usuários do locatário do Microsoft Entra ID, ative o provisionamento para um subconjunto de usuários usando atribuições de usuário ou filtros de escopo.

A tabela a seguir resume o comportamento padrão do provisionamento do Microsoft Entra ID e mostra como ativar ou desativar o provisionamento de um usuário e controla quais ações o Microsoft Entra ID executará no Cloud Identity ou no Google Workspace.

Provisionamento ativado para usuários com o Microsoft Entra ID	Estado do usuário no Cloud Identity ou no Google Workspace	Ação realizada no Microsoft Entra ID	Ação realizada no Cloud Identity ou no Google Workspace
Não	Não existe	Ativar provisionamento	Criar novo usuário (*)
Não	Existe (ativo)	Ativar provisionamento	Atualizar usuário atual
Não	Existe (suspenso)	Ativar provisionamento	Atualizar usuário atual, manter suspenso
Sim	Existe	Modificar usuário	Atualizar usuário atual
Sim	Existe	Renomear UPN/endereço de e-mail	Alterar o endereço de e-mail principal, manter o endereço anterior como alias
Sim	Existe	Desativar o provisionamento	Usuário mantido como está
Sim	Existe	Fazer a exclusão reversível de um usuário	Suspender usuário
Sim	Existe	Excluir usuário permanentemente	Suspender usuário, adicionar o prefixo del_ ao endereço de e-mail

(*) Se houver uma conta pessoal com o mesmo endereço de e-mail, ela será removida.

Observação: se você ativar o provisionamento para um usuário e posteriormente desativar o provisionamento, o usuário correspondente no Cloud Identity ou no Google Workspace permanecerá ativo. Para revogar a permissão do usuário para fazer login e acessar os serviços do Google, é preciso excluir o usuário no Microsoft Entra ID ou desativá-lo manualmente no Cloud Identity ou no Google Workspace.

Mapear grupos

O quarto fator a ser analisado quando você planeja federar o Microsoft Entra ID e o Google Cloud é se sincronizar grupos entre o Microsoft Entra ID e o Google Cloud e como mapeá-los.

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 do IAM em cada projeto, você define um conjunto de grupos que modelam papéis comuns na sua organização. Em seguida, você atribui esses grupos a um conjunto de papéis do IAM. Ao modificar a adesão dos grupos, é possível controlar o acesso dos usuários a todo um conjunto de recursos.

O mapeamento de grupos entre o Microsoft Entra ID 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 ou o Microsoft Entra ID continua sendo o sistema central para o gerenciamento de identidades, mas não para Gerenciamento de acesso do Google Cloud.

Para manter o Active Directory ou o Microsoft Entra ID como o sistema central de gerenciamento de identidade e gerenciamento de acesso, recomendamos que você sincronize grupos do Microsoft Entra ID em vez de gerenciá-los no Cloud Identity ou no Google Workspace. Com essa abordagem, é possível configurar o IAM para que seja possível usar adesões de grupo no Active Directory ou no Microsoft Entra ID para controlar quem tem acesso a recursos no Google Cloud.

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.

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 trabalhar com grupos no IAM, geralmente é necessário especificar grupos por endereço de e-mail, e não por nome. Portanto, é melhor que os grupos tenham não apenas um nome significativo, mas também um endereço de e-mail significativo e reconhecível.

Grupos no Microsoft Entra ID

O Microsoft Entra ID é compatível com vários tipos de grupos, cada um atendendo a diferentes casos de uso. Os grupos têm como escopo um único locatário e são identificados por um ID de objeto, que é um ID globalmente exclusivo gerado aleatoriamente. Os grupos podem ser aninhados e podem conter usuários do mesmo locatário ou usuários convidados de outros locatários usando o Azure B2B. O Microsoft Entra ID também é compatível com grupos dinâmicos, cujos membros são determinados automaticamente com base em uma consulta.

No contexto da integração do Microsoft Entra ID ao Cloud Identity ou Google Workspace, duas propriedades de grupos são de interesse principal: se um grupo é ativado por e-mail e se é ativado por segurança:

• Um grupo ativado por segurança pode ser usado para gerenciar o acesso a recursos no Microsoft Entra ID. Portanto, qualquer grupo ativado por segurança é potencialmente relevante no contexto do Google Cloud.
• Um grupo ativado para e-mail tem um endereço de e-mail relevante, porque o Cloud Identity e o Google Workspace exigem que os grupos sejam identificados por um endereço de e-mail.

No Microsoft Entra ID, é possível criar grupos do tipo Security ou Office 365 (às vezes chamados de grupos unificados). Também é possível criar grupos do tipo Lista de distribuição ao sincronizar grupos de um Active Directory no local ou ao usar o tipo do Office 365.

A tabela a seguir resume as diferenças entre esses diferentes tipos de grupos em relação à habilitação de e-mail ou segurança, e como são associados aos tipos de grupos do Active Directory, pressupondo uma configuração padrão do Microsoft Entra ID Connect:

Origem	Tipo de grupo do Active Directory	Tipo de grupo do Microsoft Entra ID	Ativados para e-mail	Ativados para segurança
Microsoft Entra ID	-	Grupo do Office 365	Sempre	Opcional
Microsoft Entra ID	-	Grupo de segurança	Opcional	Sempre
no local	Grupo de segurança (com e-mail)	Grupo de segurança	Sim	Sim
no local	Grupo de segurança (sem e-mail)	Grupo de segurança	Não	Sim
no local	Lista de distribuição (com e-mail)	Lista de distribuição	Sim	Não
no local	Lista de distribuição (sem e-mail)	(ignorado pelo Microsoft Entra ID Connect)

Ao contrário dos usuários, o Microsoft Entra ID exige que os endereços de e-mail atribuídos aos grupos usem um domínio registrado como um domínio personalizado no Microsoft Entra ID. Esse requisito resulta no seguinte comportamento padrão:

• Se um grupo no Active Directory usar um endereço de e-mail com um domínio registrado anteriormente no Microsoft Entra ID, o endereço de e-mail será mantido corretamente durante a sincronização com o Microsoft Entra ID.
• Se um grupo no Active Directory usar um endereço de e-mail que não tenha sido registrado no Microsoft Entra ID, o Microsoft Entra ID vai gerar automaticamente um novo endereço durante a sincronização. Esse endereço de e-mail usa o domínio padrão do locatário. Se o locatário usar o domínio inicial como domínio padrão, o endereço de e-mail resultante será no formato [name]@[tenant].onmicrosoft.com.
• Se você criar um grupo do Office 365 no Microsoft Entra ID, o Microsoft Entra ID também gerará automaticamente um endereço de e-mail que usa o domínio padrão do locatário.

Mapear identidades de grupos

O mapeamento de grupos do Microsoft Entra ID para os grupos do Cloud Identity ou do Google Workspace requer um identificador comum, e esse identificador precisa ser um endereço de e-mail. Com relação ao Microsoft Entra ID, esse requisito deixa duas opções:

• É possível usar o endereço de e-mail de um grupo no Microsoft Entra ID e mapeá-lo para um endereço de e-mail do Cloud Identity ou do Google Workspace.
• Derivar um endereço de e-mail do nome do grupo no Microsoft Entra ID e mapear o endereço resultante para um endereço de e-mail no Cloud Identity ou no Google Workspace.

Mapear por endereço de e-mail

O mapeamento de grupos por endereço de e-mail é a escolha mais óbvia, mas requer que você atenda a vários requisitos:

• Todos os grupos sujeitos a sincronização precisam ter um endereço de e-mail. Na prática, isso significa que só é possível sincronizar grupos ativados para e-mail. Grupos que não têm um endereço de e-mail são ignorados durante o provisionamento.
• Os endereços de e-mail precisam ser exclusivos no locatário. Como o Microsoft Entra ID não impõe exclusividade, talvez seja necessário implementar verificações ou políticas personalizadas.
• Os domínios usados pelos endereços de e-mail precisam ser registrados no Microsoft Entra ID e no Cloud Identity ou no Google Workspace. Todos os grupos com endereços de e-mail que usam domínios não registrados no Cloud Identity ou no Google Workspace, incluindo o domínio tenant.onmicrosoft.com, não serão sincronizados.

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.

Mapear por nome

Atender aos critérios exigidos para mapear grupos por endereço de e-mail pode ser complicado, especialmente se muitos dos grupos de segurança que você pretende provisionar para o Cloud Identity ou o Google Workspace não estiverem ativados para e-mail. Nesse caso, talvez seja melhor derivar automaticamente um endereço de e-mail do nome de exibição do grupo.

Derivar um endereço de e-mail apresenta dois desafios:

1. Um endereço de e-mail derivado do nome de um grupo pode colidir com um endereço de e-mail de um usuário.
2. O Microsoft Entra ID não impõe exclusividade para nomes de grupos. Se vários grupos no locatário do Microsoft Entra ID compartilharem o mesmo nome, os endereços de e-mail derivados desse nome entrarão em conflito, fazendo com que apenas um grupo seja sincronizado.

É possível superar o primeiro desafio usando um domínio para o endereço de e-mail gerado que seja diferente de qualquer um dos domínios usados pelos usuários. Por exemplo, se todos os usuários usarem endereços de e-mail com example.com como domínio, use groups.example.com para todos os grupos. O registro de subdomínios no Cloud Identity ou no Google Workspace não exige verificação de domínio, então, a zona DNS groups.example.com não precisa nem existir.

É possível superar o segundo desafio, duplicar nomes de grupos. Basta derivar tecnicamente o endereço de e-mail do grupo a partir do ID do objeto. Como os nomes dos grupos resultantes são bastante criptográficos e difíceis de trabalhar, é melhor identificar e renomear os nomes dos grupos duplicados no Microsoft Entra ID antes de configurar o provisionamento no Cloud Identity ou no Google Workspace.

Mapear o ciclo de vida do grupo

Depois de definir um mapeamento entre os grupos do Microsoft Entra ID e os grupos no Cloud Identity ou no Google Workspace, decida qual conjunto de grupos você quer provisionar. Assim como os usuários, é possível ativar o provisionamento de um subconjunto de grupos usando atribuições de grupo ou filtros de escopo.

A tabela a seguir resume o comportamento padrão do provisionamento do Microsoft Entra ID e mostra como ativar ou desativar o provisionamento de um grupo e controla quais ações o Microsoft Entra ID vai executar no Cloud Identity ou no Google Workspace.

Provisionamento ativado para o grupo do Microsoft Entra ID	Estado do grupo no Cloud Identity ou no Google Workspace	Ação realizada no Microsoft Entra ID	Ação realizada no Cloud Identity ou no Google Workspace
Não	Não existe	Ativar provisionamento	Criar novo grupo
Não	Existe	Ativar provisionamento	Adicionar membro, manter todos os membros atuais
Sim	Existe	Renomear grupo	Renomear grupo
Sim	Existe	Modificar descrição	Atualizar descrição
Sim	Existe	Adicionar membro	Adicionar membro, manter todos os membros atuais
Sim	Existe	Remover membro	Remover membro
Sim	Existe	Desativar o provisionamento	Grupo mantido como está (incluindo membros)
Sim	Existe	Excluir grupo	Grupo mantido como está (incluindo membros)

Observação: quando você exclui um grupo no Microsoft Entra ID, ele não propaga a exclusão para o Cloud Identity ou o Google Workspace. Da mesma forma, se você ativar o provisionamento para um grupo e depois desativar o provisionamento, o grupo no Cloud Identity ou no Google Workspace permanecerá ativo. Esse comportamento pode resultar na retenção acidental de direitos de acesso no Google Cloud. Para evitar que isso aconteça, primeiro remova todos os membros de um grupo, aguarde a propagação das alterações e só depois exclua o grupo no Microsoft Entra ID ou desative o provisionamento do grupo no Microsoft Entra ID.

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.
• Saiba como configurar o provisionamento e o logon único entre o Microsoft Entra ID e o Cloud Identity.
• Saiba mais sobre as práticas recomendadas para gerenciar contas de superadministradores.