PowerShell und Exchange Online-Sicherheit
Inhaltsverzeichnis
- Authentifizierungstypen
- Authentifizierungsrichtlinie
- Protokoll-Einschränkungen
- OWA Offline-Modus
- Nachrichtenfluss – EOP und Microsoft Defender für Office 365 (ehemals ATP)
- Role Based Access Control (RBAC)
- Exchange-/O365-Administration mit PowerShell automatisieren und delegieren
- Multi-Faktor-Authentifizierung
- Fazit
- Weiterführende Links

Hacker. Spammer. Phishing. Oh weh! (Okay, das war ein Klischee.)
Aber mal in Ernst: Exchange Online ist einer Vielzahl von Angriffen, Angriffsvektoren und Übeltätern ausgesetzt. Der Job eines Administrators ist mit dem Wechsel zu Cloud-Diensten in Bezug auf die Sicherheit schwieriger geworden. Unternehmen wie Microsoft bemühen sich jedoch, diese Ängste zu zerstreuen und Exchange Online-Admins Tools zur Verfügung zu stellen, mit denen sie diese Bedrohungen bewältigen können. In diesem Artikel sehen wir uns an, wie Sie PowerShell nutzen können, um Sicherheit für Exchange Online zu gewährleisten.
Authentifizierungstypen
Zunächst werfen wir einen Blick auf das Konzept der Authentifizierung:
Basic Authentication
Basic Authentication verwendet eine Passwort-Abfrage/Antwort für jede Interaktion mit einer Ressource in Exchange Online. Weitere Zugriffsanforderungen sind nicht implementiert. Wenn eine Verbindung zu Exchange Online nicht sicher ist, könnte das Kennwort abgefangen werden.
Modern Authentication
Modern Authentication basiert auf der Verwendung von OAUTH 2.0 und ADAL (Active Directory Authentication Library) unter Verwendung von Token-basierter Authentifizierung, die wesentlich mehr Sicherheit bietet.
Bei älteren Tenants ist Modern Auth möglicherweise deaktiviert, während es bei neueren Tenants standardmäßig aktiviert ist. Wir können unseren Tenant überprüfen, indem wir diesen Einzeiler in der Exchange Online PowerShell ausführen:
Get-OrganizationConfig | Ft OAuth2ClientProfileEnabled
Die nachfolgende Ausgabe zeigt, dass Modern Authentication aktiviert ist:
Wäre dies false, wäre Modern Auth ausgeschaltet, was gegen die Best Practices für Office 365 verstößt und auch keine sehr sichere Haltung darstellt. Stellen Sie sicher, dass dies aktiviert ist. Beachten Sie, dass dies nicht verhindert, dass sich Basic Auth-Clients mit Exchange Online verbinden. Es gibt andere Möglichkeiten, dies zu tun.
Der nächste Schritt ist das Blockieren von Basic Auth!
Authentifizierungsrichtlinie
Das Blockieren von Basic Auth für Exchange Online kann über mindestens zwei verschiedene Methoden erfolgen. Eine davon ist der bedingte Zugriff, auf den wir nicht näher eingehen werden (aber er kann mit PowerShell durchgeführt werden!), und die andere Methode ist eine sogenannte Authentifizierungsrichtlinie. Mit einer Authentifizierungsrichtlinie können wir steuern, welche Aspekte von Exchange Online Basic Auth verwenden oder nicht verwenden können. Zunächst einmal, was ist die Standardkonfiguration für eine Authentifizierungsrichtlinie? Nun, eigentlich keine!
Get-AuthenticationPolicy | fl

