Como federar o Google Cloud com o Azure Active Directory

Neste artigo, descrevemos como configurar o Cloud Identity ou o Google Workspace para usar o Azure AD como IdP e o código de origem para identidades.

O artigo compara a estrutura lógica do Azure AD com a estrutura usada pelo Cloud Identity e pelo Google Workspace e descreve como mapear locatários, domínios, usuários e grupos do Azure AD.

Como 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 Azure AD. 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 Azure AD.

Federar o Cloud Identity com o Azure AD

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

  • Provisionamento de usuários: grupos e usuários de usuários relevantes são sincronizados periodicamente do Azure AD para o Cloud Identity ou o Google Workspace. Esse processo garante que quando você criar um novo usuário no Azure AD ou sincronizar um novo usuário do Active Directory para o Azure AD, ele também será disponibilizado no Google Cloud para que possa ser referenciado no Google Cloud antes mesmo de o usuário associado fazer login na 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 Azure AD 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 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). Dependendo da configuração do Azure AD, ele pode executar um dos seguintes procedimentos:

    • 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 o Cloud Identity ou o Google Workspace autentica o Azure AD não apenas por necessidade de sincronizar senhas com o Google Cloud, mas também garante que quaisquer políticas aplicáveis ou mecanismos de autenticação multifator (MFA) configurados no Azure AD ou no AD FS são aplicados.

Estrutura lógica do Azure AD

Com o Azure, você usa um ou mais locatários do Azure AD (também chamados de diretórios). Os locatários do Azure AD 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 Azure AD 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 respectivo locatário.

Estrutura lógica do Azure AD

Uma empresa pode manter vários locatários do Azure AD. 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, exceto para contas de serviço, as organizações não são usadas para gerenciar usuários e grupos, o que torna as organizações diferentes dos locatários do Azure AD.

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.

Estrutura lógica do Google Cloud

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.

Como integrar o Azure AD e o Google Cloud

Apesar de certas semelhanças entre a estrutura lógica do Azure AD e do Google Cloud, 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 associar os locatários do Azure AD às contas do Cloud Identity ou do Google Workspace
  • Como mapear domínios DNS
  • Como mapear usuários
  • Como mapear grupos

Nas seções a seguir, analisamos cada um desses pontos.

O Google Cloud interage apenas com o Azure AD, não com o Active Directory local. Portanto, a maneira como você associou florestas e domínios do Active Directory no local ao Azure AD é uma preocupação menor.

Como mapear locatários do Azure AD

Locatário único

Se você usa apenas um único locatário do Azure AD, 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 você pode usar para gerenciar todos os recursos do Google Cloud.

Como mapear um locatário e uma única conta do Cloud Identity

Vários locatários

Em organizações grandes, é normal ter mais de um locatário do Azure AD. Vários locatários podem ser usados para diferenciar ambientes de teste e produção ou para diferenciar partes de uma organização.

Embora seja possível provisionar usuários e grupos de mais de um locatário do Azure AD para uma única conta do Cloud Identity ou do Google Workspace, não é possível configurar o logon único de uma maneira que funcione para usuários nos vários locatários do Azure AD. Se você usar vários locatários do Azure AD, precisará criar uma conta do Cloud Identity ou do Google Workspace separada 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, uma vez que o Google Cloud permite a organização dos recursos por meio de projetos e de pastas em uma única organização. 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.

Organização federada com várias florestas do Active Directory

Usuários externos

Com o Azure AD B2B, é possível convidar usuários externos como convidados para o locatário do Azure AD. Um novo usuário é criado para cada convidado, e o Azure AD atribui automaticamente um UPN a esses usuários convidados. O UPN gerado pelo Azure AD 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 do Azure AD 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 Azure AD é 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 Azure AD.

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 seja algo restrito pela política, também é possível adicionar o usuário externo diretamente como membro aos respectivos projetos, pastas ou organizações, desde que o usuário tenha uma identidade do Google.

