Woher kenne ich die OWA-URL meines Servers?

Die Adresse, mit der sich Nutzer im Browser bei Outlook Web App anmelden, meist in der Form https://mail.beispiel.de/owa. Es reicht auch der bloße Hostname (mail.beispiel.de), https:// und /owa werden automatisch ergänzt.

Wie ermittle ich die Exchange-Version von außen?

Über die OWA-Login-Seite: Exchange legt seine Build-Nummer in die Pfade der statischen Assets (/owa/auth/ /...) und oft in den X-OWA-Version-Header. Dieser Check liest beides aus und ordnet den Build der Version und dem Update-Stand zu.

Braucht das Werkzeug einen Benutzernamen oder ein Passwort?

Nein. Es ruft nur die öffentliche Login-Seite und eine feste Liste bekannter Pfade auf, ganz ohne Anmeldeversuch.

Warum wird keine konkrete Sicherheitslücke genannt?

Eine verlässliche CVE-Zuordnung bräuchte eine dauerhaft gepflegte Liste. Dieses Werkzeug zeigt nur, ob und wie weit ein Update fehlt; die Details liefert Microsofts eigener Security Update Guide.

Funktioniert das auch mit Exchange Online (Microsoft 365)?

Exchange Online hat keinen Build zum Ermitteln, Microsoft patcht selbst. Das Werkzeug erkennt das und führt keinen Update-Abgleich durch.

Was bedeutet es, wenn ECP oder PowerShell 'direkt erreichbar' sind?

Diese Pfade erlauben Admin- bzw. Skriptzugriff auf Exchange. Antworten sie direkt von Exchange statt über einen vorgeschalteten Schutz, ist das unabhängig von der Absicherung anderer Pfade ein eigenständiges Risiko.

Exchange Server Check

Exchange-Build der eigenen OWA-URL gegen Microsofts Build-Liste prüfen.

Ein on-premises Exchange-Server verrät auf seiner öffentlichen OWA-Login-Seite (Outlook Web App) unfreiwillig seinen genauen Build, und veraltete Builds enthalten fast immer bekannte, aktiv ausgenutzte Sicherheitslücken. Dieser Check ruft die von dir eingegebene OWA-URL einmal anonym auf und beantwortet die Frage, ob dieser Server auf dem aktuellen Update-Stand ist, ohne Anmeldung und ohne Scan-Verhalten.

Was dieses Werkzeug prüft

Der Pfad ist fest auf /owa eingeschränkt, es ist kein allgemeiner URL-Abruf. Aus einer einzigen Antwort werden abgeleitet: der exakte Build aus den Asset-Pfaden der Login-Seite (/owa/auth/<build>/…) und ergänzend aus dem X-OWA-Version-Header (über alle Redirect-Hops zusammengeführt), das TLS-Zertifikat, die angebotenen Auth-Verfahren (WWW-Authenticate: Basic Auth ist unverschlüsselt und sollte aus sein), ein interner Servername aus X-FEServer oder X-BEServer, der HSTS-Zustand und ob Klartext-HTTP auf Port 80 noch offen ist oder sauber umleitet. Zusätzlich wird eine feste Liste weiterer Exchange-Pfade auf demselben Host geprüft (ECP, PowerShell, ActiveSync, EWS, OAB, RPC, MAPI, Autodiscover), höchstens vier gleichzeitig.

Das Ergebnis lesen

Der Build wird gegen Microsofts gebündelte Build-Tabelle abgeglichen: aktuell (grün) oder wie viele Updates zurück (Warnung, mit einem Verweis auf Microsofts Security Update Guide, bewusst ohne CVE-Zuordnung). Eine nicht mehr unterstützte Produktfamilie (Exchange 2013/2016/2019 nach Supportende) ist ein Fehler. Bei den weiteren Pfaden gilt: direkt erreichbares ECP oder PowerShell ist ein Fehler (Admin- und Skriptzugriff), die übrigen Pfade sind bei direkter Erreichbarkeit eine Warnung, aber nicht automatisch falsch, ActiveSync und EWS sind für mobile Geräte oft absichtlich offen. Wird gar kein Exchange-Signal gefunden, erscheint das ganz oben als Hinweis.

