Préparer une révision d’accès de l’accès à une application

  • Article

Microsoft Entra ID Governance vous permet de bénéficier de la visibilité et des processus appropriés pour répondre aux besoins de votre organisation en termes de sécurité et de productivité des employés. Il offre des fonctionnalités permettant de faire en sorte que chacun dispose de droits d’accès aux ressources adaptés.

Les organisations ayant des exigences de conformité ou des plans de gestion des risques ont toutes des applications sensibles ou vitales pour l’entreprise. La sensibilité de l'application peut être basée sur sa finalité ou sur les données qu'elle contient, telles que des informations financières ou des informations personnelles sur les clients de l'organisation. Pour ces applications, seule une partie de l’ensemble des utilisateurs de l’organisation est autorisée à y avoir accès, et cet accès doit être autorisé uniquement sur la base des besoins métier documentés. Microsoft Entra ID peut être intégré à de nombreuses applications SaaS connues, à des applications locales et aux applications que votre organisation développe, en utilisant des interfaces de protocole standard et d’API. Via ces interfaces, Microsoft Entra ID peut agir comme source faisant autorité pour contrôler qui a accès à ces applications. Lorsque vous intégrez vos applications à Microsoft Entra ID, vous pouvez ensuite utiliser les révisions d’accès pour certifier à nouveau les utilisateurs qui ont accès à ces applications et révoquer l’accès des utilisateurs qui n’ont plus besoin d’y accéder. Vous pouvez également utiliser d’autres fonctionnalités, notamment les conditions d’utilisation, l’accès conditionnel et la gestion des droits d’utilisation, pour régir l’accès aux applications, comme décrit dans le guide pratique pour régir l’accès aux applications dans votre environnement.

Conditions préalables à la révision de l’accès

Pour utiliser Microsoft Entra ID pour une révision de l’accès à une application, vous devez disposer de l’une des licences suivantes dans votre locataire :

  • Microsoft Entra ID P2 ou Microsoft Entra ID Governance
  • Licence Enterprise Mobility + Security (EMS) E5

Bien que l’utilisation de la fonctionnalité de révision des accès ne nécessite pas que ces licences soient attribuées aux utilisateurs, vous devez disposer de suffisamment de licences. Pour plus d'informations, consultez Exemples de scénarios de licence pour les révisions d'accès.

En outre, bien qu’il ne soit pas nécessaire de réviser l’accès à une application, nous vous recommandons également de réviser régulièrement l’appartenance aux rôles d’annuaire privilégiés qui ont la possibilité de contrôler l’accès des autres utilisateurs à toutes les applications. Les administrateurs dans Global Administrator, Identity Governance Administrator, User Administrator, Application Administrator, Cloud Application Administratoret Privileged Role Administrator peuvent apporter des modifications aux utilisateurs et à leurs attributions de rôles d’application, de sorte que la révision d’accès de ces rôles d’annuaire a été planifié.

Déterminer comment l’application est intégrée à Microsoft Entra ID

Pour utiliser les révisions d’accès pour une application, cette application doit d’abord être intégrée à Microsoft Entra ID et représentée dans votre annuaire. Lorsque l’application est intégrée à Microsoft Entra ID, cela signifie qu’une de ces deux exigences doit être remplie :

  • L’application s’appuie sur Microsoft Entra ID pour l’authentification unique fédérée et Microsoft Entra ID contrôle l’émission de jeton d’authentification. Si Microsoft Entra ID est le seul fournisseur d’identité pour l’application, seuls les utilisateurs qui sont affectés à l’un des rôles de l’application dans Microsoft Entra ID peuvent se connecter à l’application. Ces utilisateurs qui sont refusés par une révision perdent leur attribution de rôle d’application et ne peuvent plus obtenir de nouveau jeton pour se connecter à l’application.
  • L’application s’appuie sur des listes d’utilisateurs ou de groupes fournies à l’application par Microsoft Entra ID. Ce traitement peut être effectué par un protocole de provisionnement tel que SCIM (System for Cross-Domain Identity Management), par l’application interrogeant Microsoft Entra ID au moyen de Microsoft Graph ou des groupes écrits dans AD DS. Les utilisateurs qui sont refusés lors d’une révision perdent leur attribution de rôle d’application ou leur appartenance au groupe, et lorsque ces modifications sont mises à la disposition de l’application, les utilisateurs refusés n’y auront plus accès.