Como mapear domínios DNS

O DNS desempenha um papel crucial, tanto para o Azure AD quanto para o Cloud Identity e o Google Workspace. O segundo fator a ser considerado ao planejar a federação do Azure AD e do Google Cloud é como compartilhar ou mapear domínios DNS entre o Active Directory 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.

Uso de domínios DNS no GCP

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. 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 domínio alternativo para o principal. 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. Um domínio de alias pode fornecer um nome alternativo apenas para o domínio principal. Não é possível adicionar domínios de alias para domínios secundários.

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 Azure AD

O modo como o Cloud Identity e o Google Workspace usam o DNS é semelhante ao modo como o Azure AD depende do DNS para distinguir os locatários do Azure AD e associar nomes de usuários a locatários. Mas esteja ciente de duas diferenças notáveis:

  1. Domínios iniciais: quando você cria um locatário do Azure AD, 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 Azure AD distingue os endereços de e-mail MOERAs (Endereços de Roteamento de E-mail On-line da Microsoft) de 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 Azure AD. 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 Azure AD e uma conta do Cloud Identity ou do Google Workspace podem usar os mesmos domínios DNS. Considerando as duas diferenças descritas acima, você precisa basear seu mapeamento de domínio em como planeja mapear os usuários entre o Azure AD e o Cloud Identity ou o Google Workspace.

Como 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 Azure AD e o Cloud Identity ou o Google Workspace.

O mapeamento bem-sucedido de usuários do Azure AD para usuários no Cloud Identity ou no Google Workspace requer duas informações para cada usuário:

  1. Um ID único e estável que pode ser usado durante a sincronização para rastrear qual usuário do Azure AD 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 Azure AD 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.

Como mapear usuários pelo 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 Azure AD, o usuário será redirecionado para a tela de logon do Azure AD.

O Azure AD 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.

Tela de logon que solicita um UPN

Se o locatário do Azure AD estiver configurado para usar o AD FS para conexão, 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).

Tela de login do AD FS

Se o endereço de e-mail usado para o Cloud Identity ou o Google Workspace, o UPN usado pelo Azure AD 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 (johndoe@example.com), 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.

Como mapear por UPN

Da perspectiva da experiência do usuário, o mapeamento de UPNs do Azure AD para 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 Azure AD garante exclusividade para evitar o risco de conflitos de nomenclatura.

No entanto, para associar os UPNs do Azure AD aos endereços de e-mail do Cloud Identity, você precisa atender a estes requisitos:

  • Os UPNs do Azure AD 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 correio 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 UPNs de todos os usuários relevantes no Azure AD precisam usar um domínio personalizado como sufixo ([user]@[custom-domain]). Os UPNs que usam o domínio inicial do Azure AD ([user]@[tenant].onmicrosoft.com) 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 à Microsoft.
  • Todos os domínios personalizados usados pelo Azure AD 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 do domínio no Azure AD, use um registro CNAME para confirmar a propriedade do domínio no Cloud Identity.

Como mapear usuários pelo endereço de e-mail

Se mapear endereços de e-mail do UPN do Azure AD para o Cloud Identity ou o Google Workspace não for uma opção, você poderá 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 Azure AD Connect sincroniza o valor com o atributo Mail no Azure AD. O Azure AD também disponibiliza o atributo para provisionamento de usuários para que seja possível mapeá-lo para o endereço de e-mail no Cloud Identity ou cloudid_name_short.

No momento, o atributo Mail do Azure AD 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 Azure AD.

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 Azure AD são ignorados silenciosamente durante a sincronização.
  • Os endereços de e-mail precisam ser exclusivos no locatário do Azure AD. Ainda que o Active Directory não verifique a exclusividade na criação do usuário, o Azure AD Connect detecta colisões por padrão, o que pode causar falha na sincronização dos usuários afetados.
  • Os domínios usados por endereços de e-mail não precisam ser registrados no Azure AD, mas precisam ser registrados no Cloud Identity ou cloudid_name_short. 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).

