Access Control basée sur les rôles pour les applications dans Exchange Online

Cet article vous guide tout au long de l’utilisation d’un contrôle d’accès granulaire et évolutif, étendu aux ressources : RBAC (Role Based Access Control) pour les applications dans Exchange Online.

Vue d’ensemble

RBAC pour applications dans Exchange Online permet aux administrateurs d’accorder des autorisations à une application qui accède indépendamment aux données dans Exchange Online. Cette autorisation peut être associée à une étendue d’accès (étendue de ressource) pour spécifier les boîtes aux lettres auxquelles une application peut accéder. Cette fonctionnalité étend le modèle RBAC actuel dans Exchange Online et remplace les stratégies d’accès aux applications. Ces octrois d’autorisation sont indépendants des octrois non étendues dans Microsoft Entra ID.

Le cœur de ce système est la configuration de l’attribution de rôle de gestion, qui exprime l’intention d’un administrateur d’autoriser un principal à accéder aux données. Dans ce cas, autoriser une application à jouer un rôle sur un ensemble de ressources cibles. Par exemple, un administrateur peut configurer un système de réservation de salles avec accès aux données de calendrier uniquement dans des régions spécifiques à l’aide d’une étendue de gestion. Le diagramme suivant illustre le modèle d’attribution de rôle :

Configuration Instructions

Les étapes suivantes vous guident pour créer ces affectations RBAC d’application :

1. Créer une étendue de ressource (facultatif)
2. Créer un pointeur vers un principal de service Microsoft Entra
3. Sélectionner le rôle d’application approprié
4. Créer une attribution de rôle
5. Tester le nouveau principal de service

Configuration requise

Le groupe de rôles Gestion de l’organisation a l’attribution de rôle de délégation pour les nouveaux rôles RBAC d’application. Vous devez être membre du groupe de rôles Gestion de l’organisation pour attribuer ces autorisations. Vous pouvez également utiliser Exchange Online RBAC pour accorder des attributions de délégation à ces rôles d’application comme vous le souhaitez. Dans Microsoft Entra ID, vous avez besoin du rôle Administrateur Exchange pour attribuer ces autorisations.

Définir l’étendue des ressources

• Étendues de gestion : Entité Exchange qui représente un ensemble de boîtes aux lettres à l’aide d’une expression de filtre sur les propriétés de ces boîtes aux lettres.
• unités Administration : ressource Microsoft Entra qui peut être un conteneur pour d’autres ressources Microsoft Entra qui contient uniquement des groupes d’utilisateurs ou des appareils. Pour en savoir plus, consultez Unités administratives dans Microsoft Entra ID et Créer ou supprimer des unités administratives.

Étendues de gestion

Les étendues de gestion permettent à un administrateur d’étendre un ensemble de boîtes aux lettres en fonction des propriétés de ces objets. Reportez-vous à la documentation Étendue de gestion pour ajouter, supprimer, définir. Voici une liste des propriétés filtrables dans une étendue de gestion.

Principaux de service

Les principaux de service représentent un instance d’une application au sein de votre organization. Vous devez considérer le principal de service dans Exchange comme un pointeur vers un principal de service existant dans Microsoft Entra ID. Les principaux de service ne peuvent pas être créés directement à l’aide d’outils Exchange Online. Microsoft Entra outils sont utilisés pour gérer les inscriptions de principal de service au sein des organisations. Exchange empêche la création d’un pointeur non valide et reflète automatiquement les suppressions de principaux de service dans Microsoft Entra ID.

Nouveau principal de service

New-ServicePrincipal -AppId <Client Application ID in AAD> -ObjectId <Service principal object ID in AAD> -DisplayName <name>

La capture d’écran suivante vous aide à trouver ces ID dans Microsoft Entra ID :

Vous pouvez utiliser une autre approche pour rechercher ces ID à l’aide de Get-MgServicePrincipal.

Supprimer le principal de service

Remove-ServicePrincipal -Identity <ObjectID, AppID, or DisplayName>

Définir le principal de service

Set-ServicePrincipal -Identity <ObjectID, AppID, or DisplayName > -DisplayName <Updated name>

Rôles d’application

Les rôles d’application sont un type spécial de rôle de gestion dans Exchange Online, qui ne peut être attribué qu’à une application. Ces rôles peuvent être énumérés à l’aide de Get-ManagementRole.

Attributions de rôles

Les attributions de rôles de gestion lient un principal, un rôle et une étendue de ressource personnalisée d’accès. Cette affectation agit comme l’attribution d’autorisations pour un principal de service exécutant un rôle dans une étendue.

