Let's Encrypt Zertifikate für Exchange automatisieren mit win-acme

Ein öffentliches Zertifikat gehört auf jeden Exchange-Server, der von aussen erreichbar ist. Der lästige Teil ist die Erneuerung: Let's-Encrypt-Zertifikate laufen nach 90 Tagen ab, und niemand will das alle drei Monate von Hand machen. Mit win-acme lässt sich das komplett automatisieren, inklusive Zuweisung an die Exchange-Dienste und geplanter Erneuerung. In diesem Beitrag zeige ich den kompletten Weg, und ich gehe auf einen kleinen Stolperstein im mitgelieferten Exchange-Skript ein, der mich kurz aufgehalten hat.

SPF, DKIM und DMARC – Was steckt dahinter und warum lohnt sich die Auswertung?

E-Mail ist nach wie vor das wichtigste Kommunikationsmittel im Geschäftsalltag – und gleichzeitig eines der beliebtesten Angriffsziele. Phishing, Spam und Domain-Spoofing nehmen zu. Mit SPF, DKIM und DMARC stehen drei bewährte Mechanismen zur Verfügung, die zusammen einen wirksamen Schutz bilden. In diesem Beitrag erkläre ich, wie die drei Protokolle funktionieren, was Alignment bedeutet und welchen konkreten Nutzen die Auswertung von DMARC-Reports bringt.

Die drei Säulen der E-Mail-Authentifizierung

SPF (Sender Policy Framework) legt fest, welche Mailserver berechtigt sind, E-Mails im Namen einer Domain zu versenden. Der Eintrag wird als TXT-Record im DNS veröffentlicht. Exchange Online-Kunden verwenden typischerweise:

v=spf1 include:spf.protection.outlook.com -all

DKIM (DomainKeys Identified Mail) versieht ausgehende E-Mails mit einer digitalen Signatur. Der empfangende Mailserver kann anhand eines öffentlichen Schlüssels im DNS prüfen, ob die Nachricht unverändert ist und wirklich von der angegebenen Domain stammt.

DMARC (Domain-based Message Authentication, Reporting and Conformance) baut auf SPF und DKIM auf. Es legt fest, wie ein empfangender Mailserver mit Nachrichten umgehen soll, die die Prüfungen nicht bestehen – und liefert Reports darüber, was im Namen der eigenen Domain versendet wird.

Entfernung des letzten lokalen Exchange Servers nach Hybridbetrieb

Dieser Post beschreibt den vollständigen und unterstützten Ablauf, um den letzten lokalen Exchange Server nach einer abgeschlossenen Hybridmigration ausser Betrieb zu nehmen. Er richtet sich an Umgebungen, in denen alle produktiven Postfächer bereits nach Exchange Online migriert wurden, die Identitäten jedoch weiterhin im lokalen Active Directory verwaltet und über Microsoft Entra Connect (Azure AD Connect) mit Microsoft Entra ID synchronisiert werden.

Ziel ist es, den lokalen Exchange Server sicher zu entfernen, ohne die Empfängerverwaltung zu verlieren, und gleichzeitig sicherzustellen, dass keine hybriden Abhängigkeiten mehr bestehen. Dabei werden die Exchange Server SE Management Tools zur weiteren Verwaltung verwendet, und das Microsoft-Skript CleanupActiveDirectoryEMT.ps1 sorgt für die abschliessende Bereinigung der lokalen Active-Directory-Objekte.

Update Juli 2026: Dieser Beitrag wurde überarbeitet. Die OAuth-Bereinigung erfolgt neu über ConfigureExchangeHybridApplication.ps1 statt Remove-AuthServer, der Rückbau des Hybrid Agent wurde um Remove-HybridApplication ergänzt, und mit dem Source of Authority (SOA) Transfer gibt es inzwischen eine Alternative zur Empfängerverwaltung per Management Tools (siehe Abschnitt am Ende).

Checkliste

1) Ausgangslage prüfen

• Alle produktiven Postfächer sind in Exchange Online. Keine Benutzer-, Shared-, Ressourcen- oder Archivpostfächer mehr on-prem. Beispiel vor Ort:

Set-ADServerSettings -ViewEntireForest $true
Get-Mailbox -ResultSize Unlimited

Sicherheitslücke in Exchange - Wurde ich schon angegriffen? Hafnium Test

 Es wurden ja in den letzten Monaten öfters Sicherheits-Updates für Exchange veröffentlicht. Doch die Sicherheitslücken, für welche Anfang März 2021 Patches veröffentlicht wurden, scheint eine der gefährlicheren zu sein. Informationen dazu gibt es auf dem Exchange Team Blog, im MS Security Blog oder auch bei EighTwOne.com.