Si aucun de ces critères n'est rempli pour une candidature, car celle-ci ne repose pas sur Microsoft Entra ID, les examens d'accès peuvent toujours être utilisés, mais il y aura certaines limitations. Les utilisateurs qui ne figurent pas dans votre instance Microsoft Entra ID ou qui ne sont pas affectés aux rôles d’application dans Microsoft Entra ID ne seront pas inclus dans la révision. De plus, les modifications pour supprimer les refus ne peuvent pas être envoyées automatiquement à l’application s’il n’y a pas de protocole d’approvisionnement pris en charge par l’application. L’organisation doit disposer d’un processus pour envoyer les résultats de la révision à l’application.

Pour permettre à un large éventail d’applications et d’exigences informatiques d’être traitées avec Microsoft Entra ID, il existe plusieurs modèles pour la façon dont une application peut être intégrée à Microsoft Entra ID. Chaque modèle utilise différents artéfacts Microsoft Entra. L’organigramme suivant illustre comment sélectionner parmi trois modèles d'intégration A, B et C qui sont appropriés pour les applications à utiliser avec la gouvernance des identités. Le fait de savoir quel modèle est utilisé pour une application vous aide à configurer les ressources appropriées dans Microsoft Entra ID pour être prêt à la révision d’accès.

Flowchart for application integration patterns

Modèle Modèle d’intégration des applications Étapes de préparation à une révision d’accès
A L’application prend en charge l’authentification unique fédérée, Microsoft Entra ID est le seul fournisseur d’identité et l’application ne s’appuie pas sur les revendications de groupe ou de rôle. Dans ce modèle, vous configurez pour faire en sorte que l’application demande des attributions de rôles d’application individuels et que des utilisateurs soient affectés à l’application. Ensuite, pour effectuer la révision, vous créez une seule révision d’accès pour l’application, et ce pour les utilisateurs affectés à ce rôle d’application. Une fois la révision terminée, si un utilisateur est refusé, il est supprimé du rôle d’application. Microsoft Entra ID ne donne émet plus à cet utilisateur de jetons de fédération et l’utilisateur ne peut plus se connecter à cette application.
B Si l’application utilise des revendications de groupe en plus des attributions de rôles d’application. Une application peut utiliser l'appartenance à un groupe Active Directory ou Microsoft Entra, distincte des rôles d'application, pour exprimer un accès plus précis. Ici, vous pouvez choisir en fonction de vos besoins métier pour que les utilisateurs qui ont des attributions de rôle d’application examinés, ou pour réviser les utilisateurs qui ont des appartenances à un groupe. Si les groupes ne fournissent pas une couverture d’accès complète, en particulier si les utilisateurs peuvent avoir accès à l’application même s’ils ne sont pas membres de ces groupes, nous vous recommandons de réviser les attributions de rôles d’application, comme dans le modèle A précédent.
C Si l’application ne s’appuie pas uniquement sur Microsoft Entra ID pour l’authentification unique fédérée, mais prend en charge l’approvisionnement via SCIM, via des mises à jour vers une table SQL d’utilisateurs, possède un répertoire LDAP non-AD ou prend en charge un protocole d’approvisionnement SOAP ou REST. Dans ce modèle, vous configurez Microsoft Entra ID pour approvisionner les utilisateurs avec des attributions de rôle d’application dans la base de données ou l’annuaire de l’application, mettre à jour les attributions de rôles d’application dans Microsoft Entra ID avec une liste des utilisateurs qui ont actuellement accès, puis vous créez une seule révision d’accès des attributions de rôle d’application. Pour plus d’informations, consultez Gouvernance des utilisateurs existants d’une application pour mettre à jour les attributions de rôles d’application dans Microsoft Entra ID.

