Federe Google Cloud com o Microsoft Entra ID (anteriormente Azure AD)

Last reviewed 2024-06-26 UTC

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

O documento compara a estrutura lógica do Microsoft Entra ID com a estrutura usada pelo Cloud Identity e o Google Workspace, e descreve como pode mapear inquilinos, domínios, utilizadores e grupos do Microsoft Entra ID.

Implemente a federação

Google Cloud usa identidades Google para autenticação e gestão de acesso. A manutenção manual das identidades Google para cada funcionário pode adicionar custos gerais de gestão desnecessários quando todos os funcionários já têm uma conta no Microsoft Entra ID. Ao federar identidades de utilizadores entre o Google Workspace e o seu sistema de gestão de identidades existente, pode automatizar a manutenção das identidades Google e associar o respetivo ciclo de vida aos utilizadores existentes no Microsoft Entra ID. Google Cloud

A configuração da federação entre o Microsoft Entra ID e o Cloud ID ou o Google Workspace envolve dois elementos:

• Aprovisionamento de utilizadores: os utilizadores e os grupos relevantes são sincronizados periodicamente do Microsoft Entra ID para o Cloud ID ou o Google Workspace. Este processo garante que, quando cria um novo utilizador no Microsoft Entra ID ou sincroniza um novo utilizador do Active Directory para o Microsoft Entra ID, este também fica disponível no Google Cloud para que possa ser referenciado no Google Cloud , mesmo antes de o utilizador associado ter iniciado sessão pela primeira vez. Este processo também garante que as eliminações de utilizadores estão a ser propagadas.

  O aprovisionamento funciona num único sentido, 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 aprovisionamento não inclui palavras-passe.

• Início de sessão único: sempre que um utilizador precisa de autenticar, Google Cloud delega a autenticação no Microsoft Entra ID através do protocolo Security Assertion Markup Language (SAML). Consoante a configuração do Microsoft Entra ID, o Microsoft Entra ID pode fazer uma das seguintes ações:

  • Realizar a própria autenticação.
  • Use a autenticação de passagem ou a sincronização de hash de palavras-passe.
  • Delegar a autenticação a um servidor AD FS nas instalações.

A delegação da autenticação do Cloud Identity ou do Google Workspace para o Microsoft Entra ID não só evita ter de sincronizar palavras-passe para oGoogle Cloud, como também garante que quaisquer políticas aplicáveis ou mecanismos de autenticação multifator (AMF) que tenha configurado no Microsoft Entra ID ou no AD FS são aplicados.

Nota: este documento refere-se à app de galeria Google Cloud/G Suite Connector by Microsoft do Microsoft Azure Marketplace. Esta app é um produto da Microsoft e não é mantida nem suportada pela Google.

Estrutura lógica do Microsoft Entra ID

Quando usa o Azure, usa um ou mais inquilinos do Microsoft Entra ID (também denominados diretórios). Os inquilinos do Microsoft Entra ID são uma estrutura de nível superior. São considerados limites administrativos e servem como contentores para utilizadores, grupos, bem como recursos e grupos de recursos.

Cada inquilino do Microsoft Entra ID tem, pelo menos, um domínio DNS associado. Este domínio DNS reflete-se nos nomes de utilizador (também denominados Nomes Principais de Utilizador ou UPNs), que têm o formato name@domain, em que domain é um dos domínios DNS associados ao inquilino correspondente.

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

Estrutura lógica de Google Cloud

Nas Google Cloud, organizações servem como contentores para todos os recursos e podem ser ainda mais segmentadas através de pastas e projetos. No entanto, exceto para as contas de serviço, as organizações não são usadas para gerir utilizadores e grupos, o que torna as organizações diferentes dos inquilinos do Microsoft Entra ID.

Para gerir utilizadores e grupos, Google Cloud depende do Cloud ID ou do Google Workspace. Uma conta do Cloud ID ou do Google Workspace funciona como um diretório privado para utilizadores e grupos. Enquanto administrador da conta, pode controlar o ciclo de vida e a configuração dos utilizadores e grupos, bem como definir como a autenticação pode ser realizada.