Wichtig ist auch noch zu prüfen, ob schon ein Angriff stattgefunden hat, dies geht einfach mit dem Script  Test-ProxyLogon.ps1: https://github.com/microsoft/CSS-Exchange/tree/main/Security

Unter obigem Link gibt es noch weitere Scripts, welche zu diesem Thema gehören. Das Script ExchangeMitigations.ps1 soll nur angewendet werden, wenn ihr den Exchange Server aus irgendwelchen Gründen nicht sofort Patchen könnt. Das selbe gilt für BackendCookieMitigation.ps1. Diese beiden Scripts benötigt ihr also nicht, wenn ihr die Sicherheits-Updates installiert.

Das Script CompareExchangeHashes.ps1 nutzt euch nur etwas, wenn ihr einen Supportvertrag mit Microsoft habt. Es soll zusätzlich prüfen, ob ihr angegriffen worden seid. Das Problem ist aber, dass das Script 600 - 800 MB grosse XML-Dateien produziert und immer sagt, ihr seid angegriffen worden. Auch wenn man das Script auf einem neu installierten Exchange Server ohne Internetverbindung ausführt, wie ihr hier nachlesen könnt: https://www.reddit.com/r/sysadmin/comments/m16y8m/hafnium_breach_recap_new_compareexchangehashes/
Am Ende könnt ihr dass eben die XML-Dateien bei Microsoft hochladen, doch eben nur mit einem Supportvertrag.

Jedoch gibt es noch das Script HealtjCheck, welches sehr hilfreich ist: https://github.com/dpaulson45/HealthChecker#download

Damit könnt ihr einfach nachschauen, ob alle eure Exchange Server aktuell sind und es werden sonst noch sinnvolle Einstellungen geprüft.

Wenn euere Exchange Organisation aus mehren Exchange Server besteht, startend ihr das Health Checker Script am einfachsten mit folgenden Command:

Get-ExchangeServer | ?{$_.AdminDisplayVersion -Match "^Version 15"} | %{.\HealthChecker.ps1 -Server $_.Name}; .\HealthChecker.ps1 -BuildHtmlServersReport; .\ExchangeAllServersReport.html

Neue Exchange Version angekündigt (Exchange vNext)

 Seit einigen Jahren steht betreffend MS Exchange immer wieder die gleiche Frage im Raum: Wird Microsoft noch eine neue Exchange Version on-premise herausbringen?

Nun, vor ein paar Tagen hat Microsoft an der Ignite verkündet, dass es in der zweiten Jahreshälfte 2021 die nächste Exchange Version für lokale Installationen geben wird.

Das ist doch nett, denken sich die meisten ;-) Schauen wir uns doch erst mal an, was Microsoft denn angekündigt hat:

• Migration von Exchange 2019 auf "Exchange vNext" ist als Inplace Upgrade möglich. Das heisst, Exchange vNext lässt sich auf einem Exchange 2019 genauso wie ein CU installieren. Man muss nicht parallel neue Server aufbauen und alles rüber migrieren.
  
  
• Exchange vNetxt erlaubt eine Koexistenz mit Exchange 2013, 2016 und 2019. Bis anhin waren immer nur die 2 letzten Versionen unterstützt. Nun sind es also die 3 letzten Versionen.
  
  
• Exchange vNext Lizenz gibt es nur subscription-based, also als Abo.

Wenn man sich diese Punkte auf der Zuge zergehen lässt und ein paar wenige graue Zellen im Hirn hat, dürfte jedem klar sein, was Microsoft mit dieser Exchange vNext Version für Ziele hat ;-)

Soviel , zu "nette Microsoft", wir dürfen ein CU bei euch kaufen und das geht nur im Abo ...

Exchange Team Blog zum Thema

ActiveSync bleibt verbunden trotz...

Kunden haben mir gemeldete, dass ActiveSync Verbindungen trotz geändertem Passwort oder sogar deaktiviertem AD User Objekt weiterhin verbunden bleibt, und dies zum Teil für Tage.

Aufgefallen ist dies, weil ja die meisten Firmen einen sporadischen Passwortwechsel verlangen. Dabei hat sich gezeigt, dass Mobile Geräte zum Teil erst nach Tagen das neue Passwort verlangen und in der Zwischenzeit munter Mails empfangen und versendet werden konnten, alles unter einem Passwort, welches eigentlich nicht mehr gültig ist.