Okay. Nun, wenn es keine Richtlinie gibt, was können wir dann tun? Wir erstellen eine. Mit PowerShell ODER durch eine Änderung im M365 Admin Center. Wie stellen wir das an? Zuerst müssen wir die Standard-Authentifizierungsrichtlinie finden. Die Authentifizierungsrichtlinie befindet sich im M365 Admin Center unter Settings→ Org Settings → Modern Authentication, wo wir Folgendes vorfinden:
Damit die Richtlinie in der PowerShell erscheint, entfernen wir einfach ein Häkchen bei einem Punkt, sagen wir IMAP, speichern die Einstellungen und warten 15-30 Sekunden. Nach dem Warten können wir Folgendes ausführen:
Get-AuthenticationPolicy | fl
um die vorgenommene Änderung zu sehen:
Beachten Sie, dass AllowBasicAuthIMAP deaktiviert ist. Um Basic Auth für alle diese Protokolle zu blockieren, können wir diesen Einzeiler ausführen:
Set-AuthenticationPolicy -Identity 'BlockBasic637530830181380023' -AllowBasicAuthActiveSync:$False -AllowBasicAuthAutodiscover:$False -AllowBasicAuthImap:$False -AllowBasicAuthMapi:$False -AllowBasicAuthOfflineAddressBook:$False -AllowBasicAuthOutlookService:$False -AllowBasicAuthPop:$False -AllowBasicAuthReportingWebServices:$False -AllowBasicAuthRest:$False -AllowBasicAuthRpc:$False -AllowBasicAuthSmtp:$False -AllowBasicAuthWebServices:$False -AllowBasicAuthPowershell:$FalsengWebServices $False -AllowBasicAuthRpc $False -AllowBasicAuthSmtp $False -AllowBasicAuthWebServices $False -AllowBasicAuthPowershell $False
und überprüfen Sie die Änderungen:
Get-AuthenticationPolicy | fl
Wir haben jetzt Basic für die gesamte Liste der Verbindungstypen deaktiviert, die für die Verbindung mit Exchange Online verfügbar sind.
Protokoll-Einschränkungen
Für Exchange Online bietet Microsoft viele Protokolle für Endanwender an, um eine Verbindung zu ihrem Postfach herzustellen. Wir haben IMAP, POP, ActiveSync, ECP, MAPI, OWA und mehr. Typischerweise wollen wir weniger sichere Protokolle wie IMAP4 und POP3 blockieren, damit die Anwender diese nicht einsetzen, um sich mit einem Postfach zu verbinden. Wir können diese Verbindungen mit den CasMailboxPlan-Cmdlets steuern. Im Allgemeinen gibt es in Exchange Online vier Haupt-CAS-Postfachpläne, aber diese Anzahl kann je nach Lizenzierungsmodell variieren.
Für unser Beispiel haben wir einen Exchange Online-Tenant mit entweder E3- oder E5-Lizenzierung.
Wenn wir Get-CasMailboxPlan| Ft Name
ausführen, werden diese Pläne angezeigt:
- Deskless
- Regular
- Enterprise und
- Essentials
Wir können anzeigen, was in einem dieser Pläne verfügbar ist, indem wir dieses Cmdlet ausführen:
Get-CASMailboxPlan ExchangeOnlineEnterprise-a198b3f1-d047-49ed-b00d-b9ae84d0390a | Fl *Enabled
Wenn wir nun Protokolle deaktivieren müssen, IMAP und POP sind die besten Kandidaten, können wir dies wie folgt tun:
Set-CASMailboxPlan -Identity ExchangeOnlineEnterprise-a198b3f1-d047-49ed-b00d-b9ae84d0390a -IMAPEnabled $False -POPEnabled $False
Mit diesem Einzeiler können wir diese Änderung für alle Pläne auf einmal vornehmen:
Get-CASMailboxPlan | Set-CASMailboxPlan -IMAPEnabled $False -POPEnabled $False
Damit haben wir nun die Angriffsmöglichkeiten für den Zugriff auf Exchange Online-Postfächer reduziert.
OWA Offline-Modus
Eine der oft übersehenen Funktionen von Webmail, bekannt als OWA, ist die Funktion des Offline-Modus. Diese Funktion hinterlässt eine unverschlüsselte Kopie der letzten 500 E-Mails auf Ihrem Gerät, auf die Sie einfach zugreifen können, während Sie nicht verbunden sind. Die Theorie ist, dass Vielreisende in der Lage sind, mit ihren letzten E-Mails zu arbeiten, Antworten zu erstellen und mit den in den letzten E-Mails enthaltenen Informationen zu arbeiten. Allerdings ist die fehlende Verschlüsselung die Achillesferse dieses Setups.
Wir können uns das mit der PowerShell für die OWA Mailbox Policies wie folgt ansehen:
Get-OwaMailboxPolicy | Ft AllowOfflineOn

