Gerenciamento automático de identidade

O gerenciamento automático de identidade permite que você adicione diretamente usuários, entidades de serviço e grupos de Microsoft Entra ID ao Azure Databricks. Quando o gerenciamento automático de identidade está habilitado, você pode pesquisar diretamente em espaços de trabalho federados por identidade por usuários, entidades de serviço e grupos, e adicioná-los ao seu espaço de trabalho. Azure Databricks usa Microsoft Entra ID como fonte de registro, portanto, todas as alterações nas associações de grupo são respeitadas em Azure Databricks.

O gerenciamento automático de identidade é habilitado por padrão para contas criadas após 1º de agosto de 2025.

Os usuários também podem compartilhar painéis com qualquer usuário, entidade de serviço ou grupo em seu provedor de identidade. Quando compartilhados, esses usuários, entidades de serviço e membros de grupos são adicionados automaticamente à conta Azure Databricks após o logon. Eles não são adicionados como membros à área de trabalho na qual o painel está. Os usuários que não têm acesso ao espaço de trabalho recebem acesso a uma cópia somente para visualização de um painel publicado com permissões de dados compartilhados. Para obter mais informações sobre o compartilhamento de dashboard, consulte Compartilhar um painel.

O provisionamento JIT (Just-In-Time) sempre é habilitado quando o gerenciamento automático de identidade é ativado e você não pode desativá-lo. Os novos usuários são provisionados automaticamente no Azure Databricks após o primeiro logon. Consulte Provisionar automaticamente usuários (JIT).

Não há suporte para o gerenciamento automático de identidade em workspaces federados não identitários. Para obter mais informações sobre federação de identidade, consulte Federação de identidade.

Status de usuário, entidade de serviço e grupo

Quando o gerenciamento automático de identidade está habilitado, usuários, entidades de serviço e grupos da ID do Microsoft Entra ficam visíveis no console da conta e na página de configurações do administrador do workspace. O status deles reflete a atividade e o estado entre o Microsoft Entra ID e o Azure Databricks:

O rótulo de status Ativo: removido de [IdP] inclui o nome do seu provedor de identidade. Por exemplo, Ativo: Removido do EntraID.

As identidades gerenciadas usando o gerenciamento automático de identidade são mostradas como Externas no Azure Databricks. Identidades externas não podem ser atualizadas usando a interface do usuário do Azure Databricks.

Compartilhamento e atribuição de permissões

Quando o gerenciamento automático de identidades está habilitado, você pode selecionar usuários e entidades de serviço de Microsoft Entra ID ao compartilhar ou atribuir permissões em Azure Databricks.

Para grupos, o comportamento de compartilhamento difere por tipo de ativo:

• Ativos em nível de conta: os grupos estão disponíveis ao compartilhar ou atribuir permissões a ativos em nível de conta, como Databricks Apps, objetos do Unity Catalog, dashboards de IA/BI, Genie Agents e atribuição de espaços de trabalho.
• Ativos no nível do workspace: para compartilhar ativos no nível do workspace (como notebooks, trabalhos, sql warehouses, alertas e arquivos) com grupos, os administradores do workspace devem primeiro adicionar diretamente o grupo ao workspace.

Gerenciamento automático de identidade versus provisionamento SCIM

Quando o gerenciamento automático de identidade está habilitado, todos os usuários, grupos e associações a grupos são sincronizados do seu provedor de identidade para o Azure Databricks, portanto, o provisionamento por SCIM não é necessário. Se você mantiver o provisionamento SCIM em paralelo, o SCIM continuará a gerenciar as identidades que foram adicionadas por meio do provisionamento SCIM. Ele não gerencia identidades que não foram adicionadas por meio do provisionamento SCIM.

O provisionamento SCIM requer a função Administrador de Aplicativos da Nuvem e um aplicativo separado do Microsoft Entra ID.

Azure Databricks recomenda usar o gerenciamento automático de identidade. A tabela a seguir compara os recursos de gerenciamento automático de identidades com os recursos do provisionamento SCIM.

ID externo do Azure Databricks e ID de objeto do Microsoft Entra ID