Autres options

Les modèles d’intégration répertoriés dans la section précédente s’appliquent aux applications SaaS tierces ou aux applications qui ont été développées par ou pour votre organisation.

  • Certains services Microsoft Online, comme Exchange Online, utilisent des licences. Bien que les licences de l’utilisateur ne puissent pas être examinées directement, si vous utilisez des attributions de licences basées sur un groupe avec des groupes avec des utilisateurs affectés, vous pouvez passer en revue les appartenances de ces groupes.
  • Certaines applications utilisent le consentement délégué de l'utilisateur pour contrôler l'accès à Microsoft Graph ou à d'autres ressources. Comme les consentements de chaque utilisateur ne sont pas contrôlés par un processus d’approbation, les consentements ne peuvent pas être examinés. Au lieu de cela, vous pouvez vérifier qui peut se connecter à l'application via des stratégies d'accès conditionnel qui peuvent être basées sur les attributions de rôles d'application ou les appartenances à des groupes.
  • Si l’application ne prend pas en charge les protocoles de fédération ou d’approvisionnement, vous avez besoin d’un processus pour appliquer manuellement les résultats lorsqu’une révision est terminée. Pour une application qui prend uniquement en charge l’intégration de l’authentification unique par mot de passe, si une attribution d’application est supprimée lorsqu’une révision est terminée, l’application ne s’affiche pas sur la page myapps pour l’utilisateur, mais elle n’empêche pas un utilisateur qui connaît déjà le mot de passe de pouvoir continuer à se connecter à l’application. Pour vos applications locales, consultez Régir les utilisateurs d’une application qui ne prend pas en charge l’approvisionnement. Pour les applications SaaS, demandez au fournisseur SaaS d’intégrer la galerie d’applications pour la fédération ou l’approvisionnement en mettant à jour son application pour qu’elle prenne en charge un protocole standard.

Vérifiez que l’application est prête pour la révision

