Como funciona o provisionamento de aplicativos no Microsoft Entra ID

O provisionamento automático refere-se à criação de identidades e funções de usuário nos aplicativos em nuvem que os usuários precisam acessar. Além de criar identidades de usuário, o provisionamento automático inclui a manutenção e a remoção de identidades de usuário à medida que o status ou as funções mudam. Antes de iniciar uma implantação, você pode revisar este artigo para saber como o provisionamento do Microsoft Entra funciona e obter recomendações de configuração.

O serviço de provisionamento Microsoft Entra provisiona os usuários para aplicativos SaaS e outros sistemas conectando-se a um ponto de extremidade da API de gerenciamento de usuários do System for Cross-Domain Identity Management (SCIM) 2.0 fornecido pelo fornecedor do aplicativo ou por um agente de provisionamento local. Este ponto de extremidade SCIM permite que o Microsoft Entra ID crie, atualize e remova usuários programaticamente. Para aplicativos selecionados, o serviço de provisionamento também pode criar, atualizar e remover objetos adicionais relacionados à identidade, como grupos. O canal usado para provisionamento entre o Microsoft Entra ID e o aplicativo é criptografado usando criptografia HTTPS TLS 1.2.

Figura 1: O serviço de provisionamento do Microsoft Entra

Figura 2: Fluxo de trabalho de provisionamento de usuário "Outbound" do Microsoft Entra ID para aplicativos SaaS populares

Figura 3: Fluxo de trabalho de provisionamento de usuários "Inbound" de aplicativos populares de Gerenciamento de Capital Humano (HCM) para o Microsoft Entra ID e o Ative Directory do Windows Server

Provisionamento usando SCIM 2.0

O serviço de provisionamento Microsoft Entra usa o protocolo SCIM 2.0 para provisionamento automático. O serviço se conecta ao ponto de extremidade SCIM para o aplicativo e usa o esquema de objeto de usuário SCIM e APIs REST para automatizar o provisionamento e o desprovisionamento de usuários e grupos. Um conector de provisionamento baseado em SCIM é fornecido para a maioria dos aplicativos na galeria do Microsoft Entra. Os desenvolvedores usam a API de gerenciamento de usuários SCIM 2.0 no Microsoft Entra ID para criar pontos de extremidade para seus aplicativos que se integram ao serviço de provisionamento. Para obter detalhes, consulte Criar um ponto de extremidade SCIM e configurar o provisionamento de usuários. O agente de provisionamento local também traduz operações SCIM do Microsoft Entra para LDAP, SQL, REST ou SOAP, PowerShell, chamadas para um conector ECMA personalizado ou conectores e gateways criados por parceiros.

Para solicitar um conector de provisionamento automático do Microsoft Entra para um aplicativo que não tenha um, consulte Solicitação de aplicativo do Microsoft Entra.

Autorização

As credenciais são necessárias para que o Microsoft Entra ID se conecte à API de gerenciamento de usuários do aplicativo. Ao configurar o provisionamento automático de usuários para um aplicativo, você precisa inserir credenciais válidas. Para aplicativos de galeria, você pode encontrar tipos de credenciais e requisitos para o aplicativo consultando o tutorial do aplicativo. Para aplicativos que não são de galeria, você pode consultar a documentação do SCIM para entender os tipos e requisitos de credenciais. No centro de administração do Microsoft Entra, você pode testar as credenciais fazendo com que o Microsoft Entra ID tente se conectar ao aplicativo de provisionamento do aplicativo usando as credenciais fornecidas.

Mapeando atributos

Quando você habilita o provisionamento de usuários para um aplicativo SaaS de terceiros, o centro de administração do Microsoft Entra controla seus valores de atributos por meio de mapeamentos de atributos. Os mapeamentos determinam os atributos de usuário que fluem entre o ID do Microsoft Entra e o aplicativo de destino quando as contas de usuário são provisionadas ou atualizadas.

Há um conjunto pré-configurado de atributos e mapeamentos de atributos entre os objetos de usuário do Microsoft Entra e os objetos de usuário de cada aplicativo SaaS. Algumas aplicações gerem outros tipos de objetos juntamente com Utilizadores, como Grupos.

Ao configurar o provisionamento, é importante revisar e configurar os mapeamentos de atributos e fluxos de trabalho que definem quais propriedades de usuário (ou grupo) fluem da ID do Microsoft Entra para o aplicativo. Revise e configure a propriedade correspondente (Match objects using this attribute) que é usada para identificar e corresponder exclusivamente usuários/grupos entre os dois sistemas.

