Verwenden von Azure Automation zur Verarbeitung von Exchange Online-Daten mit PowerShell

Runbook unter bestimmten Umständen nützlich

Update: Dieser Artikel ist mittlerweile etwas veraltet. Azure Automation unterstützt keine RunAs-Konten mehr und das PowerShell-Modul für die Exchange Online-Verwaltung unterstützt jetzt verwaltete Identitäten.

Die Artikel von Practical365.com enthalten häufig PowerShell-Code, um die Prinzipien der Arbeit mit Microsoft 365-Daten zur Automatisierung allgemeiner Verwaltungsvorgänge zu veranschaulichen. Manchmal fragen Leser, ob es möglich ist, den Code mit Azure Automation-Runbooks zu verwenden. Auf die Antwort eines klassischen Beraters lautet meine Antwort: „Es kommt darauf an.“ Zu den Abhängigkeiten zählen die Funktionsweise des Codes, die beteiligten PowerShell-Module und die Frage, ob ein Skript interaktiv ist oder nicht. Sean McAvinue behandelt die Grundlagen in seinem Artikel über die Implementierung eines zeitgesteuerten Haftungsausschlusses in Exchange Online-Transportregeln, aber ich wollte den Prozess durcharbeiten und dokumentieren, wie man ein Azure-Automatisierungskonto und einige Runbooks erstellt. Folgendes habe ich entdeckt.

Update: Weitere Informationen zur Verwendung von Exchange Online mit Azure Automation und Managed Identities finden Sie in diesem Artikel.

Die Rolle von Azure Automation-Konten

Azure Automation ist die Möglichkeit, Arbeiten mithilfe virtueller Maschinen auszuführen. Um Azure Automation nutzen zu können, müssen Sie über ein Azure Automation-Konto verfügen, das mit einem Azure-Abonnement verknüpft ist (um die von Ihnen verbrauchten Ressourcen zu bezahlen). Das Automatisierungskonto wiederum unterstützt ein Azure RunAs-Konto, das zur Authentifizierung verwendet wird, um Zugriff auf die Ressourcen zu erhalten, die für die Ausführung von Arbeiten erforderlich sind, beispielsweise zum Ausführen eines PowerShell-Skripts in einem Runbook. Um die Dinge in Gang zu bringen, habe ich:

Beim Azure-Portal mit einem Konto angemeldet, das die Rolle „Azure-Besitzer“ für das Abonnement besitzt, das für das Automatisierungskonto verwendet werden soll.
Ein neues Automatisierungskonto erstellt. An dieser Stelle müssen Sie das Azure-Abonnement angeben.
Erstellt ein RunAs-Konto. Dies führt zur Erstellung eines Anwendungs- und Dienstprinzipals in Azure AD, der als Grundlage für Authentifizierung und Berechtigungen dient. Azure erstellt ein X.509-Zertifikat (ein Zertifizierungsobjekt im Konto), das der Dienstprinzipal ein Jahr lang zur Authentifizierung verwenden kann (das Zertifikat kann problemlos erneuert werden). Da Exchange Online derzeit keine von Azure verwalteten Identitäten unterstützt, empfiehlt sich die Verwendung eines RunAs-Kontos. Schließlich wird ein Verbindungsasset mit dem Namen AzureRunAsConnection verfügbar. Wir werden später sehen, wie dieses Asset verwendet wird.

Notieren Sie nach dem Erstellen des RunAs-Kontos die von Azure gemeldeten Informationen für die Anwendungs-ID und die Dienstprinzipal-Objekt-ID. Diese Angaben benötigen wir später, um Berechtigungen über PowerShell zuzuweisen.

Lesen Sie, wie Sie ein Runbook mit dem Microsoft Graph SDK für PowerShell verwenden.

Verwenden von Exchange Online PowerShell in Azure Automation

Exchange Online bietet die umfassendste PowerShell-Unterstützung aller Microsoft 365-Workloads. Abgesehen von Postfächern und anderen Aspekten der E-Mail-Verwaltung umfasst das Modul Microsoft 365-Gruppen und enthält, wenn Sie eine andere Sitzung mit dem Compliance-Endpunkt verbinden, Cmdlets zur Verwaltung von Information Governance und anderen Compliance-Lösungen. Daher ist es sinnvoll, die Erkundung von Azure Automation für Microsoft mit Exchange Online zu beginnen.

Wenn Sie PowerShell zum Ausführen von Microsoft Graph-Abfragen verwendet haben, wissen Sie, dass Sie eine App registrieren müssen, um über die erforderlichen Berechtigungen für den Zugriff auf Benutzer- und andere Daten zu verfügen. In den meisten Situationen benötigen Apps Anwendungsberechtigungen, um Aufgaben wie das Lesen von Benutzerprofilen, Gruppeninformationen usw. auszuführen. Administratoren müssen Apps ihre Zustimmung erteilen, um Anwendungsberechtigungen zu verwenden.