Como mapear o ciclo de vida do usuário

Depois de definir um mapeamento entre os usuários do Azure AD 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 orientações sobre como tomar essa decisão.

Se você não quiser provisionar todos os usuários do locatário do Azure AD, poderá ativar 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 Azure AD e mostra como ativar ou desativar o provisionamento para um usuário controla quais ações o Azure AD realizará no Cloud Identity ou no Google Workspace.

Provisionamento ativado para o usuário do Azure AD Estado do usuário no Cloud Identity/Google Workspace Ação realizada no Azure AD Ação realizada no Cloud Identity/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.

Como mapear grupos

O quarto fator a ser analisado quando você planeja federar o Active Directory e o Google Cloud é sincronizar grupos entre o Active Directory 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 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.

Mapear grupos entre o Azure AD 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 Azure AD 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 Azure AD como o sistema central de gerenciamento de identidades e gerenciamento de acesso, recomendamos que você sincronize grupos do Azure AD 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 Azure AD 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 Azure AD

O Azure AD é 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 Azure AD também é compatível com grupos dinâmicos, com membros que são determinados automaticamente com base em uma consulta.

No contexto da integração do Azure AD 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 Azure AD. Portanto, qualquer grupo ativado por segurança é potencialmente relevante no contexto do Google Cloud.
  • Um grupo ativado por e-mail tem um endereço de e-mail, o que é relevante porque o Cloud Identity e o Google Workspace exigem que os grupos sejam identificados por um endereço.

No Azure AD, é 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 Azure AD Connect:

Fonte Tipo de grupo do Active Directory Tipo de grupo do Azure AD Ativados para e-mail Ativados para segurança
Azure AD - Grupo do Office 365 Sempre Opcional
Azure AD - 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 Azure AD Connect)

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

  • Se um grupo no Active Directory usar um endereço de e-mail que use um domínio que tenha sido registrado anteriormente no Azure AD, esse endereço será mantido durante a sincronização com o Azure AD.
  • Se um grupo no Active Directory usar um endereço de e-mail que não tenha sido registrado no Azure AD, o Azure AD 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 Azure AD, o Azure AD também gerará automaticamente um endereço de e-mail que usa o domínio padrão do locatário.

Como mapear identidades de grupos

O mapeamento bem-sucedido dos grupos do Azure AD e dos grupos do Cloud Identity ou do Google Workspace requer um identificador comum. Esse identificador precisa ser um endereço de e-mail. No lado do Azure AD, esse requisito deixa duas opções:

  • Use o endereço de e-mail de um grupo no Azure AD e mapeie-o 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 Azure AD 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 Azure AD não impõe exclusividade, talvez será preciso implementar verificações ou políticas personalizadas.
  • Os domínios usados pelos endereços de e-mail precisam ser registrados no Azure AD e no Cloud Identity/Google Workspace. Todos os grupos com endereços de e-mail que usam domínios não registrados no Cloud Identity/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.

Como 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 Azure AD não impõe exclusividade para nomes de grupos. Se vários grupos em seu locatário do Azure AD 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 com êxito.

É 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 Azure AD antes de configurar o provisionamento no Cloud Identity ou no Google Workspace.

Como mapear o ciclo de vida do grupo

Depois de definir um mapeamento entre os grupos do Azure AD e grupos no Cloud Identity ou no Google Workspace, é preciso decidir 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 Azure AD e mostra como ativar ou desativar o provisionamento para um grupo que controla quais ações o Azure AD realizará no Cloud Identity ou no Google Workspace.

Provisionamento ativado para o grupo do Azure AD Estado do grupo no Cloud Identity/Google Workspace Ação realizada no Azure AD Ação realizada no Cloud Identity/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)

A seguir