Wir sehen, dass sie tatsächlich eingeschaltet ist. Wie schalten wir sie nun aus? Nun, wir haben drei Optionen für AllowOfflineOn – PrivateComputersOnly, NoComputers oder AllComputers.
Der Wert, den wir brauchen, ist „NoComputers“, daher benötigt man zum Deaktivieren den Namen der Richtlinie und die Parameter für AllowOfflineOn:
Set-OwaMailboxPolicy -Identity OwaMailboxPolicy-Default -AllowOfflineOn NoComputers
Wenn wir mehr als eine OWA-Mailbox-Richtlinie haben, können wir sie für alle auf einmal deaktivieren:
Get-OwaMailboxPolicy | Set-OwaMailboxPolicy -AllowOfflineOn NoComputers
Die Anwender können den Offline-Modus nun nicht mehr für OWA verwenden und ihre E-Mails sind sicherer.
Nachrichtenfluss – EOP und Microsoft Defender für Office 365 (ehemals ATP)
Abhängig von der Lizenzierung und den in Exchange Online aktivierten Funktionen können EOP und Defender für Office 365 eine vielschichtige Verteidigung gegen bösartige E-Mails bieten. Diese Schichten umfassen Anti-Spam, Anti-Phishing und mehr.
Um zunächst zu beurteilen, wo wir uns befinden, können wir ein PowerShell-Modul namens ORCA verwenden, um nach Lücken zu suchen. ORCA ist eine Abkürzung für „Office 365 ATP Recommended Configuration Analyzer Report“, der so genannt wurde, bevor Microsoft das gesamte Namensschema für seine Produkte geändert hat.
Genauer gesagt prüft dieses Script nun Ihren Defender auf Office 365-Konfiguration. Wir können dieses Modul installieren, indem wir ein Windows PowerShell-Fenster öffnen und diesen Code eingeben:
Install-Module ORCA
Wir können einen schnellen Bericht starten, indem wir Folgendes ausführen:
Get-ORCAReport
Wir werden nach Anmeldeinformationen für ein globales Administratorkonto in Office 365 gefragt, und dann führt das Script seine Analyse durch:
Eine ähnliche Funktion können wir auch im Security and Compliance Center unter dem Namen „Configuration Analyzer“ sehen. Bemerkenswert ist, dass die Problembehebung hier vollständig in der GUI liegt. Bei der großen Anzahl von Validierungsprüfungen (über 60) wäre eine Scriptlösung zur Behebung dieser Probleme für die meisten Admins unerreichbar.
Dieses PowerShell-Modul sollte für einmalige oder automatisierte Berichte über den aktuellen Stand des Schutzes verwendet werden. Die Problem-Behebung über PowerShell liegt aufgrund der Komplexität der Konfiguration und des Umfangs der Funktionen / PowerShell-Cmdlets, die für diese Aufgabe erforderlich sind, außerhalb des Rahmens dieses Artikels.
Wenn ein Tenant aus irgendeinem Grund nicht über eine Lizenz für Defender für Office 365 verfügt, sollten die Funktionen getestet werden, um den Wert des Produkts zu beurteilen.
Wir können den Testmodus im Security and Compliance Center aktivieren → Threat Management → Policy → Evaluate Defender for Office 365.
Die Demo bleibt bis zu 90 Tage lang aktiv und das Reporting ist in der Evaluierung enthalten.
Role Based Access Control (RBAC)
Exchange war eines der ersten Produkte, das das Konzept der rollenbasierten Zugriffskontrolle erhielt, bei dem Operationen und Funktionen in Exchange über Rollengruppen und Verwaltungsrollen gewährt werden.
Management-Rollen sind die detaillierteren Berechtigungen für den Zugriff auf Exchange-Funktionen wie Journaling, Legal Hold und mehr. Rollengruppen hingegen sind Gruppierungen dieser Managementrollen, um logisch eine Jobfunktion oder eine Rolle zu erstellen, die jemand erfüllen kann, um legitime Aufgaben in Exchange zu erledigen.
Jetzt sind diese Konzepte von Exchange zu Exchange Online übergegangen.
Write-Host " Role Group Members "
Write-Host "----------------------"
$RoleGroup = Get-RoleGroup
Foreach ($Group in $RoleGroup) {
$Name = $Group.Name
$Members = Get-RoleGroupMember -Identity $Name
If ($Null -ne $Members) {
Write-Host "$Name "+": "
Foreach ($Member in $Members) {
$MemberName = $Member.Name
write-Host " - $MemberName"
}
Write-Host ''
} Else {
Write-Host "** $Name hat keine Mitglieder."
Write-Host ''
}
}
Dieser Code hilft uns herauszufinden, ob es zu viele Anwender gibt, die hoch privilegierten Rollen zugewiesen sind:
Im gegebenen Fall hat keine Gruppe mehr als drei Benutzer in einer Rollengruppe. Für die meisten Szenarien ist dies eine gute Zahl, mit der man arbeiten kann.
Nachdem der Bericht ausgeführt wurde, sollte jede Gruppe auf gültige Konten geprüft werden und ob der betreffende Benutzer noch in dieser Rollengruppe sein muss. Wenn nicht, sollten die Konten entfernt werden. Zusätzlich sollte eine Überprüfung dieser Zuweisungen regelmäßig in Verbindung mit anderen Sicherheitsüberprüfungen stattfinden.
Kostenloses Webinar
Exchange-/O365-Administration mit PowerShell automatisieren und delegieren
Gibt es bei Ihnen häufig wiederkehrende Aufgaben im täglichen Betrieb von Exchange / Exchange Online? Hier erfahren Sie, wie Sie:
- PowerShell-basierte Aufgaben zur Postfachverwaltung sicher delegieren können
- Anwendern die Ausführung bestimmter PowerShell-Scripte erlauben, ohne ihnen administrative Rechte zu geben
- PowerShell-Scripte einfach verwalten, abrufen und überwachen können
- die kostenlosen PowerShell-Scripts aus dem ScriptRunner ActionPack für Exchange Online verwenden
Multi-Faktor-Authentifizierung
In Office 365 gibt es auch einige Möglichkeiten, wie wir MFA für Anwender in einem Tenant aktivieren können. Wir können Conditional Access, Security Defaults verwenden oder sie individuell zuweisen. In diesem Artikel werden wir als Beispiel dafür, wie wir Anwender in einem Tenant absichern können, ausführen, wie dies über die individuelle Zuweisung geschieht.
Bevor wir uns damit befassen, lassen Sie uns zunächst erläutern, warum die Multi-Faktor-Authentifizierung verwendet werden sollte:
- erhöht die Sicherheit – erschwert es Angreifern, Benutzerkonten zu kompromittieren
- reduziert Bedrohungen um über 99 %
Microsoft bietet zahlreiche Ressourcen zu diesem Thema. Hier finden Sie eine gute Anlaufstelle dazu.
Um MFA auf Benutzerebene zu aktivieren, müssen wir uns zunächst über ein PowerShell-Modul mit dem MSOL-Dienst verbinden.
Wenn Sie dieses nicht installiert haben, holen Sie das nach, indem Sie Folgendes ausführen:
Install-Module MSOnline
Nach der Installation können wir die Verbindung zum MSOL-Dienst wie folgt starten:
Connect-MsolService
Dann führen wir diese Zeilen aus, um die MFA-Zuweisung für die Benutzer zu erstellen:
$st = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement
$st.RelyingParty = "*"
$st.State = "Enabled"
$sta = @($st)
Wir können dies dann für einen Benutzer wie folgt einstellen:
Set-MsolUser -UserPrincipalName damian@practicalpowershell.com -StrongAuthenticationRequirements $sta
Nach Fertigstellung können wir die Einstellungen überprüfen:
(Get-MsolUser -UserPrincipalName Damian@practicalpowershell.com).StrongAuthenticationRequirements | Fl
Jetzt müssen wir die ganze Prozedur nur noch für alle Benutzer, die MFA benötigen wiederholen. Sobald wir damit fertig sind, können wir mit diesem Code überprüfen, welche Benutzer die Einstellung jetzt besitzen:
Get-MsolUser -All | Where {$_.StrongAuthenticationRequirements -ne $Null} |ft DisplayName, UserPrincipalName,StrongAuthenticationRequirements
Und wir sehen unsere aktivierten Benutzer:
Damit können wir überprüfen, ob unsere Benutzer MFA auf Benutzerbasis aktiviert haben.
Fazit
Wenn wir uns die oben durchgeführten Konfigurationseinstellungen ansehen, können wir einige Schlussfolgerungen über Sicherheit, PowerShell und Exchange Online ziehen:
- Es kann kompliziert sein
- Microsoft bietet eine mehrschichtige Verteidigung gegen mehrere Angriffsvektoren
- Wir können all dies in PowerShell umsetzen
Um ein umfassenderes Verständnis der obigen PowerShell-Funktionen und der durchgeführten Sicherheitsmaßnahmen zu erhalten, sollten Sie die Docs-Seiten von Microsoft zu den einzelnen Themen lesen. Mit diesem Artikel und den Docs-Seiten werden Sie in der Lage sein, die oben genannten Aufgaben zu bewältigen und sie sicher für Ihren Mandanten zu konfigurieren. Sicherheit ist der Schlüssel in Exchange Online, also vergewissern Sie sich, dass Sie die oben genannten Funktionen auf Ihren Tenant anwenden.
Weiterführende Links
- Microsoft 365 identitätsmodelle und -Azure Active Directory – Microsoft 365 Enterprise | Microsoft Docs
- Allgemeine Identitäts- und Gerätezugriffsrichtlinien – Microsoft 365 unternehmensweite – Office 365 | Microsoft Docs
- Exchange Online-Begrenzungen – Service Descriptions | Microsoft Docs
- Microsoft-Empfehlungen für EOP und Defender für Office 365 Sicherheitseinstellungen – Office 365 | Microsoft Docs
- GitHub – cammurray/orca: The Microsoft Defender for Office 365 Recommended Configuration Analyzer (ORCA)
- Berechtigungen in Exchange Online | Microsoft Docs
- Multi-Faktor-Authentifizierung (MFA) – Microsoft Security
Zusammenhängende Posts
7 min read
Werden ChatGPT und AI unser PowerShell Scripting grundlegend verändern?
Mai 4, 2023 by Doug Finke
6 min read
Top PowerCLI Commands für deinen Admin‑Alltag – VM‑Inventory‑Management (Teil 1)
Apr 28, 2023 by Philip Lorenz
Ü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".
Neueste Beiträge:
- Effiziente VM-Verwaltung – Snapshots und Templates mit PowerCLI automatisieren (Teil 2)
- Werden ChatGPT und AI unser PowerShell Scripting grundlegend verändern?
- Top PowerCLI Commands für deinen Admin‑Alltag – VM‑Inventory‑Management (Teil 1)
- Diese Tools Vereinfachen dein Active Directory Troubleshooting
- ScriptRunner Portal Edition R5 – Mission erfüllt