Grundlagen

Exchange und OWA sind ein Microsoft-Produkt, kein RFC-Protokoll. Herangezogen werden Microsofts offizielle Build-Nummern und Support-Zeiträume. Für die Transport- und Härtungsprüfung gelten die üblichen Web-Standards: X.509 nach RFC 5280, TLS nach RFC 8446, HTTP Strict Transport Security nach RFC 6797. Ein Überblick über Exchange-Versionen, Support-Zeiträume und Migrationsleitfäden steht im Artikel Exchange Versionen auf frankysweb.de.

Typische Fehlerbilder und wie man sie behebt

Build liegt mehrere Updates zurück. Das jeweils aktuelle Cumulative Update und danach das neueste Sicherheitsupdate einspielen. Exchange kennt keine Teil-Patches: nur der volle CU- plus SU-Stand gilt als abgesichert.
Produktfamilie ohne Support. Exchange 2013, 2016 und 2019 erhalten nach ihrem jeweiligen Supportende keine Sicherheitsupdates mehr. Auf Exchange Subscription Edition oder Exchange Online migrieren.
Basic Auth noch aktiv. Das WWW-Authenticate: Basic überträgt Zugangsdaten Base64-kodiert, also praktisch im Klartext. Auf moderne Verfahren umstellen und Basic Auth für die betroffenen virtuellen Verzeichnisse deaktivieren.
ECP oder PowerShell direkt erreichbar. Diese Pfade gehören hinter eine Vor-Authentifizierung (Reverse-Proxy, Conditional Access) oder ins interne Netz, nicht offen ins Internet. Häufig hängt nur /owa hinter dem Schutz und die übrigen vDirs sind direkt erreichbar.
Klartext-HTTP offen oder kein HSTS. Port 80 sauber per 301 auf https umleiten und einen Strict-Transport-Security-Header mit ausreichender max-age setzen.

Häufige Fragen

Woher kenne ich die OWA-URL meines Servers?: Die Adresse, mit der sich Nutzer im Browser bei Outlook Web App anmelden, meist in der Form https://mail.beispiel.de/owa. Es reicht auch der bloße Hostname (mail.beispiel.de), https:// und /owa werden automatisch ergänzt.
Wie ermittle ich die Exchange-Version von außen?: Über die OWA-Login-Seite: Exchange legt seine Build-Nummer in die Pfade der statischen Assets (/owa/auth/<build>/...) und oft in den X-OWA-Version-Header. Dieser Check liest beides aus und ordnet den Build der Version und dem Update-Stand zu.
Braucht das Werkzeug einen Benutzernamen oder ein Passwort?: Nein. Es ruft nur die öffentliche Login-Seite und eine feste Liste bekannter Pfade auf, ganz ohne Anmeldeversuch.
Warum wird keine konkrete Sicherheitslücke genannt?: Eine verlässliche CVE-Zuordnung bräuchte eine dauerhaft gepflegte Liste. Dieses Werkzeug zeigt nur, ob und wie weit ein Update fehlt; die Details liefert Microsofts eigener Security Update Guide.
Funktioniert das auch mit Exchange Online (Microsoft 365)?: Exchange Online hat keinen Build zum Ermitteln, Microsoft patcht selbst. Das Werkzeug erkennt das und führt keinen Update-Abgleich durch.
Was bedeutet es, wenn ECP oder PowerShell 'direkt erreichbar' sind?: Diese Pfade erlauben Admin- bzw. Skriptzugriff auf Exchange. Antworten sie direkt von Exchange statt über einen vorgeschalteten Schutz, ist das unabhängig von der Absicherung anderer Pfade ein eigenständiges Risiko.