Comment fonctionne le provisionnement d’applications dans Microsoft Entra ID

Article
10/25/2023

Le provisionnement automatique correspond à la création d’identités utilisateur et de rôles dans les applications cloud auxquelles les utilisateurs ont besoin d’accéder. En plus de créer des identités utilisateur, l’approvisionnement automatique comprend la maintenance et la suppression d’identités utilisateur en cas de modification de l’état ou des rôles. Avant de démarrer un déploiement, vous pouvez consulter cet article pour découvrir comment fonctionne le provisionnement Microsoft Entra et obtenir des suggestions de configuration.

Le service d’approvisionnement Microsoft Entra approvisionne les utilisateurs en applications SaaS et autres systèmes en se connectant à un point de terminaison d’API de gestion des utilisateurs System for Cross-Domain Identity Management (SCIM) 2.0 fourni par le fournisseur d’applications ou un agent d’approvisionnement local. Ce point de terminaison SCIM permet à Microsoft Entra ID de créer, mettre à jour et supprimer des utilisateurs par programmation. Pour les applications sélectionnées, le service d’approvisionnement peut également créer, mettre à jour et supprimer d’autres objets liés à l’identité, tels que les groupes. Le canal utilisé pour le provisionnement entre Microsoft Entra ID et l'application est chiffré à l'aide du chiffrement HTTPS TLS 1.2.

Figure 1 : Le service de provisionnement Microsoft Entra

Workflow de provisionnement des utilisateurs sortants Figure 2 : Workflow de provisionnement d'utilisateurs « sortant » depuis Microsoft Entra ID vers des applications SaaS populaires

Workflow de provisionnement des utilisateurs entrants Figure 3 : Flux de travail de provisionnement des utilisateurs « entrants » depuis les applications populaires de gestion du capital humain (HCM) vers Microsoft Entra ID et Windows Server Active Directory

Provisionnement à l’aide de SCIM 2.0

Le service de provisionnement Microsoft Entra utilise le protocole SCIM 2.0 pour le provisionnement automatique. Le service se connecte au point de terminaison SCIM de l’application et utilise le schéma d’objet utilisateur SCIM et les API REST pour automatiser le provisionnement et le déprovisionnement des utilisateurs et des groupes. Un connecteur de provisionnement basé sur SCIM est fourni pour la plupart des applications de la galerie Microsoft Entra. Les développeurs utilisent l'API de gestion des utilisateurs SCIM 2.0 dans Microsoft Entra ID pour créer des points de terminaison pour leurs applications qui s'intègrent au service de provisionnement. Pour plus d’informations, consultez Créer un point de terminaison SCIM et configurer l’attribution d’utilisateurs. L’agent d’approvisionnement local traduit également les opérations SCIM Microsoft Entra en LDAP, SQL, REST ou SOAP, PowerShell, appels à un connecteur ECMA personnalisé ou passerelles et connecteurs créés par les partenaires.

Pour demander un connecteur de provisionnement automatique Microsoft Entra pour une application qui n’en possède pas actuellement, consultez Requête d’application Microsoft Entra.

Autorisation

Des informations d'identification sont requises pour que Microsoft Entra ID puisse se connecter à l'API de gestion des utilisateurs de l'application. Pour configurer l’attribution automatique d’utilisateurs dans une application, vous devez entrer des informations d’identification valides. Pour les applications de la galerie, consultez le tutoriel de l’application afin d’en connaître les différents types d’informations d’identification et les exigences. Pour les applications qui ne proviennent pas de la galerie, vous pouvez consulter la documentation SCIM pour comprendre les types d’informations d’identification et les exigences. Dans le centre d'administration Microsoft Entra, vous pouvez tester les informations d'identification en demandant à Microsoft Entra ID de tenter de se connecter à l'application de provisionnement de l'application à l'aide des informations d'identification fournies.

Mappage d’attributs

