Authentification d’application uniquement pour les scripts sans assistance dans Exchange Online PowerShell et Sécurité & Conformité PowerShell
Les scénarios d'audit et de création de rapports dans Microsoft 365 impliquent souvent des scripts sans assistance dans Exchange Online PowerShell et Security & Compliance PowerShell. Dans le passé, la connexion sans surveillance nécessitait de stocker le nom d’utilisateur et le mot de passe dans un fichier local ou dans un coffre secret accessible au moment de l'exécution. Toutefois, comme nous le savons tous, le stockage local des informations d’identification de l’utilisateur n’est pas une bonne pratique de sécurité.
L’authentification basée sur les certificats (CBA) ou l’authentification d’application uniquement, comme décrit dans cet article, prend en charge les scénarios de script et d’automatisation sans assistance à l’aide d’applications Microsoft Entra et de certificats auto-signés.
Remarque
Saviez-vous que vous pouvez vous connecter à Exchange Online PowerShell à l’aide d’identités managées dans Azure ? Consultez Utiliser des identités managées Azure pour vous connecter à Exchange Online PowerShell.
Les fonctionnalités et procédures décrites dans cet article nécessitent les versions suivantes du module Exchange Online PowerShell :
- Exchange Online PowerShell (Connect-ExchangeOnline) : version 2.0.3 ou ultérieure.
- Sécurité & Conformité PowerShell (Connect-IPPSSession) : version 3.0.0 ou ultérieure.
Pour obtenir des instructions sur l’installation ou la mise à jour du module, consultez Installer et gérer le module Exchange Online PowerShell. Pour obtenir des instructions sur l’utilisation du module dans Azure Automation, consultez Gérer les modules dans Azure Automation.
Les connexions d’API REST dans le module Exchange Online PowerShell V3 nécessitent les modules PowerShellGet et PackageManagement. Pour plus d’informations, consultez PowerShellObtenir des connexions REST dans Windows.
Si les procédures décrites dans cet article ne fonctionnent pas pour vous, vérifiez que les versions bêta des modules PackageManagement ou PowerShellGet ne sont pas installées en exécutant la commande suivante :
Get-InstalledModule PackageManagement -AllVersions; Get-InstalledModule PowerShellGet -AllVersions.Dans Exchange Online PowerShell, vous ne pouvez pas utiliser les procédures décrites dans cet article avec les applets de commande Microsoft 365 Group suivantes :
Vous pouvez utiliser Microsoft Graph pour remplacer la plupart des fonctionnalités de ces applets de commande. Pour plus d’informations, consultez Utilisation de groupes dans Microsoft Graph.
Dans Security & Compliance PowerShell, vous ne pouvez pas utiliser les procédures décrites dans cet article avec les applets de commande microsoft 365 Group suivantes :
Les scénarios délégués sont pris en charge dans Exchange Online. La méthode recommandée pour la connexion avec la délégation consiste à utiliser GDAP et le consentement de l’application. Pour plus d’informations, consultez Utiliser le module Exchange Online PowerShell v3 avec GDAP et le consentement de l’application. Vous pouvez également utiliser des applications mutualisées lorsque les relations CSP ne sont pas créées avec le client. Les étapes requises pour l’utilisation d’applications multilocataires sont décrites dans les instructions régulières de cet article.
Utilisez le commutateur SkipLoadingFormatData sur l’applet de commande Connect-ExchangeOnline si vous obtenez l’erreur suivante lors de l’utilisation du Kit de développement logiciel (SDK) Windows PowerShell pour vous connecter :
The term 'Update-ModuleManifest' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Comment cela fonctionne-t-il ?
Le module Exchange Online PowerShell utilise la bibliothèque d’authentification Active Directory pour extraire un jeton d’application uniquement à l’aide de l’ID d’application, de l’ID de locataire (organisation) et de l’empreinte numérique du certificat. Un rôle d’annuaire est attribué à l’objet d’application approvisionné à l’intérieur de l’ID Microsoft Entra, qui est retourné dans le jeton d’accès. Le contrôle d'accès basé sur les rôles (RBAC) de la session est configuré à l'aide des informations sur les rôles de l'annuaire qui sont disponibles dans le jeton.
Exemples de connexion
Les exemples suivants montrent comment utiliser le module Exchange Online PowerShell avec l’authentification d’application uniquement :
Importante
Dans les commandes de connexion suivantes, utilisez le domaine principal .onmicrosoft.com de votre organisation comme valeur du paramètre Organization .
Les commandes de connexion suivantes ont la plupart des mêmes options disponibles que celles décrites dans Se connecter à Exchange Online PowerShell et Se connecter à Sécurité & Conformité PowerShell. Par exemple :
Les environnements Microsoft 365 GCC High ou Microsoft 365 DoD nécessitent les paramètres et valeurs supplémentaires suivants :
- Connect-ExchangeOnline dans GCC High :
-ExchangeEnvironmentName O365USGovGCCHigh. - Connect-IPPSSession dans GCC High :
-ConnectionUri https://ps.compliance.protection.office365.us/powershell-liveid/ -AzureADAuthorizationEndpointUri https://login.microsoftonline.us/common. - Connect-ExchangeOnline dans DoD :
-ExchangeEnvironmentName O365USGovDoD. - Connect-IPPSSession dans DoD :
-ConnectionUri https://l5.ps.compliance.protection.office365.us/powershell-liveid/ -AzureADAuthorizationEndpointUri https://login.microsoftonline.us/common.
- Connect-ExchangeOnline dans GCC High :
Si une commande Connect-IPPSSession présente une invite de connexion, exécutez la commande :
$Global:IsWindows = $trueavant la commande Connect-IPPSSession .
Se connecter à l’aide d’une empreinte numérique de certificat :
Remarque
Le paramètre CertificateThumbprint est pris en charge uniquement dans Microsoft Windows.
Le certificat doit être installé sur l’ordinateur sur lequel vous exécutez la commande. Le certificat doit être installé dans le magasin de certificats de l’utilisateur.
Exchange Online PowerShell :
Connect-ExchangeOnline -CertificateThumbPrint "012THISISADEMOTHUMBPRINT" -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"Centre de sécurité et de conformité PowerShell :
Connect-IPPSSession -CertificateThumbPrint "012THISISADEMOTHUMBPRINT" -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"
Se connecter à l’aide d’un objet de certificat :
Le certificat n’a pas besoin d’être installé sur l’ordinateur sur lequel vous exécutez la commande. Vous pouvez stocker l’objet de certificat à distance. Le certificat est extrait lors de l’exécution du script.
Exchange Online PowerShell :
Connect-ExchangeOnline -Certificate <%X509Certificate2 Object%> -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"Centre de sécurité et de conformité PowerShell :
Connect-IPPSSession -Certificate <%X509Certificate2 Object%> -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"
Connectez-vous à l’aide d’un certificat local :
Remarque
L’utilisation d’une commande ConvertTo-SecureString pour stocker le mot de passe du certificat localement est contraire à l’objectif d’une méthode de connexion sécurisée pour les scénarios d’automatisation. L’utilisation d’une commande Get-Credential pour vous demander le mot de passe du certificat en toute sécurité n’est pas idéale pour les scénarios d’automatisation. En d’autres termes, il n’existe aucun moyen automatisé et sécurisé de se connecter à l’aide d’un certificat local.
Exchange Online PowerShell :
Connect-ExchangeOnline -CertificateFilePath "C:\Users\navin\Desktop\automation-cert.pfx" -CertificatePassword (Get-Credential).password -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"Centre de sécurité et de conformité PowerShell :
Connect-IPPSSession -CertificateFilePath "C:\Users\navin\Desktop\automation-cert.pfx" -CertificatePassword (Get-Credential).password -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"
Configurer l’authentification d’application uniquement
Un premier embarquement est nécessaire pour l'authentification à l'aide d'objets d'application. Les termes« application » et « principal de service » sont utilisés de manière interchangeable, mais une application est comme un objet de classe tandis qu'un principal de service est comme une instance de la classe. Pour plus d’informations, consultez Objets d’application et de principal de service dans l’ID Microsoft Entra.
Pour obtenir un flux visuel détaillé sur la création d’applications dans l’ID Microsoft Entra, consultez https://aka.ms/azuread-app.
Attribuer des autorisations d'API à l'application.
Un objet d’application a l’autorisation API déléguéeMicrosoft Graph>User.Read par défaut. Pour que l’objet d’application accède aux ressources dans Exchange, il a besoin de l’autorisation API d’application Office 365 Exchange Online>Exchange.ManageAsApp.
Générer un certificat auto-signé
Pour l’authentification d’application uniquement dans l’ID Microsoft Entra, vous utilisez généralement un certificat pour demander l’accès. Toute personne disposant du certificat et de sa clé privée peut utiliser l’application avec les autorisations accordées à l’application.
Créez et configurez un certificat X.509 auto-signé, qui est utilisé pour authentifier votre application auprès de l’ID Microsoft Entra, tout en demandant le jeton d’accès d’application uniquement.
Cette procédure est similaire à la génération d’un mot de passe pour les comptes d’utilisateur. Le certificat peut également être auto-signé. Consultez cette section plus loin dans cet article pour obtenir des instructions sur la génération de certificats dans PowerShell.
Remarque
Chiffrement : les certificats CNG (Next Generation) ne sont pas pris en charge pour l’authentification d’application uniquement avec Exchange. Les certificats CNG sont créés par défaut dans les versions modernes de Windows. Vous devez utiliser un certificat d'un fournisseur de clés CSP. Cette section couvre deux méthodes prises en charge pour créer un certificat CSP.
Attribuer des rôles Microsoft Entra à l’application
Les rôles RBAC appropriés doivent être attribués à l’application. Étant donné que les applications sont approvisionnées dans l’ID Microsoft Entra, vous pouvez utiliser l’un des rôles intégrés pris en charge.
Étape 1 : Inscrire l’application dans l’ID Microsoft Entra
Remarque
Si vous rencontrez des problèmes, consultez les permissions requises pour vérifier que votre compte peut créer l’identité.
Ouvrez le Centre d’administration Microsoft Entra à l’adresse https://portal.azure.com/.
Dans la zone Rechercher en haut de la page, commencez à taper Inscriptions d’applications, puis sélectionnez Inscriptions d’applications dans les résultats de la section Services .
Ou, pour accéder directement à la page Inscriptions d’applications , utilisez https://portal.azure.com/#view/Microsoft_AAD_RegisteredApps/ApplicationsListBlade.
Sur la page Inscriptions d’applications, sélectionnez Nouvelle inscription.
Dans la page Enregistrer une application qui s'ouvre, configurez les paramètres suivants :
Nom: entrez une description. Par exemple, ExO PowerShell CBA.
Types de comptes pris en charge : vérifiez que l’option Comptes de cet annuaire organisationnel uniquement (<YourOrganizationName> uniquement - Locataire unique) est sélectionnée.
Remarque
Pour rendre l’application multilocataire pour les scénarios délégués Exchange Online, sélectionnez la valeur Comptes dans n’importe quel annuaire organisationnel (n’importe quel annuaire Microsoft Entra - Multilocataire).
URI de redirection (facultatif) : ce paramètre est facultatif. Si vous devez l’utiliser, configurez les paramètres suivants :
- Plateforme : sélectionnez Web.
- URI : entrez l’URI où le jeton d’accès est envoyé.
Remarque
Vous ne pouvez pas créer d’informations d’identification pour les applications natives, car vous ne pouvez pas utiliser d’applications natives pour les applications automatisées.
Lorsque vous avez terminé d’accéder à la page Inscriptions d’applications , sélectionnez Inscrire.
Vous accédez à la page Vue d’ensemble de l’application que vous venez d’inscrire. Laissez cette page ouverte. Vous en aurez besoin à l'étape suivante.
Étape 2 : Attribuer des autorisations API à l’application
Choisissez l’une des méthodes suivantes dans cette section pour attribuer des autorisations d’API à l’application :
- Sélectionnez et attribuez les autorisations d’API à partir du portail.
- Modifiez le manifeste de l’application pour attribuer des autorisations d’API. (Les organisations Microsoft 365 GCC High et DoD doivent utiliser cette méthode)
Sélectionner et attribuer les autorisations d’API à partir du portail
Dans la page Vue d’ensemble de l’application, sélectionnez Autorisations d’API dans la section Gérer .
Dans la page Autorisations de l’API de l’application, sélectionnez Ajouter une autorisation.
Dans le menu volant Demander des autorisations d’API qui s’ouvre, sélectionnez l’onglet API que mon organisation utilise , commencez à taper Office 365 Exchange Online dans la zone de recherche , puis sélectionnez-le dans les résultats.
Dans le menu volant De quel type d’autorisations votre application a-t-elle besoin ? qui s’affiche, sélectionnez Autorisations d’application.
Dans la liste des autorisations qui s’affiche, développez Exchange, sélectionnez Exchange.ManageAsApp, puis ajouter des autorisations.
De retour dans la page Autorisations de l’API de l’application, vérifiez qu’Office 365 Exchange Online>Exchange.ManageAsApp est répertorié et contient les valeurs suivantes :
Type : Application.
Consentement de l’administrateur requis : Oui.
État : la valeur incorrecte actuelle n’est pas accordée pour l’organisation<>.
Modifiez cette valeur en sélectionnant Accorder le consentement administrateur pour <Organisation>, en lisant la boîte de dialogue de confirmation qui s’ouvre, puis en sélectionnant Oui.
La valeur État est désormais Accordée pour l’organisation<>.
Pour l’entréeUser.Readde Microsoft Graph> par défaut, sélectionnez ...>Révoquez le consentement de l’administrateur, puis sélectionnez Oui dans la boîte de dialogue de confirmation qui s’ouvre pour revenir à la valeur vide par défaut de Status.
Fermez la page Autorisations d’API (et non l’onglet du navigateur) pour revenir à la page Inscriptions des applications. Vous utilisez la page Inscriptions d’applications dans une étape à venir.
Modifier le manifeste de l’application pour attribuer des autorisations d’API
Remarque
Les procédures de cette section ajoutent les autorisations par défaut existantes sur l’application (autorisations déléguées User.Read dans Microsoft Graph) avec les autorisations d’application Exchange.ManageAsApp requises dans Office 365 Exchange Online.
Dans la page Vue d’ensemble de l’application, sélectionnez Manifeste dans la section Gérer .
Dans la page Manifeste de l’application, recherchez l’entrée
requiredResourceAccess(à environ la ligne 42) et faites en sorte que l’entrée ressemble à l’extrait de code suivant :"requiredResourceAccess": [ { "resourceAppId": "00000002-0000-0ff1-ce00-000000000000", "resourceAccess": [ { "id": "dc50a0fb-09a3-484d-be87-e023b12c6440", "type": "Role" } ] }, { "resourceAppId": "00000003-0000-0000-c000-000000000000", "resourceAccess": [ { "id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d", "type": "Scope" } ] } ],Remarque
Les environnements Microsoft 365 GCC High ou DoD ont uniquement accès à PowerShell sécurité & conformité. Utilisez les valeurs suivantes pour l’entrée
requiredResourceAccess:"requiredResourceAccess": [ { "resourceAppId": "00000007-0000-0ff1-ce00-000000000000", "resourceAccess": [ { "id": "455e5cd2-84e8-4751-8344-5672145dfa17", "type": "Role" } ] }, { "resourceAppId": "00000003-0000-0000-c000-000000000000", "resourceAccess": [ { "id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d", "type": "Scope" } ] } ],Lorsque vous avez terminé d’accéder à la page Manifeste , sélectionnez Enregistrer.
Toujours dans la page Manifeste , sélectionnez Autorisations d’API dans la section Gérer .
Dans la page Autorisations de l’API , vérifiez qu’Office 365 Exchange Online>Exchange.ManageAsApp est répertorié et contient les valeurs suivantes :
Type : Application.
Consentement de l’administrateur requis : Oui.
État : la valeur actuelle incorrecte n’est pas accordée pour <l’organisation> pour l’entréeExchange.ManageAsAppd’Office 365 Exchange Online>.
Modifiez la valeur État en sélectionnant Accorder le consentement administrateur pour <l’organisation>, en lisant la boîte de dialogue de confirmation qui s’ouvre, puis en sélectionnant Oui.
La valeur État est désormais Accordée pour l’organisation<>.
Pour l’entréeUser.Readde Microsoft Graph> par défaut, sélectionnez ...>Révoquez le consentement de l’administrateur, puis sélectionnez Oui dans la boîte de dialogue de confirmation qui s’ouvre pour revenir à la valeur vide par défaut de Status.
Fermez la page Autorisations d’API (et non l’onglet du navigateur) pour revenir à la page Inscriptions des applications. Vous utilisez la page Inscriptions d’applications dans une étape à venir.
Étape 3 : générer un certificat auto-signé
Créez un certificat x.509 auto-signé à l’aide de l’une des méthodes suivantes :
(Recommandé) Utilisez les cmdlets New-SelfSignedCertificate, Export-Certificate et Export-DessusxCertificate dans une session Windows PowerShell avec élévation (exécuté en tant qu’administrateur) pour demander un certificat auto-signé et l’exporter vers
.ceret.pfx(SHA1 par défaut). Par exemple :# Create certificate $mycert = New-SelfSignedCertificate -DnsName "contoso.org" -CertStoreLocation "cert:\CurrentUser\My" -NotAfter (Get-Date).AddYears(1) -KeySpec KeyExchange # Export certificate to .pfx file $mycert | Export-PfxCertificate -FilePath mycert.pfx -Password (Get-Credential).password # Export certificate to .cer file $mycert | Export-Certificate -FilePath mycert.cerUtilisez le script Create-SelfSignedCertificate script. génère des certificats SHA1.
.\Create-SelfSignedCertificate.ps1 -CommonName "MyCompanyName" -StartDate 2021-01-06 -EndDate 2022-01-06
Étape 4 : Attacher le certificat à l’application Microsoft Entra
Une fois que vous avez enregistré le certificat auprès de votre application, vous pouvez utiliser la clé privée (fichier .pfx) ou l’empreinte numérique pour l’authentification.
Sous l’onglet Applications détenues de la page Inscription des applications à la fin de l’étape 2, sélectionnez votre application.
Si vous devez revenir à la page d’inscription des applications , utilisez https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/RegisteredApps, vérifiez que l’onglet Applications détenues est sélectionné, puis sélectionnez votre application.
Dans la page de l’application qui s’ouvre, sélectionnez Certificats & secrets dans la section Gérer .
Dans la page Certificats & secrets , sélectionnez Charger le certificat.
Dans la boîte de dialogue qui s’ouvre, accédez au certificat auto-signé (fichier
.cer) que vous avez créé à l’Étape 3.
Lorsque vous avez terminé, sélectionnez Ajouter.
Le certificat est désormais affiché dans la section Certificats.
Fermez la page actuelle Certificats et secrets , puis la page Inscriptions des applications pour revenir à la page principale https://portal.azure.com/ . Vous en aurez besoin à l'étape suivante.
Étape 4b : Scénarios délégués Exchange Online uniquement : Accorder le consentement administrateur pour l’application multilocataire
Si vous avez rendu l’application multilocataire pour les scénarios délégués Exchange Online à l’étape 1, vous devez accorder le consentement administrateur à l’autorisation Exchange.ManageAsApp afin que l’application puisse exécuter des applets de commande dans Exchange Online dans chaque organisation cliente. Pour ce faire, générez une URL de consentement administrateur pour chaque locataire client. Avant que quiconque utilise l’application multilocataire pour se connecter à Exchange Online dans l’organisation cliente, un administrateur du locataire client doit ouvrir l’URL suivante :
https://login.microsoftonline.com/<tenant-id>/adminconsent?client_id=<client-id>&scope=https://outlook.office365.com/.default
<tenant-id>est l’ID de locataire du client.<client-id>est l’ID de l’application multilocataire.- L’étendue par défaut est utilisée pour accorder des autorisations d’application.
Pour plus d’informations sur la syntaxe d’URL, consultez Demander les autorisations à un administrateur d’annuaire.
Étape 5 : Attribuer des rôles Microsoft Entra à l’application
Vous disposez de deux options :
- Attribuer des rôles Microsoft Entra à l’application
- Attribuer des groupes de rôles personnalisés à l’application à l’aide de principaux de service : cette méthode est prise en charge uniquement lorsque vous vous connectez à Exchange Online PowerShell ou à Security & Compliance PowerShell en mode API REST. Sécurité & Conformité PowerShell prend en charge le mode API REST dans la version 3.2.0 ou ultérieure.
Remarque
Vous pouvez également combiner les deux méthodes pour attribuer des autorisations. Par exemple, vous pouvez utiliser des rôles Microsoft Entra pour le rôle « Administrateur de destinataire Exchange » et également attribuer votre rôle RBAC personnalisé pour étendre les autorisations.
Pour les applications mutualisées dans les scénarios délégués Exchange Online , vous devez attribuer des autorisations dans chaque locataire client.
Attribuer des rôles Microsoft Entra à l’application
Les rôles Microsoft Entra pris en charge sont décrits dans le tableau suivant :
| Role | Exchange Online PowerShell |
Sécurité et conformité PowerShell |
|---|---|---|
| Administrateur de conformité | ✔ | ✔ |
| Administrateur Exchange¹ | ✔ | |
| Administrateur des destinataires Exchange | ✔ | |
| Administrateur général¹ ² | ✔ | ✔ |
| Lecteur global | ✔ | ✔ |
| Administrateur du support technique | ✔ | |
| Administrateur de la sécurité¹ | ✔ | ✔ |
| Lecteur de sécurité | ✔ | ✔ |
¹ Les rôles Administrateur général et Administrateur Exchange fournissent les autorisations requises pour toute tâche dans Exchange Online PowerShell. Par exemple :
- Gestion des destinataires.
- Fonctionnalités de sécurité et de protection. Par exemple, anti-courrier indésirable, anti-programme malveillant, anti-hameçonnage et rapports associés.
Le rôle Administrateur de la sécurité ne dispose pas des autorisations nécessaires pour ces mêmes tâches.
² Microsoft vous recommande d’utiliser des rôles avec le moins d’autorisations. L’utilisation de comptes avec autorisation inférieure permet d’améliorer la sécurité de votre organisation. Administrateur général est un rôle hautement privilégié qui doit être limité aux scénarios d’urgence lorsque vous ne pouvez pas utiliser un rôle existant.
Pour obtenir des instructions générales sur l’attribution de rôles dans l’ID Microsoft Entra, consultez Attribuer des rôles Microsoft Entra aux utilisateurs.
Remarque
Les étapes suivantes sont légèrement différentes pour Exchange Online PowerShell et Security & Compliance PowerShell. Les étapes pour les deux environnements sont indiquées. Pour configurer des rôles pour les deux environnements, répétez les étapes de cette section.
Dans le Centre d’administration Microsoft Entra à l’adresse , commencez à https://portal.azure.com/taper des rôles et des administrateurs dans la zone de recherche en haut de la page, puis sélectionnez Rôles et administrateurs Microsoft Entra dans les résultats de la section Services .
Ou, pour accéder directement à la page des rôles et administrateurs Microsoft Entra , utilisez https://portal.azure.com/#view/Microsoft_AAD_IAM/AllRolesBlade.
Dans la page Rôles et administrateurs qui s’ouvre, recherchez et sélectionnez un des rôles pris en charge en cliquant sur le nom du rôle (et non sur la case à cocher) dans les résultats.
Exchange Online PowerShell : par exemple, recherchez et sélectionnez le rôle Administrateur Exchange .
Sécurité & Conformité PowerShell : par exemple, recherchez et sélectionnez le rôle Administrateur de conformité .
Dans la page Affectations qui s’ouvre, sélectionnez Ajouter des affectations.
Exchange Online PowerShell :
Centre de sécurité et de conformité PowerShell :
Dans le menu volant Ajouter des affectations qui s’ouvre, recherchez et sélectionnez l’application que vous avez créée à l’Étape 1.
Lorsque vous avez terminé dans le menu volant Ajouter des affectations , sélectionnez Ajouter.
De retour dans la page Affectations , vérifiez que le rôle a été attribué à l’application.
Exchange Online PowerShell :
Centre de sécurité et de conformité PowerShell :
Attribuer des groupes de rôles personnalisés à l’application à l’aide de principaux de service
Remarque
Vous devez vous connecter à Exchange Online PowerShell ou à Security & Compliance PowerShell avant d’effectuer les étapes de création d’un principal de service. La création d’un principal de service sans connexion à PowerShell ne fonctionne pas (votre ID d’application Azure et votre ID d’objet sont nécessaires pour créer le nouveau principal de service).
Cette méthode est prise en charge uniquement lorsque vous vous connectez à Exchange Online PowerShell ou à Security & Compliance PowerShell en mode API REST. Sécurité & Conformité PowerShell prend en charge le mode API REST dans la version 3.2.0 ou ultérieure.
Pour plus d’informations sur la création de groupes de rôles personnalisés, consultez Créer des groupes de rôles dans Exchange Online et Créer un e-mail & des groupes de rôles de collaboration dans le portail Microsoft Defender. Le groupe de rôles personnalisé que vous attribuez à l’application peut contenir n’importe quelle combinaison de rôles intégrés et personnalisés.
Pour affecter des groupes de rôles personnalisés à l’application à l’aide de principaux de service, procédez comme suit :
Dans Microsoft Graph PowerShell, exécutez les commandes suivantes pour stocker les détails de l’application Microsoft Entra que vous avez inscrite à l’étape 1 dans une variable :
Connect-MgGraph -Scopes AppRoleAssignment.ReadWrite.All,Application.Read.All $<VariableName1> = Get-MgServicePrincipal -Filter "DisplayName eq '<AppName>'"Par exemple :
Connect-MgGraph -Scopes AppRoleAssignment.ReadWrite.All,Application.Read.All $AzureADApp = Get-MgServicePrincipal -Filter "DisplayName eq 'ExO PowerShell CBA'"Pour obtenir des informations détaillées sur la syntaxe et les paramètres, consultez Get-MgServicePrincipal.
Dans la même fenêtre PowerShell, connectez-vous à Exchange Online PowerShell ou Security & Compliance PowerShell et exécutez les commandes suivantes pour :
- Créez un objet de principal de service pour l’application Microsoft Entra.
- Stockez les détails du principal de service dans une variable à utiliser à l’étape suivante.
New-ServicePrincipal -AppId $<VariableName1>.AppId -ObjectId $<VariableName1>.Id -DisplayName "<Descriptive Name>" $<VariableName2> = Get-ServicePrincipal -Identity "<Descriptive Name>"Par exemple :
New-ServicePrincipal -AppId $AzureADApp.AppId -ObjectId $AzureADApp.Id -DisplayName "SP for Azure AD App ExO PowerShell CBA" $SP = Get-ServicePrincipal -Identity "SP for Azure AD App ExO PowerShell CBA"Pour obtenir des informations détaillées sur la syntaxe et les paramètres, consultez New-ServicePrincipal.
Dans Exchange Online PowerShell ou Security & Compliance PowerShell, exécutez la commande suivante pour ajouter le principal de service en tant que membre du groupe de rôles personnalisé :
Add-RoleGroupMember -Identity "<CustomRoleGroupName>" -Member <$<VariableName2>.Identity | $<VariableName2>.ObjectId | $<VariableName2>.Id>Par exemple :
Add-RoleGroupMember -Identity "Contoso View-Only Recipients" -Member $SP.IdentityPour obtenir des informations détaillées sur la syntaxe et les paramètres, voir Add-RoleGroupMember.
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour