Partager via

Foire aux questions sur le provisionnement entrant piloté par l’API

Cet article répond aux questions fréquentes (FAQ) sur le provisionnement entrant piloté par l’API.

Comment la nouvelle API d’approvisionnement entrant /bulkUpload diffère-t-elle de l’API Utilisateurs MS Graph ?

Il existe des différences significatives entre l’API d’approvisionnement /bulkUpload et le point de terminaison de l’API Utilisateurs MS Graph.

  • Format de la charge utile : le point de terminaison de l’API MS Graph Users attend des données au format OData. Le format de charge utile de requête pour la nouvelle API d’approvisionnement entrant /bulkUpload utilise des constructions de schéma SCIM. Lors de l’appel de cette API, définissez l’en-tête « Content-Type » sur application/scim+json.
  • Résultat final de l’opération :
    • Lorsque les données d’identité sont envoyées au point de terminaison de l’API Utilisateurs MS Graph, elles sont immédiatement traitées et une opération Create/Update/Delete a lieu sur le profil utilisateur Microsoft Entra.
    • Les données de requête envoyées à l’API d’approvisionnement /bulkUpload sont traitées de manière asynchrone par le service d’approvisionnement Microsoft Entra. Le travail de provisionnement applique les règles d’étendue, le mappage des attributs et la transformation configurés par l’administrateur informatique. Il lance une opération Create/Update/Delete sur le profil de l’utilisateur Microsoft Entra ou le profil de l’utilisateur AD sur site.
  • L’administrateur informatique conserve le contrôle : avec l’approvisionnement entrant piloté par l’API, l’administrateur informatique contrôle davantage la façon dont les données d’identité entrantes sont traitées et mappées aux attributs Microsoft Entra. Ils peuvent définir des règles d’étendue pour exclure certains types de données d’identité (par exemple, les données de l’entrepreneur) et utiliser des fonctions de transformation pour dériver de nouvelles valeurs avant de définir les valeurs d’attribut sur le profil utilisateur.

L’API /bulkUpload de provisionnement entrant est-elle un point de terminaison SCIM standard ?

L’API de provisionnement entrant /bulkUpload MS Graph utilise le schéma SCIM dans la charge utile de la requête, mais il ne s’agit pas d’un point de terminaison d’API SCIM standardisé. C’est pourquoi.

En règle générale, un point de terminaison de service SCIM traite les demandes HTTP (POST, PUT, GET) avec une charge utile SCIM et les traduit en opérations respectives (création, mise à jour, consultation) sur le magasin d’identités. Le point de terminaison de service SCIM place le fardeau de spécifier la sémantique de l’opération, s’il faut créer/mettre à jour/supprimer une identité, sur le client d’API SCIM. Ce mécanisme fonctionne bien pour les scénarios où le client d’API est conscient de l’opération qu’il souhaite effectuer pour les utilisateurs dans le magasin d’identités.

Le provisionnement entrant ms Graph /bulkUpload est conçu pour gérer un scénario d’intégration d’identité d’entreprise différent mis en forme par trois exigences uniques :

  1. Possibilité de traiter de manière asynchrone les enregistrements en bloc (par exemple, traiter des enregistrements de 50 000 ko)
  2. Possibilité d’inclure n’importe quel attribut d’identité dans la charge utile (par exemple, costCenter, niveau de paiement, badgeId)
  3. Prise en charge des clients d'API qui ne connaissent pas la sémantique des opérations. Ces clients sont des clients d’API non-SCIM qui ont uniquement accès aux données sources brutes (par exemple, les enregistrements dans le fichier CSV, la table SQL ou les enregistrements RH). Ces clients n’ont pas la capacité de traitement pour lire chaque enregistrement et déterminer la sémantique des opérations de Create/Update/Delete sur le magasin d’identités.

L’objectif principal de l’API d’approvisionnement entrant /bulkUpload MS Graph est de permettre aux clients d’envoyer des données d’identité (par exemple, costCenter, niveau de paiement, badgeId) à partir de n’importe quelle source de données d’identité (par exemple, CSV/SQL/HR) pour le traitement éventuel par le service d’approvisionnement Microsoft Entra. Le service d’approvisionnement Microsoft Entra consomme les données par lots reçues à ce point d'accès, applique les règles de mappage d’attributs configurées par l’administrateur informatique et détermine si ces données entraînent une opération (Créer, Mettre à jour, Activer, Désactiver) dans le magasin d’identités cible (Microsoft Entra ID / AD local).

L'API de provisionnement /bulkUpload prend-elle en charge les domaines Active Directory locaux comme cible ?

Oui, l’API d’approvisionnement prend en charge les domaines AD locaux en tant que cible.