Quando cria uma conta do Cloud Identity ou do Google Workspace, uma Google Cloud organização é criada automaticamente para si. A conta do Cloud ID ou do Google Workspace e a Google Cloud organização associada partilham o mesmo nome e estão interligadas. No entanto, uma organização pode fazer referência a utilizadores e grupos de outras contas do Cloud ID ou do Google Workspace.Google Cloud

Integre o Microsoft Entra ID e Google Cloud

Apesar de existirem algumas semelhanças entre a estrutura lógica do Microsoft Entra ID e o Google Cloud, não existe um único mapeamento entre as duas estruturas que funcione igualmente bem em todos os cenários. Em alternativa, a abordagem correta para integrar os dois sistemas e mapear a estrutura depende de vários fatores:

• Como mapear inquilinos do Microsoft Entra ID para contas do Cloud ID ou do Google Workspace
• Como mapear domínios DNS
• Como mapear utilizadores
• Como mapear grupos

As secções seguintes analisam cada um destes fatores.

OGoogle Cloud interage apenas com o Microsoft Entra ID e não com o Active Directory no local. Assim, a forma como mapeou florestas e domínios do seu Active Directory no local para o Microsoft Entra ID é de menor importância.

Mapeie inquilinos do Microsoft Entra ID

As secções seguintes descrevem como mapear inquilinos do Microsoft Entra ID para estes cenários:

• Inquilino único
• Vários inquilinos
• Utilizadores externos

Inquilino único

Se usar apenas um inquilino do Microsoft Entra ID, pode mapear o inquilino para uma única conta do Cloud ID ou do Google Workspace e configurar a federação entre os dois. Esta conta do Cloud ID ou do Google Workspace fornece, então, a base para uma única Google Cloud organização que pode usar para gerir todos os Google Cloud recursos.

Vários inquilinos

Em organizações maiores, não é invulgar ter mais do que um inquilino do Microsoft Entra ID. Podem ser usados vários inquilinos para diferenciar entre ambientes de teste e de produção ou para diferenciar entre diferentes partes de uma organização.

É possível mapear vários inquilinos do Microsoft Entra ID para uma única conta do Cloud Identity ou do Google Workspace, e configurar o aprovisionamento de utilizadores e o início de sessão único em conformidade. No entanto, tal mapeamento N:1 pode enfraquecer o isolamento entre inquilinos do Microsoft Entra ID: se conceder a vários inquilinos do Microsoft Entra ID autorização para criar e modificar utilizadores numa única conta do Cloud ID ou Google Workspace, estes inquilinos podem interferir e adulterar as alterações uns dos outros.

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

No Google Cloud, é criada uma organização separada para cada conta do Cloud ID ou do Google Workspace. Uma vez que Google Cloud permite que os recursos sejam organizados através de projetos e pastas numa única organização, ter mais do que uma organização é frequentemente impraticável. No entanto, pode selecionar uma das organizações e associá-la às outras contas do Cloud Identity ou Google Workspace, criando efetivamente uma organização federada com várias florestas do Active Directory. As outras organizações permanecem não usadas.

Utilizadores externos

Com o Microsoft Entra ID B2B, pode convidar utilizadores externos como convidados para o seu inquilino do Microsoft Entra ID. É criado um novo utilizador para cada convidado e o Microsoft Entra ID atribui automaticamente um UPN a estes utilizadores convidados. O UPN gerado pelo Microsoft Entra ID usa um prefixo derivado do endereço de email do convidado, combinado com o domínio inicial do inquilino: prefix#EXT#@tenant.onmicrosoft.com.

O aprovisionamento de utilizadores convidados do Microsoft Entra ID para o Cloud ID ou o Google Workspace está sujeito a determinadas limitações:

• Não pode mapear o UPN de utilizadores convidados para endereços de email no Cloud ID ou Google Workspace porque onmicrosoft.com é um domínio que não pode ser adicionado nem validado no Cloud ID ou Google Workspace. Por isso, tem de mapear os utilizadores através de um atributo que não seja o UPN.
• Se um utilizador convidado for suspenso no respetivo inquilino principal, o utilizador correspondente no Cloud ID ou no Google Workspace pode permanecer ativo e o acesso aos recursos pode não ser revogado corretamente. Google Cloud

