So klappt die Verbindung zu Exchange Online mit CBA (zertifikatsbasierter Authentifizierung)

Im Artikel erfährst du, wie CBA (Certificate Based Authentication) für Exchange Online PowerShell funktioniert. Da die 'Basic Authentication' deaktiviert wurde, ein Thema mit Relevanz. 

PowerShell und Security sollten nicht behandelt werden wie zwei flüchtige Bekannte, sondern in den Köpfen von Administratoren, die ihre Skripte vor Ort oder in der Cloud ausführen, eng miteinander verzahnt werden. Beim Arbeiten mit Exchange Online (ExO) über PowerShell ist das nicht anders. In diesem Artikel werden wir einige Änderungen untersuchen, die Administratoren vornehmen müssen, um eine sichere Verbindung mit PowerShell herzustellen, nachdem die Basisauthentifizierung (Basic Authentication / Basic Auth) deaktiviert wurde. Wir werden die verschiedenen Verbindungen und die damit verbundene Sicherheit überprüfen und schließlich die zertifikatsbasierte Authentifizierung (CBA) für Exchange Online PowerShell behandeln.

Optionen beim Speichern und Übergeben von Credentials

Die erste Schutzmaßnahme beim Herstellen einer Verbindung zu einem Zielsystem ist die Art der Übergabe von Anmeldeinformationen an dieses System. Mit PowerShell stehen viele Optionen zur Verfügung, und Administratoren haben bei der Arbeit mit den von ihnen betreuten Systemen wahrscheinlich mindestens drei oder mehr der folgenden Methoden verwendet:

Clear Text: Klartext im Skript [schlechte Idee, bloß nicht nachahmen!] – Beispiel: Uber Hack
Password File: verschlüsselte Passwortdatei auf dem lokalen Rechner [etwas besser als Klartext, aber schlecht, wenn keine entsprechenden Zugriffsberechtigungen gesetzt sind]
Local Credentials: lokal gespeicherte Zugangsberechtigungen im PowerShell Secrets-Modul [sicherer als eine Kennwortdatei, verschlüsselt]
Certificates: Verwende ein selbst-signiertes Zertifikat oder ein Zertifikat eines Drittanbieters als Identitätsnachweis (Azure App-Registrierung erforderlich) [am sichersten]
Azure Automation Credentials: Azure Automations-Anmeldeinformationen erfordern eine spezielle Konfiguration in Azure [am sichersten]
Azure Key Vault: Credentials werden in einem Azure Key Vault gespeichert (Azure-Ressourcen erforderlich) [am sichersten]

Ändern der Authentifizierung

Bis Oktober letzten Jahres konnten Administratoren mit dem Cmdlet New-PSSession (zusammen mit einigen anderen Kriterien) eine Verbindung zu Exchange Online mit einfacher Authentifizierung herstellen. Nun, da Microsoft diese Tür geschlossen hat und diese Verbindungen nicht mehr zulässt, müssen wir andere Optionen in Betracht ziehen. Im Dezember kündigte Microsoft dann eine weitere Änderung für Exchange Online PowerShell-Verbindungen an, bei der ab Juli 2023 RPS (Remote PowerShell) ebenfalls blockiert wird (Microsoft Announcement und Update Juli 2023)

Was wurde durch diese Änderung abgeschafft?

• Jede mit New-PSSession aufgebaute Verbindung
• Exchange Online-PowerShell-Modul v1 oder v2
• Jedes Exchange Online PowerShell-Modul, das den Parameter -UseRPSSession verwendet

Was ist der Ersatz?

Es ist nicht alles verloren, da Microsoft eine Methode für die Verbindung mit Exchange Online über PowerShell bereitgestellt hat. Dazu gehören die Verwendung des Exchange Online PowerShell-Moduls v3 (ohne -UseRPSSession-Parameter) oder die Verwendung der zertifikatsbasierten Authentifizierung (CBA). In diesem Artikel wird die Verwendung von CBA untersucht, da diese sowohl für die interaktive Ausführung von Skripts als auch für die sichere Ausführung von Automatisierungsskripts zur Ausführung von Aufgaben ohne Benutzereingriff verwendet werden kann.

Einrichten von CBA

Die Einrichtung der zertifikatsbasierten Authentifizierung (CBA) für Exchange Online erfordert nur wenige Komponenten. Wir müssen einige Voraussetzungen erfüllen, um eine erfolgreiche Verbindung mit PowerShell herzustellen:

• 1. Registriere eine Anwendung in Azure AD
• 2. Weise der Anwendung API-Berechtigungen zu
• 3. Erstelle ein selbst-signiertes Zertifikat
• 4.  Verknüpfe das Zertifikat mit der Azure App
• 5. Weise Azure AD-Rollen zu

Anwendung registrieren

Gehe zunächst direkt zur Seite App-Registrierungen im Azure-Tenant:
https://portal.azure.com/#view/Microsoft_AAD_RegisteredApps/ApplicationsListBlade

Dort klickst du auf die Schaltfläche 'Neue Registrierung':

(1) Füge einen Namen für die App hinzu, (2) verwende die Standard-Account-Typen (für die meisten Szenarien), (3) wähle 'Web' aus dem Dropdown-Menü, (4) gib eine Domain für diese Umleitung ein. Klicke auf Registrieren und fertig ist eine App, die wir mit der PowerShell verwenden können.

API-Berechtigungen für die App zuweisen

Dieser Teil ist etwas kniffliger, aber Microsoft bietet hier eine gute Anleitung in seiner Dokumentation. Die Schritte lassen sich wie folgt zusammenfassen: 

1. Klicke auf die App, die du gerade in deinem Tenant erstellt hast, und nimm die in diesem Schritt von Microsoft beschriebenen Änderungen am Manifest-Code der Anwendung vor:

JSON wird für den Zugriff benötigt (siehe Microsoft documentation)

2. Gehe dann zu 'API-Berechtigungen' für die App und (1) erteile die Zustimmung und (2) füge diese Exchange-Berechtigung hinzu:

API-Berechtigungen in Azure registrierten Apps

Ein selbst-signiertes Zertifikat erstellen

Als Nächstes brauchen wir das Zertifikat, mit dem die Verbindung zwischen der Konsole, auf der das PowerShell-Skript läuft, und Exchange Online überprüft wird. Wir können ein selbstsigniertes Zertifikat mit der PowerShell erstellen. Zum Beispiel muss eine Organisation mit der Domäne PowerShellGeek.com das Zertifikat erstellen, was wichtig ist, da wir es für die App und das Zertifikat benötigen:

Erzeuge das Zertifikat

$NewCertificate = New-SelfSignedCertificate -DnsName "PowerShellGeek.com" -CertStoreLocation "cert:\CurrentUser\My" -NotAfter (Get-Date).AddYears(1) -KeySpec KeyExchange

Erstelle eine PFX-Version des Zertifikats

$NewCertificate | Export-PfxCertificate -FilePath ExOConnection.pfx -Password (Get-Credential).password

Hinweis: Markus vom ScriptRunner-Team hat dazu einen lesenswerten Blogbeitrag verfasst:  Wie erstelle ich PFX-Dateien mit PowerShell?

Erstelle eine CER-Version des Zertifikats

$NewCertificate | Export-Certificate -FilePath c:\ExOConnection.cer 

Beachte, dass der Benutzername für die obige Anmeldungsaufforderung nicht verwendet wird, sondern wir etwas eingeben müssen, um zumindest das Passwort zu erfassen.

Zwei mit der PowerShell erstellte Dateien für die spätere Verwendung

Zertifikat zur Azure-App hinzufügen

Jetzt, da wir ein Zertifikat haben, können wir es zu unserer Azure App hinzufügen, die wir zuvor erstellt haben. Gehe zurück zum Azure Portal und dann zu 'App-Registrierungen':

Suche die App, die du im vorherigen Schritt erstellt hast, und öffne sie. Klicke dann auf 'Zertifikate & Geheimnisse'.

Zertifikates für die Azure-App

Klicke auf 'Zertifikat hochladen' und wähle das Zertifikat aus, das du mit der PowerShell erstellt hast:

Achte darauf, dass du den Thumbprint des Zertifikats irgendwann während dieses Prozesses abrufst, denn er wird für die Verbindung mit Exchange Online PS benötigt. In diesem Beispiel lautet der Thumbprint des Zertifikats: AE20B242AE58AA3ABED4D57C22253E2F7572B404

Hinweis: Achte darauf, die erzeugten Zertifikatsdateien mit den entsprechenden NTFS-Berechtigungen zu sichern, damit sie nicht zum schwächsten Glied in deiner sicheren PowerShell-Kommunikation werden. 

Azure AD-Rollen zuweisen