Você pode personalizar os mapeamentos de atributos padrão de acordo com suas necessidades de negócios. Portanto, você pode alterar ou excluir mapeamentos de atributos existentes ou criar novos mapeamentos de atributos. Para obter detalhes, consulte Personalizando mapeamentos de atributos de provisionamento de usuário para aplicativos SaaS.

Quando você configura o provisionamento para um aplicativo SaaS, um dos tipos de mapeamentos de atributos que você pode especificar é um mapeamento de expressão. Para esses mapeamentos, você deve escrever uma expressão semelhante a um script que permita transformar os dados dos usuários em formatos mais aceitáveis para o aplicativo SaaS. Para obter detalhes, consulte Escrevendo expressões para mapeamentos de atributos.

Escopo

Escopo baseado em atribuição

Para provisionamento de saída do Microsoft Entra ID para um aplicativo SaaS, confiar em atribuições de usuário ou grupo é a maneira mais comum de determinar quais usuários estão no escopo para provisionamento. Como as atribuições de usuário também são usadas para habilitar o logon único, o mesmo método pode ser usado para gerenciar o acesso e o provisionamento. O escopo baseado em atribuição não se aplica a cenários de provisionamento de entrada, como Workday e Successfactors.

• Grupos. Com um plano de licença do Microsoft Entra ID P1 ou P2, você pode usar grupos para atribuir acesso a um aplicativo SaaS. Em seguida, quando o escopo de provisionamento é definido como Sincronizar somente usuários e grupos atribuídos, o serviço de provisionamento do Microsoft Entra provisiona ou desprovisiona usuários com base no fato de serem membros de um grupo atribuído ao aplicativo. O objeto de grupo em si não é provisionado, a menos que o aplicativo ofereça suporte a objetos de grupo. Certifique-se de que os grupos atribuídos ao seu aplicativo tenham a propriedade "SecurityEnabled" definida como "True".

• Grupos dinâmicos. O serviço de provisionamento de usuários do Microsoft Entra pode ler e provisionar usuários em grupos de associação dinâmica. Tenha estas ressalvas e recomendações em mente:

  • Os grupos dinâmicos podem afetar o desempenho do provisionamento de ponta a ponta do Microsoft Entra ID para aplicativos SaaS.

  • A rapidez com que um usuário em um grupo dinâmico é provisionado ou desprovisionado em um aplicativo SaaS depende da rapidez com que o grupo dinâmico pode avaliar as alterações de associação. Para obter informações sobre como verificar o status de processamento de um grupo dinâmico, consulte Verificar o status de processamento de uma regra de associação.

  • Quando um usuário perde a associação ao grupo dinâmico, é considerado um evento de desprovisionamento. Considere esse cenário ao criar regras para grupos dinâmicos de associação.

• Grupos aninhados. O serviço de provisionamento de usuários do Microsoft Entra não pode ler ou provisionar usuários em grupos aninhados. O serviço só pode ler e provisionar usuários que sejam membros imediatos de um grupo explicitamente atribuído. Essa limitação de "atribuições baseadas em grupo para aplicativos" também afeta o logon único (consulte Usando um grupo para gerenciar o acesso a aplicativos SaaS). Em vez disso, atribua diretamente ou de outra forma o escopo nos grupos que contêm os usuários que precisam ser provisionados.

Escopo baseado em atributos

Você pode usar filtros de escopo para definir regras baseadas em atributos que determinam quais usuários são provisionados para um aplicativo. Esse método é comumente usado para provisionamento de entrada de aplicativos HCM para Microsoft Entra ID e Ative Directory. Os filtros de escopo são configurados como parte dos mapeamentos de atributos para cada conector de provisionamento de usuário do Microsoft Entra. Para obter detalhes sobre como configurar filtros de escopo baseados em atributos, consulte Provisionamento de aplicativos baseados em atributos com filtros de escopo.

Utilizadores B2B (convidados)

É possível usar o serviço de provisionamento de usuários do Microsoft Entra para provisionar usuários B2B (convidados) no Microsoft Entra ID para aplicativos SaaS. No entanto, para que os usuários B2B entrem no aplicativo SaaS usando o Microsoft Entra ID, você deve configurar manualmente o aplicativo SaaS para usar o Microsoft Entra ID como um provedor de identidade SAML (Security Assertion Markup Language).

Siga estas diretrizes gerais ao configurar aplicativos SaaS para usuários B2B (convidados):