Uma melhor forma de lidar com utilizadores convidados provenientes de um inquilino do Microsoft Entra ID diferente é criar várias contas do Cloud Identity ou do Google Workspace , conforme descrito na secção anterior, cada uma federada com um inquilino do Microsoft Entra ID diferente. Para mais informações, consulte o artigo Aprovisionamento de utilizadores B2B e início de sessão único do Microsoft Entra ID

Para conceder a um utilizador externo acesso a determinados Google Cloud recursos, não é um pré-requisito que o utilizador tenha uma conta de utilizador no Cloud Identity ou no Google Workspace. A menos que seja restrito por política, também pode adicionar o utilizador externo diretamente como membro aos respetivos projetos, pastas ou organização, desde que o utilizador tenha uma identidade Google.

Mapeie domínios DNS

O DNS desempenha um papel crucial, tanto para o Microsoft Entra ID como para o Cloud ID e o Google Workspace. O segundo fator a ter em atenção ao planear a federação do Microsoft Entra ID e do Google Cloud é como pode partilhar ou mapear domínios DNS entre o Microsoft Entra ID e o Google Cloud.

Utilização de domínios DNS em Google Cloud

O Início de sessão da Google, que Google Cloud usa para fins de autenticação, usa endereços de email para identificar os utilizadores. A utilização de endereços de email não só garante que são globalmente únicos, como também permite o envio de mensagens de notificação para os endereços. Google Cloud

O Início de sessão Google determina o diretório ou o fornecedor de identidade a usar para autenticar um utilizador com base na parte do domínio dos endereços de email, que segue o @. Para um endereço de email que usa o domínio gmail.com, por exemplo, o início de sessão Google usa o diretório de utilizadores do Gmail para autenticação.

Quando se inscreve numa conta do Google Workspace ou do Cloud Identity, cria um diretório privado que o Início de sessão pode usar para autenticação. Tal como o diretório do Gmail está associado ao domínio gmail.com, as contas do Google Workspace e do Cloud ID têm de estar associadas a um domínio personalizado. São usados três tipos diferentes de domínios:

• Domínio principal: este domínio identifica a conta do Cloud ID ou do Google Workspace e é usado como o nome da organização no Google Cloud. Quando se inscreve no Cloud ID ou no Google Workspace, tem de especificar este nome de domínio.
• Domínio secundário: juntamente com o domínio principal, pode associar outros domínios secundários a uma conta do Cloud ID ou do Google Workspace. Cada utilizador no diretório está associado ao domínio principal ou a um dos domínios secundários. Dois utilizadores, [e-mail] e [e-mail], são considerados utilizadores separados se example.com for o domínio principal e secondary.example.com for um domínio secundário.
• Domínio do alias: um domínio do alias é um nome alternativo para outro domínio. Ou seja, [e-mail] e [e-mail] referem-se ao mesmo utilizador se alias.example.com estiver configurado como um domínio de alias para example.com.

Todos os domínios têm de cumprir os seguintes requisitos:

• Têm de ser nomes de domínio DNS globais válidos. Durante a configuração, pode ter de ter acesso administrativo às respetivas zonas de DNS para validar a propriedade do domínio.
• Um domínio, como example.com, só pode referir-se a um único diretório. No entanto, pode usar subdomínios diferentes, como subdomain.example.com, para se referir a diretórios diferentes.
• Os domínios principal e secundário devem ter um registo MX válido para que as mensagens enviadas para endereços de email formados através deste nome de domínio possam ser entregues corretamente.

Utilização de domínios DNS no Microsoft Entra ID

A forma como o Cloud Identity e o Google Workspace usam o DNS é semelhante à forma como o Microsoft Entra ID depende do DNS para distinguir inquilinos do Microsoft Entra ID e associar nomes de utilizador a inquilinos. No entanto, tenha em atenção duas diferenças notáveis:

1. Domínios iniciais: quando cria um inquilino do Microsoft Entra ID, o inquilino é associado a um domínio inicial, que é um subdomínio de onmicrosoft.com. Este domínio é diferente de qualquer nome de domínio personalizado que possa registar, uma vez que não é proprietário do domínio e não tem acesso administrativo à zona DNS respetiva.

   O Cloud ID não tem um equivalente de um domínio inicial e, em alternativa, requer que detenha a propriedade de todos os domínios que associa a uma conta do Cloud ID. Este requisito significa que não pode registar um subdomínio onmicrosoft.com como um domínio do Cloud Identity.