Nouvelle attribution de rôle

New-ManagementRoleAssignment [[-Name] <String>] -Role <RoleIdParameter> -App <ObjectID, AppID, or DisplayName> -CustomResourceScope <Management Scope> (or -RecipientAdministrativeUnitScope)

Définir l’attribution de rôle

Set-ManagementRoleAssignment [-Identity] <RoleAssignmentIdParameter> -CustomResourceScope <Management Scope> (or -RecipientAdministrativeUnitScope)

Supprimer l’attribution de rôle

Pour supprimer une attribution de rôle, consultez Supprimer l’attribution de gestion.

Test de l’autorisation

Une applet de commande de test peut être utilisée pour simuler le comportement activé par les affectations RBAC pour un principal de service particulier.

Lors du test de l’autorisation, vous pouvez inclure un paramètre de ressource facultatif pour évaluer les autorisations étendues qui s’appliquent à cette boîte aux lettres cible. InScope will = true or false pour représenter si, true cette autorisation s’applique à cette boîte aux lettres pour ce principal de service, ou false que ce principal de service dispose de cette autorisation mais pas sur cette boîte aux lettres particulière. L’omission de cet indicateur entraîne « Not Run ».

Les résultats des tests incluent toujours l’étendue de ressource autorisée pour une autorisation affectée particulière.

Tester l’accès du principal du service

Test-ServicePrincipalAuthorization -Identity <ObjectID, AppID, or DisplayName> [-Resource] <target mailbox>

Exemples

Après avoir utilisé Connect-ExchangeOnline dans PowerShell, procédez comme suit :

Exemple 1 : Configuration de l’accès en lecture au calendrier pour les utilisateurs canadiens à l’aide d’une étendue de gestion

New-ServicePrincipal -AppId 71487acd-ec93-476d-bd0e-6c8b31831053 -ObjectId 6233fba6-0198-4277-892f-9275bf728bcc -DisplayName "example"

DisplayName   ObjectId                              AppId
-----------   ---------                              -----
example       6233fba6-0198-4277-892f-9275bf728bcc   71487acd-ec93-476d-bd0e-6c8b3183105

New-ManagementScope -Name "Canadian users" -RecipientRestrictionFilter "CustomAttribute1 -eq '012332'"

Name                 ScopeRestrictionType      Exclusive      RecipientRoot          RecipientFilter
----                 --------------------      ---------      -------------          ---------------
Canadian users    RecipientScope            False                                CustomAttribute1 -eq '012332'

New-ManagementRoleAssignment -App 6233fba6-0198-4277-892f-9275bf728bcc -Role "Application Calendars.Read" -CustomResourceScope "Canadian users"

Name                      Role                 RoleAssigneeName       RoleAssigneeType        AssignmentMethod
----                      ----                 ----------------       ----------------        ----------------
Application Calendar...   Application Ca...    6233fba6-0198-...      ServicePrincipal        Direct

Exemple 2 : Configuration de Mail.Read pour toutes les boîtes aux lettres d’unité Administration d’Europe

New-ServicePrincipal -AppId eb19847b-5563-42ea-b719-ea47cb0cf4b3 -ObjectId 59b7c6cb-58d3-4ee8-a409-8c1f9dbb5d36 -DisplayName "example"

DisplayName    ObjectId                                  AppId
-----------    ---------                                  -----
example        59b7c6cb-58d3-4ee8-a409-8c1f9dbb5d36       eb19847b-5563-42ea-b719-ea47cb0cf4b3

New-ManagementRoleAssignment -App 59b7c6cb-58d3-4ee8-a409-8c1f9dbb5d36 -Role "Application Mail.Read" -RecipientAdministrativeUnitScope 4d819ce9-9257-44d7-af20-68a49e6697f4

Name                         Role                RoleAssigneeName         RoleAssigneeType             AssignmentMethod
----                         ----                ----------------          ----------------            ----------------
Application Mail.Rea...      Application Ma...   59b7c6cb-58d3-...         ServicePrincipal            Direct

Exemple 3 : Tester les autorisations affectées à un principal de service

Test-ServicePrincipalAuthorization -Resource b -Identity "DemoB" |Format-Table

RoleName                      GrantedPermissions          AllowedResourceScope        ScopeType                 InScope
--------                      ------------------          --------------------        ---------                 ------
Application Mail.Read         Mail.Read                   Scope-MESGaDN                CustomRecipientScope     False
Application Calendars.Read    Calendars.Read              Scope-DL1                    CustomRecipientScope     False
Application Contacts.Read     Contacts.Read               Scope-MESGa                  CustomRecipientScope     False

