Module V1 : Connecter au Centre de sécurité & conformité PowerShell à l’aide de l’ation MFA

Notes

L’Exchange Online module PowerShell distant décrit dans cet article sera finalement retiré. Le Exchange Online module PowerShell V2 (module EXO v2) prend en charge l’mfmf. Nous vous suggérons donc de l’utiliser à la place. Pour obtenir des instructions, consultez Connecter sur le Centre de sécurité & conformité PowerShell.

Si votre compte utilise l’authentification multifacteur (MFA) ou l’authentification fédérée, vous ne pouvez pas utiliser les instructions de l’authentification de base ( Connecter to Security & Compliance Center PowerShell) pour utiliser l’environnement PowerShell distant pour vous connecter au Centre de sécurité & conformité PowerShell. Au lieu de cela, vous devez installer le module Exchange Online Remote PowerShell et utiliser la cmdlet Connecter-IPPSSession pour vous connecter au Centre de sécurité & conformité PowerShell.

Remarques :

  • Les partenaires avec autorisation d’accès délégué ne peuvent pas utiliser les procédures de cet article pour se connecter à leurs organisations client clientes dans le Centre de sécurité & conformité PowerShell. L’authentification multifacteur et Exchange Online module PowerShell distant ne fonctionnent pas avec l’authentification déléguée.

  • Le Exchange Online Remote PowerShell Module n’est pas pris en charge dans PowerShell Core (macOS, Linux ou Windows Nano Server). Pour contourner ce problème, vous pouvez installer le module sur un ordinateur exécutant une version prise en charge de Windows (physique ou virtuelle) et utiliser le logiciel bureau à distance pour vous connecter.

Ce qu'il faut savoir avant de commencer

  • Durée d’exécution estimée : 5 minutes

  • 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 Après vous être connecté, les cmdlets et paramètres que vous avez ou n’avez pas accès sont contrôlés par le contrôle d’accès basé sur un rôle (RBAC). Pour plus d’informations, consultez Autorisations dans le portail Microsoft 365 Defender et Autorisations dans le Centre de sécurité Microsoft 365.

  • Vous pouvez utiliser les versions de Windows suivantes :

    • Windows 10
    • Windows 8.1
    • Windows Server 2019
    • Windows Server 2016
    • Windows Server 2012 ou Windows Server 2012 R2
    • Windows 7 Service Pack 1 (SP1)*
    • Windows Server 2008 R2 SP1*

    * Cette version de Windows a atteint la fin du support, et n'est maintenant supportée que par les machines virtuelles Azure. Pour utiliser cette version de Windows, vous devez installer Microsoft .NET Framework 4.5 ou une version ultérieure, puis une version mise à jour de Windows Management Framework : 3.0, 4.0 ou 5.1 (une seule). Pour plus d’informations, consultezInstaller le .NET Framework, Windows Management Framework 3.0, Windows Management Framework 4.0et Windows Management Framework 5.1.

  • WinRM doit autoriser l’authentification de base (elle est activée par défaut). Nous n’envoyons pas la combinaison nom d’utilisateur et mot de passe, mais l’en-tête d’authentification de base est requis pour envoyer le jeton OAuth de la session, car l’implémentation de WinRM côté client ne prend pas en charge le protocole OAuth.

    Remarque : vous devez autoriser provisoirement WinRM à exécuter les commandes suivantes. Vous pouvez l’activer en exécutant la commande : winrm quickconfig.

    Pour vérifier que l’authentification de base est activée pour WinRM, exécutez cette commande dans une invite de commandes (et non dans Windows PowerShell) :

    winrm get winrm/config/client/auth
    

    Si la valeur Basic = true ne s’affiche pas, vous devez exécuter cette commande dans une invite de commandes (et non dans Windows PowerShell) pour activer l’authentification de base pour WinRM :

    winrm set winrm/config/client/auth @{Basic="true"}
    

    Remarque : si vous préférez exécuter la commande dans Windows PowerShell, placez cette partie de la commande entre guillemets : '@{Basic="true"}'.

    Si l’authentification de base pour WinRM est désactivée, vous obtenez l’erreur suivante lorsque vous essayez de vous connecter :

    Le client WinRM ne peut pas traiter la demande. L’authentification de base est actuellement désactivée dans la configuration du client. Modifiez la configuration du client, puis renouvelez la demande.

Installer le module PowerShell Exchange Online distant

Notes

  • Le Exchange Online Remote PowerShell Module n’est pas pris en charge dans PowerShell Core (macOS, Linux ou Windows Nano Server). Pour contourner ce problème, vous pouvez installer le module sur un ordinateur exécutant une version prise en charge de Windows (physique ou virtuelle) et utiliser le logiciel bureau à distance pour vous connecter.

  • Si votre version installée du module Exchange Online Remote PowerShell ne comprend pas la cmdlet Connecter-IPPSSession, vous devez installer la dernière version du module.

Vous devez suivre les étapes suivantes dans un navigateur qui prend en charge ClickOnce (par exemple, Internet Explorer ou Edge) :

