Risolvere i problemi relativi all'API di provisioning in ingresso
Introduzione
Questo documento illustra gli errori e i problemi comunemente riscontrati con l'API di provisioning in ingresso e spiega come risolverli.
Scenari di risoluzione dei problemi
Formato dati non valido
Descrizione del problema
- Viene visualizzato il messaggio di errore
Invalid Data Formatcon codice di risposta HTTP 400 (Richiesta non valida).
Possibili cause
- Si sta inviando una richiesta in blocco valida in base alle specifiche dell'API di provisioning /bulkUpload, ma l'intestazione della richiesta HTTP "Content-Type" non è stata impostata su
application/scim+json. - Si sta inviando una richiesta in blocco che non è conforme alle specifiche dell'API di provisioning /bulkUpload.
Risoluzione:
- Verificare che l'intestazione
Content-Typedella richiesta HTTP sia impostata sul valoreapplication/scim+json. - Assicurarsi che il payload della richiesta in blocco sia conforme alle specifiche dell'API di provisioning /bulkUpload.
I log di provisioning sono vuoti
Descrizione del problema
- È stata inviata una richiesta all'endpoint API di provisioning /bulkUpload ed è stato ricevuto il codice di risposta HTTP 202, ma non sono presenti dati nei log di provisioning corrispondenti alla richiesta.
Possibili cause
- L'app di provisioning basato su API è sospesa.
- Il servizio di provisioning non ha ancora aggiornato i log di provisioning con i dettagli di elaborazione delle richieste in blocco.
- Lo stato dell'agente di provisioning locale è inattivo (se si esegue il provisioning utenti in ingresso basato su API ad Active Directory locale).
Risoluzione:
- Verificare che l'app di provisioning sia in esecuzione. Se non è in esecuzione, selezionare l'opzione di menu Avvia il provisioning per elaborare i dati.
- Riattivare l'agente di provisioning locale riavviando l'agente locale.
- Si potrebbe riscontrare un ritardo di 5-10 minuti tra l'elaborazione della richiesta e la scrittura di dati nei log di provisioning. Se il client API invia dati all'endpoint API /bulkUpload, introdurre un ritardo tra la chiamata della richiesta e la query sui log di provisioning.
Codice di risposta 403 Accesso negato
Descrizione del problema
- È stata inviata una richiesta all'endpoint API di provisioning /bulkUpload ed è stato ricevuto il codice di risposta HTTP 403 (Accesso negato).
Possibili cause
- Al client API non è stata assegnata l'autorizzazione
SynchronizationData-User.Uploaddi Graph.
Risoluzione:
- Assegnare al client API l'autorizzazione
SynchronizationData-User.Uploaddi Graph e ripetere l'operazione.
Codice di risposta 429 Troppe richieste
L'endpoint API bulkUpload applica i limiti seguenti previsti dalla limitazione delle richieste e restituisce un codice di risposta 429 se questi limiti vengono superati.
40 chiamate API per 5 secondi: se il numero di chiamate supera questo limite in un intervallo di 5 secondi, il client ottiene una risposta 429. Un modo per evitare questo problema consiste nel distanziare l'invio della richiesta usando ritardi nella logica di invio delle richieste client.
6000 chiamate API in un periodo di 24 ore: se il numero di chiamate supera questo limite, il client ottiene una risposta 429. Un modo per evitare questo problema consiste nell'assicurarsi che il payload in blocco SCIM sia ottimizzato per usare il numero massimo di 50 record per ogni chiamata API. Con questo approccio è possibile inviare 300.000 record ogni 24 ore.
Codice di risposta 401 Non autorizzato
Descrizione del problema
- È stata inviata una richiesta all'endpoint API di provisioning /bulkUpload ed è stato ricevuto il codice di risposta HTTP 401 (Non autorizzato). Il codice errore visualizza "InvalidAuthenticationToken" con un messaggio in cui viene segnalato che il token di accesso è scaduto o non è ancora valido.
Possibili cause
- Il token di accesso è scaduto.
Risoluzione:
- Generare un nuovo token di accesso per il client API.
Il processo è in stato di quarantena
Descrizione del problema
- È stata appena avviata l'app di provisioning ed è in stato di quarantena.
Possibili cause
- Non è stato impostato l'indirizzo di posta elettronica per le notifiche prima di avviare il processo.
Risoluzione: passare alla voce di menu Modifica il provisioning. In Impostazioni è presente una casella di controllo accanto a Invia una notifica di posta elettronica in caso di errore e un campo in cui inserire l'indirizzo di posta elettronica per le notifiche. Assicurarsi di selezionare la casella, specificare un indirizzo di posta elettronica e salvare la modifica. Fare clic su Riavvia provisioning per rimuovere il processo dalla quarantena.
Creazione di utenti - UPN non valido
Descrizione del problema: si è verificato un errore di provisioning degli utenti. I log di provisioning visualizzano il codice errore AzureActiveDirectoryInvalidUserPrincipalName.
Risoluzione:
- Passare alla pagina Modifica i mapping degli attributi.
- Selezionare il mapping
UserPrincipalNamee aggiornarlo per usare la funzioneRandomString. - Copiare e incollare questa espressione nella casella dell'espressione:
Join("", Replace([userName], , "(?<Suffix>@(.)*)", "Suffix", "", , ), RandomString(3, 3, 0, 0, 0, ), "@", DefaultDomain())
Questa espressione consente di risolvere il problema aggiungendo un numero casuale al valore UPN accettato da Microsoft Entra ID.
Creazione dell'utente non riuscita - Dominio non valido
Descrizione del problema: si è verificato un errore di provisioning degli utenti. I log di provisioning visualizzano un messaggio di errore domain does not exist.
Risoluzione:
- Passare alla pagina Modifica i mapping degli attributi.
- Selezionare il mapping
UserPrincipalName, quindi copiare e incollare questa espressione nella casella di input dell'espressione:Join("", Replace([userName], , "(?<Suffix>@(.)*)", "Suffix", "", , ), RandomString(3, 3, 0, 0, 0, ), "@", DefaultDomain())
Questa espressione consente di risolvere il problema aggiungendo un dominio predefinito al valore UPN accettato da Microsoft Entra ID.