• Para a maioria dos aplicativos, a configuração do usuário precisa acontecer manualmente. Os usuários também devem ser criados manualmente no aplicativo.
• Para aplicativos que suportam a configuração automática, como o Dropbox, convites separados são criados a partir dos aplicativos. Os usuários devem aceitar cada convite.
• Nos atributos de usuário, para mitigar quaisquer problemas com o disco de perfil de usuário (UPD) manipulado em usuários convidados, sempre defina o identificador de usuário como user.mail.

Ciclos de provisionamento: inicial e incremental

Quando o Microsoft Entra ID é o sistema de origem, o serviço de provisionamento usa a consulta delta para controlar alterações nos dados do Microsoft Graph para monitorar usuários e grupos. O serviço de provisionamento executa um ciclo inicial no sistema de origem e no sistema de destino, seguido por ciclos incrementais periódicos.

Ciclo inicial

Quando o serviço de provisionamento é iniciado, o primeiro ciclo irá:

1. Consulte todos os usuários e grupos do sistema de origem, recuperando todos os atributos definidos nos mapeamentos de atributos.

2. Filtre os usuários e grupos retornados, usando quaisquer atribuições configuradas ou filtros de escopo baseados em atributos.

3. Quando um usuário é atribuído ou está no escopo para provisionamento, o serviço consulta o sistema de destino para um usuário correspondente usando os atributos de correspondência especificados. Exemplo: Se o nome userPrincipal no sistema de origem for o atributo correspondente e for mapeado para userName no sistema de destino, o serviço de provisionamento consultará o sistema de destino em busca de userNames que correspondam aos valores de nome userPrincipal no sistema de origem.

4. Se um usuário correspondente não for encontrado no sistema de destino, ele será criado usando os atributos retornados do sistema de origem. Depois que a conta de usuário é criada, o serviço de provisionamento deteta e armazena em cache o ID do sistema de destino para o novo usuário. Esse ID é usado para executar todas as operações futuras nesse usuário.

5. Se um usuário correspondente for encontrado, ele será atualizado usando os atributos fornecidos pelo sistema de origem. Depois que a conta de usuário é correspondida, o serviço de provisionamento deteta e armazena em cache o ID do sistema de destino para o novo usuário. Esse ID é usado para executar todas as operações futuras nesse usuário.

6. Se os mapeamentos de atributos contiverem atributos de "referência", o serviço fará mais atualizações no sistema de destino para criar e vincular os objetos referenciados. Por exemplo, um usuário pode ter um atributo "Manager" no sistema de destino, que está vinculado a outro usuário criado no sistema de destino.

7. Persista uma marca d'água no final do ciclo inicial, que fornece o ponto de partida para os ciclos incrementais posteriores.

Algumas aplicações, como o ServiceNow, o G Suite e o Box, suportam não só o aprovisionamento de utilizadores, mas também o aprovisionamento de grupos e respetivos membros. Nesses casos, se o provisionamento de grupo estiver habilitado nos mapeamentos, o serviço de provisionamento sincronizará os usuários e os grupos e, posteriormente, sincronizará o grupo de associação dinâmica.

Ciclos incrementais

Após o ciclo inicial, todos os outros ciclos:

1. Consulte o sistema de origem para todos os usuários e grupos que foram atualizados desde que a última marca d'água foi armazenada.

2. Filtre os usuários e grupos retornados, usando quaisquer atribuições configuradas ou filtros de escopo baseados em atributos.

3. Quando um usuário é atribuído ou está no escopo para provisionamento, o serviço consulta o sistema de destino para um usuário correspondente usando os atributos de correspondência especificados.

4. Se um usuário correspondente não for encontrado no sistema de destino, ele será criado usando os atributos retornados do sistema de origem. Depois que a conta de usuário é criada, o serviço de provisionamento deteta e armazena em cache o ID do sistema de destino para o novo usuário. Esse ID é usado para executar todas as operações futuras nesse usuário.

5. Se um usuário correspondente for encontrado, ele será atualizado usando os atributos fornecidos pelo sistema de origem. Se for uma conta recém-atribuída que corresponde, o serviço de provisionamento detetará e armazenará em cache o ID do sistema de destino para o novo usuário. Esse ID é usado para executar todas as operações futuras nesse usuário.

6. Se os mapeamentos de atributos contiverem atributos de "referência", o serviço fará mais atualizações no sistema de destino para criar e vincular os objetos referenciados. Por exemplo, um usuário pode ter um atributo "Manager" no sistema de destino, que está vinculado a outro usuário criado no sistema de destino.

7. Se um usuário que estava anteriormente no escopo para provisionamento for removido do escopo, inclusive não sendo atribuído, o serviço desativará o usuário no sistema de destino por meio de uma atualização.