O Azure Databricks usa o Microsoft Entra ID ObjectId como o vínculo autoritativo para sincronizar identidades e associações de grupo, e atualiza automaticamente o campo externalId para corresponder ao ObjectId em um fluxo recorrente diário. O Databricks recomenda não misturar métodos de provisionamento. Adicionar a mesma identidade por meio do gerenciamento automático de identidade e do provisionamento SCIM causa entradas duplicadas e conflitos de permissão. Use o gerenciamento de identidade automático como a única fonte de verdade, com as associações de grupos fazendo o espelhamento do Microsoft Entra ID.

Você pode mesclar essas identidades duplicadas fornecendo sua ID externa no Azure Databricks. Use a API Usuários da Conta, Entidades de Serviço da Conta ou Grupos de Contas para atualizar a entidade de segurança a fim de adicionar a objectId do Microsoft Entra ID ao campo externalId.

Como o externalId pode ser atualizado ao longo do tempo, Azure Databricks recomendamos que você não use fluxos de trabalho personalizados que dependam do campo externalId.

Como o gerenciamento automático de identidades faz a correspondência de identidades

Quando o gerenciamento automático de identidade sincroniza uma identidade, ele faz a correspondência dessa identidade com o usuário, a entidade de serviço ou o grupo correto no seu provedor de identidade. As informações que o Azure Databricks usa para encontrar a correspondência dependem de como a sincronização é acionada.

Correspondência durante o login

Quando um usuário faz login por meio de single log-on, o Azure Databricks recebe um token do seu provedor de identidade. Quando o token inclui o ID de objeto do usuário, o Azure Databricks faz a correspondência com base no ID de objeto, que é um identificador estável e exclusivo. Essa é a combinação mais confiável.

O token de login do Microsoft Entra ID inclui o ID do objeto, ID do inquilino, membros do grupo e nome de usuário, então o login corresponde ao ID do objeto.

Correspondência com base no nome de usuário

Alguns fluxos não incluem um token de autenticação, como criar ou renovar um contexto de permissões, a autenticação com token de acesso pessoal, ações no console da conta e a sincronização de identidade em segundo plano. Nesses fluxos, o Azure Databricks faz a correspondência com base no nome de usuário do Azure Databricks. Ele procura no Microsoft Entra ID um usuário cujo nome principal do usuário (UPN) ou e-mail seja igual ao nome de usuário do Azure Databricks e dá preferência a uma correspondência por UPN em vez de uma correspondência por e-mail.

Por exemplo, se um usuário do Azure Databricks tem o nome alice@contoso.comde usuário , o Azure Databricks primeiro procura um usuário do Microsoft Entra ID com o UPN alice@contoso.com. Se nenhum UPN coincidir, ele procura um usuário cujo e-mail seja alice@contoso.com.

Correspondência na resolução e criação de usuários

Quando você compartilha um objeto com uma identidade do Microsoft Entra ID que ainda não existe no Azure Databricks, ou quando a API Resolve User (resolveByExternalId) é chamada, o Azure Databricks primeiro tenta encontrar um usuário existente correspondente no Azure Databricks por UPN ou e-mail. Se nenhum usuário corresponder, o Azure Databricks criará um usuário just-in-time e definirá o nome de usuário com base na forma como o usuário está registrado no Microsoft Entra ID:

• Usuários criados no seu tenant: Azure Databricks usa o UPN como nome de usuário. Por exemplo, um usuário do Microsoft Entra ID com o UPN bob@contoso.com torna-se um usuário do Azure Databricks com o nome bob@contoso.comde usuário .
• Usuários convidados ou sincronizados por colaboração B2B (convidados): O Azure Databricks prefere o e-mail como nome de usuário e recorre ao UPN quando o objeto convidado não tem e-mail. Por exemplo, um convidado cujo UPN é carol_fabrikam.com#EXT#@contoso.onmicrosoft.com e cujo e-mail é carol@fabrikam.com torna-se um usuário do Azure Databricks com o nome carol@fabrikam.comde usuário .

Casos que o gerenciamento automático de identidade não consegue resolver

Algumas configurações de provedores de identidade impedem que o Azure Databricks corresponda de forma confiável ao usuário pretendido. Configurem suas identidades para evitar os seguintes casos.