Ebenso muss ein Administrator die Zustimmung zum Verwaltungszugriff auf Exchange Online erteilen, bevor ein RunAs-Konto Cmdlets im Exchange Online-Verwaltungsmodul verwenden kann. Sie können dies über den Abschnitt „Registrierte Apps“ des Azure AD Admin Centers in drei Schritten tun:

Wählen Sie die für das RunAs-Konto erstellte App aus (ihr Name ist das Automatisierungskonto plus eine zufällige Zeichenfolge wie ExoAutomationAccount_Y6LgjDYIfPnxmFzrqdbaClsnTD/gN4BNnVMywiju5hk=).
Weisen Sie die Berechtigung ExchangeManageAsApp über die Office 365 Exchange Online-API zu.
Erteilen Sie der Organisation Ihre Zustimmung.

Abbildung 1 zeigt, dass die Berechtigung ExchangeManageAsApp mit Zustimmung erteilt wird.

Sie müssen außerdem den Dienstprinzipal für das RunAs-Konto zur Exchange-Administratorrolle hinzufügen. Sie können dies im Abschnitt „Rollen und Administratoren“ des Azure AD Admin Centers tun (Abbildung 2).

Importieren Sie das Exchange Online-Verwaltungsmodul

Der Dienstprinzipal für das RunAs-Konto verfügt jetzt über die entsprechenden Berechtigungen, um als Exchange Online-Administrator zu fungieren. Der nächste Schritt besteht darin, dem Automatisierungskonto die Verwendung der Exchange-Cmdlets zu erlauben. Denken Sie daran, dass Azure Automation nicht an bestimmte Maschinen gebunden ist. Sie müssen daher das Exchange Online-Verwaltungsmodul importieren, um es als gemeinsam genutzte Ressource für das Automatisierungskonto verfügbar zu machen. Wenn Azure Automation ein Runbook ausführt, das Exchange-Cmdlets aufruft, wird das Modul automatisch geladen.

Suchen Sie zunächst im Abschnitt „Gemeinsame Ressourcen“ nach „Modulen“ (viele Module sind bereits vorinstalliert, Exchange jedoch nicht). Durchsuchen Sie dann die Modulgalerie, um das Exchange Online-Verwaltungsmodul zu finden (Abbildung 3). Wählen Sie das Modul aus, wählen Sie Version 5.1 als PowerShell-Laufzeitversion und importieren Sie dann das Modul. Dies kann einige Minuten dauern. Sie können die Modulansicht aktualisieren, um zu erfahren, wann der Import abgeschlossen ist.

Weitere Microsoft 365-Module sind ebenfalls in der Galerie verfügbar, darunter Azure AD, Teams und SharePoint Online. Für viele Aufgaben sind Cmdlets von mehreren Modulen erforderlich. Je nachdem, was Sie tun möchten, müssen Sie möglicherweise andere Module importieren.

Erstellen und Testen eines Runbooks

Runbooks werden von Azure Automation verwendet, um die Arbeit zu erledigen. In diesem Fall könnten Sie sich ein Runbook als ein vollständiges PowerShell-Skript vorstellen, das bereit ist, in einer Sandbox ausgeführt zu werden. Sie erstellen neue Runbooks im Abschnitt „Prozessautomatisierung“ für das Automatisierungskonto. Azure lädt mehrere Tutorial-Runbooks in das Konto, um Benutzern den Einstieg in die Technik zu erleichtern.

Um die Dinge zu testen, habe ich ein Skript verwendet, das das Überwachungsprotokoll durchsucht, um Gruppenlöschereignisse zu melden, und den Code in ein neues PowerShell-Runbook kopiert. Vor dem kopierten Code habe ich einige Zeilen eingefügt, um eine Sitzung mit der Automatisierungsverbindung (AzureRunAsConnection) zu erstellen und eine Verbindung zu Exchange Online herzustellen und mich mithilfe des Zertifikatfingerabdrucks zu authentifizieren, der für das Konto erstellt wurde, das die Sitzung mit der Automatisierungsverbindung verwendet.

$Session = Get-AutomationConnection –Name AzureRunAsConnection
$Tenant = 'office365itpros.onmicrosoft.com'
Connect-ExchangeOnline –CertificateThumbprint $Session.CertificateThumbprint –AppId $Session.ApplicationID –ShowBanner:$false –Organization $Tenant

Denken Sie daran, dass unser Automatisierungskonto über die Berechtigung zum Verwalten von Exchange als App verfügt und der Dienstprinzipal Mitglied der Exchange-Administratorrollengruppe ist. Sobald das Runbook authentifiziert ist, kann es also jedes Exchange-Verwaltungs-Cmdlet ausführen.