Limitations

• Les applications ne peuvent pas devenir membres d’un groupe de rôles.
• Les rôles d’application ne peuvent être attribués qu’aux principaux de service.
• Les rôles d’application ne peuvent pas être copiés ou dérivés.
• Les étendues de gestion exclusives ne limitent pas l’accès aux applications.
• Les modifications apportées aux autorisations d’application sont soumises à une maintenance du cache qui varie entre 30 minutes et 2 heures en fonction de l’utilisation récente de l’application. Lorsque vous testez des configurations, la commande test contourne ce cache. Le cache d’une application sans appel entrant aux API est réinitialisé au bout de 30 minutes. Le cache d’une application active est conservé actif pendant 2 heures maximum.

Protocoles pris en charge

• MS Graph
• EWS

Rôles d’application pris en charge

Vous remarquerez peut-être que ces rôles représentent des autorisations Microsoft Graph auxquelles vous pouvez donner votre consentement ailleurs dans la plateforme Azure Identity. Ces autorisations ont le même effet que les autorisations Graph, à l’exception de ces attributions de rôles qui permettent un accès granulaire délimité aux ressources.

FAQ

Pourquoi mon application a-t-elle toujours accès aux boîtes aux lettres qui ne sont pas accordées par l’étendue que j’ai utilisée dans Exchange Online RBAC d’application ?

Vous devez vous assurer que vous avez supprimé les autorisations non étendues organization affectées dans Microsoft Entra ID. Les autorisations affectées à l’aide du RBAC d’application agissent en plus des octrois que vous effectuez dans Microsoft Entra ID. Microsoft Entra autorisations ne peuvent être limitées qu’à l’aide de stratégies d’accès aux applications. En d’autres termes, les autorisations affectées sont une opération d’union sur les autorisations de Microsoft Entra ID et les autorisations affectées dans Exchange Online RBAC. Chaque autorité peut agir indépendamment.

Par exemple, si votre principal de service a Mail.Read accordé dans Microsoft Entra ID et que vous configurez une autorisation étendue aux ressources Mail.Read dans application RBAC, il est important de supprimer l’attribution de Mail.Read de Microsoft Entra ID. Dans le cas contraire, l’union d’une subvention non étendue Mail.Read à partir de Microsoft Entra et d’une allocation d’étendue Mail.Read de ressources dans application RBAC n’entraîne aucune étendue de ressource efficace.

Comment puis-je afficher et modifier toutes les autorisations d’application dans une seule interface ?

Pour garantir que les administrateurs disposent d’une vue consolidée des autorisations d’application, nous mettons en évidence ces autorisations accordées dans Exchange Online dans une expérience d’administration Microsoft Entra. Cette fonctionnalité est à venir, restez à l’écoute.

Comment migrer des stratégies d’accès aux applications vers RBAC pour les applications ?

Avec les stratégies d’accès aux applications, vous disposez d’un principal de service, d’un consentement d’autorisations dans Azure et d’une stratégie associée à un principal de service dans Exchange Online. Bien que vous puissiez restructurer votre mécanisme d’étendue à l’aide d’étendues de gestion Exchange ou d’unités administratives, voici quelques conseils sur la réutilisation des groupes dans une stratégie d’accès aux applications comme étendue pour votre octroi RBAC pour applications. Ce processus n’entraîne aucune interruption de l’utilisation de votre application.

Étapes de migration :

1. Créez une nouvelle étendue de gestion, qui pointe vers le groupe d’étendue de la stratégie d’accès aux applications.

2. Créez l’objet pointeur de principal de service.

3. Attribuez les autorisations nécessaires au principal de service dans Exchange Online avec la restriction d’étendue de gestion.

4. Supprimez le consentement à l’autorisation dans Azure.

5. Supprimez la stratégie d’accès aux applications.

   Lors de la création de l’étendue de gestion à l’étape 1, vous utilisez un filtre de destinataires avec le paramètre MemberOfGroupde filtre . Voici un exemple :

   "MemberOfGroup -eq 'CN=mesga20220818210551,OU=Fabrikam346.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=NAMPR00A001,DC=prod,DC=outlook,DC=com'"

Limitations:

• Les membres du groupe imbriqué sont considérés comme hors de portée. Seule l’appartenance directe au groupe entraîne la prise en compte du membre dans l’étendue de l’autorisation.
• Groupes Microsoft 365, les groupes de sécurité Mail-Enabled et les listes de distribution sont pris en charge.