Comment obtenir le point de terminaison de l’API /bulkUpload pour notre application d’approvisionnement ?

L’API /bulkUpload est disponible uniquement pour les applications de type : « approvisionnement entrant piloté par l’API vers l’ID Microsoft Entra » et « approvisionnement entrant piloté par l’API vers Active Directory local ». Vous pouvez récupérer l'API endpoint unique pour chaque application d'approvisionnement à partir de la page d'accueil du volet de provisionnement. Dans Statistics to date>View technical information, copiez l’URL du point de terminaison de l’API d’approvisionnement .

Il a le format :

https://graph.microsoft.com/beta/servicePrincipals/{servicePrincipalId}/synchronization/jobs/{jobId}/bulkUpload

Comment effectuer une synchronisation complète à l’aide de l’API /bulkUpload d’approvisionnement ?

Pour effectuer une synchronisation complète, utilisez votre client API pour envoyer les données de tous les utilisateurs de votre source approuvée au point de terminaison d’API en tant que requête en bloc. Une fois que vous avez envoyé toutes les données au point de terminaison de l’API, le cycle de synchronisation suivant traite tous les enregistrements utilisateur et vous permet de suivre la progression à l’aide du point de terminaison de l’API des journaux de provisionnement.

Comment effectuer la synchronisation delta à l’aide de l’API d’approvisionnement /bulkUpload ?

Pour effectuer une synchronisation delta, utilisez votre client API pour envoyer uniquement des informations sur les utilisateurs dont les données ont changé dans la source approuvée. Une fois que vous avez envoyé toutes les données au point de terminaison de l’API, le cycle de synchronisation suivant traite tous les enregistrements utilisateur et vous permet de suivre la progression à l’aide du point de terminaison de l’API des journaux de provisionnement.

Comment fonctionne le redémarrage du provisionnement ?

Utilisez l’option Redémarrer l’approvisionnement uniquement si nécessaire. Voici comment cela fonctionne :

Scénario 1 : Lorsque vous cliquez sur le bouton Redémarrer l’approvisionnement et que le travail est en cours d’exécution, il continue de traiter les données existantes qui sont déjà mises en attente. L’opérationde provisionnement de redémarrage n’interrompt pas un cycle existant. Dans le cycle suivant, le service de provisionnement efface toutes les provisions et sélectionne la nouvelle commande groupée pour le traitement.

Scénario 2 : Lorsque vous cliquez sur le bouton Redémarrer l’approvisionnement et que le travail n’est pas en cours d’exécution, avant d’exécuter le cycle suivant, le moteur d’approvisionnement vide les données chargées avant le redémarrage, efface toutes les demandes d’accès et traite uniquement les nouvelles données entrantes.

Comment créer des utilisateurs en utilisant le point de terminaison de l'API de provisionnement /bulkUpload ?

Voici comment le travail d’approvisionnement associé au point de terminaison de l’API /bulkUpload traite les charges utiles utilisateur entrantes :

  1. Le travail récupère le mappage d’attributs pour le travail de provisionnement et note la paire d’attributs correspondante (par défaut, l’attribut API externalId est utilisé pour la correspondance avec employeeId dans Microsoft Entra ID).
  2. Vous pouvez modifier cette paire de correspondances d’attributs par défaut.
  3. Le travail extrait chaque opération présente dans la charge utile de la requête groupée.
  4. Le travail vérifie l’identificateur de correspondance de valeur dans la requête (par défaut l’attribut externalId) et l’utilise pour vérifier s’il existe un utilisateur dans Microsoft Entra ID avec une valeur qui correspond à employeeId.
  5. Si le travail ne trouve pas d’utilisateur correspondant, le travail applique les règles de synchronisation et crée un utilisateur dans le répertoire cible.

Pour vous assurer que les utilisateurs appropriés sont créés dans l’ID Microsoft Entra, définissez la paire d’attributs correspondante appropriée dans votre mappage qui identifie de manière unique les utilisateurs de votre source et de votre ID Microsoft Entra.

Comment générer des valeurs uniques pour UPN ?

Le service d’approvisionnement ne fournit pas la possibilité de rechercher des doublons userPrincipalName (UPN) et de gérer les conflits. Si la règle de synchronisation par défaut pour l’attribut UPN génère une valeur UPN existante, l’opération de création de l’utilisateur échoue.

Voici quelques options que vous pouvez envisager pour générer des UPN uniques :

  1. Ajoutez la logique de génération UPN unique dans votre client API.
  2. Mettez à jour la règle de synchronisation de l’attribut UPN pour utiliser la fonction RandomString et définissez le paramètre de mappage sur On object creation only. Exemple:

Join("", Replace([userName], , "(?<Suffix>@(.)*)", "Suffix", "", , ), RandomString(3, 3, 0, 0, 0, ), "@", DefaultDomain())

  1. Si vous approvisionnez un Active Directory local, vous pouvez utiliser la fonction SelectUniqueValue et définir le paramètre de mappage à appliquer sur On object creation only.

Comment envoyer d’autres attributs RH au point de terminaison de l’API provisionnement /bulkUpload ?

Par défaut, le point de terminaison de l’API prend en charge le traitement de n’importe quel attribut qui fait partie du schéma utilisateur principal SCIM et Utilisateur d’entreprise. Si vous souhaitez envoyer d’autres attributs, vous pouvez étendre le schéma de l’application d’approvisionnement, mapper les nouveaux attributs aux attributs Microsoft Entra et mettre à jour la demande en bloc pour envoyer ces attributs. Reportez-vous au didacticiel Étendre l’approvisionnement piloté par l’API pour synchroniser les attributs personnalisés.

Comment exclure certains utilisateurs du flux d’approvisionnement ?

Vous pouvez avoir un scénario dans lequel vous souhaitez envoyer tous les utilisateurs au point de terminaison de l’API, mais inclure uniquement certains utilisateurs dans le flux d’approvisionnement et exclure le reste.

Vous pouvez effectuer cette opération à l’aide du Filtre d’étendue. Dans la configuration de l’application d’approvisionnement, vous pouvez définir une étendue d’objet source et exclure certains utilisateurs du traitement à l’aide d’une « règle d’inclusion » (par exemple, traiter uniquement les utilisateurs où le service EQUALS Sales) ou une « règle d’exclusion » (par exemple, exclure les utilisateurs appartenant à Sales, department NOT EQUALS Sales).

Voir Étendue des utilisateurs ou des groupes à provisionner avec des filtres d’étendue.

Comment mettre à jour les utilisateurs grâce au point d'accès de l'API de provisionnement /bulkUpload ?

Voici comment le travail d’approvisionnement associé au point de terminaison de l’API /bulkUpload traite les charges utiles utilisateur entrantes :

  1. Le travail de provisionnement récupère le mappage d’attributs pour le travail de provisionnement et note la paire d’attributs correspondante (par défaut, l’attribut API externalId est utilisé pour la correspondance avec employeeId dans Microsoft Entra ID). Vous pouvez modifier cette paire de correspondances d’attributs par défaut.
  2. Le travail extrait les opérations de la charge utile de la requête groupée.
  3. Le travail vérifie l’identificateur de correspondance de valeur dans la requête SCIM (par défaut : attribut externalIdd’API) et l’utilise pour vérifier s’il existe un utilisateur dans Microsoft Entra ID avec une valeur correspondante employeeId .
  4. Si le travail trouve un utilisateur correspondant, il applique les règles de synchronisation et compare les profils source et cible.
  5. Si le travail détermine que certaines valeurs ont changé, elle met à jour l’enregistrement utilisateur correspondant dans le répertoire.

Pour vous assurer que les utilisateurs appropriés sont mis à jour dans l’ID Microsoft Entra, veillez à définir la paire d’attributs correspondante appropriée dans votre mappage qui identifie de manière unique les utilisateurs dans votre ID source et Microsoft Entra.

Pouvons-nous créer plusieurs applications qui prennent en charge l’approvisionnement entrant piloté par l’API ?

Oui, c’est possible. Voici quelques scénarios qui peuvent nécessiter plusieurs applications d’approvisionnement :

Scénario 1 : Supposons que vous disposez de trois sources de données approuvées : un pour les employés, un pour les sous-traitants et un pour les fournisseurs. Vous pouvez créer trois applications d’approvisionnement distinctes : une pour chaque type d’identité avec son propre mappage d’attributs distinct. Chaque application d’approvisionnement a un point de terminaison d’API unique et vous pouvez envoyer les charges utiles respectives à chaque point de terminaison.

Vous pouvez récupérer le point de terminaison d’API unique pour chaque tâche depuis la page d'accueil du volet Provisioning. Accédez à Statistiques à ce jour>, puis à Afficher les informations techniques, et copiez l’URL du point de terminaison de l’API de provisionnement.

