Authentification par application uniquement pour les scripts sans assistance dans Exchange Online PowerShell et PowerShell de conformité & sécurité

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. Auparavant, la connexion sans assistance nécessitait le stockage du nom d’utilisateur et du mot de passe dans un fichier local ou dans un coffre-fort secret auquel vous accédiez au moment de l’exécution. Mais, comme nous le savons tous, le stockage local des informations d’identification des utilisateurs n’est pas une bonne pratique de sécurité.

L’authentification basée sur les certificats (CBA) ou l’authentification basée sur l’application uniquement, comme décrit dans cet article, prend en charge les scénarios de script et d’automatisation sans assistance à l’aide des applications et certificats Microsoft Entra.

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.4 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 l’article Installer et mettre à jour le module Exchange Online PowerShell. Pour obtenir des instructions sur l’utilisation du module dans Azure Automation, voir Gérer les modules dans Azure Automation.
L’authentification CBA ou l’authentification basée uniquement sur l’application est disponible dans Office 365 géré par 21Vianet en Chine.
Les connexions d’API REST dans le module Exchange Online PowerShell V3 nécessitent les modules PowerShellGet et PackageManagement. Pour plus d’informations, consultez PowerShellGet pour les connexions REST dans Windows.
Si les procédures décrites dans cet article ne fonctionnent pas pour vous, vérifiez que vous n’avez pas de préversion des modules PackageManagement ou PowerShellGet installés 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 des groupes dans Microsoft Graph.
Pour exécuter les applets de commande eDiscovery avec authentification à l’application uniquement dans le PowerShell de conformité de la sécurité &, utilisez ExchangeOnlineManagement 3.10.1 ou version ultérieure, incluez le commutateur EnableSearchOnlySession lorsque vous exécutez Connect-IPPSSession, puis configurez le principal de service et le contrôle d’accès basé sur un rôle (RBAC) eDiscovery. Pour plus d’informations, voir Configurer l’authentification d’application uniquement pour eDiscovery PowerShell.
Les scénarios délégué sont pris en charge dans Exchange Online. La méthode recommandée pour se connecter à la délégation consiste à utiliser GDAP et le consentement de l’application. Pour plus d’informations, voir 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 des applications mutualisées 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 le message d’erreur suivant 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 PowerShell d’Exchange Online utilise la bibliothèque d’authentification Active Directory pour récupérer un jeton d’application uniquement à l’aide de l’ID d’application, de l’ID de locataire (organisation) et de l’empreinte du certificat. Un rôle d’annuaire est attribué à l’objet d’application provisionné dans Microsoft Entra ID, qui est renvoyé 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 PowerShell d’Exchange Online 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 offrent bon nombre des options décrites dans Se connecter à Exchange Online PowerShell et Se connecter à & sécurité Conformité PowerShell. Par exemple :

Les environnements Microsoft 365 GCC High, Microsoft 365 DoD ou Microsoft 365 Chine (géré par 21Vianet) nécessitent les paramètres et valeurs supplémentaires suivants :
Microsoft 365 GCC High
- Connect-ExchangeOnline -ExchangeEnvironmentName O365USGovGCCHigh
- Connect-IPPSSession -ConnectionUri https://ps.compliance.protection.office365.us/powershell-liveid/ -AzureADAuthorizationEndpointUri https://login.microsoftonline.us/organizations^*
Microsoft 365 DoD
- Connect-ExchangeOnline -ExchangeEnvironmentName O365USGovDoD
- Connect-IPPSSession -ConnectionUri https://compliance.dod.microsoft.com/powershell-liveid -AzureADAuthorizationEndpointUri https://login.microsoftonline.us/organizations^*
Microsoft 365 géré par 21Vianet (Chine)
- Connect-ExchangeOnline -ExchangeEnvironmentName O365China
- Connect-IPPSSession -ConnectionUri https://ps.compliance.protection.partner.outlook.cn/powershell-liveid -AzureADAuthorizationEndpointUri https://login.chinacloudapi.cn/organizations^*
^* La valeur AzureADAuthorizationEndpointUri se terminant par /organizations autorise uniquement les comptes professionnels ou scolaires. L’ancienne valeur URI se terminant par /common fonctionne toujours, mais peut vous inviter à choisir entre un compte personnel et un compte professionnel ou scolaire. Nous recommandons la valeur d’URI dans les scénarios d’entreprise où les /organizations comptes de consommateurs doivent être exclus.
Si une commande Connect-IPPSSession présente une invite de connexion, exécutez la commande : $Global:IsWindows = $true avant la commande Connect-IPPSSession .
Pour exécuter les applets de commande eDiscovery, utilisez ExchangeOnlineManagement 3.10.1 ou version ultérieure et ajoutez le commutateur EnableSearchOnlySession à la commande Connect-IPPSSession .