Maintenant que vous avez identifié le modèle d’intégration de l’application, vérifiez si l’application telle qu’elle est représentée dans Microsoft Entra ID est prête à être examinée.

  1. Connectez-vous au Centre d’administration Microsoft Entra au moins en tant qu’Administrateur de gouvernance des identités.

  2. Accédez à >Identité>Applications>Applications d’entreprise.

  3. Ici, vous pouvez voir si votre application figure dans la liste des applications d’entreprise de votre locataire.

  4. Si l’application n’est pas déjà répertoriée, vérifiez si l’application est disponible dans la galerie d’applications pour les applications qui peuvent être intégrées pour l’authentification unique fédérée ou l’approvisionnement. Si elle se trouve dans la galerie, utilisez les tutoriels pour configurer l’application pour la fédération, et si elle prend en charge l’approvisionnement, configurez également l’application pour l’approvisionnement.

  5. Si l’application n’est pas déjà répertoriée, mais qu’elle utilise des groupes de sécurité AD et qu’elle est une application web, et que la configuration de l’application peut être modifiée pour rechercher différents groupes de sécurité dans AD, ajoutez l’application pour l’accès à distance via le Proxy d’application, déplacez l’appartenance des groupes de sécurité AD existants vers de nouveaux groupes Microsoft Entra et configurez la réécriture de groupes dans AD. Ensuite, mettez à jour l’application pour vérifier les nouveaux groupes AD créés par l’écriture différée de groupe, comme décrit dans la section Gouvernance des applications basées sur Active Directory local (Kerberos).

  6. Si l’application n’est pas déjà répertoriée, mais qu’elle utilise des groupes de sécurité AD et qu’elle est une application web, et que la configuration de l’application ne peut pas être modifiée pour rechercher différents groupes de sécurité dans AD, ajoutez l’application pour l’accès à distance via le Proxy d’application, déplacez l’appartenance des groupes de sécurité AD existants vers de nouveaux groupes Microsoft Entra et configurez la réécriture de groupes dans AD. Ensuite, mettez à jour les groupes de sécurité AD existants que l’application vérifiait afin d’inclure les nouveaux groupes en tant que membre, comme décrit dans la section Gouvernance des applications basées sur Active Directory local (Kerberos).

  7. Si l’application n’est pas déjà répertoriée, qu’elle utilise des groupes de sécurité AD et qu’elle n’est pas une application web, et que la configuration de l’application peut être modifiée pour rechercher différents groupes de sécurité dans AD, déplacez l’appartenance des groupes de sécurité AD existants vers de nouveaux groupes Microsoft Entra et configurez la réécriture de groupes dans AD. Ensuite, mettez à jour l’application pour vérifier les nouveaux groupes AD créés par l’écriture différée de groupe, comme décrit dans la section Gouvernance des applications basées sur Active Directory local (Kerberos). Passez à la section suivante.

  8. Si l’application n’est pas déjà répertoriée, qu’elle utilise des groupes de sécurité AD et qu’elle n’est pas une application web, et que la configuration de l’application ne peut pas être modifiée pour rechercher différents groupes de sécurité dans AD, déplacez l’appartenance des groupes de sécurité AD existants vers de nouveaux groupes Microsoft Entra et configurez la réécriture de groupes dans AD. Ensuite, mettez à jour les groupes de sécurité AD existants que l’application vérifiait afin d’inclure les nouveaux groupes en tant que membre, comme décrit dans la section Gouvernance des applications basées sur Active Directory local (Kerberos). Passez à la section suivante.

  9. Une fois que l’application figure dans la liste des applications d’entreprise dans votre locataire, sélectionnez-la dans la liste.

  10. Accédez à l’onglet Propriétés. Vérifiez que l’option Attribution d’utilisateur requise est définie sur Oui. Si elle est définie sur Non, tous les utilisateurs de votre répertoire, y compris les identités externes, peuvent accéder à l’application et vous ne pouvez pas réviser l’accès à l’application.

    Screenshot that shows planning app assignments.

  11. Accédez à l'onglet Rôles et administrateurs. Cet onglet affiche les rôles administratifs qui donnent le droit de contrôler la représentation de l'application dans Microsoft Entra ID, et non les droits d'accès à l'application. Pour chaque rôle administratif disposant d’autorisations pour autoriser la modification de l’intégration ou des attributions de l’application, et d’une attribution à ce rôle d’administration, assurez-vous que seuls les utilisateurs autorisés se trouvent dans ce rôle.

  12. Accédez à l’onglet Approvisionnement. Si l’approvisionnement automatique n’est pas configuré, est à l’arrêt ou est en quarantaine, Microsoft Entra ID n’a pas de moyen d’avertir l’application quand l’accès d’un utilisateur est supprimé, si cet accès est refusé pendant la révision. Le provisionnement peut ne pas être nécessaire pour certains modèles d’intégration si l’application est fédérée et s’appuie uniquement sur Microsoft Entra ID comme fournisseur d’identité ou si l’application utilise des groupes AD DS. Toutefois, si l’intégration de votre application suit le modèle C et que l’application ne prend pas en charge l’authentification unique fédérée avec Microsoft Entra ID en tant que seul fournisseur d’identité, vous devez configurer l’approvisionnement de Microsoft Entra ID sur l’application. L’approvisionnement est nécessaire pour que Microsoft Entra ID puisse supprimer automatiquement les utilisateurs révisés de l’application lorsqu’une révision est terminée, et cette étape de suppression peut être effectuée via un changement envoyé depuis Microsoft Entra ID à l’application via SCIM, LDAP, SQL, SOAP ou REST.