2. Domínios usados em identificadores de utilizadores: o Microsoft Entra ID distingue entre endereços de email MOERAs (Microsoft Online Email Routing Addresses) e UPNs. Ambos seguem um formato RFC 822 (user@domain), mas servem propósitos diferentes: quando os UPNs são usados para identificar utilizadores e são usados no formulário de início de sessão, apenas os MOERAs são usados para entregar emails.

   O sufixo de domínio usado pelos UPNs tem de corresponder a um dos domínios registados do seu inquilino do Microsoft Entra ID. O mesmo requisito não se aplica aos endereços de email.

   O Cloud ID e o Google Workspace não dependem do conceito de um UPN e, em vez disso, usam o endereço de email de um utilizador como identificador. Consequentemente, o domínio usado pelo endereço de email tem de corresponder a um dos domínios registados da conta do Cloud ID ou do Google Workspace.

Um inquilino do Microsoft Entra ID e uma conta do Cloud ID ou do Google Workspace podem usar os mesmos domínios DNS. Se não for possível usar os mesmos domínios, pode configurar o aprovisionamento de utilizadores e o Início de sessão único para substituir os nomes de domínio.

Tendo em conta as duas diferenças descritas acima, deve basear o mapeamento de domínios na forma como planeia mapear os utilizadores entre o Microsoft Entra ID e o Cloud Identity ou o Google Workspace.

Utilizadores do mapa

O terceiro fator a ter em conta ao planear a federação do Microsoft Entra ID e do Google Cloud é como mapear os utilizadores entre o Microsoft Entra ID e o Cloud Identity ou o Google Workspace.

Mapear com êxito os utilizadores do Microsoft Entra ID para utilizadores no Cloud ID ou Google Workspace requer duas informações para cada utilizador:

1. Um ID estável e exclusivo que pode usar durante a sincronização para acompanhar que utilizador do Microsoft Entra ID corresponde a que utilizador no Cloud ID ou Google Workspace.
2. Um endereço de email cuja parte do domínio corresponde a um domínio principal, secundário ou alias do Cloud ID. Uma vez que este endereço de email vai ser usado em todo o sistema Google Cloud, deve ser legível.

Internamente, o Microsoft Entra ID identifica os utilizadores pelo ObjectId, que é um ID gerado aleatoriamente e exclusivo a nível global. Embora este ID seja estável e, por isso, cumpra o primeiro requisito, não tem significado para os humanos e não segue o formato de um endereço de email. Para mapear utilizadores, as únicas opções práticas são mapear por UPN ou por endereço de email.

Se o utilizador introduzir um endereço de email pertencente a uma conta do Cloud ID ou do Google Workspace configurada para usar o início de sessão único com o Microsoft Entra ID, o utilizador é redirecionado para o ecrã de início de sessão do Microsoft Entra ID.

O Microsoft Entra ID usa UPNs, e não endereços de email, para identificar os utilizadores, pelo que o ecrã de início de sessão pede ao utilizador que forneça um UPN.

Se o inquilino do Microsoft Entra ID estiver configurado para usar o AD FS para o início de sessão, outro redirecionamento leva o utilizador para o ecrã de início de sessão do AD FS. O AD FS pode identificar os utilizadores através do UPN do Active Directory ou do nome de início de sessão anterior ao Windows 2000 (domain\user).

Se o endereço de email usado para o Cloud Identity ou o Google Workspace, o UPN usado pelo Microsoft Entra ID e o UPN usado pelo Active Directory forem todos diferentes, a sequência de ecrãs de início de sessão pode tornar-se confusa para os utilizadores finais. Por outro lado, se os três identificadores forem iguais aos das capturas de ecrã de exemplo ([e-mail]), os utilizadores não são expostos às diferenças técnicas entre os UPNs e os endereços de email, o que minimiza a potencial confusão entre os seus utilizadores.

Mapeamento por UPN

Do ponto de vista da experiência do utilizador, o mapeamento dos UPNs do Microsoft Entra ID para endereços de email do Cloud Identity ou do Google Workspace pode ser considerado a melhor opção. Outra vantagem de usar UPNs é que o Microsoft Entra ID garante a exclusividade para evitar o risco de conflitos de nomes.

