Solucionar problemas de API de provisionamento de entrada
Introdução
Este documento aborda erros comumente encontrados e problemas com a API de provisionamento de entrada e como solucioná-los.
Cenários de resolução de problemas
Formato de dados inválido
Descrição do problema
- Você está recebendo a mensagem
Invalid Data Format
de erro com o código de resposta HTTP 400 (solicitação incorreta).
Causas prováveis
- Você está enviando uma solicitação em massa válida de acordo com as especificações da API de provisionamento /bulkUpload , mas não definiu o cabeçalho de solicitação HTTP 'Content-Type' como
application/scim+json
. - Você está enviando uma solicitação em massa que não está em conformidade com as especificações da API de provisionamento /bulkUpload .
Resolução:
- Verifique se a Solicitação HTTP tem o
Content-Type
cabeçalho definido como o valorapplication/scim+json
. - Certifique-se de que a carga útil de solicitação em massa esteja em conformidade com as especificações da API de provisionamento /bulkUpload .
Não há nada nos logs de provisionamento
Descrição do problema
- Você enviou uma solicitação para o ponto de extremidade da API de provisionamento /bulkUpload e obteve o código de resposta HTTP 202, mas não há dados nos logs de provisionamento correspondentes à sua solicitação.
Causas prováveis
- Seu aplicativo de provisionamento controlado por API está pausado.
- O serviço de provisionamento ainda não atualizou os logs de provisionamento com os detalhes de processamento de solicitação em massa.
- Seu status de agente de provisionamento local está inativo (se você estiver executando o provisionamento de usuário de entrada orientado por /API para o Ative Directory local).
Resolução:
- Verifique se seu aplicativo de provisionamento está em execução. Se não estiver em execução, selecione a opção de menu Iniciar provisionamento para processar os dados.
- Ative o status do agente de provisionamento local para ativo reiniciando o agente local.
- Espere um atraso de 5 a 10 minutos entre o processamento da solicitação e a gravação nos logs de provisionamento. Se o seu cliente de API estiver enviando dados para o ponto de extremidade da API de provisionamento /bulkUpload, introduza um intervalo de tempo entre a invocação da solicitação e a consulta de logs de provisionamento.
Código de resposta 403 proibido
Descrição do problema
- Você enviou uma solicitação para o ponto de extremidade da API de provisionamento /bulkUpload e obteve o código de resposta HTTP 403 (Proibido).
Causas prováveis
- A permissão
SynchronizationData-User.Upload
Graph não é atribuída ao seu cliente de API.
Resolução:
- Atribua ao seu cliente de API a permissão
SynchronizationData-User.Upload
Graph e tente novamente a operação.
Demasiados pedidos 429 código de resposta
O ponto de extremidade da API bulkUpload impõe os seguintes limites de limitação e retorna um código de resposta 429 se esses limites forem violados.
40 chamadas de API por 5 segundos – se o número de chamadas ultrapassar esse limite em um intervalo de 5 segundos, o cliente receberá uma resposta de 429. Uma maneira de evitar isso é marcando o envio da solicitação usando atrasos na lógica de envio da solicitação do cliente.
6000 chamadas API durante um período de 24 horas – se o número de chamadas ultrapassar este limite, o cliente recebe uma resposta 429. Uma maneira de evitar isso é garantir que sua carga útil em massa SCIM seja otimizada para usar o máximo de 50 registros por chamada de API. Com essa abordagem, você pode enviar 300 mil registros a cada 24 horas.
Código de resposta 401 não autorizado
Descrição do problema
- Você enviou uma solicitação para o ponto de extremidade da API de provisionamento /bulkUpload e obteve o código de resposta HTTP 401 (Não autorizado). O código de erro exibe "InvalidAuthenticationToken" com uma mensagem informando que o "Token de acesso expirou ou ainda não é válido".
Causas prováveis
- O seu token de acesso expirou.
Resolução:
- Gere um novo token de acesso para seu cliente de API.
O trabalho entra em estado de quarentena
Descrição do problema
- Você acabou de iniciar o aplicativo de provisionamento e ele está em estado de quarentena.
Causas prováveis
- Você não definiu o e-mail de notificação antes de iniciar o trabalho.
Resolução: vá para o item de menu Editar provisionamento . Em Configurações , há uma caixa de seleção ao lado de Enviar uma notificação por e-mail quando ocorrer uma falha e um campo para inserir seu Email de notificação. Certifique-se de marcar a caixa, fornecer um e-mail e salvar a alteração. Clique em Reiniciar provisionamento para tirar o trabalho da quarentena.
Criação de usuário - UPN inválido
Descrição do problema: há uma falha de provisionamento do usuário. Os logs de provisionamento exibem o código de erro: AzureActiveDirectoryInvalidUserPrincipalName
.
Resolução:
- Chegou à página Editar mapeamentos de atributos.
- Selecione o
UserPrincipalName
mapeamento e atualize-o para usar aRandomString
função. - Copie e cole esta expressão na caixa de expressão:
Join("", Replace([userName], , "(?<Suffix>@(.)*)", "Suffix", "", , ), RandomString(3, 3, 0, 0, 0, ), "@", DefaultDomain())
Esta expressão corrige o problema anexando um número aleatório ao valor UPN aceito pelo ID do Microsoft Entra.
Falha na criação do usuário - Domínio inválido
Descrição do problema: há uma falha de provisionamento do usuário. Os logs de provisionamento exibem uma mensagem de erro informando domain does not exist
.
Resolução:
- Vá para a página Editar mapeamentos de atributos.
- Selecione o
UserPrincipalName
mapeamento e copie e cole esta expressão na caixa de entrada da expressão:Join("", Replace([userName], , "(?<Suffix>@(.)*)", "Suffix", "", , ), RandomString(3, 3, 0, 0, 0, ), "@", DefaultDomain())
Esta expressão corrige o problema anexando um domínio padrão ao valor UPN aceito pelo ID do Microsoft Entra.