Comment le RBAC pour les applications fonctionne-t-il avec les stratégies d’accès aux applications ?

Compatibilité avec la stratégie d’accès aux applications :

RBAC pour applications remplace les stratégies d’accès aux applications.

L’interopérabilité d’autorisation peut être décrite comme suit :

• Les stratégies d’accès aux applications limitent UNIQUEMENT les autorisations affectées dans Microsoft Entra ID.

• RBAC pour applications offre une autre expression d’autorisation avec une étendue de ressource associée.

• Une application peut avoir à la fois des autorisations Microsoft Entra consentées et des affectations RBAC. Nous nous attendons à ce cas lorsqu’une application a (par exemple) organization-wide Mail.Read and scoped Mail.Send.

• Les consentements d’autorisation sont additifs.

Exemple 1 : consent à partir de 2 systèmes :

• Une application a Mail.Read dans Microsoft Entra ID.
• Cette application est limitée au groupe de sécurité à extension messagerie 1 à l’aide d’une stratégie d’accès aux applications.
• La même application a Calendar.Read donné son consentement pour l’étendue de gestion 1 dans RBAC pour les applications.
• La boîte aux lettres A se trouve dans le groupe de sécurité à extension messagerie 1.
• La boîte aux lettres B est comprise dans l’étendue de gestion 1.

Accès MS Graph à un point de terminaison nécessitant à la fois Mail.Read et Calendar.Read pour l’application 1 :

• Le ciblage de la boîte aux lettres A : échoue.
• Le ciblage de la boîte aux lettres B : échoue.

Ce point de terminaison a besoin à la fois Mail.Read de et Calendar.Readde . Bien que l’application dispose de ces autorisations individuellement sur deux boîtes aux lettres distinctes, elle n’a pas les deux autorisations sur une boîte aux lettres.

Exemple 2 : attribution de la même autorisation à deux reprises :

• Une application a Mail.Read dans Microsoft Entra ID.
• Cette application est limitée au groupe de sécurité à extension messagerie 1 à l’aide d’une stratégie d’accès aux applications.
• La même application a Mail.Read donné son consentement pour l’étendue de gestion 1 à l’aide du contrôle d’accès en fonction du rôle pour les applications.
• La boîte aux lettres A se trouve dans le groupe de sécurité à extension messagerie 1.
• L’étendue de gestion 1 autorise l’accès à toutes les boîtes aux lettres, à l’exception de la boîte aux lettres A (selon un filtre tel que Alias -ne mbxa).

Accès MS Graph à un point de terminaison nécessitant Mail.Read pour l’application 1 :

• Ciblage de la boîte aux lettres A : autoriser.
• Ciblage de la boîte aux lettres B : autoriser.

Alors que le Mail.Read de Microsoft Entra autorise uniquement l’accès à la boîte aux lettres A, l’affectation RBAC autorise l’accès à tout, sauf À. En effet, cette affectation permet d’accéder à tout, car « A » et « Not A » signifie tout.

Bien que nous ayons décrit ces cas de périphérie pour l’exhaustivité, nous ne nous attendons pas à ce que les stratégies d’accès aux applications soient généralement utilisées avec RBAC pour les applications. Les autorisations à l’échelle de l’organisation doivent être affectées dans Microsoft Entra ID tandis que les autorisations étendues aux ressources doivent être accordées à l’aide du contrôle d’accès en fonction du rôle pour les applications.

Combien d’applications sont prises en charge par RBAC pour applications ?

Vous pouvez avoir jusqu’à 10 000 applications par organization à l’aide de RBAC pour les applications. Faites-nous savoir si cette limite vous pose problème. Nous avons créé RBAC pour applications d’une manière hautement évolutive pour répondre aux besoins de nos plus grands clients.

Pourquoi la découverte automatique ne fonctionne-t-elle pas ?

Actuellement, le service de découverte automatique n’est pas accessible lorsque vous utilisez des rôles d’application RBAC.

Si je supprime un principal de service dans Microsoft Entra que se passe-t-il dans Exchange ?

Les principaux de service supprimés dans Microsoft Entra sont également supprimés automatiquement dans Exchange. Cette suppression supprime toutes les affectations effectuées à ces principaux de service, mais n’affecte pas les étendues de gestion.

Commentaires sur cette fonctionnalité

Les commentaires sur cette fonctionnalité peuvent être partagés avec exoapprbacpreview@microsoft.com.