Herstellen einer Verbindung mit Security & Compliance PowerShell

Dieser Artikel enthält Anweisungen zum Herstellen einer Verbindung mit Security & Compliance PowerShell mithilfe des Exchange Online PowerShell-Moduls mit oder ohne Multi-Factor Authentication (MFA).

Das Exchange Online PowerShell-Modul verwendet die moderne Authentifizierung zum Herstellen einer Verbindung mit allen Exchange-bezogenen PowerShell-Umgebungen in Microsoft 365: Exchange Online PowerShell, PowerShell zur Sicherheitskonformität & und eigenständiger Exchange Online Protection PowerShell (EOP). Weitere Informationen zum Exchange Online PowerShell-Moduls finden Sie unter Informationen zum Exchange Online PowerShell-Moduls.

Hinweis

Version 2.0.5 und früher wird als Exchange Online PowerShell V2-Modul (abgekürzt als EXO V2-Modul) bezeichnet. Version 3.0.0 und höher wird als Exchange Online PowerShell V3-Modul (abgekürzt als EXO V3-Modul) bezeichnet.

Informationen zum Herstellen einer Verbindung mit PowerShell für die Sicherheitskonformität & zur Automatisierung finden Sie unter Nur-App-Authentifizierung für unbeaufsichtigte Skripts.

Informationen zum Verwenden des älteren Exchange Online Remote PowerShell-Moduls (das V1-Modul) zum Herstellen einer Verbindung mit PowerShell zur Sicherheitskonformität & mithilfe von MFA finden Sie unter V1-Modul – Herstellen einer Verbindung mit Security & Compliance PowerShell mithilfe von MFA. Beachten Sie, dass diese ältere Version des Moduls in Kürze zurückgezogen wird.

Was sollten Sie wissen, bevor Sie beginnen?

• Die Anforderungen für die Installation und Verwendung des Moduls werden unter Installieren und Verwalten des Exchange Online PowerShell-Moduls beschrieben.

  Hinweis

  PowerShell für Sicherheitskonformität & erfordert weiterhin die Standardauthentifizierung in WinRM, wie unter Voraussetzungen für das Exchange Online PowerShell-Modul beschrieben. REST-API-Cmdlets, mit denen Sie die Standardauthentifizierung in WinRM deaktivieren können, sind für das Cmdlet Connect-IPPSSession noch nicht verfügbar. Weitere Informationen finden Sie unter Aktualisierungen für das EXO V3-Modul).

• Nachdem Sie eine Verbindung hergestellt haben, wird über die rollenbasierte Zugriffssteuerung (RBAC) gesteuert, auf welche Cmdlets und Parameter Sie Zugriff haben bzw. nicht haben. Weitere Informationen finden Sie unter Berechtigungen im Microsoft 365 Defender-Portal und Berechtigungen im Microsoft Purview-Complianceportal.

Schritt 1: Laden des Exchange Online PowerShell-Moduls

Hinweis

Wenn das Modul bereits installiert ist, können Sie diesen Schritt in der Regel überspringen und Connect-IPPSSession ausführen, ohne das Modul zuerst manuell zu laden.

Nachdem Sie das Modul installiert haben, öffnen Sie ein PowerShell-Fenster, und laden Sie das Modul, indem Sie den folgenden Befehl ausführen:

Import-Module ExchangeOnlineManagement

Schritt 2: Verbinden und Authentifizieren

Hinweis

Verbindungsbefehle schlagen wahrscheinlich fehl, wenn der Profilpfad des Kontos, das Sie für die Verbindung verwendet haben, $spezielle PowerShell-Zeichen enthält (z. B. ). Die Problemumgehung besteht darin, eine Verbindung mit einem anderen Konto herzustellen, das keine Sonderzeichen im Profilpfad enthält.

Die Syntax des Befehls, den Sie ausführen müssen, sieht so aus:

Connect-IPPSSession -UserPrincipalName <UPN> [-ConnectionUri <URL>] [-AzureADAuthorizationEndpointUri <URL>] [-DelegatedOrganization <String>] [-PSSessionOption $ProxyOptions]

Ausführliche Informationen zu Syntax und Parametern finden Sie unter Connect-IPPSSession.

• <DER UPN> ist Ihr Konto im Benutzerprinzipalnamenformat (z. B navin@contoso.onmicrosoft.com. ).

• Die erforderlichen ConnectionUri - und AzureADAuthorizationEndpointUri-Werte hängen von der Art Ihrer Microsoft 365-Organisation ab. Allgemeine Werte werden in der folgenden Tabelle beschrieben:

  Umgebung	ConnectionUri	AzureADAuthorizationEndpointUri
  Microsoft 365 oder Microsoft 365 GCC	n/v*	n/v**
  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
  Office 365, betrieben von 21Vianet	https://ps.compliance.protection.partner.outlook.cn/powershell-liveid	https://login.chinacloudapi.cn/common

  ^* Der erforderliche Wert https://ps.compliance.protection.outlook.com/powershell-liveid/ ist auch der Standardwert, sodass Sie den Parameter ConnectionUri in Microsoft 365- oder Microsoft 365 GCC-Umgebungen nicht verwenden müssen.

  ^** Der erforderliche Wert https://login.microsoftonline.com/common ist auch der Standardwert, sodass Sie den Parameter AzureADAuthorizationEndpointUri in Microsoft 365- oder Microsoft 365 GCC-Umgebungen nicht verwenden müssen.