8. Se um usuário que anteriormente estava no escopo para provisionamento for desabilitado ou excluído suavemente no sistema de origem, o serviço desativará o usuário no sistema de destino por meio de uma atualização.

9. Se um usuário que estava anteriormente no escopo para provisionamento for excluído no sistema de origem, o serviço excluirá o usuário no sistema de destino. No Microsoft Entra ID, os usuários são excluídos 30 dias após serem excluídos suavemente.

10. Persista uma nova marca d'água no final do ciclo incremental, que fornece o ponto de partida para os ciclos incrementais posteriores.

O serviço de provisionamento continua executando ciclos incrementais consecutivos indefinidamente, em intervalos definidos no tutorial específico para cada aplicativo. Os ciclos incrementais continuam até ocorrer um dos eventos:

• O serviço é interrompido manualmente usando o centro de administração do Microsoft Entra ou usando o comando apropriado da API do Microsoft Graph.
• Um novo ciclo inicial é acionado usando a opção Reiniciar provisionamento no centro de administração do Microsoft Entra ou usando o comando apropriado da API do Microsoft Graph. A ação limpa qualquer marca d'água armazenada e faz com que todos os objetos de origem sejam avaliados novamente. Além disso, a ação não quebra os links entre os objetos de origem e de destino. Para quebrar os links, use Restart synchronizationJob com a solicitação:

POST https://graph.microsoft.com/beta/servicePrincipals/{id}/synchronization/jobs/{jobId}/restart
Authorization: Bearer <token>
Content-type: application/json
{
   "criteria": {
       "resetScope": "Full"
   }
}

• Um novo ciclo inicial é acionado devido a uma alteração nos mapeamentos de atributos ou filtros de escopo. Essa ação também limpa qualquer marca d'água armazenada e faz com que todos os objetos de origem sejam avaliados novamente.
• O processo de provisionamento entra em quarentena (ver exemplo) devido a uma alta taxa de erro e permanece em quarentena por mais de quatro semanas. Nesse caso, o serviço é desativado automaticamente.

Erros e novas tentativas

Se um erro no sistema de destino impedir que um usuário individual seja adicionado, atualizado ou excluído no sistema de destino, a operação será repetida no próximo ciclo de sincronização. Os erros são continuamente repetidos, reduzindo gradualmente a frequência de tentativas. Para resolver a falha, os administradores devem verificar os logs de provisionamento para determinar a causa raiz e tomar as medidas apropriadas. As falhas comuns podem incluir:

• Usuários que não têm um atributo preenchido no sistema de origem que é necessário no sistema de destino
• Usuários com um valor de atributo no sistema de origem para o qual há uma restrição exclusiva no sistema de destino e o mesmo valor está presente em outro registro de usuário

Resolva essas falhas ajustando os valores de atributo para o usuário afetado no sistema de origem ou ajustando os mapeamentos de atributos para que não causem conflitos.

Quarentena

Se a maioria ou todas as chamadas feitas no sistema de destino falharem consistentemente devido a um erro (por exemplo, credenciais de administrador inválidas), o trabalho de provisionamento entrará em um estado de "quarentena". Esse estado é indicado no relatório de resumo de provisionamento e por e-mail se as notificações por email foram configuradas no centro de administração do Microsoft Entra.

Quando em quarentena, a frequência de ciclos incrementais é gradualmente reduzida para uma vez por dia.

O trabalho de provisionamento sai da quarentena depois que todos os erros ofensivos são corrigidos e o próximo ciclo de sincronização é iniciado. Se o trabalho de provisionamento permanecer em quarentena por mais de quatro semanas, o trabalho de provisionamento será desativado. Saiba mais aqui sobre o estado da quarentena aqui.

Quanto tempo demora o provisionamento

O desempenho depende se o trabalho de provisionamento está executando um ciclo de provisionamento inicial ou um ciclo incremental. Para obter detalhes sobre quanto tempo leva o provisionamento e como monitorar o status do serviço de provisionamento, consulte Verificar o status do provisionamento do usuário.

Como saber se os usuários estão sendo provisionados corretamente

Todas as operações executadas pelo serviço de provisionamento do usuário são registradas nos logs de provisionamento do Microsoft Entra. Os logs incluem todas as operações de leitura e gravação feitas nos sistemas de origem e de destino e os dados do usuário que foram lidos ou gravados durante cada operação. Para obter informações sobre como ler os logs de provisionamento no centro de administração do Microsoft Entra, consulte o guia de relatórios de provisionamento.

Desprovisionamento