Se connecter à l’aide d’une empreinte 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 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"
```
Se connecter à l’aide d’un certificat local :

Remarque

L’utilisation d’une commande ConvertTo-SecureString pour stocker localement le mot de passe du certificat va à l’encontre de 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 vraiment 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 Principaux objets d’application et de service dans Microsoft Entra ID.

Pour un flux visuel détaillé sur la création d’applications dans Microsoft Entra ID, consultez https://aka.ms/azuread-app.

Inscrivez l’application dans Microsoft Entra ID.
Attribuer des autorisations d'API à l'application.

Un objet d’application dispose de l’autorisation d’API déléguéeMicrosoft Graph>User.Read par défaut. Ajoutez l’autorisation d’application qui correspond à la connexion PowerShell :
- Exchange Online PowerShell (Connect-ExchangeOnline) : Office 365 Exchange Online>Exchange.ManageAsApp.
- Sécurité & conformité PowerShell (Connect-IPPSSession) : Microsoft Exchange Online Protection>Exchange.ManageAsApp.
Si l’application se connecte aux deux environnements, ajoutez les deux autorisations. Accordez le consentement de l’administrateur à l’échelle du client pour chaque autorisation.
Générer un certificat
- Pour l’authentification basée uniquement sur l’application dans Microsoft Entra ID, 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, qui est utilisé pour authentifier votre application contre Microsoft Entra ID, tout en demandant le jeton d’accès à l’application uniquement. Le certificat peut être auto-signé.
- Cette procédure est similaire à la génération d’un mot de passe pour les comptes d’utilisateurs. Consultez cette section plus loin dans cet article pour obtenir des instructions sur la génération de certificats dans PowerShell.
  
  Remarque
  
  Les certificats de chiffrement nouvelle génération (CNG) ne sont pas pris en charge pour l’authentification basée uniquement sur l’application 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 décrit deux méthodes prises en charge pour créer un certificat CSP.
Joindre le certificat à l’application Microsoft Entra
Attribuer des autorisations de rôles à l’application

Étape 1 : Inscrire l’application dans Microsoft Entra ID

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 à https://portal.azure.com/.
Dans la zone de recherche 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 des 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 les comptes de cet annuaire organisationnel uniquement (<VotrenomOrganisation> uniquement – Locataire unique) sont sélectionnés.
  
  Remarque
  
  Pour rendre l’application mutualisée pour les scénarios de délégation d’Exchange Online, sélectionnez la valeur Comptes dans n’importe quel répertoire organisationnel (Tout répertoire 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é sur la page des inscriptions d’applications, sélectionnez Inscrire.
Vous accédez à la page Vue d’ensemble de l’application que vous avez inscrite. Laissez cette page ouverte. Vous l’utiliserez à 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 utilisées par mon organisation, puis sélectionnez l’API qui correspond à la connexion PowerShell :
- Exchange Online PowerShell (Connect-ExchangeOnline) : recherchez et sélectionnez Office 365 Exchange Online.
- Sécurité & conformité PowerShell (Connect-IPPSSession) : recherchez et sélectionnez Microsoft Exchange Online Protection.
Si l’application se connecte aux deux environnements, répétez les étapes 2 à 5 pour l’autre API avant de passer à l’étape 6.

La capture d’écran suivante montre la sélection PowerShell dans Exchange Online :
Dans le menu volant Quel type d’autorisation votre application nécessite-t-elle ? qui s’affiche , sélectionnez Autorisations de l’application.
Dans la liste des autorisations qui s’affiche, développez Exchange, sélectionnez Exchange.ManageAsApp, puis sélectionnez Ajouter des autorisations.
De retour sur la page des autorisations de l’API d’application, vérifiez que chaque autorisation Exchange.ManageAsApp requise est répertoriée et contient les valeurs suivantes :
- Type : Application.
- Administration consentement requis : Oui.
- Statut : la valeur incorrecte actuelle n’est pas accordée pour <l’organisation>.
  
  Modifiez cette valeur en sélectionnant Accorder le consentement administrateur pour <l’organisation>, lisez la boîte de dialogue de confirmation qui s’ouvre, puis sélectionnez Oui.
  
  La valeur Statut est désormais Accordé pour <l’organisation>.
Pour l’entrée par défaut Microsoft Graph>User.Read , 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 rétablir la valeur vide par défaut de l’état .
Fermez la page Autorisations d’API (et non l’onglet du navigateur) pour revenir à la page Inscriptions des applications. Vous utiliserez la page d’inscriptions d’applications dans une prochaine étape.

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 l’autorisation d’application Exchange.ManageAsApp requise. Utilisez les valeurs de ressource qui correspondent à la connexion PowerShell. Si l’application se connecte à la fois à Exchange Online PowerShell et à Security & Compliance PowerShell, incluez à la fois des objets de ressource Exchange et un objet de ressource Microsoft Graph.

Dans la page Vue d’ensemble de l’application, sélectionnez Manifeste dans la section Gérer .

Sur la page Manifeste de l’application, recherchez l’entrée (à la ligne 42 ou vers cette requiredResourceAccess fin). Pour Exchange Online PowerShell, 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

Pour le PowerShell Sécurité & Conformité dans n’importe quel environnement, y compris Microsoft 365 GCC High et DoD, 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é sur la page Manifeste , sélectionnez Enregistrer.

Toujours sur la page Manifeste , sélectionnez Autorisations d’API dans la section Gérer .
Sur la page Autorisations de l’API , vérifiez que chaque autorisation Exchange.ManageAsApp requise est répertoriée et contient les valeurs suivantes :
- Type : Application.
- Administration consentement requis : Oui.
- Statut : la valeur incorrecte actuelle n’est pas accordée pour <l’organisation>.
  
  Modifiez la valeur Statut en sélectionnant Accorder le consentement administrateur pour <l’organisation>, lisez la boîte de dialogue de confirmation qui s’ouvre, puis sélectionnez Oui.
  
  La valeur Statut est désormais Accordé pour <l’organisation>.
Pour l’entrée par défaut Microsoft Graph>User.Read , 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 rétablir la valeur vide par défaut de l’état .
Fermez la page Autorisations d’API (et non l’onglet du navigateur) pour revenir à la page Inscriptions des applications. Vous utiliserez la page d’inscriptions d’applications dans une prochaine étape.

Étape 3 : Générer un certificat

Remarque

Les certificats de chiffrement nouvelle génération (CNG) ne sont pas pris en charge pour l’authentification basée sur l’application uniquement, comme décrit dans cet article. Les certificats GNC sont créés par défaut dans les versions modernes de Windows. Vous devez utiliser un certificat d’un fournisseur de clés CSP.

Vous pouvez utiliser un certificat auto-signé, un certificat émis par une infrastructure à clé publique interne ou une infrastructure à clé publique (par exemple, Services de certificats Active Directory ou AD CS) ou un certificat émis par une autorité de certification commerciale approuvée.

Les seules exigences pour le certificat X.509 sont une clé privée exportable et disponible (.pfx) et un certificat public (.cer).

Pour un certificat auto-signé, utilisez l’une des méthodes suivantes :

(Recommandé) : utilisez les applets de commande New-SelfSignedCertificate, Export-Certificate et Export-PfxCertificate dans une session PowerShell avec élévation de privilèges (une fenêtre PowerShell que vous avez ouverte après avoir sélectionné l’option Exécuter en tant qu’administrateur) pour demander un certificat auto-signé et exporter les clés privée et publique du certificat vers des fichiers (SHA1 par défaut). Par exemple :

# Create a self-signed certificate
$mycert = New-SelfSignedCertificate -DnsName "contoso.org" -CertStoreLocation "cert:\CurrentUser\My" -NotAfter (Get-Date).AddYears(1) -KeySpec KeyExchange

# Export the X.509 certificate and the associated private key to a password-protected .pfx file
$mycert | Export-PfxCertificate -FilePath mycert.pfx -Password (Get-Credential).password

# Export the X.509 public certificate to a .cer file
$mycert | Export-Certificate -FilePath mycert.cer

Utilisez le script Create-SelfSignedCertificate script. génère des certificats SHA1.

.\Create-SelfSignedCertificate.ps1 -CommonName "MyCompanyName" -StartDate 2026-01-06 -EndDate 2027-01-06

Étape 4 : Joindre 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 avez besoin de 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.
Sur la page de l’application qui s’ouvre, sélectionnez Certificats & secrets dans la section Gérer .
Sur la page Certificats & secrets , sélectionnez Télécharger le certificat.

Dans le menu volant Télécharger le certificat qui s’ouvre, accédez au certificat public (.cer fichier) que vous avez exporté à l’étape 3, puis 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 l’utiliserez à l’étape suivante.

Si vous avez rendu l’application mutualisée pour les scénarios de délégation d’Exchange Online à l’étape 1, vous devez accorder le consentement de l’administrateur à l’autorisation Exchange.ManageAsApp afin que l’application puisse exécuter des applets de commande dans Exchange Online dans chaque organisation cliente. Vous devez générer une URL de consentement administrateur pour chaque client client. Avant d’utiliser l’application mutualisée pour se connecter à Exchange Online dans l’organisation cliente, un administrateur du client 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 mutualisée.
L’étendue par défaut est utilisée pour accorder des autorisations d’application.

Pour plus d’informations sur la syntaxe URL, consultez Demander les autorisations à un administrateur d’annuaire.

Étape 5 : Attribuer des autorisations de rôle à l’application

Vous avez le choix parmi les options suivantes :

Option 1 : Affecter des rôles Microsoft Entra à l’application : Utilisez les rôles Microsoft Entra intégrés pour accorder toutes les autorisations du rôle. Vous ne pouvez pas personnaliser ou étendre ces rôles.
Option 2 : affecter des groupes de rôles personnalisés à l’application à l’aide des principaux de service : cette option est recommandée dans les scénarios suivants :
- Vous devez limiter les commandes disponibles dans votre application.
- Vous devez utiliser une étendue d’écriture pour limiter les destinataires qui peuvent être modifiés.
Option 3 : Combiner les rôles Microsoft Entra avec des groupes de rôles personnalisés : RBAC combine les autorisations de toutes les sources. Nous vous recommandons cette méthode pour étendre les fonctionnalités d’un rôle Microsoft Entra intégré. Par exemple, vous pouvez étendre les fonctionnalités du rôle Administrateur de destinataire Exchange en accordant des autorisations supplémentaires à partir d’un rôle personnalisé.

Ces options sont décrites dans les sous-sections suivantes.

Remarque

Pour les applications mutualisées dans les scénarios de délégation d’Exchange Online, vous devez attribuer des autorisations à chaque client client.

Option 1 : 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 général	✔	✔
Administrateur du support technique	✔
Administrateur de sécurité¹	✔	✔
Lecteur de sécurité	✔	✔

¹ Les rôles Administrateur général et Administrateur Exchange fournissent les autorisations requises pour n’importe quelle 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 d’administrateur de la sécurité ne dispose pas des autorisations nécessaires pour ces mêmes tâches.

² Microsoft défend fermement le principe du moindre privilège. Le fait de ne donner aux comptes que les autorisations minimales nécessaires à l’exécution de leurs tâches permet de réduire les risques de sécurité et de renforcer la protection globale de votre organisation. Le rôle Administrateur général est un rôle hautement privilégié que vous devez limiter aux scénarios d’urgence ou lorsque vous ne pouvez pas utiliser un autre rôle.

Pour obtenir des instructions générales sur l’attribution de rôles dans Microsoft Entra ID, 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 https://portal.azure.com/à , commencez à taper rôles et 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 Rôles et administrateurs de 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 d’administrateur Exchange.
- PowerShell Sécurité & conformité : Par exemple, recherchez et sélectionnez le rôle Administrateur de conformité .
Dans la page Devoirs qui s’ouvre, sélectionnez Ajouter des devoirs.
- 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 sur la page Devoirs , vérifiez que le rôle est attribué à l’application.
- Exchange Online PowerShell :
- Centre de sécurité et de conformité PowerShell :

Option 2 : attribuer des groupes de rôles personnalisés à l’application à l’aide des principaux de service

Remarque

Vous devez vous connecter à Exchange Online PowerShell ou à Security & Compliance PowerShell avant de suivre les étapes de création d’un principal de service. La création d’un nouveau principal de service sans se connecter à PowerShell ne fonctionne pas (votre ID d’application et votre ID d’objet Azure App sont nécessaires pour créer le nouveau principal de service).

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 Email & groupes de rôles de collaboration dans le portail Microsoft Defender. Le groupe de rôles personnalisé que vous affectez à l’application peut contenir n’importe quelle combinaison de rôles intégrés et personnalisés.

Pour attribuer 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 enregistrée à 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 à & de conformité de sécurité et exécutez les commandes suivantes pour :
- Créez un objet principal du service pour l’application Microsoft Entra.
- Stockez les détails du principal du 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 plus d’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.Identity
```
Pour obtenir des informations détaillées sur la syntaxe et les paramètres, voir Add-RoleGroupMember.

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-08-25

Authentification par application uniquement pour les scripts sans assistance dans Exchange Online PowerShell et PowerShell de conformité & sécurité

Comment cela fonctionne-t-il ?

Exemples de connexion

Configurer l’authentification d’application uniquement

Étape 1 : Inscrire l’application dans Microsoft Entra ID

Étape 2 : Attribuer des autorisations API à l’application

Sélectionner et attribuer les autorisations d’API à partir du portail

Modifier le manifeste de l’application pour attribuer des autorisations d’API

Étape 3 : Générer un certificat

Étape 4 : Joindre le certificat à l’application Microsoft Entra

Étape 4b : Scénarios de délégation dans Exchange Online uniquement : accorder le consentement de l’administrateur pour l’application mutualisée

Étape 5 : Attribuer des autorisations de rôle à l’application

Option 1 : Attribuer des rôles Microsoft Entra à l’application

Option 2 : attribuer des groupes de rôles personnalisés à l’application à l’aide des principaux de service

Commentaires

Ressources supplémentaires