• Wenn Sie sich hinter einem Proxyserver befinden, können Sie den PSSessionOption-Parameter im Verbindungsbefehl verwenden. Führen Sie zunächst den folgenden Befehl aus: $ProxyOptions = New-PSSessionOption -ProxyAccessType <Value>, wobei <Value> , WinHttpConfigoder AutoDetectistIEConfig. Verwenden Sie dann den Wert $ProxyOptions für den PSSessionOption-Parameter . Weitere Informationen finden Sie unter New-PSSessionOption.

• Je nach Art Ihrer Organisation können Sie den Parameter UserPrincipalName möglicherweise im nächsten Schritt weglassen. Geben Sie stattdessen den Benutzernamen und das Kennwort ein, oder wählen Sie gespeicherte Anmeldeinformationen aus, nachdem Sie den Befehl Connect-IPPSSession ausgeführt haben. Wenn dies nicht funktioniert, müssen Sie den Parameter UserPrincipalName verwenden.

• Wenn keine MFA verwendet wird, kann häufig der Parameter Credential anstelle des Parameters UserPrincipalName verwendet werden. Führen Sie zuerst den Befehl $Credential = Get-Credential aus, geben Sie Ihren Benutzernamen und Ihr Kennwort ein, und verwenden Sie dann den Variablennamen für den Credential-Parameter (-Credential $Credential). Wenn dies nicht funktioniert, müssen Sie den Parameter UserPrincipalName verwenden.

Herstellen einer Verbindung mit Security & Compliance PowerShell mit einer interaktiven Anmeldeaufforderung

1. Die folgenden Beispiele funktionieren in Windows PowerShell 5.1 und PowerShell 7 für Konten mit oder ohne MFA:

   • In diesem Beispiel wird eine Verbindung mit Security hergestellt. & Compliance-PowerShell in einer Microsoft 365- oder Microsoft 365 GCC-Organisation:

     Connect-IPPSSession -UserPrincipalName navin@contoso.onmicrosoft.com
     

   • In diesem Beispiel wird eine Verbindung mit Security hergestellt. & Compliance-PowerShell in einer Microsoft GCC High-Organisation:

     Connect-IPPSSession -UserPrincipalName chris@govt.us -ConnectionUri https://ps.compliance.protection.office365.us/powershell-liveid/ -AzureADAuthorizationEndpointUri https://login.microsoftonline.us/common
     

   • In diesem Beispiel wird eine Verbindung mit Security hergestellt. & Compliance-PowerShell in einer Microsoft 365 DoD-Organisation:

     Connect-IPPSSession -UserPrincipalName michelle@govt.mil -ConnectionUri https://l5.ps.compliance.protection.office365.us/powershell-liveid/ -AzureADAuthorizationEndpointUri https://login.microsoftonline.us/common
     

   • In diesem Beispiel wird eine Verbindung mit Security hergestellt.& Compliance-PowerShell in einer Office 365, die von der 21Vianet-Organisation betrieben wird:

     Connect-IPPSSession -UserPrincipalName li@fabrikam.cn -ConnectionUri https://ps.compliance.protection.partner.outlook.cn/powershell-liveid
     

2. Ein Anmeldefenster wird geöffnet. Geben Sie Ihr Kennwort ein, und klicken Sie auf Anmelden.

   

   Hinweis

   In PowerShell 7 wird standardmäßig das browserbasierte einmalige Anmelden (Single Sign-On, SSO) verwendet, sodass die Anmeldeaufforderung in Ihrem Standardwebbrowser anstelle eines eigenständigen Dialogfelds geöffnet wird.

3. Nur bei MFA: Ein Prüfcode wird generiert und gemäß der für Ihr Konto festgelegten Antwortoption zugestellt (z. B. als SMS oder in der Microsoft Authenticator-App auf Ihrem Gerät).

   Ein Verifizierungsfenster wird geöffnet. Geben Sie den Prüfcode ein, und klicken Sie auf Bestätigen.

   

Herstellen einer Verbindung mit Security & Compliance PowerShell ohne Anmeldeaufforderung (unbeaufsichtigte Skripts)

Eine vollständige Anleitung finden Sie unter Nur-App-Authentifizierung für unbeaufsichtigte Skripts in Exchange Online PowerShell und Security & Compliance PowerShell.

Herstellen einer Verbindung mit PowerShell für Sicherheitskonformität & in Kundenorganisationen

Für die Verfahren in diesem Abschnitt ist mindestens Version 3.0.0 des Moduls erforderlich.