Lorsque vous activez l’approvisionnement d’utilisateurs pour une application SaaS tierce, le centre d’administration Microsoft Entra contrôle ses valeurs d’attributs via des mappages d’attributs. Les mappages déterminent les attributs utilisateur qui circulent entre Microsoft Entra ID et l'application cible lorsque les comptes d'utilisateurs sont provisionnés ou mis à jour.

Il existe un ensemble préconfiguré d'attributs et de mappages d'attributs entre les objets utilisateur Microsoft Entra et les objets utilisateur de chaque application SaaS. Certaines applications gèrent d’autres types d’objets parallèlement aux Utilisateurs, tels que des Groupes.

Lors de la configuration du provisionnement, il est important d’examiner et de configurer les mappages d’attributs et les flux de travail qui définissent les propriétés d’utilisateur (ou de groupe) transmises de Microsoft Entra ID à l’application. Vérifiez et configurez la propriété correspondante (Trouver les objets utilisant cet attribut) qui est utilisée pour identifier de façon unique et établir une correspondance entre les utilisateurs et groupes des deux systèmes.

Vous pouvez personnaliser les mappages d’attributs par défaut en fonction des besoins de votre organisation. Vous pouvez ainsi modifier ou supprimer des mappages d’attributs existants ou en créer de nouveaux. Pour plus d’informations, consultez Personnalisation des mappages d’attributs d’attribution d’utilisateurs pour les applications SaaS.

Quand vous configurez l’approvisionnement pour une application SaaS, l’un des types de mappages d’attributs que vous pouvez spécifier est un mappage d’expression. Pour ces mappages, vous devez écrire une expression semblable à un script qui vous permet de transformer les données des utilisateurs dans des formats plus acceptables pour l’application SaaS. Pour plus d’informations, consultez Écriture d’expressions pour les mappages d’attributs.

Scoping

Étendue basée sur les attributions

Pour le provisionnement sortant de Microsoft Entra ID vers une application SaaS, s'appuyer sur les affectations d'utilisateurs ou de groupes est le moyen le plus courant de déterminer quels utilisateurs sont concernés par le provisionnement. Étant donné que les attributions d’utilisateurs sont également utilisées pour l’authentification unique, cette même méthode peut être utilisée pour gérer l’accès et le provisionnement. L’étendue basée sur les attributions ne s’applique pas aux scénarios de provisionnement entrant tels que Workday et Successfactors.

Groupes. Avec un plan de licence Microsoft Entra ID P1 ou P2, vous pouvez utiliser des groupes pour attribuer l'accès à une application SaaS. Ensuite, lorsque l’étendue de provisionnement est définie sur Synchroniser uniquement les utilisateurs et groupes attribués, le service de provisionnement Microsoft Entra provisionne ou déprovisionne les utilisateurs selon qu’ils sont membres d’un groupe attribué à l’application. L’objet de groupe n’est pas provisionné, sauf si l’application prend en charge les objets de groupe. Assurez-vous que les groupes attribués à votre application ont la propriété « SecurityEnabled » définie sur « False ».
Groupes dynamiques. Le service de provisionnement des utilisateurs Microsoft Entra peut lire et provisionner les utilisateurs dans des groupes dynamiques. Gardez à l’esprit les mises en garde et suggestions suivantes :
- Les groupes dynamiques peuvent avoir un impact sur les performances du provisionnement de bout en bout de Microsoft Entra ID vers les applications SaaS.
- L’attribution d’un utilisateur dans un groupe dynamique, ou l’annulation de son attribution, dans une application SaaS est plus ou moins rapide selon la vitesse à laquelle le groupe dynamique réussit à analyser les changements d’appartenance. Pour plus d’informations sur la vérification de l’état de traitement d’un groupe dynamique, consultez Vérifier l’état de traitement d’une règle d’appartenance.
- Le fait qu’un utilisateur perde son appartenance à un groupe dynamique est considéré comme un événement de déprovisionnement. Envisagez ce scénario lorsque vous créez des règles pour les groupes dynamiques.
Groupes imbriqués. Le service de provisionnement d’utilisateurs Microsoft Entra ne peut pas lire ou provisionner les utilisateurs dans des groupes imbriqués. Le service peut uniquement lire et attribuer les utilisateurs qui se trouvent directement dans un groupe attribué explicitement. Cette limitation concernant les « attributions basées sur les groupes à des applications » affecte également l’authentification unique (voir Utilisation d’un groupe pour gérer l’accès aux applications SaaS). Vous devez attribuer explicitement les groupes qui contiennent les utilisateurs à attribuer ou les inclure dans l’étendue.

Étendue basée sur les attributs

Vous pouvez utiliser les filtres d’étendue pour définir les règles basées sur des attributs qui précisent quels utilisateurs sont provisionnés dans une application. Cette méthode est couramment utilisée pour le provisionnement entrant depuis les applications HCM vers Microsoft Entra ID et Active Directory. Les filtres de portée sont configurés dans le cadre des mappages d'attributs pour chaque connecteur de provisionnement d'utilisateur Microsoft Entra. Pour plus d’informations sur la configuration des filtres d’étendue basés sur les attributs, consultez Approvisionnement d’applications basé sur les attributs avec filtres d’étendue.

Utilisateurs B2B invités

Il est possible d'utiliser le service de provisionnement d'utilisateurs Microsoft Entra pour provisionner des utilisateurs B2B (invités) dans Microsoft Entra ID vers des applications SaaS. Toutefois, pour que les utilisateurs B2B puissent se connecter à l'application SaaS à l'aide de Microsoft Entra ID, vous devez configurer manuellement l'application SaaS pour utiliser Microsoft Entra ID comme fournisseur d'identité SAML (Security Assertion Markup Language).

Suivez ces recommandations générales lors de la configuration d’applications SaaS pour les utilisateurs B2B (invités) :

Pour la plupart des applications, le paramétrage utilisateur doit être effectué manuellement. Les utilisateurs doivent également être créés manuellement dans l’application.
Pour les applications qui prennent en charge la configuration automatique, par exemple Dropbox, des invitations distinctes sont créées à partir des applications. Les utilisateurs doivent accepter chaque invitation.
Dans les attributs d’utilisateur, pour atténuer les problèmes liés aux disques de profil utilisateur altérés dans les utilisateurs invités, définissez toujours l’identificateur d’utilisateur sur user.mail.

Remarque

Le userPrincipalName d’un(e) utilisateur(-trice) de collaboration B2B représente l’adresse e-mail de l’utilisateur(-trice) externe alias@theirdomain sous la forme « alias_theirdomain#EXT#@yourdomain ». Quand l’attribut userPrincipalName est inclus dans vos mappages d’attributs en tant qu’attribut source, et qu’un utilisateur B2B est provisionné, #EXT# et votre domaine sont supprimés de userPrincipalName. Ainsi, seul le alias@sondomaine d’origine est utilisé pour la correspondance ou le provisionnement. Si vous avez besoin que le nom d’utilisateur principal complet, notamment #EXT# et votre domaine soient présents, remplacez userPrincipalName par originalUserPrincipalName en tant qu’attribut source.
userPrincipalName = alias@sondomaine
originalUserPrincipalName = alias_sondomaine#EXT#@votredomaine

Cycles de provisionnement : cycle initial et cycle incrémentiel

Lorsque Microsoft Entra ID est le système source, le service de provisionnement utilise la requête delta pour suivre les modifications apportées aux données Microsoft Graph afin de surveiller les utilisateurs et les groupes. Le service de provisionnement exécute un cycle initial sur le système source et le système cible, qui est suivi de cycles incrémentiels périodiques.

Cycle initial

Une fois le service de provisionnement démarré, le premier cycle va :

Interroger tous les utilisateurs et groupes à partir du système source, afin de récupérer tous les attributs définis dans les mappages d’attributs.
Filtrer les utilisateurs et les groupes renvoyés à l’aide d’affectations ou de filtres d’étendue basés sur un attribut configurés.
Quand un utilisateur est affecté ou se trouve dans une étendue pour l’approvisionnement, le service interroge le système cible pour rechercher un utilisateur correspondant à l’aide des attributs de correspondance spécifiés. Exemple : si le nom userPrincipal dans le système source est l’attribut de correspondance et s’il est mappé à userName dans le système cible, le service d’approvisionnement interroge le système cible pour les userNames qui correspondent aux valeurs de nom userPrincipal dans le système source.
Si aucun utilisateur correspondant n’est trouvé dans le système cible, il est créé à l’aide des attributs renvoyés depuis le système source. Une fois que le compte d’utilisateur a été créé, le service de provisionnement détecte et met en cache l’ID du nouvel utilisateur dans le système cible. Cet ID sera utilisé pour exécuter toutes les futures opérations concernant cet utilisateur.
Si un utilisateur correspondant est trouvé, il est mis à jour à l’aide des attributs fournis par le système source. Une fois que le compte d’utilisateur a été trouvé, le service de provisionnement détecte et met en cache l’ID du nouvel utilisateur dans le système cible. Cet ID sera utilisé pour exécuter toutes les futures opérations concernant cet utilisateur.
Si les mappages d’attributs contiennent des attributs de « référence », le service effectue des mises à jour supplémentaires sur le système cible pour créer et lier les objets référencés. Par exemple, un utilisateur peut avoir un attribut « Manager » dans le système cible, qui est lié à un autre utilisateur créé dans le système cible.
Conserver un filigrane à la fin du cycle initial, qui fournit le point de départ pour les cycles incrémentiels ultérieurs.

Certaines applications telles que ServiceNow, G Suite et Box prennent non seulement en charge l’approvisionnement des utilisateurs, mais également celui des groupes et de leurs membres. Dans ce type de situation, si l’approvisionnement des groupes est activé dans les mappages, le service d’approvisionnement synchronise les utilisateurs et les groupes, puis les appartenances au groupe.

Cycles incrémentiels

Après le cycle initial, tous les autres cycles effectuent les opérations suivantes :

Interroger le système source pour rechercher les utilisateurs et les groupes qui ont été mis à jour depuis le dernier filigrane enregistré.
Filtrer les utilisateurs et les groupes renvoyés à l’aide d’affectations ou de filtres d’étendue basés sur un attribut configurés.
Quand un utilisateur est affecté ou se trouve dans une étendue pour l’approvisionnement, le service interroge le système cible pour rechercher un utilisateur correspondant à l’aide des attributs de correspondance spécifiés.
Si aucun utilisateur correspondant n’est trouvé dans le système cible, il est créé à l’aide des attributs renvoyés depuis le système source. Une fois que le compte d’utilisateur a été créé, le service de provisionnement détecte et met en cache l’ID du nouvel utilisateur dans le système cible. Cet ID sera utilisé pour exécuter toutes les futures opérations concernant cet utilisateur.
Si un utilisateur correspondant est trouvé, il est mis à jour à l’aide des attributs fournis par le système source. Si le compte d’utilisateur trouvé a été récemment attribué, le service de provisionnement détecte et met en cache l’ID du nouvel utilisateur dans le système cible. Cet ID sera utilisé pour exécuter toutes les futures opérations concernant cet utilisateur.
Si les mappages d’attributs contiennent des attributs de « référence », le service effectue des mises à jour supplémentaires sur le système cible pour créer et lier les objets référencés. Par exemple, un utilisateur peut avoir un attribut « Manager » dans le système cible, qui est lié à un autre utilisateur créé dans le système cible.
Si un utilisateur qui se trouvait précédemment dans l’étendue de provisionnement est supprimé de l’étendue (ou déprovisionné), le service désactive l’utilisateur dans le système cible via une mise à jour.
Si un utilisateur qui se trouvait précédemment dans l’étendue de l’approvisionnement est désactivé ou supprimé de façon réversible dans le système source, le service désactive l’utilisateur dans le système cible via une mise à jour.
Si un utilisateur qui se trouvait précédemment dans l’étendue de l’approvisionnement est définitivement supprimé du système source, le service efface l’utilisateur dans le système cible. Dans Microsoft Entra ID, les utilisateurs sont supprimés définitivement 30 jours après leur suppression logicielle.
Conserver un nouveau filigrane à la fin du cycle initial, qui fournit le point de départ pour les cycles incrémentiels ultérieurs.

Notes

Vous pouvez éventuellement désactiver les opérations de création, mise à jour et suppression à l’aide des cases à cocher Actions d’objet cible dans la section Mappages. La logique pour désactiver un utilisateur pendant une mise à jour est également contrôlée via un mappage d’attributs à partir d’un champ tel que accountEnabled.

Le service de provisionnement continue à exécuter indéfiniment des cycles incrémentiels consécutifs, à des intervalles définis dans le tutoriel propre à chaque application. Les cycles incrémentiels se poursuivent jusqu’à ce que l’un des événements suivants se produise :

Le service est arrêté manuellement à l’aide du centre d’administration Microsoft Entra ou à l’aide de la commande appropriée de l’API Microsoft Graph.
Un nouveau cycle initial est déclenché au moyen de l’option Redémarrer l’approvisionnement. dans le centre d’administration Microsoft Entra ou à l’aide de la commande appropriée de l’API Microsoft Graph. Cette action permet d’effacer les filigranes stockés et de rendre tous les objets source disponibles pour une nouvelle évaluation. De plus, cette action ne rompt pas les liens entre les objets source et cible. Pour rompre les liens, utilisez Redémarrer le travail de synchronisation avec la requête suivante :

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

Une nouveau cycle initial est déclenché en raison d’une modification dans les mappages d’attributs ou les filtres d’étendue. Cette action permet également d’effacer les filigranes stockés et de rendre tous les objets source disponibles pour une nouvelle évaluation.
Le processus d’approvisionnement est mis en quarantaine (voir ci-dessous) en raison d’un taux d’erreur élevé et reste en quarantaine pendant plus de quatre semaines. Dans ce cas, le service est automatiquement désactivé.

Erreurs et nouvelles tentatives

Si un utilisateur ne peut pas être ajouté, mis à jour ou supprimé dans le système cible en raison d’une erreur dans le système cible, une nouvelle tentative est effectuée lors du prochain cycle de synchronisation. Les erreurs sont continuellement retentées, en remettant progressivement à l’échelle la fréquence des nouvelles tentatives. Pour résoudre le problème, les administrateurs doivent vérifier les journaux de provisionnement pour déterminer la cause racine et prendre les mesures nécessaires. Les échecs courants peuvent inclure :

Utilisateurs n’ayant pas d’attribut renseigné dans le système source alors qu’il est requis dans le système cible
Utilisateurs ayant une valeur d’attribut dans le système source pour laquelle il existe une contrainte unique dans le système cible, et la même valeur se trouve dans un autre enregistrement utilisateur

Ces échecs peuvent être résolus en ajustant les valeurs d’attribut de l’utilisateur concerné dans le système source, ou en ajustant les mappages d’attributs pour ne pas provoquer de conflits.

Mise en quarantaine

Si la plupart ou la totalité des appels effectués sur le système cible échouent constamment en raison d’une erreur (des informations d’identification non valides, par exemple), le travail de provisionnement est mis en quarantaine. Cet état est indiqué dans le rapport de synthèse sur l’approvisionnement et via les notifications par e-mail si elles ont été configurées dans le centre d’administration Microsoft Entra.

