Connexion à PowerShell pour Exchange Online Protection

Le module Exchange Online PowerShell v2 (abrégé en module EXO v2) utilise l’authentification moderne et fonctionne avec l’authentification multifacteur (MFA) pour la connexion à tous les environnements PowerShell liés à Exchange dans Microsoft 365 : Exchange Online PowerShell, sécurité et conformité PowerShell et Exchange Online Protection (EOP) PowerShell autonome. Pour plus d’informations sur le module EXO V2, consultez le module À propos du module Exchange Online PowerShell v2.

Cet article contient des instructions pour se connecter à Exchange Online Protection PowerShell à l'aide du module EXO V2 avec ou sans utilisation de l'AMF.

Pour utiliser les anciennes instructions de connexion PowerShell à distance, moins sécurisées, qui seront éventuellement obsolètes, consultez Authentification de base : Connexion à Exchange Online Protection PowerShell.

Ce qu'il faut savoir avant de commencer

  • Les procédures décrites dans cet article ne concernent que les organisations Microsoft 365 qui n'ont pas de boîte aux lettres Exchange Online. Par exemple, vous avez un abonnement Exchange Online Protection (EOP) autonome qui protège votre environnement de messagerie local. Si votre abonnement Microsoft 365 inclut des boîtes aux lettres Exchange Online, vous ne pouvez pas vous connecter à Exchange Online Protection (EOP) PowerShell ; vous devez à la place vous connecter à Exchange Online PowerShell.

    Si votre organisation utilise Exchange local, et vous avez une Licence d’accès client (CAL) d’Exchange Entreprise avec les licences des Services pour Exchange Online Protection (EOP), les instructions de la connexion PowerShell de votre EOP sont les mêmes que celles de Exchange Online Powershell. Utilisez les instructions de connexion d'Exchange Online PowerShell dans Connexion à Exchange Online PowerShell au lieu des instructions de cet article.

  • Les conditions requises pour l’installation et l’utilisation du module EXO V2 sont décrites dans Installer et gérer le module EXO V2. Le reste des instructions dans l'article suppose que vous avez déjà installé le module.

  • Après votre connexion, les cmdlets et les paramètres auxquels vous avez ou n'avez pas accès sont contrôlés par un contrôle d'accès basé sur les rôles (RBAC). Pour plus d'informations, voir Autorisations dans le cadre de l'EOP autonome.

Conseil

Vous rencontrez des difficultés ? Demandez de l’aide dans le Forum Exchange Online Protection .

Connexion à PowerShell pour Exchange Online Protection à l’aide de l’authentification multifacteur

Si votre compte utilise l’authentification multifacteur, suivez les étapes décrites dans cette section. Dans le cas contraire, passez à la section Connectez-vous à Exchange Online Protection PowerShell sans utiliser l’authentification multifacteur.

  1. Dans une fenêtre Windows PowerShell, chargez le module EXO V2 en exécutant la commande suivante :

    Import-Module ExchangeOnlineManagement
    

    Remarque Si vous avez déjà installé le module EXO v2, la commande précédente fonctionnera comme écrite.

  2. La commande à exécuter utilise la syntaxe suivante:

    Connect-IPPSSession -UserPrincipalName <UPN> [-ConnectionUri <URL>] [-AzureADAuthorizationEndPointUri <URL>] [-PSSessionOption $ProxyOptions]
    
    • <UPN> est votre compte au format du nom d’utilisateur principal (par exemple, navin@contoso.com).
    • Les valeurs requises de ConnectionUri et de AzureADAuthorizationEndPointUrl dépendent de la nature de votre organisation Microsoft 365. Si vous souhaitez obtenir plus d’informations, consultez la description du paramètre dans Connect-IPPSSession.
    • Si vous êtes derrière un serveur proxy, exécutez cette commande en premier : $ProxyOptions = New-PSSessionOption -ProxyAccessType <Value>, où <Value> estIEConfig, WinHttpConfig, ou AutoDetect. Utilisez ensuite le paramètre de PSSessionOption avec la valeur $ProxyOptions. Pour plus d’informations, voir Nouveau-PSSessionOption.

    Cet exemple se connecte à Exchange Online Protection PowerShell dans une organisation Microsoft 365 :

    Connect-IPPSSession -UserPrincipalName navin@contoso.com -ConnectionUri https://ps.protection.outlook.com/powershell-liveid/
    

    Cet exemple se connecte à Exchange Online Protection PowerShell dans une organisation Office 365 Allemagne :

    Connect-IPPSSession -UserPrincipalName lukas@fabrikam.com -ConnectionUri https://ps.protection.outlook.de/powershell-liveid/ -AzureADAuthorizationEndPointUri https://login.microsoftonline.de/common
    

Pour obtenir des informations de syntaxe et de paramètre détaillées, consultez Connect-IPPSSession.

Notes

N’oubliez pas de déconnecter la session PowerShell distante dès que vous avez terminé. Si vous fermez la fenêtre Windows PowerShell sans déconnecter la session, vous pourriez épuiser toutes les sessions PowerShell distantes à votre disposition et vous devrez attendre l’expiration des sessions. Pour déconnecter la session PowerShell distante, exécutez la commande suivante.

Disconnect-ExchangeOnline

Connexion à PowerShell pour Exchange Online Protection à l’aide de l’authentification moderne