Wenn Sie jemals eine PowerShell ISE oder den Cloud Shell-Editor zum Arbeiten mit PowerShell-Code verwendet haben, wird Ihnen der Runbook-Editor vertraut sein (Abbildung 4). Um Code von der interaktiven Nutzung zur Automatisierung zu übertragen, müssen alle Benutzerinteraktions-Cmdlets (wie Read-Host) entfernt werden, während Write-Output Write-Host ersetzt. Denken Sie daran, dass der Code in einer Headless-Sandbox ausgeführt wird, sodass es keinen Sinn macht, Benutzerinteraktionen einzubeziehen. Wenn Sie fertig sind, speichern Sie den Code und klicken Sie auf das Symbol Testbereich.

Im Testbereich können Sie das Runbook ausführen und überprüfen, ob Ihr Code funktioniert. Klicken Sie auf „Start“, um zu beginnen. Azure Automation stellt das Runbook in die Warteschlange und wenn eine Ressource (eine Sandbox-Maschine) verfügbar ist, wird der Code ausgeführt. Sie sehen nichts, bis ein Fehler auftritt oder das Skript beendet wird. Anschließend werden im Testbereich alle Ausgaben angezeigt (Abbildung 5).

Wenn Sie ein Skript innerhalb eines kurzen Zeitraums mehrmals ausführen, drosselt Exchange Online möglicherweise Ihre Verbindung. Wenn das passiert, ist es Zeit für eine Tasse Kaffee. Der Drosselmechanismus erlischt nach einigen Minuten und Sie können es erneut versuchen. Alternativ können Sie das Cmdlet „Disconnect-ExchangeOnline“ in Ihr Skript einbinden, um die Sitzung zu schließen.

Sobald Sie sicher sind, dass der Code funktioniert, können Sie das Runbook veröffentlichen (klicken Sie beim Bearbeiten des Codes auf das Symbol „Veröffentlichen“, wie in Abbildung 4 dargestellt). Sie erhalten dann eine Entwurfsversion des Runbooks für die weitere Entwicklung und eine veröffentlichte Version, die auf unterschiedliche Weise ausgeführt werden kann. Beispielsweise können Sie Azure Automation so planen, dass die Ausführung einmal zu einem bestimmten Datum und zu einer bestimmten Uhrzeit oder in Intervallen ausgeführt wird.

Zertifikatbasierte Authentifizierung für Sicherheit und Compliance

Die bisherige Beschreibung deckt Cmdlets im Hauptverwaltungsmodul von Exchange Online ab. Das Modul enthält außerdem die Sicherheits- und Compliance-Cmdlets, die nach der Ausführung des Cmdlets Connect-IPPSSession nutzbar werden. Diese Cmdlets unterstützen derzeit keine zertifikatbasierte Authentifizierung, werden dies aber bald tun. Laut Microsoft 365 Message Center-Benachrichtigung MC316448 (21. Januar 2022) soll die Funktion bis Anfang März überall verfügbar sein.

Wenn Sie zunächst die Sicherheits- und Compliance-Cmdlets verwenden möchten, können Sie dem Automatisierungskonto einen Benutzernamen und ein Kennwort hinzufügen. Das Konto kann keine Multi-Faktor-Authentifizierung (MFA) verwenden und muss ein Exchange-Administrator sein. Das Fehlen von MFA macht dies zu einer weniger wünschenswerten Methode, dient aber als Beweis dafür, dass Azure Automation verschiedene Arten von Anmeldeinformationen unterstützt. Ich habe diese Methode mit anderen Modulen verwendet, die keine zertifikatbasierte Authentifizierung unterstützen, wie zum Beispiel dem SharePoint Online-Verwaltungsmodul.

Dieser Code greift auf einen gespeicherten Benutzernamen und ein Kennwort zu, die als Anmeldeinformationen im Automation-Konto mit dem Namen O365Password gespeichert sind, und verwendet die Anmeldeinformationen, um eine Verbindung zum Sicherheits- und Compliance-Endpunkt herzustellen:

$O365Cred = Get-AutomationPSCredential -Name "O365Password"
Connect-IPPSSession -Credential $O365Cred

Automatisierung mit Graph-APIs

Natürlich decken Exchange Online-Cmdlets nicht alle Daten ab, auf die Sie zugreifen möchten, aber die Chancen stehen gut, dass eine Microsoft Graph-API dies tut. Als Beispiel habe ich ein Skript genommen, das zum Melden von Anmeldeinformationen für Dienstprinzipale verwendet wird, und es in ein Runbook importiert. Wenn Sie ein Skript zur Interaktion mit Graph-API-Abfragen schreiben, ist normalerweise eine Präambel vorhanden, um eine registrierte App, einen Mandanten und ein App-Geheimnis (oder Zertifikat) zu identifizieren, das zur Authentifizierung und Rückgabe eines Zugriffstokens verwendet wird. Wenn Sie ein Runbook verwenden, verwenden wir das Automatisierungskonto anstelle einer registrierten App und den Zertifikatfingerabdruck anstelle eines App-Geheimnisses. Daher ersetzen wir die normale Präambel durch einen Verbindungscode wie folgt:

# Set up a connection
$Connection = Get-AutomationConnection -Name AzureRunAsConnection
# Get certificate from the automation account
$Certificate = Get-AutomationCertificate -Name AzureRunAsCertificate
# Get an access token using the Get-MsalToken cmdlet from the MSAL.PS Module
$GraphConnection = Get-MsalToken -ClientCertificate $Certificate -ClientId $Connection.ApplicationID -TenantId  $Connection.TenantID 
# Populate the headers for our Graph queries
$Header =  @{Authorization = "Bearer $($GraphConnection.AccessToken)"}

Dieser Code verwendet ein Modul namens MSAL.PS (Microsoft Authentication Library), um ein Zugriffstoken zu erhalten. Mehr zum Modul können Sie hier lesen.

Denken Sie daran, dass der Dienstprinzipal für das RunAs-Konto Berechtigungen zum Zugriff auf Daten benötigt. In diesem Fall muss ein Administrator die Zustimmung für die Anwendungsberechtigungen Directory.Read.All und AuditLog.Read.All erteilen. Das Zugriffstoken bestätigt, dass die Berechtigungen verfügbar sind, sodass wir Folgendes ausführen können:

$Uri = "https://graph.microsoft.com/beta/auditLogs/signIns?&`$filter=createdDateTime ge " + $StartDate + " and createdDateTime le " + $EndDate + " and signInEventTypes/any(z:z eq 'servicePrincipal')"
[array]$SpSignInData = Invoke-RestMethod -Method GET -Uri $Uri -ContentType "application/json" -Headers $Header

Danach geht es darum, alles zu verarbeiten, was die Graph-Abfrage zurückgibt, und es zu melden. Abbildung 6 zeigt, wie die Daten im Testbereich angezeigt werden.

Automatisierung für das Unternehmen

Meiner Ansicht nach besteht die beste Verwendung von Azure Automation-Runbooks darin, große Datenmengen in Jobs zu verarbeiten, die wahrscheinlich längere Zeit in Anspruch nehmen, z. B. das Entnehmen täglicher Datenextrakte aus dem Office 365-Überwachungsprotokoll und das Schreiben dieser in ein externes Repository zur langfristigen Aufbewahrung . Im Wesentlichen handelt es sich hierbei um ein Unternehmensspiel.

Andere Ad-hoc-Verwaltungsverfahren, wie die Überprüfung, welche Microsoft 365-Gruppen keine Besitzer haben oder welchen Teams Vertraulichkeitsbezeichnungen fehlen, sollten besser interaktiv ausgeführt werden, es sei denn, eine Organisation führt diese Überprüfungen regelmäßig durch. In diesem Fall ist ein Runbook eine gute Wahl.

Die Dinge, an die Sie sich erinnern sollten, sind:

Sie benötigen ein Azure-Abonnement. Sie werden nicht viel ausgeben, es sei denn, Ihr Datenvolumen ist groß, aber Sie müssen trotzdem ein Abonnement haben. Ich habe es geschafft, fünf Cent für Runbooks auszugeben, die während des Schreibens dieses Artikels entwickelt wurden.
In Skripten findet keine Benutzerinteraktion statt. Beispielsweise können Sie einen Benutzer nicht auffordern, zu bestätigen, dass ein Vorgang fortgesetzt werden soll.
Runbooks werden auf Sandbox-Maschinen ausgeführt. Wenn Sie die Ergebnisse der Verarbeitung als Datei speichern möchten, müssen Sie dies an einem Netzwerkspeicherort tun. Andernfalls könnten Sie eine E-Mail senden oder eine Nachricht an einen Teams-Kanal posten.

Wie bei jeder anderen Technologie liegt die Genialität darin, die Stärken der Azure-Automatisierung zu nutzen und gleichzeitig ihre Nachteile zu minimieren. Wie bei jedem anderen Tool gilt: Sobald Sie wissen, wie man damit echte Arbeit erledigt, werden Sie wahrscheinlich eine Verwendung für ein oder zwei Runbooks finden. Exchange Online und andere Microsoft 365 PowerShell-Module sind in Runbooks zugänglich und nutzbar, ebenso wie Microsoft Graph API-Abfragen, sodass viel Potenzial vorhanden ist. Durch etwas Übung und Ausprobieren wird sich bald zeigen, ob Azure Automation-Runbooks leistungsstark genug sind, um zu einem wichtigen Tool in Ihrem Toolset für die Mandantenverwaltung zu werden.