Remarque: ClickOnce prise en charge est disponible dans la version Chromium de Edge sur edge et peut ne pas être activée edge://flags/#edge-click-once par défaut.

  1. Ouvrez le Centre d’administration Exchange. Pour obtenir des instructions, voir Exchange centre d’administration dans Exchange Online.

  2. Dans le CENTRE d’installation, cliquez sur le bouton Configurer approprié pour télécharger le module PowerShell distant Exchange Online pour l’authentification > multifacteur.

    Téléchargez le Exchange Online Module PowerShell à partir de l’onglet Hybride du EAC.

  3. Dans la fenêtre Installation de l’application qui s’ouvre, cliquez sur Installer.

    Cliquez sur Installer dans la Exchange Online module PowerShell.

Connecter centre de sécurité & et conformité PowerShell à l’aide de l’authentification multifacteur ou fédérée

  1. Sur votre ordinateur local, ouvrez le module Exchange Online Remote PowerShell (Module PowerShell Microsoft Exchange Online Microsoft > Corporation).

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

    Connect-IPPSSession -UserPrincipalName <UPN> [-ConnectionUri <ConnectionUri> -AzureADAuthorizationEndPointUri <AzureADUri>]
    
    • <UPN> est votre compte Microsoft 365 scolaire ou scolaire.

    • Les <ConnectionUri> <AzureADUri> valeurs et les valeurs dépendent de l’emplacement de votre organisation Microsoft 365, comme décrit dans le tableau suivant :



    Offre Microsoft 365 Valeur du paramètre ConnectionUri Valeur du paramètre AzureADAuthorizationEndPointUri
    Microsoft 365 Inutilisé Inutilisé
    Office 365 Allemagne https://ps.compliance.protection.outlook.de/PowerShell-LiveID https://login.microsoftonline.de/common
    Microsoft 365 GCC High https://ps.compliance.protection.office365.us/powershell-liveid/ https://login.microsoftonline.us/common
    Microsoft 365 DoD https://l5.ps.compliance.protection.office365.us/powershell-liveid/ https://login.microsoftonline.us/common

    Cet exemple se connecte au Centre de sécurité & conformité PowerShell dans Microsoft 365 l’aide du compte chris@contoso.com.

    Connect-IPPSSession -UserPrincipalName chris@contoso.com
    

    Cet exemple se connecte au Centre de sécurité & conformité PowerShell dans Office 365 Germany à l’aide du compte lukas@fabrikam.com.

    Connect-IPPSSession -UserPrincipalName lukas@fabrikam.com -ConnectionUri https://ps.compliance.protection.outlook.de/PowerShell-LiveID -AzureADAuthorizationEndPointUri https://login.microsoftonline.de/common
    
  3. Dans la fenêtre de connexion qui s’ouvre, entrez votre mot de passe, puis cliquez sur Se connecter.

    Entrez votre mot de passe dans la Exchange Online PowerShell distante.

    Pour l’mf, un code de vérification est généré et remis en fonction de l’option de réponse de vérification configurée pour votre compte (par exemple, un SMS ou l’application Azure Authenticator sur votre téléphone mobile).

  4. (MFA uniquement): dans la fenêtre de vérification qui s’ouvre, entrez le code de vérification, puis cliquez sur Se connectez.

    Entrez votre code de vérification dans la Exchange Online PowerShell distante.

  5. (Facultatif): si vous souhaitez vous connecter à une session Exchange Online module PowerShell dans la même fenêtre, vous devez exécuter

    $EXOSession=New-ExoPSSession -UserPrincipalName <UPN> [-ConnectionUri <ConnectionUri> -AzureADAuthorizationEndPointUri <AzureADUri>]
    

    puis importer la session Exchange Online dans la session actuelle à l’aide d’un préfixe spécifique

    Import-PSSession $EXOSession -Prefix EXO
    

Comment savoir si cela a fonctionné ?

Après vous être connectez, les cmdlets PowerShell du Centre de sécurité & conformité sont importées dans votre session de module PowerShell distant Exchange Online et sont suivis par une barre de progression. Si vous ne recevez aucune erreur, la connexion est établie. Un test rapide consiste à exécuter une cmdlet du Centre de sécurité & conformité, par exemple, Get-RetentionCompliancePolicy, et à consulter les résultats.

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

  • Pour éviter les attaques par déni de service, vous ne pouvez ouvrir que cinq sessions PowerShell à distance au Centre de conformité et sécurité PowerShell.

  • Le compte que vous utilisez pour vous connecter au Centre de sécurité & conformité PowerShell doit être activé pour PowerShell à distance. Pour plus d’informations, consultez Activer ou désactiver l’accès à Exchange Online PowerShell.

  • 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.

  • La Connecter-IPPSSession (étape 2) risque de ne pas pouvoir se connecter si votre adresse IP cliente change au cours de 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 :

    The request for the Windows Remote Shell with ShellId <ID> failed because the shell was not found on the server. Possible causes are: the specified ShellId is incorrect or the shell no longer exists on the server. Provide the correct ShellId or create a new shell and retry the operation.

    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 du Centre de sécurité et de conformité PowerShell.