Múltiplos usuários correspondem ao mesmo e-mail

Se mais de um usuário do Microsoft Entra ID tiver um e-mail igual ao nome de usuário do Azure Databricks, e nenhum deles tiver um UPN correspondente, o Azure Databricks não consegue determinar qual usuário você pretende. Ele corresponde a um deles sem nenhuma ordem garantida, então pode sincronizar o usuário errado, e as sincronizações podem alternar entre os usuários correspondentes ao longo do tempo.

Por exemplo, um usuário do Azure Databricks tem o nome dana@contoso.comde usuário . No Microsoft Entra ID, dois usuários têm o e-maildana@contoso.com: uma conta de membro cujo UPN é d.lee@fabrikam.com, e uma conta de convidado cujo UPN é dana_contoso.com#EXT#@fabrikam.onmicrosoft.com. O nome de usuário corresponde ao e-mail de ambos os usuários, mas não corresponde a nenhum UPN, então o Azure Databricks não consegue diferenciá-los e corresponde a um deles arbitrariamente.

Para evitar esse caso, certifique-se de que o UPN do usuário do Microsoft Entra ID pretendido seja igual ao nome de usuário do Azure Databricks e não mantenha múltiplos objetos do Microsoft Entra ID que compartilham um e-mail.

O nome de usuário vem de um locatário diferente

Um usuário convidado pode entrar com um token que carrega um nome de usuário do seu locatário de origem, enquanto o objeto de convidado no seu locatário não tem UPN nem e-mail iguais a esse nome de usuário. No login, isso ainda funciona, porque a correspondência baseada em tokens resolve o usuário a partir do ID do objeto em vez do nome de usuário. Fluxos sem correspondência de token usam, em vez disso, o nome de usuário do Azure Databricks; assim, não conseguem encontrar o objeto de convidado a ser sincronizado, e a resolução ou o compartilhamento podem criar um usuário do Azure Databricks com um nome de usuário inesperado.

Por exemplo, um usuário do Azure Databricks tem o nome de usuário erin@fabrikam.com, trazido do locatário de origem do usuário. No seu locatário, o objeto de convidado tem o UPN erin_fabrikam.com#EXT#@contoso.onmicrosoft.com e não há nenhum e-mail correspondente. Uma entrada baseada em token identifica esse usuário pelo ID do objeto, mas, como nem o UPN nem o e-mail é igual a erin@fabrikam.com, a correspondência por nome de usuário não encontra nenhum usuário.

Para evitar esse caso, certifique-se de que o e-mail do objeto convidado seja igual ao nome de usuário do Azure Databricks.

Como funciona a sincronização de membros de grupo

Quando o gerenciamento automático de identidade está habilitado, Azure Databricks atualiza as associações de grupo de usuários do seu provedor de identidade durante atividades que disparam verificações de autenticação e autorização, por exemplo, logons do navegador, autenticação de token ou execuções de trabalho. Isso garante que as permissões baseadas em grupo no Azure Databricks permaneçam sincronizadas com as alterações feitas em seu provedor de identidade.

Quando o Azure Databricks atualiza as associações de grupos, ele busca associações de grupos provisórias (aninhadas) do seu provedor de identidade. Isso significa que, se um usuário for membro do Grupo A e o Grupo A for membro do Grupo B, o Azure Databricks reconhecerá o usuário como tendo associação em ambos os grupos. O Azure Databricks busca apenas associações para grupos que foram adicionados ao Azure Databricks. Ele não sincroniza ou recria a hierarquia de grupo pai completa do seu provedor de identidade.

O Azure Databricks atualiza as associações de grupo em agendas diferentes, dependendo da atividade:

• Logins no navegador: As participações em grupos são sincronizadas se tiverem se passado mais de 5 minutos desde a última sincronização.
• Outras atividades (por exemplo, autenticação de tokens ou execução de jobs): o Azure Databricks atualiza as associações de grupos com base em quanto tempo atrás ocorreu a última sincronização:
  • Menos de 10 minutos: Nenhuma atualização ocorre.
  • 10 a 40 minutos: O Azure Databricks aciona uma atualização assíncrona em segundo plano. A solicitação que aciona a atualização pode ainda usar as membresias anteriores dos grupos. As assinaturas atualizadas se aplicam a solicitações subsequentes.
  • Mais de 40 minutos: Azure Databricks atualiza as associações de grupos antes de concluir a solicitação.