Scénario 2 : Supposons que vous avez plusieurs sources de vérité, chacune avec son propre ensemble d’attributs. Par exemple, les Ressources humaines fournissent des attributs d’information sur les emplois (par exemple jobTitle, employeeType) et le système de badge fournit des attributs d’information sur les badges (par exemple badgeId, représentés à l’aide d’un attribut d’extension). Dans ce scénario, vous pouvez configurer deux applications d’approvisionnement :

  • Application d'approvisionnement #1 qui reçoit des attributs de votre source RH et crée l’utilisateur.

  • Application de provisionnement n° 2 qui reçoit les attributs du système de badgeage et met à jour uniquement les attributs des utilisateurs. Le mappage d’attributs dans cette application est limité aux attributs Informations sur les badges et, sous Actions d’objet cible, la mise à jour est activée uniquement.

  • Les deux applications utilisent la même paire d’identificateurs correspondante (externalId<->employeeId)

Comment traiter les résiliations à l'aide du point de terminaison de l'API /bulkUpload ?

Pour traiter les terminaisons, identifiez un attribut dans votre source qui sera utilisé pour définir l’indicateur accountEnabled dans l’ID Microsoft Entra. Si vous approvisionnez sur Active Directory local, mappez cet attribut source à l’attribut accountDisabled .

Par défaut, la valeur associée à l’attribut active de schéma utilisateur principal SCIM détermine l’état du compte de l’utilisateur dans le répertoire cible.

Si l’attribut est défini sur true, la règle de mappage par défaut active le compte. Si l’attribut est défini sur false, la règle de mappage par défaut désactive le compte.

Comment empêcher la désactivation/suppression accidentelle des utilisateurs ?

Pour empêcher et récupérer des suppressions accidentelles, nous vous recommandons de configurer un seuil de suppression accidentel dans l’application d’approvisionnement et d’activer la corbeille Active Directory locale. Dans le panneau Mappage d’attributs de votre application d’approvisionnement, sous Actions d’objet cible, désactivez l’opération Supprimer.

Récupération de comptes supprimés

  • Si le répertoire cible de l’opération est Microsoft Entra ID, l’utilisateur correspondant est supprimé de manière réversible. L’utilisateur est visible sur la page Utilisateurs supprimés du Centre d’administration Microsoft Entra pour les 30 prochains jours et peut être restauré pendant cette période.
  • Si le répertoire cible de l’opération est local Active Directory, l’utilisateur correspondant est supprimé en dur. Si la Corbeille Active Directory est activée, vous pouvez restaurer l’objet utilisateur AD local supprimé.

Devons-nous envoyer tous les utilisateurs du système RH à chaque demande ?

Non, vous n’avez pas besoin d’envoyer tous les utilisateurs du système RH / « source de vérité » dans chaque requête. Envoyez simplement les utilisateurs que vous souhaitez créer ou mettre à jour.

L’API prend-elle en charge toutes les actions HTTP (GET/POST/PUT/PATCH) ?

Non, le point de terminaison de l’API de provisionnement /bulkUpload prend uniquement en charge l’action HTTP POST.

Si je souhaite mettre à jour un utilisateur, dois-je envoyer une demande PUT/PATCH ?

Non, le point de terminaison de l’API ne prend pas en charge la requête PUT/PATCH. Pour mettre à jour un utilisateur, envoyez les données associées à l’utilisateur dans la charge utile de requête en bloc POST.

Le travail d’approvisionnement qui traite les données reçues par le point de terminaison d’API détecte automatiquement si l’utilisateur dans la charge utile de la requête POST doit être créé, mis à jour, activé ou désactivé en fonction des règles de synchronisation configurées. En tant que client d’API, vous n’avez pas besoin d’effectuer d’autres étapes si vous souhaitez qu’un profil utilisateur soit mis à jour.

Comment l’écriture différée est-elle prise en charge ?

L’API actuelle prend uniquement en charge les données entrantes. Voici quelques options à prendre en compte pour implémenter le retour d’attributs tels que l’e-mail / nom d’utilisateur / téléphone générés par Microsoft Entra ID, que vous pouvez renvoyer au système RH :

  • Option 1 : connectivité SCIM au point de terminaison RH/service proxy qui met à jour à son tour la source RH

    • Si le système d’enregistrement fournit un point de terminaison SCIM pour les mises à jour utilisateur, vous pouvez créer une application SCIM personnalisée dans la galerie d’applications d’entreprise et configurer l’approvisionnement comme indiqué.
    • Si le système d’enregistrement ne fournit pas de point de terminaison SCIM, explorez la possibilité de configurer un service SCIM proxy, qui reçoit la mise à jour et propage la modification vers le système RH.

  • Option 2 : Utiliser le connecteur Microsoft Entra ECMA pour le scénario d’écriture différée

    • En fonction des besoins du client, explorez si l’un des connecteurs ECMA peut être utilisé (PowerShell / SQL / Services Web).

  • Option 3 : Utiliser la tâche d'extension personnalisée des Lifecycle Workflows dans un flux de travail de jointure

Étapes suivantes

  • Last updated on