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!
Webinar: PowerShell Security Best Practices
Die sichere Ausführung von PowerShell-Skripten ist unerlässlich, wenn es um die Verwaltung komplexer IT-Infrastrukturen geht. Unter anderem müssen die erforderlichen Anmeldeinformationen sicher aufbewahrt werden.
Die PowerShell selbst verfügt bereits über viele Sicherheitsfunktionen, und ScriptRunner erweitert diese für eine sichere Delegation und zentrale Verwaltung von Skripten und Anmeldeinformationen.
Dieses Webinar richtet sich an Administratoren, IT- und DevOps-Experten, PowerShell-Entwickler und IT-Manager.
Darum geht es in dem Webinar:
- Wie du das PowerShell SecretManagement Modul verwendest
- Arbeiten mit Ausführungsrichtlinien
- Sichere Verwaltung von Anmeldeinformationen
- Integration von Passwort-Servern
- Delegierung einzelner, parametrisierbarer PowerShell-Skripte ohne administrative Rechte des Benutzers
- Sichere browserbasierte Ausführung von PowerShell-Skripten
Die Aufzeichnung des Webinars ist verfügbar.
Weiterführende Links
Zusammenhängende Posts
Über den Autor:
Damian Scoles ist ein zehnfacher Microsoft MVP mit Spezialisierung auf Exchange, Office 365 und PowerShell, der über 25 Jahre Erfahrung in der IT-Branche mitbringt. Er ist im Großraum Chicago ansässig und begann mit der Verwaltung von Exchange 5.5 und Windows NT. Im Laufe der Jahre hat er mit Office 365 seit BPOS gearbeitet und darüber hinaus Erfahrung mit Azure AD, Security and Compliance Admin Centers und Exchange Online. Zu seinem Engagement in der Community gehören Beiträge in TechNet-Foren, die Erstellung von PowerShell-Skripten, die in seinen Blogs zu finden sind, das Schreiben von ausführlichen PowerShell/Office365/Exchange-Blogartikeln, Tweets und die Erstellung von PowerShell-Videos auf YouTube. Er hat fünf PowerShell-Bücher geschrieben und arbeitet außerdem aktiv an dem Buch "Microsoft 365 Security for IT Pros".