Grupos aninhados e entidades de serviço

Quando o gerenciamento automático de identidade está habilitado, os membros de grupos aninhados herdam permissões de grupos provisionados. As permissões atribuídas a um grupo pai se aplicam a todos os usuários e entidades de serviço que pertencem ao grupo, incluindo os adicionados diretamente ao grupo e os que pertencem por meio de associações de grupo aninhadas. Mas, grupos aninhados e entidades de serviço em um grupo não são referenciáveis automaticamente na conta, com exceção do compartilhamento de painéis.

Visibilidade de grupo aninhada

Grupos aninhados são visíveis no Azure Databricks. Considere um grupo filho, Group-C, que é um membro de um grupo pai, Group-P. Se você adicionar Group-P a um espaço de trabalho, todas as identidades em Group-P e Group-C terão acesso ao espaço de trabalho. Nas interfaces do administrador da conta e do administrador do workspace, Group-C aparece como membro na página de detalhes dos membros do grupo Group-P. Somente o primeiro nível de aninhamento aparece na página de detalhes do grupo.

Considerações para grupos aninhados

• Acesso ao workspace: grupos hierárquicos e entidades de serviço não precisam ser adicionados diretamente a um workspace para obter acesso. Se um grupo pai for adicionado a um espaço de trabalho, todos os membros desse grupo terão acesso ao espaço de trabalho.
• Ativos em nível de conta: os grupos estão disponíveis ao compartilhar ou atribuir permissões a ativos em nível de conta, como Databricks Apps, objetos do Unity Catalog, dashboards de IA/BI, Genie Agents e atribuição de espaços de trabalho.
• Limites do grupo de contas e da entidade de serviço: grupos aninhados e entidades de serviço que não são provisionadas diretamente para a conta não contam para os limites do grupo de contas. Somente os grupos que são explicitamente provisionados à conta contam para os limites.

Por exemplo, na ID do Microsoft Entra, você tem a seguinte estrutura de grupo:

• Marketing-All (grupo-pai)
  • Marketing-US (grupo filho)
  • Marketing-EU (grupo filho)
  • Marketing-APAC (grupo filho)

Se um administrador de workspace adicionar Marketing-All ao seu workspace:

• Acesso concedido: todos os membros de Marketing-All e de todos os seus grupos filho (Marketing-US, Marketing-EU, Marketing-APAC) podem acessar o Workspace. Por exemplo, usuários e entidades de serviço em Marketing-APAC podem autenticar e usar o workspace.
• Provisionamento de conta: apenas Marketing-All é provisionado para a conta do Azure Databricks e é considerado para os limites do grupo de contas. Os grupos filho não são considerados nos limites, a menos que você os provisione explicitamente.
• Ativos no nível da conta: Marketing-All e todos os seus grupos filho (Marketing-US, Marketing-EU, Marketing-APAC) estão disponíveis ao compartilhar ou atribuir permissões a ativos no nível da conta, como dashboards e objetos no Catálogo do Unity.

Habilitar o gerenciamento automático de identidade

O gerenciamento automático de identidade é habilitado por padrão para contas criadas após 1º de agosto de 2025. Os administradores de conta podem habilitar o gerenciamento automático de identidade no console da conta.

1. Como administrador da conta, faça logon no console da conta.

2. Na barra lateral, clique em Segurança.

3. Na guia Provisionamento de usuário , alterne o gerenciamento automático de identidade para Habilitado.

   As alterações levam de cinco a dez minutos para entrar em vigor.

Depois que sua conta estiver habilitada, para adicionar e remover usuários, entidades de serviço e grupos do seu provedor de identidade, siga as instruções abaixo:

• Adicionar usuários à sua conta
• Adicionar entidades de serviço à sua conta
• Adicionar grupos à conta

Para migrar do provisionamento SCIM, consulte Migrar para o gerenciamento automático de identidades com Microsoft Entra ID.