Lors de la mise en quarantaine, la fréquence des cycles incrémentiels est progressivement réduite à une fois par jour.

Le travail de provisionnement sort de quarantaine lorsque toutes les erreurs ont été corrigées et que le prochain cycle de synchronisation démarre. Si le travail d’approvisionnement reste en quarantaine pendant plus de quatre semaines, celui-ci est désactivé. Pour en savoir plus sur l’état de quarantaine, cliquez ici.

Durée du provisionnement

Les performances varient selon que votre tâche d’approvisionnement exécute un cycle d’approvisionnement initial ou un cycle incrémentiel. Pour en savoir plus sur la durée de l’approvisionnement et comment surveiller l’était du service d’approvisionnement, consultez Vérifier l’état de l’approvisionnement d’utilisateurs.

Comment savoir si les utilisateurs sont correctement attribués ?

Toutes les opérations exécutées par le service de provisionnement des utilisateurs sont enregistrées dans les journaux Microsoft Entra Provisioning (préversion). Les journaux comprennent toutes les opérations de lecture et d’écriture effectuées sur les systèmes sources et cibles, ainsi que les données utilisateur qui ont été lues ou écrites lors de chaque opération. Pour plus d’informations sur la lecture des journaux d’approvisionnement dans le centre d’administration Microsoft Entra, consultez le guide de création de rapports sur l’approvisionnement.

Annulation de l'approvisionnement

Le service de provisionnement Microsoft Entra maintient les systèmes source et cible synchronisés en supprimant les comptes lorsque l'accès des utilisateurs est supprimé.

Le service d’approvisionnement prend en charge la suppression et la désactivation (parfois appelées « suppressions réversibles ») des utilisateurs. La définition exacte de désactivation et de suppression varie en fonction de l’implémentation de l’application cible, mais en général, une désactivation indique que l’utilisateur ne peut pas se connecter. Une suppression indique que l’utilisateur a été entièrement supprimé de l’application. Pour les applications SCIM, une désactivation correspond une demande de définition de la propriété active sur false pour un utilisateur.

Configurer votre application pour désactiver un utilisateur

Vérifiez que la case des mises à jour est cochée.

Vérifiez que le mappage est actif pour votre application. Si vous utilisez une application à partir de la galerie d’applications, il est possible que le mappage soit légèrement différent. Dans ce cas, utilisez le mappage par défaut pour les applications de galerie.

Configurer votre application pour supprimer un utilisateur

Le scénario déclenche une désactivation ou une suppression :

Un utilisateur est supprimé de manière logicielle dans Microsoft Entra ID (envoyé vers la corbeille / propriété AccountEnabled définie sur false). Trente jours après la suppression d’un utilisateur dans Microsoft Entra ID, il est définitivement supprimé du locataire. À ce stade, le service d’approvisionnement envoie une demande de suppression pour supprimer définitivement l’utilisateur de l’application. Pendant cette période de 30 jours, vous pouvez à tout moment supprimer manuellement un utilisateur, ce qui a pour effet d’envoyer une demande de suppression à l’application.
Un utilisateur est définitivement supprimé/supprimé de la corbeille dans Microsoft Entra ID.
Un utilisateur n’est plus affecté à une application.
Un utilisateur dans l’étendue d’application sort de cette étendue (et ne transmet plus de filtre d’étendue).

Par défaut, le service de provisionnement Microsoft Entra supprime ou désactive les utilisateurs hors de portée. Si vous souhaitez substituer ce comportement par défaut, vous pouvez définir un indicateur permettant d'ignorer les suppressions non comprises dans l'étendue.

Quand l’un des quatre événements se produit et que l’application cible ne prend pas en charge les suppressions réversibles, le service d’approvisionnement envoie une demande de SUPPRESSION pour supprimer définitivement l’utilisateur de l’application.