Pour plus d’informations, consultez Intégration d'applications avec Microsoft Entra ID.

  1. Si l’approvisionnement est configuré, sélectionnez Modifier les mappages d’attributs, développez la section Mappage, puis sélectionnez Approvisionner des utilisateurs Microsoft Entra. Vérifiez que dans la liste des mappages d’attributs, il existe un mappage pour isSoftDeleted à l’attribut dans le magasin de données de l’application pour lequel vous souhaitez avoir Microsoft Entra ID défini sur false lorsqu’un utilisateur perd l’accès. Si ce mappage n’est pas présent, Microsoft Entra ID ne notifie pas l’application lorsqu’un utilisateur quitte l’étendue, comme décrit dans le fonctionnement de l’approvisionnement.

  2. Si l’application prend en charge l’authentification unique fédérée, passez à l’onglet Accès conditionnel. Inspectez les stratégies activées pour cette application. Si des stratégies sont activées, bloquent l'accès, si des utilisateurs sont affectés aux stratégies, mais aucune autre condition, alors ces utilisateurs peuvent déjà être empêchés d'obtenir une authentification unique fédérée vers l'application.

  3. Accédez à l’onglet Utilisateurs et groupes. Cette liste contient tous les utilisateurs affectés à l’application dans Microsoft Entra ID. Si la liste est vide, une révision de l’application se fait immédiatement, étant donné que le réviseur n’a plus d’accès à réviser.

  4. Si votre application est intégrée au modèle C, vous devez confirmer que les utilisateurs de cette liste sont identiques à ceux du magasin de données interne des applications avant de commencer la révision. Microsoft Entra ID n’importe pas automatiquement les utilisateurs ou leurs droits d’accès à partir d’une application, mais vous pouvez affecter des utilisateurs à un rôle d’application via PowerShell. Consultez Gouvernance des utilisateurs existants d’une application pour savoir comment importer des utilisateurs à partir de différents magasins de données d’application dans Microsoft Entra ID et les attribuer à un rôle d’application.

  5. Vérifiez si tous les utilisateurs sont affectés au même rôle d’application, par exemple le rôle utilisateur. Si les utilisateurs sont affectés à plusieurs rôles et que vous créez une révision d’accès de l’application, toutes les attributions à tous les rôles de l’application seront examinées ensemble.

  6. Vérifiez la liste des objets d’annuaire affectés aux rôles pour vérifier qu’il n’y a pas de groupes affectés aux rôles d’application. Il est possible de réviser cette application s’il y a un groupe affecté à un rôle. Toutefois, un utilisateur membre du groupe affecté au rôle et dont l’accès a été refusé ne sera pas automatiquement supprimé du groupe. Si l’application ne s’appuie pas elle-même sur des groupes, nous vous recommandons d’abord de convertir l’application pour avoir des affectations directes d’utilisateurs, plutôt que des membres de groupes, afin que l’attribution de rôle d’application d’un utilisateur dont l’accès est refusé pendant la révision d’accès puisse être automatiquement supprimée. Si l’application s’appuie sur des groupes et que tous les groupes de l’application sont affectés au même rôle d’application, vous révisez les appartenances aux groupes au lieu de réviser les affectations d’applications.

Vérifiez que les groupes sont prêts pour la révision