No entanto, para mapear os UPNs do Microsoft Entra ID para endereços de email do Cloud Identity, tem de cumprir os seguintes requisitos:

• Os UPNs do Microsoft Entra ID devem ser endereços de email válidos para que todos os emails de notificação enviados pelo Google Cloud sejam entregues corretamente na caixa de correio do utilizador. Se ainda não for o caso, pode configurar endereços de email de alias para garantir que o utilizador recebe esse email.
• Os UPNs de todos os utilizadores relevantes no Microsoft Entra ID têm de 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 email no Cloud ID, porque o domínio inicial não é detido por si, mas sim pela Microsoft.
• Todos os domínios personalizados usados pelo Microsoft Entra ID para UPNs também têm de ser registados no Cloud Identity. Este requisito significa que tem de ter acesso às respetivas zonas de DNS para realizar a validação de domínio. Para evitar substituir os registos DNS existentes que possa ter criado para validar a propriedade do domínio no Microsoft Entra ID, pode usar um registo CNAME para validar a propriedade do domínio no Cloud Identity.TXT

Mapeie utilizadores por endereço de email

Se o mapeamento dos UPNs do Microsoft Entra ID para endereços de email do Cloud Identity ou do Google Workspace não for uma opção, pode mapear os utilizadores por endereço de email.

Quando especifica um endereço de email no Active Directory, este é armazenado no atributo mail do objeto user respetivo, e o Microsoft Entra ID Connect sincroniza o valor com o atributo Mail no Microsoft Entra ID. O Microsoft Entra ID também disponibiliza o atributo para o aprovisionamento de utilizadores, para que o possa mapear para o endereço de email no Cloud Identity ou cloudid_name_short.

É fundamental que o atributo Mail do Microsoft Entra ID não seja apresentado atualmente no portal do Azure e só possa ser visto e editado através de APIs ou do PowerShell. Embora a interface do utilizador lhe permita especificar um endereço de email e um endereço de email alternativo, nenhum destes valores é armazenado no atributo Mail, pelo que não podem ser usados para o aprovisionamento no Cloud Identity nem no cloudid_name_short. Como resultado, o mapeamento de utilizadores de um endereço de email só é prático quando faz a maioria da criação e edição de utilizadores no Active Directory e não no Microsoft Entra ID.

O mapeamento de utilizadores por endereço de email requer que cumpra os seguintes requisitos adicionais:

• As atribuições de email têm de estar concluídas. É necessário atribuir um endereço de email a todos os utilizadores sujeitos à sincronização. Especialmente quando os utilizadores são sincronizados a partir de um Active Directory no local, isto pode não ser o caso, uma vez que mail é um atributo de utilizador opcional no Active Directory. Os utilizadores que não têm um endereço de email no atributo Mail do Microsoft Entra ID são ignorados silenciosamente durante a sincronização.
• Os endereços de email têm de ser exclusivos no inquilino do Microsoft Entra ID. Embora o Active Directory não verifique a unicidade na criação de utilizadores, o Microsoft Entra ID Connect deteta colisões por predefinição, o que pode fazer com que a sincronização dos utilizadores afetados falhe.
• Os domínios usados pelos endereços de email não têm de estar registados no Microsoft Entra ID, mas têm de estar registados no Cloud ID ou no Google Workspace. Este requisito significa que tem de ter acesso às zonas DNS respetivas para realizar a validação de domínio e exclui a utilização de endereços de email com domínios que não detém (como gmail.com).

Mapeie o ciclo de vida do utilizador

Depois de definir um mapeamento entre os utilizadores do Microsoft Entra ID e os utilizadores no Cloud Identity ou no Google Workspace, tem de decidir que conjunto de utilizadores quer aprovisionar. Consulte as nossas práticas recomendadas sobre o mapeamento de conjuntos de identidades para receber orientações sobre como tomar esta decisão.

Se não quiser aprovisionar todos os utilizadores do seu inquilino do Microsoft Entra ID, pode ativar o aprovisionamento para um subconjunto de utilizadores através de atribuições de utilizadores ou filtros de âmbito.

A tabela seguinte resume o comportamento predefinido do aprovisionamento do Microsoft Entra ID e mostra como a ativação ou a desativação do aprovisionamento para um utilizador controla as ações que o Microsoft Entra ID vai realizar no Cloud Identity ou no Google Workspace.