Für Benutzer, welche einfach so oder weil dies sporadisch verlangt wird, ihr Passwort ändern, die Firma aber nicht verlassen, stellt dieses Verhalten kein allzu grosses Problem dar. Der Benutzer hat ja sein Passwort selbst gewechselt und wüsste das neue Passwort.

Problematisch wird es, wenn das Passwort vom Administrator gewechselt oder der Account deaktiviert wurde, weil der Benutzer das Unternehmen verlassen hat. In diesem Fall würde man ja annehmen, dass der Benutzer durch diese Aktion keinerlei Zugriffe auf die Firmeninfrastruktur mehr hat.

Durch die Beschriebene Problematik ist der Benutzer also, unter Umständen, noch tagelang in der Lage Mails zu empfangen und auch zu versenden. Dies kann grossen Schaden verursachen, je nach dem wie einvernehmlich die Trennung von der Firma abgelaufen ist.

Meine Suche nach einer Lösung hat hervorgebracht, dass dieses Problem schon diversen Personen aufgefallen ist, es aber keine Lösung dafür gibt. Es scheint, dass hier Sicherheit durch Benutzerfreundlichkeit ausgehebelt wurde.

Wichtig ist, diesen Umstand zu kennen, denn ein User lässt schon gänzlich von seinem Postfach trennen, nur reicht es nicht, "nur" den AD Account zu deaktivieren oder das Passwort zu ändern. Mindestens einer der folgenden Schritte muss zusätzlich ausgeführt werden:

• Neustart der Webservices (IIS)
• Recyceln der Application Pools "MSExchangeSyncAppPool"

Diese beiden Optionen sind nicht die optimalsten, denn diese Aktionen betreffen auch andere Benutzer. Ohne andere Benutzer zu stören nützen auch folgende Aktionen:

• In den Einstellungen des Postfaches ActiveSync deaktivieren
• Das betroffene Postfach in eine andere Datenbank verschieben
• Das Telefon aus der Exchange Verwaltungsseite heraus wipen
• Die Verbindung des Telefons aus dem Postfach löschen

OWA und EAS Log Analyse

OWA Log Analyse

Die Zugriffe auf OWA lassen sich mittels der IIS Logs analysieren. Dazu kann man das MS Tool «LogParser 2.2» verwenden. Das Tool lässt sich hier herunter laden:

https://www.microsoft.com/en-us/download/details.aspx?id=24659

Arbeitsordner erstellen

Für die Analyse der IIS Logs ist es am einfachsten, zuerst mal einen Arbeitsordner zu erstellen. Danach werden dort die Logs abgelegt, welche analysiert werden sollen.

Hierarchisches Adressbuch

In grossen Organisationen stellt sich immer wieder die Frage, wie Adressbücher übersichtlich gestaltet werden sollen. Seit Exchange 2010 SP1 haben wir eine neue Funktion bekommen, welche sich «Hierarchisches Adressbuch» nennt. Das Ganze sieht wie folgt aus:

Der Aufbau eines hierarchischen Adressbuches wird über Verteilerlisten gesteuert. Diese werden ineinander verschachtelt und so gekennzeichnet, dass sie im hierarchischen Adressbuch berücksichtigt werden. Wie das geht, zeige ich anhand einer Step by Step Anleitung am Beispiel der Firma, in welcher ich arbeite. Das Ziel ist, ein hierarchisches Adressbuch aufzubauen, wie ihr es oben in der Ausbildung sehen könnt.

iOS 8.3 bringt Exchange relevante Fixes

Das neueste Update für iPhones bringt auch Fehlerkorrekturen in Bezug auf Exchange:

• Exchange-Abwesenheitsbenachrichtigungen können jetzt separat für externe Antworten bearbeitet werden
• Optimiert die Wiederherstellung von Exchange-Accounts bei temporären Verbindungsproblemen
• Korrigiert ein Problem, durch das Exchange-Termine mit langen Notizen abgeschnitten wurden

Falls ihr in letzter Zeit mit solchen Problemen gekämpft habt, ist dies sicher eine gute Nachricht.

Die ganze Liste der Leistungsverbesserungen und Fehlerkorrekturen findet ihr hier.

Outlook App for iOS & Android

Microsoft hat vor kurzem die App Outlook App for iOS & Android veröffentlicht. Spezialisten haben sich die App angesehen und mussten feststellen, dass die App für den Zugriff auf die Mails einen "kleinen" Umweg über diverse Server, welche meist in den USA stehen, macht.

Dies kann man hier nachlesen:

Hände weg von der neuen Outlook-App für iPhone und Android – warnt die ETH Zürich

Wie man die App auf dem Exchange blocken kann, könnt ihr hier nachlesen:

Blocking Outlook App for iOS & Android