Si votre application ne s’appuie pas sur des groupes, passez à la section suivante. Ensuite, si l’intégration de l’application nécessite également la révision d’un ou plusieurs groupes, comme décrit dans le modèle B, vérifiez que chaque groupe est prêt à être révisé.

  1. Connectez-vous au Centre d’administration Microsoft Entra au moins en tant qu’Administrateur de gouvernance des identités.
  2. Accédez à >Groupes.
  3. Recherchez et sélectionnez chaque groupe dans la liste.
  4. Dans l’onglet Vue d’ensemble, vérifiez que le type d’appartenance est affecté et que la source est cloud. Si l’application utilise un groupe dynamique ou un groupe synchronisé à partir d’un site local, ces appartenances de groupe ne peuvent pas être modifiées dans Microsoft Entra ID. Nous vous recommandons de convertir l’application en groupes créés dans Microsoft Entra ID avec des appartenances affectées, puis de copier les utilisateurs membres dans ce nouveau groupe.
  5. Accédez à l'onglet Rôles et administrateurs. Cet onglet affiche les rôles administratifs qui donnent le droit de contrôler la représentation du groupe dans Microsoft Entra ID, et non les droits d'accès dans l'application. Pour chaque rôle d’administration qui autorise la modification de l’appartenance au groupe et qui a des utilisateurs dans ce rôle d’administration, assurez-vous que seuls les utilisateurs autorisés se trouvent dans ce rôle.
  6. Accédez à l’onglet Membres. Vérifiez que les membres du groupe sont des utilisateurs et qu’il n’y a pas de membres non-utilisateur ou de groupes imbriqués. S’il n’y a aucun membre d’un groupe au démarrage de la révision, la révision du groupe se fait immédiatement.
  7. Accédez à l’onglet Propriétaires. Assurez-vous qu’aucun utilisateur non autorisé n’est affiché en tant que propriétaire. Si vous demandez aux propriétaires d’un groupe d’effectuer la révision d’accès de ce groupe, vérifiez que le groupe comporte un ou plusieurs propriétaires.

Sélectionner les réviseurs appropriés

Lors de la création d’une révision d’accès, les administrateurs peuvent choisir un ou plusieurs réviseurs. Tous les réviseurs peuvent démarrer et effectuer une révision, en choisissant des utilisateurs pour un accès continu à une ressource ou en les supprimant.

En règle générale, le propriétaire de la ressource est responsable de l’exécution d’une révision. Si vous créez une révision d’un groupe, dans le cadre de la révision de l’accès à une application intégrée au modèle B, vous pouvez sélectionner les propriétaires de groupe en tant que réviseurs. Les applications dans Microsoft Entra ID n'ont pas nécessairement de propriétaire. Par conséquent, vous ne pouvez pas sélectionner propriétaire de l’application en tant que réviseur. Au lieu de cela, lors de la création de la révision, vous pouvez fournir les noms des propriétaires d’application pour qu’ils soient les réviseurs.

Vous pouvez également choisir lors de la création d’une révision d’un groupe ou d’une application d’avoir une révision en plusieurs étapes. Par exemple, vous pouvez choisir de faire en sorte que le responsable de chaque utilisateur affecté effectue la première étape de la révision et le propriétaire de la ressource la deuxième étape. Ainsi, le propriétaire de la ressource peut se concentrer sur les utilisateurs qui ont déjà été approuvés par leur responsable.

Avant de créer les révisions, vérifiez que vous disposez de suffisamment de sièges Microsoft Entra ID P2 ou Microsoft Entra ID Governance SKU dans votre locataire. Vérifiez également que tous les réviseurs sont des utilisateurs actifs avec des adresses e-mail. Lorsque les révisions d’accès démarrent, elles passent chacune en revue un e-mail tiré de Microsoft Entra ID. Si le réviseur n’a pas de boîte aux lettres, il ne reçoit pas l’e-mail au démarrage de la révision ou ni le rappel par e-mail. En outre, si le réviseur ne peut pas se connecter à Microsoft Entra ID, il ne pourra pas effectuer l’évaluation.

Créer les révisions