Si votre compte n’utilise pas l’authentification multifacteur, suivez les étapes décrites dans cette section.

  1. Dans une fenêtre Windows PowerShell, chargez le module EXO V2 en exécutant la commande suivante :

    Import-Module ExchangeOnlineManagement
    

    Remarque Si vous avez déjà installé le module EXO v2, la commande précédente fonctionnera comme écrite.

  2. Exécutez la commande suivante :

    Notes

    Vous pouvez ignorer cette étape et omettre le paramètre Informations d’identification dans l’étape suivante pour être invité à entrer le nom d’utilisateur et le mot de passe après l’exécution de la commande Connect-IPPSSession. Si vous omettez le paramètre Informations d’identification et incluez le paramètre UserPrincipalName à l’étape suivante, vous êtes invité à entrer le mot de passe après l’exécution de la commande Connect-IPPSSession.

    $UserCredential = Get-Credential
    

    Dans la boîte de dialogue Demande d’informations d’identification Windows PowerShell qui s’affiche, saisissez vos nom d’utilisateur et mot de passe, puis cliquez sur OK.

  3. La dernière commande que vous devez exécuter utilise la syntaxe suivante :

    Connect-IPPSSession [-Credential $UserCredential] -ConnectionUri <URL> [-PSSessionOption $ProxyOptions]
    
    • La valeur requise de la ConnectionUri dépend de la nature de votre organisation Microsoft 365. Si vous souhaitez obtenir plus d’informations, consultez les descriptions du paramètre dans Connect-IPPSSession.
    • Si vous vous trouvez derrière un serveur proxy, stockez la sortie de l’applet de commande New-PSSessionOption dans une variable (par exemple, $ProxyOptions = New-PSSessionOption -ProxyAccessType <Value> [-ProxyAuthentication <Value>] [-ProxyCredential <Value>]). Utilisez ensuite la variable ($ProxyOptions) comme valeur du paramètre PSSessionOption.

    Cet exemple se connecte à Exchange Online Protection PowerShell dans une organisation Microsoft 365 :

    Connect-IPPSSession -Credential $UserCredential -ConnectionUri https://ps.protection.outlook.com/powershell-liveid/
    

    Cet exemple se connecte à Exchange Online Protection PowerShell dans une organisation Office 365 Allemagne :

    Connect-IPPSSession -Credential $UserCredential -ConnectionUri https://ps.protection.outlook.de/powershell-liveid/
    

Pour obtenir des informations de syntaxe et de paramètre détaillées, consultez Connect-IPPSSession.

Notes

N’oubliez pas de déconnecter la session PowerShell distante dès que vous avez terminé. Si vous fermez la fenêtre Windows PowerShell sans déconnecter la session, vous pourriez épuiser toutes les sessions PowerShell distantes à votre disposition et vous devrez attendre l’expiration des sessions. Pour déconnecter la session PowerShell distante, exécutez la commande suivante :

Disconnect-ExchangeOnline

Comment savoir si cela a fonctionné ?

Les cmdlets Exchange Online Protection sont importées dans votre session Windows PowerShell locale et indiqué par une barre de progression. Si vous ne recevez aucune erreur, la connexion est établie. Un test rapide consiste à exécuter une cmdlet Exchange Online Protection (par exemple, Get-TransportRule) et à consulter les résultats.

Si vous recevez des erreurs, vérifiez les conditions requises suivantes :

  • Un mot de passe incorrect est un problème courant. Exécutez à nouveau les trois étapes et portez une attention particulière au nom d’utilisateur et au mot de passe que vous utilisez.

  • Pour éviter les attaques par déni de service (DoS), vous ne pouvez ouvrir que cinq sessions PowerShell à distance sur Exchange Online Protection.

  • Le trafic du port TCP 80 doit être ouvert entre votre ordinateur local et Microsoft 365. Il est probablement ouvert, mais il est à prendre en compte si votre organisation a une stratégie d’accès Internet restrictive.

  • Le compte que vous utilisez pour vous connecter à Exchange Online Protection PowerShell doit être représenté sous la forme d’un utilisateur de messagerie dans EOP (créé manuellement ou via la synchronisation d’annuaires). Si le compte n’est pas visible dans le Centre d’administration Exchange en tant qu’utilisateur de messagerie auprès des Destinataires > Contacts, le message d’erreur suivant s’affiche lorsque vous essayez de vous connecter :

    Import-PSSession : l’exécution de la commande Get-Command dans une session distante a signalé l’erreur suivante : le traitement des données d’une commande distante a échoué avec le message d’erreur suivant : la demande d’accès à distance Windows avec ShellId a échoué, car l’environnement est introuvable sur le serveur. Causes possibles : la ShellId spécifiée est incorrecte ou l’interpréteur de la Shell n’existe plus sur le serveur. Fournissez les ShellId correctes ou créez un nouveau shell et recommencez l’opération.

  • Il se peut que vous ne parvenez pas à vous connecter si l’adresse IP de votre client change pendant la demande de connexion. Cela peut se produire si votre organisation utilise un pool de traduction d’adresses réseau (SNAT) source contenant plusieurs adresses IP. L’erreur de connexion se présente comme suit :

    Échec de la demande d’accès Windows Remote PowerShell avec ShellId , car l’environnement est introuvable sur le serveur. Causes possibles : la ShellId spécifiée est incorrecte ou l’interpréteur de la Shell n’existe plus sur le serveur. Fournissez les ShellId correctes ou créez un nouveau shell et recommencez l’opération.

    Pour résoudre le problème, utilisez un pool SNAT qui contient une adresse IP unique, ou forcez l’utilisation d’une adresse IP spécifique pour les connexions au point de terminaison de Exchange Online Protection PowerShell.