Aprovisionamento ativado para o utilizador do Microsoft Entra ID	Estado do utilizador no Cloud ID ou no Google Workspace	Ação realizada no Microsoft Entra ID	Ação realizada no Cloud ID ou no Google Workspace
Não	(não existe)	Ative a Administração de contas	Criar novo utilizador (*)
Não	Existe (ativo)	Ative a Administração de contas	Atualize o utilizador existente
Não	Existe (suspensa)	Ative a Administração de contas	Atualize o utilizador existente e mantenha-o suspenso
Sim	Existe	Modificar utilizador	Atualize o utilizador existente
Sim	Existe	Mude o nome do UPN/endereço de email	Altere o endereço de email principal e mantenha o endereço anterior como alias
Sim	Existe	Desative a Administração de contas	Suspender utilizador
Sim	Existe	Elimine o utilizador de forma recuperável	Suspender utilizador

(*) Se existir uma conta de consumidor com o mesmo endereço de email, a conta de consumidor é removida.

Grupos de mapas

O quarto fator a ter em atenção quando planeia federar o Microsoft Entra ID e Google Cloud é se deve sincronizar grupos entre o Microsoft Entra ID e Google Cloud e como mapeá-los.

Os Google Cloud, grupos são usados frequentemente como uma forma de gerir o acesso de forma eficiente em vários projetos. Em vez de atribuir utilizadores individuais a funções do IAM em cada projeto, define um conjunto de grupos que modelam funções comuns na sua organização. Em seguida, atribui esses grupos a um conjunto de funções do IAM. Ao modificar a associação dos grupos, pode controlar o acesso dos utilizadores a um conjunto completo de recursos.

O mapeamento de grupos entre o Microsoft Entra ID e o Google Cloud é opcional. Depois de configurar o aprovisionamento de utilizadores, pode criar e gerir grupos diretamente no Cloud Identity ou no Google Workspace, o que significa que o Active Directory ou o Microsoft Entra ID permanecem o sistema central para a gestão de identidades, mas não para a Google Cloud gestão de acesso.

Para manter o Active Directory ou o Microsoft Entra ID como o sistema central para a gestão de identidades e a gestão de acesso, recomendamos que sincronize os grupos do Microsoft Entra ID em vez de os gerir no Cloud ID ou no Google Workspace. Com esta abordagem, pode configurar o IAM para poder usar as subscrições de grupos no Active Directory ou no Microsoft Entra ID para controlar quem tem acesso aos recursos no Google Cloud.

Grupos no Cloud ID e Google Workspace

No Cloud Identity e no Google Workspace, existe apenas um tipo de grupo. Os grupos no Cloud ID e no Google Workspace não se limitam ao âmbito da conta do Cloud ID ou do Google Workspace onde foram definidos. Em alternativa, podem incluir utilizadores de diferentes contas do Cloud ID ou Google Workspace, suportar referências e aninhamento noutras contas, e ser usadas em qualquer Google Cloud organização.

Tal como acontece com os utilizadores, o Cloud ID e o Google Workspace identificam os grupos através do endereço de email. O endereço de email não tem de corresponder a uma caixa de correio real, mas tem de usar um dos domínios registados para a respetiva conta do Cloud ID.

Quando trabalha com grupos no IAM, muitas vezes, tem de especificar os grupos por endereço de email e não por nome. Por isso, é melhor que os grupos tenham não só um nome significativo, mas também um endereço de email significativo e reconhecível.

Grupos no Microsoft Entra ID

O Microsoft Entra ID suporta vários tipos de grupos, cada um adequado a diferentes exemplos de utilização. Os grupos têm âmbito num único inquilino e são identificados por um ID do objeto, que é um ID exclusivo gerado aleatoriamente a nível global. Os grupos podem ser aninhados e podem conter utilizadores do mesmo inquilino ou utilizadores convidados de outros inquilinos através do Azure B2B. O Microsoft Entra ID também suporta grupos dinâmicos, cujos membros são determinados automaticamente com base numa consulta.

No contexto da integração do Microsoft Entra ID com o Cloud ID ou o Google Workspace, duas propriedades dos grupos são de interesse principal: se um grupo tem o email ativado e se tem a segurança ativada:

• Um grupo com segurança ativada pode ser usado para gerir o acesso a recursos no Microsoft Entra ID. Por conseguinte, qualquer grupo com segurança ativada é potencialmente relevante no contexto de Google Cloud.
• Um grupo ativado por email tem um endereço de email, o que é relevante porque o Cloud Identity e o Google Workspace requerem que os grupos sejam identificados por um endereço de email.

No Microsoft Entra ID, pode criar grupos do tipo Segurança ou Office 365 (por vezes, denominados grupos unificados). Quando sincroniza grupos a partir de um Active Directory no local ou quando usa o tipo Office 365, também pode criar grupos do tipo lista de distribuição.

A tabela seguinte resume as diferenças entre estes diferentes tipos de grupos no que diz respeito à ativação do envio de emails ou da segurança, e como são mapeados para os tipos de grupos do Active Directory, partindo do princípio de uma configuração predefinida do Microsoft Entra ID Connect:

Origem	Tipo de grupo do Active Directory	Tipo de grupo do Microsoft Entra ID	Com capacidade de envio de emails	Com segurança
Microsoft Entra ID	-	Grupo do Office 365	Sempre	Opcional
Microsoft Entra ID	-	Grupo de segurança	Opcional	Sempre
nas instalações	Grupo de segurança (com email)	Grupo de segurança	Sim	Sim
nas instalações	Grupo de segurança (sem email)	Grupo de segurança	Não	Sim
nas instalações	Lista de distribuição (com email)	Lista de distribuição	Sim	Não
nas instalações	Lista de distribuição (sem email)	(ignorada pelo Microsoft Entra ID Connect)

Ao contrário do que acontece com os utilizadores, o Microsoft Entra ID requer que os endereços de email atribuídos a grupos usem um domínio que tenha sido registado como um domínio personalizado no Microsoft Entra ID. Este requisito resulta no seguinte comportamento predefinido:

• Se um grupo no Active Directory usar um endereço de email que use um domínio que tenha sido registado anteriormente no Microsoft Entra ID, o endereço de email é mantido corretamente durante a sincronização com o Microsoft Entra ID.
• Se um grupo no Active Directory usar um endereço de email que não tenha sido registado no Microsoft Entra ID, o Microsoft Entra ID gera automaticamente um novo endereço de email durante a sincronização. Este endereço de email usa o domínio predefinido do inquilino. Se o seu inquilino usar o domínio inicial como o domínio predefinido, o endereço de email resultante vai ter o formato [name]@[tenant].onmicrosoft.com.
• Se criar um grupo do Office 365 no Microsoft Entra ID, o Microsoft Entra ID também gera automaticamente um endereço de email que usa o domínio predefinido do inquilino.

Mapeie identidades de grupos

O mapeamento bem-sucedido de grupos do Microsoft Entra ID para grupos do Cloud ID ou do Google Workspace requer um identificador comum, e este identificador tem de ser um endereço de email. No lado do Microsoft Entra ID, este requisito deixa-lhe duas opções:

• Pode usar o endereço de email de um grupo no Microsoft Entra ID e mapeá-lo para um endereço de email do Cloud ID ou do Google Workspace.
• Pode derivar um endereço de email do nome do grupo no Microsoft Entra ID e mapear o endereço resultante para um endereço de email no Cloud ID ou no Google Workspace.

Mapeie por endereço de email

O mapeamento de grupos por endereço de email é a escolha mais óbvia, mas requer que cumpra vários requisitos:

• Todos os grupos sujeitos à sincronização têm de ter um endereço de email. Na prática, isto significa que só pode sincronizar grupos com capacidade de envio de correio eletrónico. Os grupos que não têm um endereço de email são ignorados durante o aprovisionamento.
• Os endereços de email têm de ser exclusivos no inquilino. Uma vez que o Microsoft Entra ID não aplica a exclusividade, pode ter de implementar verificações ou políticas personalizadas.
• Os domínios usados pelos endereços de email têm de estar registados no Microsoft Entra ID e no Cloud ID ou Google Workspace. Todos os grupos com endereços de email que usam domínios não registados no Cloud Identity ou no Google Workspace, incluindo o domínio tenant.onmicrosoft.com, não vão ser sincronizados.