Une fois que vous avez identifié les ressources, l’application et éventuellement un ou plusieurs groupes en fonction du modèle d’intégration et de qui les réviseurs doivent être, vous pouvez configurer Microsoft Entra ID pour démarrer les révisions.

  1. Pour cette étape, vous devez être dans le rôle Global administrator ou Identity Governance administrator.

  2. Dans les modèles A et C, vous créez une révision d’accès en sélectionnant l’application. Suivez les instructions du guide pour créer une révision d’accès de groupes ou d’applications pour créer la révision des attributions de rôles de l’application.

  3. Si votre application est intégrée au modèle B, utilisez le même guide pour créer d’autres révisions d’accès pour chacun des groupes.

    Notes

    Si vous créez une révision d’accès et que vous activez les aides à la décision de révision, l’assistance à la décision varie en fonction de la ressource en cours de révision. Si la ressource est une application, les recommandations seront basées sur la période d’intervalle de 30 jours en fonction de la date de la dernière connexion de l’utilisateur à l’application. Si la ressource est un groupe, les recommandations sont basées sur l’intervalle selon lequel l’utilisateur s’est connecté pour la dernière fois à n’importe quelle application dans le locataire et pas seulement à l’application utilisant ces groupes.

  4. Lorsque la révision d’accès démarre, demandez aux réviseurs de donner leur avis. Par défaut, chacun d’eux reçoit un e-mail provenant de Microsoft Entra ID et contenant un lien vers le panneau d’accès, dans lequel ils peuvent réviser l’appartenance aux groupes ou l’accès à l’application.

Voir les affectations mises à jour une fois les révisions terminées

Une fois les révisions démarrées, vous pouvez surveiller leur progression et mettre à jour les approbateurs si nécessaire, jusqu’à ce que la révision soit terminée. Vous pouvez ensuite confirmer que les utilisateurs, dont l’accès a été refusé par les réviseurs, ont vu leur accès supprimé de l’application.

  1. Surveillez les révisions d’accès, en veillant à ce que les réviseurs effectuent des sélections pour approuver ou refuser un accès continu à l’utilisateur jusqu’à ce que la révision d’accès soit terminée.

  2. Si l’application automatique n’a pas été sélectionnée lors de la création de la révision, vous devez appliquer les résultats de la révision une fois qu’elle est terminée.

  3. Attendez que l’état de la révision passe à Résultat appliqué. Les utilisateurs dont l’accès est refusé doivent normalement perdre leur appartenance au groupe ou leur affectation d’applications au bout de quelques minutes.

  4. Si vous aviez configuré l’approvisionnement d’utilisateurs sur l’application, lorsque les résultats sont appliqués, Microsoft Entra ID commence à désapprovisionner les utilisateurs refusés dans l’application. Vous pouvez surveiller le processus de déprovisionnement des utilisateurs. Si l’approvisionnement indique une erreur dans l’application, vous pouvez télécharger le journal d’approvisionnement pour voir s’il y a un problème avec l’application.

  5. Si vous avez configuré la réécriture de groupe pour les groupes révisés, attendez qu’elle se termine dans Microsoft Entra Cloud Sync et que les modifications se propagent à tous les contrôleurs de domaine.

  6. Si l’approvisionnement n’a pas été configuré pour votre application, vous devez copier séparément la liste des utilisateurs refusés dans l’application. Par exemple, pour accéder aux révisions d’un groupe géré par Windows Server AD, utilisez cet exemple de script PowerShell. Le script décrit les appels Microsoft Graph requis et exporte les cmdlets Windows Server AD-PowerShell pour effectuer les modifications.

  7. Si vous le souhaitez, vous pouvez également télécharger un rapport d’historique des révisions terminées.

  8. La durée pendant laquelle un utilisateur qui s’est vu refuser un accès continu peut continuer à utiliser une application fédérée dépend de la durée de vie de la session de l’application et de la durée de vie du jeton d’accès. Si les applications utilisaient Kerberos, puisque Kerberos met en cache les appartenances aux groupes d'un utilisateur lorsqu'il se connecte à un domaine, les utilisateurs pourraient continuer à y accéder jusqu'à l'expiration de leurs tickets Kerberos. Pour en savoir plus sur le contrôle de la durée de vie des jetons d’accès, consultez Durées de vie des jetons configurables.

Étapes suivantes