Si vous voyez IsSoftDeleted dans vos mappages d’attributs, sachez qu’il sera utilisé pour déterminer l’état de l’utilisateur et s’il faut envoyer une demande de mise à jour avec active = false pour supprimer l’utilisateur de manière réversible.

Déprovisionnement des événements

Le tableau décrit comment configurer les actions de déprovisionnement avec le service de provisionnement Microsoft Entra. Ces règles sont écrites en pensant à l’application non-galerie/personnalisée, mais s’appliquent généralement aux applications de la galerie. Toutefois, le comportement des applications de la galerie peut varier, car elles ont été optimisées pour répondre aux besoins de l’application. Par exemple, si l'application cible ne prend pas en charge la suppression réversible, le service de provisionnement Microsoft Entra peut envoyer une requête de suppression matérielle pour supprimer des utilisateurs plutôt que d'envoyer une suppression logicielle.

Scénario	Comment configurer dans Microsoft Entra ID
Un utilisateur n’est plus attribué à une application, est supprimé de manière logicielle dans Microsoft Entra ID ou ne peut plus se connecter. Vous ne voulez rien faire.	Supprimez `isSoftDeleted` des mappages d’attributs et/ou définissez la propriété Ignorer les suppressions hors de l’étendue sur true.
Un utilisateur n’est plus attribué à une application, est supprimé de manière logicielle dans Microsoft Entra ID ou ne peut plus se connecter. Vous voulez définir un attribut spécifique sur `true` ou `false`.	Mappez `isSoftDeleted` à l’attribut auquel vous souhaitez affecter la valeur false.
Un utilisateur est désactivé dans Microsoft Entra ID, n'est plus attribué à partir d'une application, est supprimé de manière logicielle dans Microsoft Entra ID ou ne peut plus se connecter. Vous souhaitez envoyer une requête DELETE à l’application cible.	Cette fonctionnalité est actuellement prise en charge pour un ensemble limité d’applications de la galerie où elle est requise. Il n’est pas configurable par les clients.
Un utilisateur est supprimé dans Microsoft Entra ID. Vous ne voulez rien faire dans l’application cible.	Vérifiez que « Delete » n’est pas sélectionné comme l’une des actions de l’objet cible dans l’expérience de configuration d’attribut.
Un utilisateur est supprimé dans Microsoft Entra ID. Vous voulez définir la valeur d’un attribut dans l’application cible.	Non pris en charge.
Un utilisateur est supprimé dans Microsoft Entra ID. Vous voulez supprimer l’utilisateur dans l’application cible	Assurez-vous que « DELETE » est sélectionné comme l’une des actions de l’objet cible dans l’expérience de configuration d’attribut.

Limitations connues

Lorsque l’attribution d’une application est annulée auprès d’un utilisateur ou d’un groupe et que celui-ci n’est plus géré avec le service d’approvisionnement, une demande de désactivation est envoyée. À ce stade, le service ne gère pas l’utilisateur et aucune requête de suppression n’est envoyée lorsqu’il est supprimé du répertoire.
Le provisionnement d’un utilisateur désactivé dans Microsoft Entra ID n’est pas pris en charge. Ils doivent être actifs dans Microsoft Entra ID avant d’être provisionnés.
Lorsqu'un utilisateur passe de l'état supprimé de manière réversible à l'état actif, le service de provisionnement Microsoft Entra active l'utilisateur dans l'application cible, mais ne restaure pas automatiquement les appartenances aux groupes. L’application cible doit conserver les appartenances aux groupes de l’utilisateur dans un état inactif. Si l’application cible ne prend pas en charge le maintien de l’état inactif, vous pouvez redémarrer l’approvisionnement pour mettre à jour les appartenances aux groupes.

Recommandation

Lors du développement d’une application, prenez toujours en charge les suppressions réversibles et les suppressions définitives. Cela permet aux clients de récupérer un client qui a été désactivé accidentellement.