Se todos os grupos relevantes cumprirem estes critérios, identifique os domínios usados por estes endereços de email e certifique-se de que a lista de domínios DNS registados no Cloud Identity ou no Google Workspace abrange estes domínios.

Mapeie por nome

O cumprimento dos critérios necessários para mapear grupos por endereço de email pode ser difícil, especialmente se muitos dos grupos de segurança que pretende aprovisionar no Cloud Identity ou no Google Workspace não tiverem o email ativado. Neste caso, pode ser melhor derivar automaticamente um endereço de email do nome a apresentar do grupo.

A obtenção de um endereço de email apresenta dois desafios:

1. Um endereço de email derivado do nome de um grupo pode entrar em conflito com o endereço de email de um utilizador.
2. O Microsoft Entra ID não aplica a exclusividade aos nomes dos grupos. Se vários grupos no seu inquilino do Microsoft Entra ID partilharem o mesmo nome, os endereços de email derivados deste nome vão entrar em conflito, o que faz com que apenas um grupo seja sincronizado com êxito.

Pode superar o primeiro desafio usando um domínio para o endereço de email gerado que seja diferente de qualquer um dos domínios usados pelos utilizadores. Por exemplo, se todos os seus utilizadores usarem endereços de email com example.com como domínio, pode usar groups.example.com para todos os grupos. O registo de subdomínios no Cloud Identity ou no Google Workspace não requer a validação do domínio, pelo que a zona DNS groups.example.com nem sequer tem de existir.

Só pode superar o segundo desafio, os nomes de grupos duplicados, tecnicamente, derivando o endereço de email do grupo do ID do objeto. Uma vez que os nomes dos grupos resultantes são bastante enigmáticos e difíceis de usar, é melhor identificar e mudar o nome dos nomes dos grupos duplicados no Microsoft Entra ID antes de configurar o aprovisionamento para o Cloud Identity ou o Google Workspace.

Mapeie 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, tem de decidir que conjunto de grupos quer aprovisionar. Tal como para os utilizadores, pode ativar o aprovisionamento para um subconjunto de grupos através de atribuições de grupos ou filtros de âmbito.

A tabela seguinte resume o comportamento predefinido do aprovisionamento do Microsoft Entra ID e mostra como a ativação ou a desativação do aprovisionamento para um grupo controla as ações que o Microsoft Entra ID vai realizar no Cloud Identity ou no Google Workspace.

Aprovisionamento ativado para o grupo do Microsoft Entra ID	Estado do grupo no Cloud ID ou no Google Workspace	Ação realizada no Microsoft Entra ID	Ação realizada no Cloud ID ou no Google Workspace
Não	(não existe)	Ative a Administração de contas	Criar novo grupo
Não	Existe	Ative a Administração de contas	Adicione um membro e mantenha todos os membros existentes
Sim	Existe	Mudar o nome do grupo	Mudar o nome do grupo
Sim	Existe	Modifique a descrição	Atualizar descrição
Sim	Existe	Adicionar membro	Adicione um membro e mantenha todos os membros existentes
Sim	Existe	Remover membro	Remover membro
Sim	Existe	Desative a Administração de contas	O grupo foi deixado tal como está (incluindo os membros)
Sim	Existe	Eliminar grupo	O grupo foi deixado tal como está (incluindo os membros)

Nota: quando elimina um grupo no Microsoft Entra ID, o Microsoft Entra ID não propaga a eliminação para o Cloud Identity nem para o Google Workspace. Da mesma forma, se ativar o aprovisionamento para um grupo e, posteriormente, o desativar, o grupo no Cloud Identity ou Google Workspace permanece ativo. Este comportamento pode resultar na retenção inadvertida de direitos de acesso por parte dos utilizadores no Google Cloud. Para evitar que isto aconteça, remova primeiro todos os membros de um grupo, aguarde que as alterações sejam propagadas e só depois elimine o grupo no Microsoft Entra ID ou desative o aprovisionamento para o grupo no Microsoft Entra ID.

O que se segue?

• Leia acerca das práticas recomendadas para planear contas e organizações e das práticas recomendadas para federar Google Cloud com um fornecedor de identidade externo.
• Saiba como configurar o aprovisionamento e o início de sessão único entre o Microsoft Entra ID e o Cloud Identity.
• Saiba mais sobre as práticas recomendadas para gerir contas de superadministrador.