In PowerShell zur Sicherheitskonformität & müssen Sie azureADAuthorizationEndpointUri mit dem Parameter DelegatedOrganization verwenden.

Weitere Informationen zu Partnern und Kundenorganisationen finden Sie in den folgenden Themen:

• Was ist das CSP-Programm (Cloud Solution Provider)?.
• Einführung in granulare delegierte Administratorrechte (GDAP)

In diesem Beispiel wird in den folgenden Szenarien eine Verbindung mit Kundenorganisationen hergestellt:

• Stellen Sie mithilfe eines CSP-Kontos eine Verbindung mit einer Kundenorganisation her.

• Herstellen einer Verbindung mit einer Kundenorganisation mithilfe eines GDAP

• Stellen Sie als Gastbenutzer eine Verbindung mit einer Kundenorganisation her.

  Connect-IPPSSession -UserPrincipalName navin@contoso.onmicrosoft.com -DelegatedOrganization adatum.onmicrosoft.com -AzureADAuthorizationEndpointUri https://ps.compliance.protection.outlook.com/powershell-liveid/
  

Schritt 3: Trennen, wenn Sie fertig sind

Stellen Sie sicher, dass Sie die Sitzung trennen, wenn Sie fertig sind. Wenn Sie das PowerShell-Fenster schließen, ohne die Sitzung zu trennen, können Sie alle verfügbaren Sitzungen aufgebraucht haben, und Sie müssen warten, bis die Sitzungen ablaufen. Führen Sie den folgenden Befehl aus, um die Sitzung zu trennen.

Disconnect-ExchangeOnline

Führen Sie den folgenden Befehl aus, um die Verbindung ohne Bestätigungsaufforderung automatisch zu trennen:

Disconnect-ExchangeOnline -Confirm:$false

Hinweis

Der Befehl disconnect schlägt wahrscheinlich fehl, wenn der Profilpfad des Kontos, das Sie für die Verbindung verwendet haben, $spezielle PowerShell-Zeichen enthält (z. B. ). Die Problemumgehung besteht darin, eine Verbindung mit einem anderen Konto herzustellen, das keine Sonderzeichen im Profilpfad enthält.

Woher wissen Sie, dass Die Verbindung erfolgreich hergestellt wurde?

Die PowerShell-Cmdlets für die Sicherheitskonformität & werden in Ihre lokale Windows PowerShell-Sitzung importiert und über eine Statusanzeige nachverfolgt. Wenn Sie keine Fehler erhalten, haben Sie erfolgreich eine Verbindung hergestellt. Ein kurzer Test besteht darin, ein PowerShell-Cmdlet zur Sicherheitskonformität & auszuführen, z. B. Get-RetentionCompliancePolicy, und die Ergebnisse anzuzeigen.

Wenn Sie Fehlermeldungen erhalten, überprüfen Sie die folgenden Anforderungen:

• Ein häufig auftretendes Problem ist ein falsches Kennwort. Führen Sie die drei Schritte erneut durch, und achten Sie besonders auf die Eingabe des verwendeten Benutzernamens und Kennworts.

• Um DoS-Angriffe (Denial-of-Service) zu verhindern, sind Sie auf fünf geöffnete PowerShell-Remoteverbindungen mit Security & Compliance PowerShell beschränkt.

• Das Benutzerkonto, mit dem Sie die Verbindung herstellen, muss für Remote-PowerShell aktiviert sein. Weitere Informationen finden Sie unter Aktivieren oder Deaktivieren des Zugriffs auf Exchange Online PowerShell.

• Der TCP-Port 80 muss für den Datenverkehr zwischen Ihrem lokalen Computer und Microsoft 365 geöffnet sein. Er ist wahrscheinlich offen, es kann jedoch vorkommen, dass Ihre Organisation eine eingeschränkte Internetzugriffsrichtlinie verfolgt.

• Möglicherweise können Sie keine Verbindung herstellen, wenn sich Ihre Client-IP-Adresse während der Verbindungsanforderung ändert. Dies kann vorkommen, wenn in Ihrer Organisation ein SNAT-Pool (Source Network Address Translation, Quell-Netzwerkadressenübersetzung) verwendet wird, der mehrere IP-Adressen enthält. Der Verbindungsfehler sieht wie folgt aus:

  Bei der Anforderung für die Windows-Remoteshell mit ShellId-ID <> ist ein Fehler aufgetreten, da die Shell auf dem Server nicht gefunden wurde. Mögliche Ursachen sind: Die angegebene Shell-ID ist falsch, oder die Shell ist nicht mehr auf dem Server vorhanden. Stellen Sie die richtige Shell-ID bereit, oder erstellen Sie eine neue Shell, und wiederholen Sie den Vorgang.

  Um das Problem zu beheben, verwenden Sie einen SNAT-Pool, der eine einzelne IP-Adresse enthält, oder erzwingen Sie die Verwendung einer bestimmten IP-Adresse für Verbindungen mit dem PowerShell-Endpunkt für die Sicherheitskonformität & .