Der letzte Teil des Prozesses besteht nun darin, verschiedenen Rollen in Azure AD Zugriff auf diese Azure App zu gewähren. Das befähigt die jeweiligen Benutzer, mit den ihnen zugewiesenen Rollen eine Verbindung mit der PowerShell mit den richtigen Berechtigungen herzustellen. Dies geschieht im Azure AD-Portal (https://aad.portal.azure.com). In diesem Beispiel weisen wir die Rolle 'Global Administrator' zu, könnten sie aber genauso gut der Rolle 'Exchange Services Admin' zuweisen.

Klicke auf Zuweisungen hinzufügen ('Add assignments'), suche nach der App, die erstellt wurde, wähle sie aus und klicke auf 'Hinzufügen', um diesem Benutzer Berechtigungen zu erteilen.

Zuweisung Azure AD Gruppenrolle

Mit CBA verbinden

Sobald wir ein Zertifikat, API-Berechtigungen und ein Zertifikat mit der App verknüpft haben, können wir ExO PS v3 für die Verbindung verwenden.

PowerShell für ExO v3 herunterladen

Install-Module ExchangeOnlineManagement

Modul in PowerShell laden

Import-Module ExchangeOnlineManagement

Verbindung zu Exchange Online PowerShell herstellen

Um eine ordnungsgemäße Verbindung mit PowerShell unter Verwendung von CBA herzustellen, benötigen wir einige Komponenten:

(A) Thumbprint aus dem Zertifikatsprozess:

Wie bereits erwähnt und dokumentiert, benötigen wir den Thumbprint des Zertifikats, das wir erstellt und mit der Azure-App verknüpft haben:

AE20B242AE58AA3ABED4D57C22253E2F7572B404

(B) Wir brauchen auch die Anwendungs-ID der erstellten Azure-App:

Hier findest du die Azure App ID für PowerShell

Sobald wir diese beiden Informationen haben, können wir uns mit dem Zertifikat mit Exchange Online verbinden:

Connect-ExchangeOnline -CertificateThumbPrint <Certificate Thumbprint> -AppID <App ID> -Organization "<tenant>.onmicrosoft.com"

Connect-ExchangeOnline -CertificateThumbPrint AE20B242AE58AA3ABED4D57C22253E2F7572B404 -AppID 279fcdda-c0b9-4f99-b2d7-c99dd2376d3c -Organization tenantdomain.onmicrosoft.com

Jetzt sind wir mit einem Zertifikat mit Exchange Online verbunden.

Warum überhaupt CBA verwenden?

Jetzt, wo wir wissen, wie wir es einrichten und verwenden können, stellt sich die Frage, warum wir CBA überhaupt verwenden sollten? Das ExO v3 Modul kann sich auch ohne CBA mit Exchange Online verbinden. Wir können die Anmeldedaten aus einer sicheren Textdatei, dem Secrets PowerShell-Modul oder manuell eingeben. Warum überhaupt CBA verwenden? CBA bietet eine sicherere Verbindung, lässt deine Anmeldedaten (Anmeldename und Kennwort) nicht ungeschützt und gilt als sicherer in der Anwendung. CBA vereinfacht außerdem die Authentifizierung und macht die Automatisierung von Skripten einfacher.

Welche anderen Workloads können CBA nutzen?

• Sicherheits- und Compliance Center PowerShell
• Microsoft Teams
• SharePoint PNP
• usw.

Jeder dieser Workloads sollte eine eigene App haben, damit sie nach dem Prinzip der geringsten Berechtigung zugewiesen werden können. Wenn sonst der gesamte Zugriff über eine App erfolgt, kann ein Benutzer, der dieser App zugewiesen ist, mehr Rechte haben, als er für seine Arbeit benötigt, was ein Sicherheitsproblem darstellt. 

(Links) eine Azure-App, die mehreren Workloads zugeordnet ist
(Rechts) eine Azure-Anwendung, die nur einem Workload zugeordnet ist

Fazit

Die zertifikatsbasierte Authentifizierung ist nur eine Methode der Authentifizierung für Exchange Online, aber sie bietet eine sicherere Verbindung als diejenige, die die Anmeldung und das Kennwort des Administrators (Klartext, sichere Datei oder anders) erfordert. Die Umstellung auf CBA für Exchange Online ist etwas, das Administratoren tun sollten, denn die Einrichtung ist einfach, bequem und sicher und kann in automatisierten Skripten sowie in anderen Arbeitslasten wie Security and Compliance Center, SharePoint PnP und Teams verwendet werden.

Lass dich nicht wie Uber mit Klartextpasswörtern in deinen Skriptdateien hacken!

Weiterführende Links

• Markus' Artikel: Wie erstelle ich PFX-Dateien mit PowerShell?
• ScriptRunner ActionPacks für O365
• Entdecke unser Produkt hier
• Artikel zum Uber Hack
• ScriptRunner: Sprich mit einem Produktexperten