O serviço de provisionamento Microsoft Entra mantém os sistemas de origem e de destino sincronizados, desprovisionando contas quando o acesso do usuário é removido.

O serviço de provisionamento suporta a exclusão e a desativação de usuários (às vezes chamados de exclusão suave). A definição exata de desabilitar e excluir varia de acordo com a implementação do aplicativo de destino, mas geralmente uma desativação indica que o usuário não pode entrar. Uma exclusão indica que o usuário foi removido completamente do aplicativo. Para aplicativos SCIM, uma desativação é uma solicitação para definir a propriedade ativa como false em um usuário.

Configurar seu aplicativo para desabilitar um usuário

Confirme se a caixa de seleção para atualizações está marcada.

Confirme o mapeamento para ativo para seu aplicativo. Se você estiver usando um aplicativo da galeria de aplicativos, o mapeamento pode ser ligeiramente diferente. Nesse caso, use o mapeamento padrão para aplicativos de galeria.

Configurar seu aplicativo para excluir um usuário

O cenário dispara uma desativação ou uma exclusão:

• Um usuário é excluído suavemente na ID do Microsoft Entra (enviado para a lixeira / propriedade AccountEnabled definida como false). Trinta dias depois que um usuário é excluído no Microsoft Entra ID, ele é excluído permanentemente do locatário. Neste ponto, o serviço de provisionamento envia uma solicitação DELETE para excluir permanentemente o usuário no aplicativo. A qualquer momento durante a janela de 30 dias, você pode excluir manualmente um usuário permanentemente, que envia uma solicitação de exclusão para o aplicativo.
• Um usuário é permanentemente excluído / removido da lixeira no Microsoft Entra ID.
• Um usuário não é atribuído de um aplicativo.
• Um usuário passa de escopo para fora do escopo (não passa mais por um filtro de escopo).

Por padrão, o serviço de provisionamento do Microsoft Entra exclui ou desabilita usuários que saem do escopo. Se quiser substituir esse comportamento padrão, você pode definir um sinalizador para ignorar exclusões fora do escopo.

Quando um dos quatro eventos ocorre e o aplicativo de destino não oferece suporte a exclusões suaves, o serviço de provisionamento envia uma solicitação DELETE para excluir permanentemente o usuário do aplicativo.

Se você vir IsSoftDeleted em seus mapeamentos de atributo, ele é usado para determinar o estado do usuário e se deve enviar uma solicitação de atualização com active = false para excluir suavemente o usuário.

Eventos de desprovisionamento

A tabela descreve como você pode configurar ações de desprovisionamento com o serviço de provisionamento do Microsoft Entra. Essas regras são escritas com o aplicativo não-galeria / personalizado em mente, mas geralmente se aplicam a aplicativos na galeria. No entanto, o comportamento dos aplicativos de galeria pode diferir, pois eles foram otimizados para atender às necessidades do aplicativo. Por exemplo, se o aplicativo de destino não oferecer suporte à exclusão suave, o serviço de provisionamento do Microsoft Entra poderá enviar uma solicitação de exclusão física para excluir usuários em vez de enviar uma exclusão suave.

Limitações conhecidas

• Quando um usuário ou grupo é desatribuído de um aplicativo e não é mais gerenciado com o serviço de provisionamento, uma solicitação de desabilitação é enviada. Nesse ponto, o serviço não gerencia o usuário e uma solicitação de exclusão não é enviada quando o usuário é excluído suavemente do diretório.
• Não há suporte para o provisionamento de um usuário desabilitado no Microsoft Entra ID. Eles devem estar ativos no Microsoft Entra ID antes de serem provisionados.
• Quando um usuário passa de excluído suavemente para ativo, o serviço de provisionamento do Microsoft Entra ativa o usuário no aplicativo de destino, mas não restaura automaticamente o grupo de associação dinâmica. O aplicativo de destino deve manter o grupo de associação dinâmica para o usuário em estado inativo. Se o aplicativo de destino não oferecer suporte à manutenção do estado inativo, você poderá reiniciar o provisionamento para atualizar os grupos dinâmicos de associação.

Recomendação

Ao desenvolver um aplicativo, sempre suporte soft-deletes e hard-deletes. Ele permite que os clientes se recuperem quando um usuário é desativado acidentalmente.

Próximos passos

Planejar uma implantação de provisionamento automático de usuários

Configurar o provisionamento para um aplicativo de galeria

Crie um ponto de extremidade SCIM e configure o provisionamento ao criar seu próprio aplicativo

Solucione problemas com a configuração e o provisionamento de usuários para um aplicativo.