Partilhar via


Provisionamento de aplicativos em status de quarentena

O serviço de provisionamento do Microsoft Entra monitora a integridade da sua configuração. Ele também coloca aplicativos não saudáveis em um estado de "quarentena". Se a maioria, ou todas, as chamadas feitas no sistema de destino falharem consistentemente, o trabalho de provisionamento será marcado como em quarentena. Um exemplo de falha é um erro recebido devido a credenciais de administrador inválidas.

Durante a quarentena:

  • A frequência dos ciclos incrementais é gradualmente reduzida para uma vez por dia.
  • O trabalho de provisionamento é removido da quarentena depois que todos os erros 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 (interrompe a execução).

Como sei se a minha candidatura está em quarentena?

Há três maneiras de verificar se um aplicativo está em quarentena:

  • No centro de administração do Microsoft Entra, navegue até Identity>Applications>Enterprise applications<>application name>>Provisioning e revise a barra de progresso para ver uma mensagem de quarentena.

    Barra de status de provisionamento mostrando o status da quarentena

  • No centro de administração do Microsoft Entra, navegue até o filtro Logs>> de auditoria de monitoramento de identidade e integridade>em Atividade: Quarentena e revise o histórico de quarentena. A exibição na barra de progresso, conforme descrito acima, mostra se o provisionamento está atualmente em quarentena. Os logs de auditoria mostram o histórico de quarentena de um aplicativo.

  • Use a solicitação Get synchronizationJob do Microsoft Graph para obter programaticamente o status do trabalho de provisionamento:

        GET https://graph.microsoft.com/beta/servicePrincipals/{id}/synchronization/jobs/{jobId}/
  • Verifique o seu e-mail. Quando um aplicativo é colocado em quarentena, um e-mail de notificação única é enviado. Se o motivo da quarentena mudar, um e-mail atualizado será enviado mostrando o novo motivo da quarentena. Se não vir um e-mail:

    • Certifique-se de ter especificado um Email de Notificação válido na configuração de provisionamento para o aplicativo.
    • Verifique se não há filtragem de spam na caixa de entrada do e-mail de notificação.
    • Certifique-se de que não cancelou a subscrição de e-mails.
    • Verifique se há e-mails de azure-noreply@microsoft.com

Porque é que a minha aplicação está em quarentena?

Abaixo estão os motivos comuns pelos quais seu aplicativo pode entrar em quarentena:

Description Ação Recomendada
Problema de conformidade SCIM: Uma resposta HTTP/404 não encontrada foi retornada em vez da resposta HTTP/200 OK esperada. Nesse caso, o serviço de provisionamento do Microsoft Entra fez uma solicitação ao aplicativo de destino e recebeu uma resposta inesperada. Verifique a seção de credenciais de administrador. Veja se o aplicativo requer a especificação da URL do locatário e se a URL está correta. Se você não vir um problema, entre em contato com o desenvolvedor do aplicativo para garantir que o serviço seja compatível com SCIM. https://tools.ietf.org/html/rfc7644#section-3.4.2
Credenciais inválidas: ao tentar autorizar o acesso ao aplicativo de destino, recebemos uma resposta do aplicativo de destino que indica que as credenciais fornecidas são inválidas. Navegue até a seção de credenciais de administrador da interface do usuário de configuração de provisionamento e autorize o acesso novamente com credenciais válidas. Se o aplicativo estiver na galeria, revise o tutorial de configuração do aplicativo para obter as etapas necessárias.
Funções duplicadas: as funções importadas de determinados aplicativos, como Salesforce e Zendesk, devem ser exclusivas. Navegue até o manifesto do aplicativo no centro de administração do Microsoft Entra e remova a função duplicada.

Uma solicitação do Microsoft Graph para obter o status do trabalho de provisionamento mostra o seguinte motivo para a quarentena:

  • EncounteredQuarantineException indica que foram fornecidas credenciais inválidas. O serviço de provisionamento não consegue estabelecer uma conexão entre o sistema de origem e o sistema de destino.
  • EncounteredEscrowProportionThreshold indica que o provisionamento excedeu o limite de depósito. Essa condição ocorre quando mais de 40% dos eventos de provisionamento falharam. Para obter mais informações, consulte os detalhes do limite de depósito abaixo.
  • QuarantineOnDemand significa que detetamos um problema com seu aplicativo e o definimos manualmente para quarentena.

Limiares de depósito

Se o limite de depósito proporcional for atingido, o trabalho de provisionamento entrará em quarentena. Esta lógica está sujeita a alterações, mas funciona aproximadamente como descrito abaixo:

Um trabalho pode entrar em quarentena independentemente da contagem de falhas para problemas como credenciais de administrador ou conformidade com SCIM. No entanto, em geral, 5.000 falhas são o mínimo para começar a avaliar se deve fazer quarentena por causa de muitas falhas. Por exemplo, um trabalho com 4.000 falhas não entraria em quarentena. Mas, um trabalho com 5.000 falhas desencadearia uma avaliação. Uma avaliação utiliza os seguintes critérios:

  • Se mais de 40% dos eventos de provisionamento falharem, ou se houver mais de 40.000 falhas, o trabalho de provisionamento entrará em quarentena. As falhas de referência não serão contabilizadas como parte do limite de 40% ou 40.000. Por exemplo, a falha ao atualizar um gerente ou um membro do grupo é uma falha de referência.
  • Um trabalho em que 45.000 usuários foram provisionados sem sucesso levaria à quarentena, uma vez que excede o limite de 40.000.
  • Um trabalho em que 30.000 usuários falharam no provisionamento e 5.000 foram bem-sucedidos levaria à quarentena, pois excede o limite de 40% e o mínimo de 5.000.
  • Um trabalho com 20.000 falhas e 100.000 sucessos não entraria em quarentena porque não excede o limite de 40% de falhas ou o máximo de 40.000 falhas.
  • Há um limite absoluto de 60.000 falhas que contabiliza falhas de referência e não referência. Por exemplo, 40.000 usuários não puderam ser provisionados e 21.000 atualizações do gerenciador falharam. O total é de 61.000 falhas e ultrapassa o limite de 60.000.

Duração da repetição

A lógica documentada aqui pode ser diferente para determinados conectores para garantir a melhor experiência do cliente, mas geralmente temos os ciclos de repetição abaixo após uma falha:

Após a falha, a primeira tentativa acontecerá em 6 horas.

  • A segunda tentativa acontece 12 horas após a primeira falha.
  • A terceira tentativa acontece 24 horas após a primeira falha.

Haverá novas tentativas a cada 24 horas após a 3ª tentativa. As novas tentativas continuarão por 28 dias após a primeira falha, após a qual a entrada de depósito é removida e o trabalho é desativado.
Se qualquer uma das repetições acima obtiver uma resposta bem-sucedida, o trabalho será automaticamente colocado fora da quarentena e retomará o comportamento de sincronização regular.

Como faço para tirar meu aplicativo da quarentena?

Primeiro, resolva o problema que fez com que o aplicativo fosse colocado em quarentena.

  • Verifique as configurações de provisionamento do aplicativo para certificar-se de que inseriu credenciais de administrador válidas. O Microsoft Entra ID deve estabelecer uma relação de confiança com o aplicativo de destino. Certifique-se de que introduziu credenciais válidas e que a sua conta tem as permissões necessárias.

  • Revise os logs de provisionamento para investigar melhor quais erros estão causando quarentena e resolva o erro. Vá para Logs de provisionamento de aplicativos>corporativos do Microsoft Entra ID>na seção Atividade.

Depois de resolver o problema, reinicie o trabalho de provisionamento. Certas alterações nas configurações de provisionamento do aplicativo, como mapeamentos de atributos ou filtros de escopo, reiniciarão automaticamente o provisionamento para você. A barra de progresso na página Provisionamento do aplicativo indica quando o provisionamento foi iniciado pela última vez. Se você precisar reiniciar o trabalho de provisionamento manualmente, use um dos seguintes métodos:

  • Use o centro de administração do Microsoft Entra para reiniciar o trabalho de provisionamento. Na página Provisionamento do aplicativo, selecione Reiniciar provisionamento. Essa ação reinicia totalmente o serviço de provisionamento, o que pode levar algum tempo. Um ciclo inicial completo será executado novamente, o que limpa as cauções, remove a aplicação da quarentena e limpa quaisquer marcas d’água. O serviço avaliará, em seguida, todos os utilizadores do sistema de origem novamente e determinará se estão no âmbito do aprovisionamento. Isso pode ser útil quando seu aplicativo está atualmente em quarentena, como este artigo discute, ou você precisa fazer uma alteração em seus mapeamentos de atributos. Observe que o ciclo inicial leva mais tempo para ser concluído do que o ciclo incremental típico devido ao número de objetos que precisam ser avaliados. Você pode saber mais sobre o desempenho dos ciclos iniciais e incrementais aqui.

  • Use o Microsoft Graph para reiniciar o trabalho de provisionamento. Você terá controle total sobre o que reiniciar. Você pode optar por limpar depósitos (para reiniciar o contador de depósito acumulado em direção ao status de quarentena), limpar quarentena (para remover o aplicativo da quarentena) ou limpar marcas d'água. Use a seguinte solicitação:

        POST /servicePrincipals/{id}/synchronization/jobs/{jobId}/restart

Substitua "{ID}" pelo valor da ID do aplicativo e substitua "{jobId}" pela ID do trabalho de sincronização.