Zur HAFNIUM Sicherheitslücke in Exchange Server stehen Informationen auf zahlreichen Seiten zur Verfügung.
Dieser Post dient der Sammlung von Links zu diesem Thema.
Wenn Sie einen Link vermissen, senden Sie mir gerne eine E-Mail an Exchange2019@Exchange-Doktor.de
Update 2021-03-17: Guidance for responders: Investigating and remediating on-premises Exchange Server vulnerabilities hinzugefügt
Heute wurde die elfte Folge von Thomas' Tech Talk veröffentlicht.
Das Thema des Talks ist:
Das PowerShell-Skript HealthChecker.ps1 hilft Ihnen bei der korrekten Konfiguration des Serversystems, auf dem Sie eine Exchange Server Installation betreiben. Nutzen Sie dieses Skript nach der Installation und Basiseinrichtung des Servers.
Die Aufgabe des Skriptes ist es nicht, Exchange Server richtig zu konfigurieren, sondern Empfehlungen für die Konfiguration der Betriebssystemkomponenten wie Netzwerk-Adapter, Page File, C++ Bibliotheken, CPU oder den Arbeitsspeicher zu geben. Wenn Sie die vom Skript empfohlenen Einstellungen umsetzen, erhöhen Sie die Betriebssicherheit und Stabilität des Exchange Server Systems.
In diesem Tech Talk zeige ich Ihnen, wie hilfreich und einfach dieses Skript ist.
<!--cke_bookmark_408E--><!--cke_bookmark_104E-->
Viel Spaß.
Exchange Server and Exchange Online use retention policies to group retention tags. A retention tag defines how and when Exchange should delete a mailbox object automatically or move it to the archive mailbox. Most of the time, you think of emails when talking about Exchange mailbox objects. We stay with emails for this article.
Sometimes, retention policies show an unexpected behavior, and you want to clean up the retention information from a mailbox.
To understand how to clean up the policies, we need to know the basics.
Default tags and personal tags specify what the Managed Folder Assistant should do with the emails. You assign one or more retention tags to a retention policy. You then assign the retention policy to a mailbox.
Default tags are assigned to the whole mailbox. End users can set personal tags to folders or single elements. The third tag, the default folder tag, is primarily used in delete policies.
A retention policy can have one or more default or personal retention tags. A single mailbox can only have one policy assigned.
The following screenshot shows the default retention policies for user and arbitration mailboxes, and two additional test policies.
If you want to know more about retention tags and policies, I recommend reading the Microsoft documentation.
But what exactly would we like to remove from a mailbox?
Removing a retention policy from a mailbox is simple. You replace the assigned policy with another policy, or you set the attribute to $null to remove the policy assignment. Removing or replacing a retention policy does not remove personal tags assigned to folders by the user.
If you want to remove a personal tag from a mailbox, Microsoft has the answer for you:
But what if other users in your Exchange organization also use this personal tag? Deleting a personal retention tag from the Exchange Organization will remove this tag from all mailboxes.
Supposed you have a delete policy (default tag) set on a mailbox. Also, you allow the user to exclude folders with a personal tag. Removing this personal tag for all mailboxes will lead to significant calls for your helpdesk because the Managed Folder Assistant will delete all emails from all mailboxes. Not to say that you must restore the mails.
But help is on the way. The tool RemovePersonalRetentionTag helps you cleaning up retention tags.
With this tool, you can remove one or more personal tags from the folders in a single mailbox without deleting the tag from your Exchange Organization.
You need impersonation rights for the mailbox you want to clean up. And basic authentication needs to be enabled for Exchange Online if the mailbox is an EXO mailbox. At this time, the code uses Exchange Web Services to remove retention tags.
If you want to remove all personal tags from a mailbox, it is simple:
RemovePersonalRetentionTag.exe -mailbox "user@example.com" -impersonate
If you want to remove a specific tag, you must know the retention tag id.
First, grab a list of the retention tag ids in your environment:
Get-RetentionPolicyTag -Types Personal | Select Name,RetentionId | ft -a
RemovePersonalRetentionTag.exe -mailbox "user@example.com" -impersonate -retentionid "a7966968-dadf-4df7-ae87-4482686b4634"
RemovePersonalRetentionTag.exe -mailbox "user@example.com" -impersonate -retentionid "a7966968-dadf-4df7-ae87-4482686b4634, 414c6a14-3ed5-432e-9edb-c6620a8278f0"
This tool is very useful when personal MRM policies are assigned to system folders like “Yammer.”
Exchange Server und Exchange Online nutzen Aufbewahrungsrichtlinien, um sog. Aufbewahrungstags zu gruppieren. Ein Aufbewahrungstag beschreibt, wie der Exchange Managed Folder Assistant Elemente in einem Postfach oder einem Postfachordner verarbeiten soll, wenn diese automatisch bereinigt oder aufbewahrt werden sollen.
Manchmal zeigen diese Richtlinien ein unerwartetes Verhalten an den Tag. Dieses Verhalten lässt sich nur durch eine Entfernung der Aufbewahrungsinformationen aus dem betroffenen Postfach lösen.
Um zu verstehen, wie man Exchange Aufbewahrungsrichtlinien bereinigt, müssen wir zuerst ein Blick auf die Basics der Aufbewahrung in Exchange Server werfen werfen.
Es existieren Standard (Default) und Persönliche (Personal) Tags. Diese Tags definieren, was mit einem Objekt passieren soll, ob aufbewahrt, gelöscht oder in das Archiv-Postfach verschoben werden soll.
Standard-Tags greifen immer für das gesamte Postfach, oder, im Fall von Löschrichtlinien, für Standard-Ordner.
Alle Richitlinen-Tags, die Sie einer Mailbox zuweisen möchten, werden in einer Aufbewahrungsrichtlinie zusammengefasst. Jedem Postfach kann nur eine Aufbewahrungsrichtlinie zugewiesen werden.
Der folgende Screenshot zeigt die Standard MRM Aufbewahrungsrichtlinien für Benutzer- und Arbitration-Postfächer, ergänzt um zwei Test-Richtlinien.
Wenn Sie mehr über Aufbewahrungsrichtlinien und Richtlinien-Tags erfahren möchten, empfehlen ich einen Blick in die Exchange Dokumentation zu werfen.
Was genau wollen wir eigentlich entfernen?
Es geht um
Zugewiesene Aufbewahrungsrichtlinien zu entfernen ist einfach. Weisen Sie dem Postfach eine andere Richtlinie zu oder setzen Sie den Parameter RententionPolicy auf $null. Damit werden allerdings nicht die persönlichen Tags, die ein Benutzer Postfach-Ordnern zugewiesen hat, entfernt.
Wie wird man nun die persönlichen Tags los? Microsoft hat hierauf eine einfache Antwort:
Aber was passiert, wenn das zu entfernende Tag von anderen Benutzern in Ihrer Exchange Organisation ebenfalls verwendet wurde? In diesem Fall würde es aus allen Postfächern entfernt.
Mal angenommen, Sie haben eine Lösch-Richtlinie, die aus Compliance-Gründen alles älter 10 Jahre löscht. Sie haben dem Benutzer mit einem persönlichen Tag die Möglichkeit gegeben einzelne Ordner vom Löschen auszunehmen. Wenn Sie nun dieses persönliche Tag aus der Exchange Organisation entfernen, werden Sie ein nicht zu vernachlässigendes Supportaufkommen in Ihrer Hotline generieren. Der Managed Folder Assistant wird E-Mail-Nachrichten (älter 10 Jahre) aus allen Ordnern aller Postfächer löschen, an denen das persönliche Tag gesetzt war. Nicht davon zu sprechen, das sie diese dann wiederherstellen müssen.
Zum Glück ist Hilfe nah. Das Tool RemovePersonalRetentionTag hilft Ihnen bei der selektiven Entferung von Richtlinien-Tags.
Mit diesem Tool können Sie eine oder mehrere persönliche Tags von Ordnern eines Postfaches entfernen, ohne diese aus der Exchange Organisation löschen zu müssen.
Dazu gibt es zwei Voraussetzungen. Sie müssen Impersonation-Rechte für das Postfach besitzen, in welchem Sie die Tags entfernen möchten. Wenn sich das Postfach in Exchange Online befindet, muss in einer Exchange Online Umgebung die Basic-Authentifizierung aktiviert sein, da das Tool über Exchange Web Services auf Postfächer zugreift.
Das Tool kann auch dabei helfen, persönliche Tags von Systemordnern, wie zum Beispiel „Yammer“, zu entfernen.
Exchange Server besteht aus zwei Kernkomponenten. Zum einen ist es die Bereitstellung von Postfächern, mit all den benötigten Client-Zugriffsprotokollen und Postfach-Funktionen. Die zweite Komponente ist der Nachrichtenfluss, also der Empfang, die Verarbeitung und der Versand von E-Mail-Nachrichten.
Was sich so einfach und trivial anhört, ist ein zentraler und komplexer Baustein in der Exchange Architektur. In diesem Artikel versuche ich ein wenig Licht ins Dunkel des Exchange Nachrichtenflusses zu bringen. Lassen Sie uns mit einem kurzen Rückblick auf die Exchange Server Architektur beginnen.
Wer sich den Nachrichtenfluss von Exchange Server anschaut, muss sich immer den Funktionsaufbau eines Exchange Servers und die empfohlene Implementierung im Rahmen der Preferred Architecture (PA) in Erinnerung rufen. In der PA wird Exchange Server immer in einer Konfiguration aus mehreren Exchange Servern, die als Datenbankverfügbarkeitsgruppe (DAG) zusammengefasst sind, betrieben. Hierdurch wird eine hochverfügbare Bereitstellung von Postfachfunktionen und Nachrichtentransport erreicht.
Jeder Exchange Server besteht aus einer Frontend- und Backend-Komponente. Eingehende Verbindungen von Drittsystemen erfolgen immer über die Exchange Frontend-Komponenten. Die Kommunikation mit den Backend-Komponenten erfolgt im Regelfall nur Exchange-intern.
Das folgende Diagramm zeigt den schematischen Aufbau der Verbindungen in einer DAG.
Die Konfigurationen für den Nachrichtenfluss unterteilen sich in organisationsweite und serverbezogene Einstellungen. Die organisationsweiten Einstellungen gelten, wie der Name es schon sagt, für die gesamte Exchange Organisation, ganz unabhängig davon wie viele Exchange Server oder DAGs Sie betreiben. Ob und wie ein Exchange Server diese Einstellungen verarbeiten kann, hängt von der Produktversion ab. Diese Einstellungen sind vollständig in der Konfigurationspartition des Active Directory gespeichert. Ein Beispiel für den Nachrichtenfluss sind die Konfigurationen der Sendekonnektoren.
Serverbezogene Einstellungen wirken sich nur für ein bestimmtes Serversystem aus. Diese Einstellungen werden hauptsächlich ebenfalls in der Konfigurationspartition des Active Directory gespeichert. Ein Beispiel für den Nachrichtenfluss sind die Konfigurationen der Empfangskonnektoren. Einige wenige Einstellungen werden jedoch auch in der lokalen Systemregistrierung gespeichert.
Für den sicheren und stabilen Betrieb von Exchange Server ist eine funktionierende Active Directory Replikation unerlässlich. Hierzu gehört auch eine korrekte Konfiguration der Active Directory Sites. Sie ist gerade in größeren Exchange Organisationen unerlässlich.
Ebenso wichtig ist die korrekte und einheitliche Konfiguration der TLS-Einstellungen auf allen Exchange Servern. Ohne solch eine Konfiguration ist nicht sichergestellt, dass verschlüsselte Verbindungen durch die Empfangs- und Sendekonnektoren aufgebaut werden können. Exchange Server vertraut hier auf die Konfiguration des lokalen Windows Server Betriebssystems und die Bereitstellung gültiger TLS-Zertifikate.
Kommen wir nun zum eigentlichen Thema, dem Exchange Nachrichtenfluss und beginnen mit dem Empfang von E-Mail-Nachrichten.
Exchange Server nehmen eingehende E-Mail-Nachrichten über unterschiedliche Wege entgegen. Der bekannteste Weg ist der Empfang über das Protokoll SMTP. Ein Exchange Server unterscheidet hierbei drei unterschiedliche Quelltypen. Im Frontend-Transport erfolgt die Annahme von Verbindungen anderer Server über den Standard TCP-Port 25. Zu den Servern, die sich über diesen Standard SMTP-Port verbinden, zählen:
Diese Verbindungen erfolgen über den Default Frontend Konnektor, der in seiner Standardkonfiguration nur Nachrichten, die an bekannte Empfänger eigener Domänen entgegennimmt. Die Zustellung von Applikationsnachrichten an externe Empfänger erfordert die Erstellung eines separaten Frontend-Empfangskonnektor.
Zusätzlich zu den Empfangskonnektoren stehen zwei weitere Wege über das lokale Dateisystem des Exchange Servers zur Verfügung, das Pickup- und Replay-Verzeichnis. Beide Verzeichnisse werden vom Backend-Transportdienst, den Sie aus früheren Exchange Versionen sicher noch als Hub-Transport kennen, permanent überwacht und sobald eine Datei dort abgelegt ist, wird sie aufgenommen und verarbeitet. Das Pickup-Verzeichnis dient der Ablage von neuen E-Mail-Nachrichten durch Applikationen. Das Replay-Verzeichnis können Sie nutzen, um Nachrichten, die Sie aus einer Warteschlange exportiert und entfernt haben, erneut in die Verarbeitung zu übergeben.
Zum Schutz vor unberechtigten Verbindungen verwendet Exchange Server unterschiedliche Formen der Authentifizierung. Ergänzend verfügen die Eingangswege über eine Header-Firewall, mit der unberechtigte Informationen aus einer E-Mail-Nachricht herausgefiltert werden.
Der Frontend-Transport verfügt über keine komplexe Business-Logik. Daher ist es wichtig, das Zusammenspiel zwischen Frontend-Transport und Transportdiensten im Backend zu verstehen und sich immer wieder in Erinnerung zu rufen, wenn es zu Problemen kommt. Der Empfangskonnektor im Frontend-Transport nimmt die Verbindung entgegen und führt die Authentifizierung durch. Anschließend wird eine Proxyverbindung zum Transportdienst per TCP-Port 2525 aufgebaut. Hierbei entscheidet nun die Konfiguration Ihrer Exchange Umgebung darüber, wie diese Proxyverbindung erfolgt. Bei einem Einzelserverbetrieb erfolgt die Verbindung zum Transportdienst des gleichen Servers. In einer DAG-Konfiguration wählt der Frontend-Transport den Transportdienst des DAG-Mitgliedservers aus, auf dem in diesem Moment die Datenbankkopie mit dem Postfach des Empfängers aktiv eingebunden ist.
Das folgende Diagramm zeigt das Zusammenspiel zwischen Frontend und Backend beim Empfang von Nachrichten per SMTP.
Beim Empfang einer Nachricht per SMTP versucht Exchange Server die Nachricht ausfallsicher entgegenzunehmen. Zu diesem Zweck erstellt Exchange Server eine Kopie der empfangenen Nachricht und speichert sie als Schattenkopie im Transportdienst eines anderen Exchange Servers. Erst nach dem erfolgreichen Speichern der Schattenkopie und der Speicherung in der lokalen Warteschlange des Backend-Transportdienstes, meldet der empfangende Exchange Server dem sendenden Server eine OK-Meldung.
Auf einem Exchange Server können mehrere Empfangskonnektoren für den gleichen Port konfiguriert werden. Wenn Sie weitere Konnektoren für den gleichen Port erstellen, müssen Sie festlegen, wie Exchange Server einen Konnektor auswählen soll. Am einfachsten ist hier die Konfiguration der IP-Adressen des absendenden Systems als Remote IP-Adresse am Konnektor.
Im Backend des Exchange Servers befinden sich zwei Transportdienste. Der wichtigste Dienst ist der Transportdienst, den manche von Ihnen sicher noch als Hub-Transport aus älteren Versionen von Exchange Server kennen. Diesen Dienst schauen wir uns im nächsten Abschnitt einmal genauer an. Der zweite Dienst ist der Postfachtransportdienst. Dieser Dienst hat die Aufgabe, eingehende Nachrichten in Postfächern lokal eingebundener Datenbanken zu speichern und Nachrichten, die versendet werden sollen, aus Postfächern lokaler Datenbanken zu lesen und zur weiteren Verarbeitung an den Transportdienst zu übermitteln. Diesen Dienst beschreibe ich in einem zukünftigen Artikel.
Der einfach erscheinende Empfang einer E-Mail-Nachricht ist, aus Gründen der Nachrichtensicherheit und zum Schutz vor dem Ausfall eines Systems, eine komplexe Aufgabe. Nach dem Empfang der Nachricht muss sie verarbeitet werden.
Die gesamte Verarbeitung von E-Mail-Nachrichten erfolgt im Transportdienst und ist Warteschlangen-basiert, mit der Betonung auf „Warte“. Eine empfangene E-Mail-Nachricht wird in der Submission-Warteschlange gespeichert und wartet dort darauf, zur sog. Kategorisierung aufgegriffen zu werden. In der Categorizer-Komponente erfolgt die Hauptarbeit des Transportdienstes. Zu den Aufgaben gehören:
Nach der Verarbeitung im Categorizer ist die Nachricht bereit zur weiteren Zustellung und wird hierzu in einer passenden Warteschlange gespeichert. Der Transportdienst legt für jedes Zustellungsziel eine separate Warteschlange an. Dies ist der Grund, warum Sie immer eine unterschiedliche Anzahl an Warteschlangen auf einem Exchange Server sehen. Die Warteschlangen gliedern sich in unterschiedliche Kategorien:
Zur Speicherung der Warteschlangen verwendet der Transportdienst auf jedem Exchange Server eine eigene Datenbank. In dieser Datenbank werden alle Nachrichten mit ihrem jeweiligen Verarbeitungs- und Zustellungsstatus gespeichert. Der Transportdienst kümmert sich eigenständig um den Funktionsstatus der Datenbank. Kommt es zu einem nicht behebbaren Fehler, wir eine komplett neue Datenbank erstellt und die korrupte Datenbank in einen neuen Ordner verschoben.
Das folgende Schaubild zeigt die Hauptkomponenten zur Verarbeitung von E-Mail-Nachrichten im Exchange Transportdienst.
Leider steht uns für die aktuelle Version Exchange Server kein detailliertes Diagramm des Transportdienstes offiziell zur Verfügung. Im Microsoft Download Center steht das Diagramm von Exchange Server 2010 zur Verfügung und bietet einen guten konzeptionellen Überblick über den Transportdienst. Achten Sie auf die Unterschiede zu modernen Exchange Server Versionen.
Anwender leben in der Illusion, dass die Zustellung von E-Mail-Nachrichten eine einfache Sache ist und haben meist kein Verständnis für eine verzögerte Zustellung von Nachrichten. In Zeiten von Gigabit-Leitungen und schier unerschöpflicher Computer-Ressourcen hat man sich daran gewöhnt, dass Nachrichten nahezu in Echtzeit übertragen werden.
Einen wesentlichen Beitrag zu einer schnellen und fehlerfreien Verarbeitung leistet das korrekte Routing einer E-Mail-Nachricht. Damit eine Nachricht von Exchange Server fehlerfrei verarbeitet und zugestellt werden kann, ist eine fehlerfreie Active Directory Gesamtstruktur unerlässlich. Die im Exchange Transportdienst aktiven Routing-Agenten arbeiten mit den Informationen, die im Active Directory gespeichert sind. Dies sind u.a.:
Beim Routing einer Nachricht spielt auch die Nachrichtengröße eine Rolle. Exchange zieht mehrere Konfigurationen zu maximalen Nachrichtengröße in Betracht, um so zu bewerten, ob die Nachricht auch wirklich zugestellt werden kann. Kann eine Nachricht nicht zugestellt werden, erhält der Absender einen sog. Non-Delivery Report (NDR). Der Transportdienst betrachtet für die Ermittlung der erlaubten Nachrichtengröße die Konfigurationen auf Organisationsebene, die aller Sende- und Empfangskonnektoren der internen Verbindungsstrecke und die Einstellungen des Zielpostfaches.
Sendekonnektoren arbeiten die Nachrichten in den Warteschlangen ab und versuchen das jeweilige Zielsystem mit den Konnektoreinstellungen zu erreichen. Eine korrekte DNS-Namensauflösung ist der Schlüssel zu einer fehlerfreifunktionierenden Exchange Infrastruktur. Die interne Namensauflösung ist selten eine Fehlerquelle. Anderes sieht es aus, wenn es um die DNS-Auflösung externer Domänen geht. Stellen Sie sicher, dass Ihre Exchange Server auch externe Domänen effizient und sicher auflösen können, um einen fehlerfreien Nachrichtenfluss mit externen Empfängern zu gewährleisten.
Kommt es beim Versuch einer Zustellung zu einem Fehler, wird der Fehler in der Warteschlange festgehalten. Im Regelfall erkennen Sie Zustellfehler am Anwachsen einer oder mehrerer Warteschlangen. Die Überwachung der Warteschlangengröße ist unerlässlich für einen stabilen Betrieb der Exchange Organisation.
Bedenken Sie, dass die Datenbank des Transportdienstes im Installationspfad eines Exchange Servers platziert ist. Wenn Ihre Exchange Server eine hohe Anzahl von Nachrichten verarbeiten muss, sollten Sie die Datenbank auf einem separaten und ausreichend dimensionierten Laufwerk platzieren.
Der Exchange Server Nachrichtenfluss ist, wenn man unter die Motorhaube schaut, ein komplexes Gebilde. Mit einem richtig konfigurierten Active Directory sind keine Probleme beim Betrieb von Exchange Server zu erwarten. Die Herausforderungen für den Exchange Nachrichtenfluss beginnen mit der Anpassung der Exchange Konfiguration.
Gerade im Hinblick auf die Konfiguration von zusätzlichen Empfangskonnektoren müssen Sie sich immer fragen, ob Sie einen neuen Konnektor wirklich benötigen. Das Troubleshooting des Exchange Nachrichtenflusses ist nicht schwierig, jedoch zeitaufwendig. Gerade in Exchange Umgebungen, die seit einigen Jahren betrieben werden und mehrere Exchange Versionen gesehen haben, besteht ein Risiko, dass veraltete Einträge in der Konfigurationspartition den Betrieb stören. Gleiches gilt für die Exchange Empfängerobjekte. Eine regelmäßige Pflege vermeidet Störungen im Nachrichtenfluss.
Der tägliche Betrieb Ihrer Exchange Organisation wird durch ein proaktives Monitoring, in dem nicht nur der Nachrichtenfluss überwacht wird, einfacher. Neben der Überwachung der Warteschlangen, empfehle ich auch die Überwachung der Transportdienste selbst. Exchange Server verfügt mit der Funktion der Managed Availability zwar über eine integrierte Monitoring Lösung mit automatischen Recovery-Aktionen, jedoch möchten Sie sicher nicht von automatisch neustartenden Diensten überrascht werden.
Viel Spaß mit Exchange Server.
Mailscape 365 - Überwachung von Hybrid Exchange und Office 365: Viele Unternehmen verwenden eine lokale Exchange Organisation und Exchange Online in einer Hybrid-Konfiguration, um die Anforderungen ihrer Mitarbeiter zu erfüllen. Der Betrieb einer hybriden Exchange Organisation seine ganz eigenen Herausforderungen für das Monitoring der Dienstverfügbarkeiten. Beginnen Sie noch heute einen unverbindlichen 14-Tage Test von Mailscape 365.