Desabilitar o gerenciamento automático de identidade

Quando o gerenciamento automático de identidades é desabilitado:

• Os usuários e as entidades de serviço permanecem: eles mantêm o acesso, mas não são mais sincronizados com seu provedor de identidade. Você pode remover ou desativar manualmente usuários e entidades de serviço no console da conta depois de desabilitar o gerenciamento automático de identidade.
• Os grupos perdem a associação: os grupos permanecem no Azure Databricks, mas todos os membros do grupo são removidos.
• Nenhuma sincronização com o provedor de identidade: as alterações em seu provedor de identidade (como remoções de usuário ou atualizações de grupo) não são refletidas em Azure Databricks.
• Sem herança de permissão: os usuários gerenciados pelo gerenciamento automático de identidade não podem herdar permissões de grupos pai. Isso afeta modelos de permissão aninhados baseados em grupo.

Se você planeja desabilitar o gerenciamento automático de identidades, o Databricks recomenda configurar o provisionamento SCIM com antecedência como uma alternativa. O SCIM pode então assumir a sincronização de identidades e grupos.

1. Como administrador da conta, faça logon no console da conta.
2. Na barra lateral, clique em Segurança.
3. Na guia Provisionamento de usuário , alterne o gerenciamento automático de identidade para Desabilitado.

Negar acesso de identidades à sua conta

A lista de bloqueio de acesso à conta controla quais identidades do seu provedor de identidade podem acessar sua conta do Azure Databricks. Os administradores de conta podem adicionar usuários, grupos ou entidades de serviço específicos à lista de negação para bloquear seu acesso. A participação na lista de negações é provisória — se você negar um grupo, todos os membros, incluindo aqueles em grupos aninhados, também serão negados.

Para obter instruções de configuração e uma descrição completa do comportamento da lista de negação, consulte Negar acesso de identidades à sua conta.

Auditar eventos automáticos de gerenciamento de identidade

Quando o gerenciamento automático de identidades estiver habilitado, você poderá usar logs de auditoria para acompanhar as operações de identidade executadas pelo processo de gerenciamento automático de identidade.

Auditar marcas de log para eventos de gerenciamento de identidade automático

O gerenciamento automático de identidade usa eventos de log de auditoria existentes, mas adiciona marcas para identificar operações executadas automaticamente pelo processo de sincronização de identidade:

• endpoint: "autoUserCreation" - Indica que o evento foi gerado pelo processo de gerenciamento automático de identidades. Essa marca aparece em operações de usuário (add, , activateUser, deactivateUser, updateUser), operações de grupo (createGroup, updateGroup, ), removeGroupe operações de associação de grupo (addPrincipalToGroup, removePrincipalFromGroup).
• groupMembershipType: "IdentityProvider" – aparece em operações de associação de grupo (addPrincipalToGroup, removePrincipalFromGroup) para indicar que a associação de grupo foi sincronizada do seu provedor de identidade.

Consultar eventos de auditoria automática de gerenciamento de identidade

Você pode consultar a system.access.audit tabela para acompanhar as operações automáticas de gerenciamento de identidade. Por exemplo:

Acompanhar logons do usuário:

SELECT
  DISTINCT user_identity.email
FROM
  system.access.audit
WHERE
  action_name = "aadBrowserLogin"

Acompanhe os usuários criados pelo gerenciamento automático de identidade:

SELECT
  request_params.targetUserName,
  event_time
FROM
  system.access.audit
WHERE
  action_name = "add"
  AND request_params.endpoint = "autoUserCreation"

Acompanhe as associações de grupo sincronizadas do seu provedor de identidade:

SELECT
  request_params.targetGroupName,
  request_params.targetUserName,
  event_time
FROM
  system.access.audit
WHERE
  action_name IN ("addPrincipalToGroup", "removePrincipalFromGroup")
  AND request_params.groupMembershipType = "IdentityProvider"

Para mais informações sobre a tabela system.access.audit, consulte Referência da tabela do sistema de log de auditoria.

Comportamentos e limitações conhecidos

Esta seção descreve comportamentos que podem não ser imediatamente óbvios ao trabalhar com o gerenciamento automático de identidade.