Zum Thema Exchange und Hybrid Modus mit Office 365 habe ich nun schon häufiger Anfragen erhalten. Ich habe mir daher vorgenommen in Zukunft mehr auf das Thema Office 365 in Verbindung mit lokalen Exchange Servern einzugehen. Hier ist nun der erste Artikel zu Exchange 2016 in Verbindung mit Office 365 und dem Hybrid Modus. In diesem Artikel geht es erst einmal um die Testumgebung, die weiteren Artikel behandeln dann die Konfiguration von Office 365 und Exchange 2016.

Hier gibt es also an dieser Stelle erst einmal nur einen Überblick der Testumgebung. Alles Weitere folgt dann in den nächsten Artikeln.

Die Umgebung

Ich habe für diesen Artikel eine kleine Testumgebung installiert. Es gibt einen Domain Controller und einen Exchange 2016 CU9 Server. Beide Server laufen auf Windows Server 2016. Der Name des Active Directory lautet frankysweb.org, dies passt ganz gut, da ich diese Domain auch öffentlich registriert habe, aber derzeit nicht nutze.

Der Domain Controller hört auf den Namen DC1.frankysweb.org, der Exchange Server trägt den Namen EX1.frankysweb.org:

Um die Internetanbindung kümmert sich ein eine Sophos UTM, diese spielt hier allerdings nur eine nebensächliche Rolle. Der Internetanschluss verfügt über eine statische IP-Adresse.

Die öffentlichen DNS Einstellungen für die Domain frankysweb.org sind wie folgt konfiguriert:

Der MX Eintrag zeigt auf outlook.frankysweb.org und damit auf die feste IP-Adresse des Internetanschlusses. Die Sophos UTM arbeitet als SPAM Filter für eingehende Mails und wird vom Exchange Server als Smarthost für ausgehende Mails benutzt. Zusätzlich gibt es einen  SPF Eintrag (siehe TXT Eintrag im Screenshot), welcher nur die statische IP des Internetanschlusses enthält und diese für den Mailversand von frankysweb.org erlaubt.

Details zur Testumgebung

Hier nun ein paar Details zur Testumgebung. Nicht alles ist direkt relevant und dient daher dem besseren Überblick und Verständnis.

Wie zuvor bereits erwähnt zeigt der MX Eintrag auf die öffentliche IP der Sophos UTM. Die Sophos UTM fungiert in meiner Umgebung als Router und SPAM-Filter. Der Mailfluss ist also bisher wie folgt:

Letztendlich lässt sich dieses Szenario auch mit jedem anderem SPAM-Filter umsetzen. Der SPAM Filter wird auch von Exchange als Smarthost benutzt um Mails an externe Empfänger zu verschicken. Auf der Sophos UTM gibt es ein SMTP Profil, welches alle Mails an frankysweb.org an den Exchange Server der Testumgebung schickt:

Der Zugriff auf Exchange aus dem Internet erfolgt über den Hostnamen outlook.frankysweb.org, der Hostname ist für alle Protokolle gleich, nur Autodiscover wird unter dem Namen autodiscover.frankysweb.org veröffentlicht. Der Router leitet in diesem Fall via DNAT nur Port 443 an den Exchange Server weiter:

Ich wollte hier bewusst die Webserver Protection der UTM außen vor lassen um die Artikel etwas allgemeiner zu halten.

Outlook Anywhere sowie auch alle anderen virtuellen Verzeichnisse wurden auf dn Namen “outlook.frankysweb.org” konfiguriert:

Hier noch ein Screenshot zum /OWA Verzeichnis. Die anderen Verzeichnisse wurden, mit Ausnahme von /PowerShell auch auf den Hostnamen “outlook.frankysweb.org” konfiguriert:

Die Autodiscover URL wurde auf autodiscover.frankysweb.org konfiguriert:

Als Zertifikat kommt ein Wildcard Zertifikat von Let’s Encrypt zum Einsatz:

Im Active Directory habe ich 3 Testbenutzer und eine Verteilergruppe angelegt:

Alle Testbenutzer sind Mitglied der Gruppe “alle”.

In der Testumgebung habe ich zusätzlich einen Client mit Outlook 2016 installiert. Somit kann auch die Outlook Verbindung geprüft werden.

Soweit zur Testumgebung. Im nächsten Teil geht es dann los mit der Konfiguration von Office 365 und Exchange 2016.

Der Beitrag Exchange 2016: Hybrid Modus mit Office 365 (Teil 1) erschien zuerst auf Frankys Web.

Kleiner Hinweis am Rande, ab dem 01.06.2018 werden neue Limits in Exchange Online und damit auch in Office 365 eingeführt. Konkret geht es um neue Limitierungen bei authentifizierten SMTP-Verbindungen (SMTP Authenticated submission):

• Gesendete Mails werden im Ordner “Gesendete Elemente” des Postfachs gespeichert
• Es sind nur noch drei gleichzeitige Verbindungen pro Postfach erlaubt

Je nach Konfiguration könnte man hier in Probleme laufen. Problematisch wird es, wenn Geräte wie Scanner oder Multifunktionsgeräte einen Serviceaccount nutzen um Mails zu versenden. Auch Software für den E-Mail Newsletter Versand kann von dem neuen Limit betroffen sein.

Ganz konkret bedeutet dies folgendes: Pro Postfach sind nur 3 gleichzeitige authentifizierte SMTP Verbindungen möglich. Wenn Multifunktionsgeräte, die Monitoring Software und das Newsletter Tool beispielsweise alle einen ServiceAccount mit dem Namen “noreply” verwenden, kommt man je nach Mailaufkommen schnell an dieses Limit. Die Verbindung kann zwar einfach zu einem späteren Zeitpunkt wiederholt werden, jedoch unterstützen meist gerade Multifunktionsgeräte dies nicht. Solche Geräte zeigen üblicherweise nur einen Fehler an und versuchen nicht wieder die Mail loszuwerden.

In der folgenden Grafik ist einmal Limit dargestellt, 4 Clients versuchen zeitgleich mit dem Benutzer “noreply” und einem Passwort ihre Mails zu senden. Drei der Verbindungen werden akzeptiert, die vierte wird den folgenden Fehler erhalten:

• 4.3.2 STOREDRV.ClientSubmit; sender thread limit exceeded.

Da nun auch die Mails in dem “Gesendete Elemente” Ordner im Postfach “noreply” erscheinen, bietet es sich hier an entsprechende Aufbewahrungsrichtlinien zu konfigurieren und die Mails nach einer bestimmten Zeit automatisch zu löschen. Zwar sollte die Postfachgröße bei Exchange Online und Office 365 eher kein Problem darstellen, allerdings schaut sich im Normalfall auch niemand die gesendeten Mails eines ServiceAccounts an. Die Mails müssen also nicht zwingend für immer gespeichert werden.

Gerade wenn viele Drucker oder Newsletter Programme auf den gleichen ServiceAccount konfiguriert sind, kann die Gefahr bestehen, dass mehr als 3 gleichzeitige Verbindungen aufgebaut werden. In diesem Fall würde es also zu dem oben genannten Fehler kommen.

Als Alternative bietet sich nur an für jedes Gerät oder Dienst ein eigenes Postfach / ServiceAccount zu verwenden. Dies sorgt natürlich auch für zusätzliche Kosten. Zwar muss nicht jeder Drucker sein eigenes Konto verwenden, aber vielleicht lässt es sich ja etwas entzerren indem beispielsweise alle Drucker einer Etage eines Bürogebäudes einen eigenen ServiceAccount nutzen.

Newsletter (Bulk Mail) sollten lieber über spezielle Dienste und nicht via Exchange Online oder Office 365 abgewickelt werden.

Der Beitrag Vorsicht: Neue Limits für Office 365 / Exchange Online erschien zuerst auf Frankys Web.

Teil 1 dieser Artikelreihe behandelte ja erst einmal nur die Testumgebung für ein Exchange 2016 / Office 365 Hybrid Szenario. In diesem Teil geht es nun um die Vorbereitung von Office 365 und der Domain frankysweb.org.

Was ist der Hybrid Modus

Eine kleine Erklärung mit Hybrid Modus bin ich noch schuldig: Was ist überhaupt der Hybrid Modus?

Im Prinzip ist es recht einfach erklärt, der Hybrid Modus verbindet eine lokale Exchange Organisation mit Office 365 / Exchange Online. Beide Welten lassen sich also parallel benutzen. Ein Anwendungsszenario für den Hybrid Modus wäre beispielsweise alle Postfächer der Aussendienstler und Home Office Benutzer als Office 365 Nutzer anzulegen. Alle anderen Benutzer die ihren Schreibtisch in der Firma stehen haben, könnten weiterhin Postfächer auf dem lokalen Exchange Server haben.

Ein weiteres Beispiel für einen Anwendungsfall: Die Migration von einer lokalen Exchange Umgebung hin zu Office 365. Für den Zeitraum der Migration lassen sich so beide Welten parallel betreiben, bis alle Daten zu Office 365 migriert wurden.

Für diese Artikel ist erst einmal das erste Szenario relevant, ein paar Postfächer in der Cloud, ein paar Postfächer lokal.

Office 365 Testaccount / Testtenant

Wenn Exchange im Hybrid Modus betrieben werden soll ist logischerweise ein Office 365 Abo notwendig. Microsoft stellt erfreulicherweise Office 365 Testversionen aus.

Für diese Artikel verwende ich die Testversionen von Office 365 Business Premium. Unter folgenden Link findet sich die Möglichkeit einen Testtenant anzulegen:

• Office 365 Business Premium

Hier einmal kurz der Prozess um an einen Testtenant zu kommen, hier sind nur wenige Informationen nötig und es entstehen keine Kosten. Auch können bei Bedarf Lizenzen erworben werden und somit später produktiv genutzt werden:

Im nächsten Schritt muss das Benutzerkonto festgelegt werden, welches auch als Office 365 Administrator angelegt wird:

Nachdem eine Telefonnummer angegeben und der Bestätigungscode eingegeben wurde, ist der Testtenant aktiv. Mit einem Klick auf “Sie können jetzt loslegen” landet man direkt im Office 365 Portal:

Jetzt präsentiert sich das Office 365 Portal, mit einem Klick auf die “9 Punkte” oben links öffnet sich das Menü:

Im Portal muss nun zunächst in die Administrator Ansicht gewechselt werden:

Hier lassen sich nun schon einmal die Lizenzen prüfen, Microsoft teilt einem Testtenant 25 Lizenzen zu, eine Lizenz wird bereits für das Admin Konto verwendet:

Die Lizenzen sind 30 Tage lang gültig und lassen sich einmal verlängern. Hier ist dann die Angabe einer Kreditkarte erforderlich. Das Verlängern des Testzeitraums ist kostenlos:

Diese Schritte dienten nur der Überprüfung, jetzt kann die Office 365 Konfiguration beginnen.

Office 365 Basiskonfiguration

Zunächst muss die Domain hinzugefügt werden. Im Menü muss dazu zunächst auf “Mehr anzeigen” geklickt werden:

Jetzt ist der Punkt “Setup” sichtbar und es lässt sich eine neue Domain hinzufügen:

Im Assistent “Neue Domäne” können nun alle E-Mail Domänen hinzugefügt werden. Ich verwende hier nur frankysweb.org:

Wichtiger Hinweis: Es war lange Zeit üblich, den lokalen Active Directory Namen beispielsweise auf .local oder .domain enden zu lassen. Ich verwende beispielweise frankysweb.local immer noch für ausschließlich lokale Testumgebungen. Ein Benutzername (UPN) aus so einem Active Directory würde beispielsweise frank@frankysweb.local lauten. Diese Benutzernamen lassen sich aber nicht in Verbindung mit Office 365 nutzen. Grund: frank@frankysweb.local ist nicht eineindeutig, jeder könnte sein lokales Active Directory so nennen und es gäbe unter Umständen viele gleiche Benutzernamen. Ebenfalls kann die frankysweb.local nicht als Domain durch Office 365 verifiziert werden, dies ist aber erforderlich um später die Benutzerkonten zu synchronisieren und in der lokalen Umgebung sowie auch in Office 365 einheitliche Benutzernamen zu verwenden. Falls jemand in dieses Problem läuft: Dafür lassen sich Alternative UPNs nutzen, dazu wird es noch einen separaten Artikel geben, hier aber schon einmal die Vorgehensweise.

Die Domain wird durch Office 365 überprüft. Dies kann entweder per E-Mail oder TXT-Record im öffentlichen DNS erfolgen. Ich verwende hier die Überprüfungs-E-Mail:

Nachdem die Domain überprüft wurde, fragt der Assistent nach den Onlinediensten und DNS Einstellungen. Hier wird “Ich verwalte meine eigenen DNS-Einträge” ausgewählt:

In der Auswahl der “Onlinedienste” verwende ich erst einmal nur “Exchange”, die anderen Dienste sind in dieser reinen Exchange Umgebungen erst einmal nicht relevant und können auch später aktiviert werden. Diese Artikel beziehen sich zunächst auf Exchange Hybrid und nicht auf Skype etc.:

Nachdem auf “Speichern und schließen” geklickt wurde, wird die neue Domain angezeigt und hat den Status “Setup wird ausgeführt”:

Weiter geht es schon einmal mit der Anpassung des SPF Eintrags für die Domain frankysweb.org.

Anpassung SPF-Eintrag

Damit später auch Mails via Office 365 versendet werden können, muss der SPF Eintrag für frankysweb.org angepasst werden und um den Office 365 Mail Server erweitert werden. Aktuell gelten folgende SPF Einstellungen für frankysweb.org:

Nur die statische IP wird als sendender Mailserver zugelassen, damit auch Office 365 Mails mit der Domain frankysweb.org verschicken kann, muss der SPF erweitert werden. Mit einem Klick auf die Domain frankysweb-org in Office 365 Portal lässt sich der SPF Eintrag anzeigen der gesetzt werden soll, wenn es sich um eine reine Office 365 Installation handelt (ohen Hybrid Szenario):

Der wichtige Teil ist hier:

• include:spf.protection.outlook.com

Dieser String wird nun zum vorhandenen SPF Eintrag hinzugefügt:

Nach der Anpassung enthält der SPF Eintrag also beide Welten, den eigenen Mailserver und die Einstellungen zu Office 365:

Die Einstellungen lassen sich mit beispielsweise mit MXToolbox verifizieren:

• https://mxtoolbox.com

Soweit erst einmal an dieser Stelle, im nächsten Artikel geht es dann um die Synchronisation der Benutzerkonten.

Der Beitrag Exchange 2016: Hybrid Modus mit Office 365 (Teil 2) erschien zuerst auf Frankys Web.

Microsoft hat die erste Preview von Office 2019 und damit auch Outlook 2019 veröffentlicht.

Die Preview ist öffentlich und lässt sich beispielsweise mit einen Office 365 Account runterladen. Um die Preview zu testen, kann sich hier zunächst für das Collaborate Program registriert werden:

https://developer.microsoft.com/en-us/dashboard/collaborate/

Unter dem Punkt “Engagements” kann dann die Office 2019 Preview runtergeladen werden:

Nach dem Download des C2R Installers, kann die folgende XML Datei verwendet werden um die Office 2019 Preview zu installieren. Die XML-Datei kann einfach im gleichen Verzecihnis gespeichert werden, wie der Installer:

<Configuration>
<Add SourcePath=“c:\Office“ OfficeClientEdition=“64″ Channel=“Perpetual2019″>
<Product ID=“ProPlus2019Volume“  PIDKEY=“N9J9Q-Q7MMP-XDDM6-63KKP-76FPM“ >
<Language ID=“en-us“ />
</Product>
<Product ID=“ProofingTools“>
<Language ID=“de-de“ />
<Language ID=“ja-jp“ />
</Product>
</Add>
<RemoveMSI All=“True“ />
<Display Level=“None“ AcceptEULA=“TRUE“ />
</Configuration>

Ich habe die vorhandene XML einfach ersetzt:

Die Installation wird mittels Befehlszeile gestartet:

Beide Befehle arbeiten im Hintergrund, der erste lädt die erforderlichen Dateien runter, der zweite installiert Office 2019.

Ich habe die Outlook 2019 Preview direkt mal mit einem Exchange 2016 Server verbunden. Hier sind die ersten Bilder der Einrichtung:

Der erste Outlook Start sieht etwas anders aus, als der Start von Outlook 2016.

Outlook 2019 und Exchange 2016 Autodiscover funktionieren schon einmal:

Der erste Start von Outlook:

Nachdem Outlook 2019 gestartet wurde, fällt mir hier nicht direkt etwas neues auf. Das Design ist nahezu identisch zu Outlook 2016. Hier muss sich also nicht umgewöhnt werden:

Nach den ersten paar Klicks, fällt mir nur die geänderte Version auf:

Alle anderen Dialoge scheinen identisch zu Outlook 2016 zu sein:

Ich habe nun ein paar Minuten lang mit Outlook 2019 gearbeitet. Fehler konnte ich bisher keine feststellen, Neuerungen allerdings auch nicht, zumindest nicht auf den ersten Blick. Ich werde mich mal etwas eingehender mit der Preview beschäftigen.

Neben Windows Server 2019 Preview, gibt es also nun auch die Office 2019 Preview. Mal sehne, wann es dann die Exchange 2019 Preview gibt.

Der Beitrag Preview von Office 2019 veröffentlich (inkl.Outlook 2019) erschien zuerst auf Frankys Web.

Dies ist der dritte Teil der Serie „Exchange 2016 Hybrid Modus mit Office 365”. In diesem Teil geht es um die Synchronisation der lokalen Benutzerkonten zu Office 365 bzw. Azure Active Directory.

Hier noch die Links zu den vorherigen Artikeln:

• Exchange 2016: Hybrid Modus mit Office 365 (Teil 1)
• Exchange 2016: Hybrid Modus mit Office 365 (Teil 2)

IDFix

Um vorab Probleme zu erkennen, die die erfolgreiche Synchronisation der lokalen Benutzerkonten mit Azure AD verhindern, kann das Tool IDFix verwendet werden. IDFix kann hier kostenlos runtergeladen werden:

• https://www.microsoft.com/en-us/download/confirmation.aspx?id=36832

IDFix erfordert keine Installation und kann direkt ausgeführt werden:

Mit einem Klick auf “Query” sucht IDFix Probleme und schlägt auch direkt eine Lösung vor:

In meiner frischen Testumgebung wurden keine Probleme erkannt. Falls es hier zu Problemen kommt, können diese mittels IDFix auch direkt behoben werden. Hier ist allerdings etwas Vorsicht geboten.

Azure AD Connect

Damit der Hybrid Modus genutzt werden kann, müssen die Benutzerkonten des lokalen Active Directory mit Azure Active Directory synchronisiert werden. Die Synchronisation erledigt das Tool “Azure AD Connect”. Azure AD Connect ist zwar nicht zwingend nötig, erleichtert aber die Administration deutlich.

Die aktuelle Version von Azure AD Connect kann hier runtergeladen werden:

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

Die Installation ist mit wenigen Klicks erledigt, danach startet der Assistent zur Konfiguration:

Ich wähle hier die “angepasste” Installation, da hier direkt einige Anpassungen durchgeführt werden können:

Die Komponenten können in diesem Fall mit den Standard-Einstellungen installiert werden, ggf. macht es Sinn den Installationsort auf eine andere Partition zu verschieben:

Nachdem auf “Installieren” geklickt wurde, erfolgt die Installation der SQL Express Datenbank und der weiteren Komponenten:

Direkt nach der Installation der Komponenten, erfolgt die Basis Konfiguration von Azure AD Connect. Damit sich Benutzer mit gleichen Benutzer/Passwort an Office 365 und an lokalen Ressourcen anmelden können, wird hier die Kennworthashsynchronisierung ausgewählt.

Der Vorteil der Kennworthashsynchronisierung ist, dass keine zusätzliche lokale Infrastruktur wie ADFS erforderlich ist, Azure AD Connect synchronisiert dazu die Passworthashes in beide Richtungen:

Im nächsten Schritt werden die Office 365 Anmeldeinformationen angegeben, damit Azure AD Connect eine Verbindung zum Azure Active Directory herstellen kann:

Da Azure AD Connect auf einem Server der Mitglied des lokalen Active Directory ist installiert wurde, ist die lokale Gesamtstruktur schon vorgeschlagen:

Unter dem Punkt “Verzeichnis hinzufügen” müssen allerdings noch die Anmeldeinformationen angegeben werden.

Bei mir war im folgenden Dialog das Kennwortfeld nicht sichtbar, wenn man aber einmal die Tab-Taste drückt, kommt man in das Feld.

Nachdem die Anmeldeinformationen angegeben wurden, ist das lokale Active Directory in der Liste der „Konfigurierten Verzeichnisse” zu sehen:

Der nächste Dialog zeigt die Azure Anmeldungskonfiguration für die Benutzer. Die Benutzer können sich in diesem Fall mit ihren UPN sowohl am lokalen AD, sowie auch an Office 365 anmelden:

Hier zeigt sich einer der Hauptgründe weshalb die “Angepasste Konfiguration” ausgewählt wurde. In diesem Schritt lassen sich gezielt OUs auswählen die mit Azure AD synchronisiert werden sollen. Auf diesem Weg lässt sich recht einfach einschränken, welche Benutzer und Gruppen mit AzureAD synchronisiert werden:

Der nächste Dialog kann mit den Standardeinstellungen fortgesetzt werden, die Identifizierung anhand der E-Mail Adresse ist meistens eindeutig, denn diese kann es nur einmal geben:

Die Filterung welche Benutzer und Geräte synchronisiert werden sollen, wurde in diesem Fall bereits aus OU-Ebene durchgeführt. Wenn die Synchronisation noch weiter eingeschränkt werden soll, kann hier zusätzlich eine AD-Gruppe genutzt werden:

Als Optionales Feature wird im nächsten Dialog “Exchange Hybridbereitstellung” ausgewählt:

Im nächsten Schritt kann die Synchronisation aktiviert werden. Nach der Konfiguration startet Azure AD Connect direkt mit der Synchronisierung der lokalen AD-Konten mit AzureAD:

Die Einrichtung und Synchronisation dauert nun etwas:

Der letzte Dialog zeigt eine Zusammenfassung:

Sobald die erste Synchronisation abgeschlossen wurde, sind die lokalen Benutzerkonten auch im Office 365 Portal zu sehen:

Im nächsten Teil geht es dann um die Exchange Konfiguration.

Der Beitrag Exchange 2016: Hybrid Modus mit Office 365 (Teil 3) erschien zuerst auf Frankys Web.

Es ist wieder soweit, das nächste Treffen der EUGO (Exchange User Group OWL) findet am 22.06.18 statt. Wieder einmal sind alle Interessierten herzlich zum Treffen eingeladen. Hier einmal die Daten:

Freitag den 22. Juni 2018 19:30 Uhr

Allegro Habichtshöhe in Bielefeld

Bodelschwinghstr. 79 33604 Bielefeld

Link: Google Maps

Link: Website Allegro Habichtshöhe

Über unsere Webseite ist auch direkt die Anmeldung möglich. Bei unserem Treffen werden längst nicht nur Exchange Themen diskutiert, sondern auch andere aktuellen Themen, es gibt wie immer kein festes Programm, keine Folienschlachten oder langwierige Vorträge. Nach wie vor steht das Miteinander sprechen im Vordergrund, einfach mal dem Nachbarn eine Frage stellen und vielleicht eine andere Sichtweise oder Herangehensweise für Herausforderungen kennen lernen. Mit der EUGO möchten wir den Austausch untereinander fördern, ganz egal ob es dabei um Exchange, Windows, Cloud oder Netzwerk geht. Interessante Diskussionen entstehen meist von selbst.

Leider konnte ich bei den letzten beiden Treffen nicht dabei sein, am 22.06 kappt es aber wieder und ich freue mich schon auf die netten Gespräche.

Ich hoffe man sieht sich!

Der Beitrag Exchange User Group OWL (EUGO): Nächstes Treffen am 22.06.18 erschien zuerst auf Frankys Web.

Kritische Updates für Exchange Server:

In allen unterstützen Exchange Server Versionen steckt eine Schwachstelle mit der Angreifer mittels einer speziell präparierten Mail Code auf dem Exchange Server ausführen können.

Microsoft beschreibt das Problem hier:

• CVE-2018-8154 | Microsoft Exchange Memory Corruption Vulnerability

A remote code execution vulnerability exists in Microsoft Exchange software when the software fails to properly handle objects in memory. An attacker who successfully exploited the vulnerability could run arbitrary code in the context of the System user. An attacker could then install programs; view, change, or delete data; or create new accounts.

Exploitation of the vulnerability requires that a specially crafted email be sent to a vulnerable Exchange server.

The security update addresses the vulnerability by correcting how Microsoft Exchange handles objects in memory.

Ein entsprechendes Update für Exchange 2010, Exchange 2013 und Exchange 2016 ist verfügbar. Hier geht es direkt zu den Download des Updates:

• Microsoft Exchange Server 2016 Cumulative Update 9
• Microsoft Exchange Server 2016 Cumulative Update 8
• Microsoft Exchange Server 2013 Service Pack 1
• Microsoft Exchange Server 2013 Cumulative Update 20
• Microsoft Exchange Server 2013 Cumulative Update 19
• Microsoft Exchange Server 2010 Service Pack 3 Update Rollup 21

Auch wenn noch keine Ausnutzung der Schwachstelle bekannt ist, sollte das Update zügig installiert werden.

Der Beitrag Kritische Updates für Exchange Server veröffentlicht (CVE-2018-8154) erschien zuerst auf Frankys Web.

Ich habe mich mal wieder etwas aufs Glatteis führen lassen. Ich hatte ein Update für Exchange installiert, als kurze Zeit später die Outlook App für iOS und Android den Dienst einstellte. Die App synchronisierte keine Daten mehr, Fehlermeldungen gab es keine. Da ich kurz vorher ein Update vorgenommen habe, hatte ich dieses zuerst in Verdacht. Nach einigem Gewühle in den Exchange Logs, ist mir dann allerdings aufgefallen, dass überhaupt keine Verbindung der Outlook App am Exchange Server ankommt.

Daraufhin habe ich die Logs der Webserver Protection der Sophos UTM kontrolliert. Hier wurde ich dann fündig.

Wie man hier sehen kann, stellt die Outlook App die Verbindung zu Exchange nicht direkt her, sondern geht den Umweg über Server im Internet (srcip=“23.101.75.158″). Hier der entsprechende Auszug aus dem Log der UTM:

2018:05:12-22:45:51 utm httpd: id=“0299″ srcip=“23.101.75.158“ localip=“192.168.10.106″ size=“236″ user=“-“ host=“23.101.75.158″ method=“POST“ statuscode=“403″ reason=“dnsrbl“ extra=“Client is listed on DNSRBL black.rbl.ctipd.astaro.local“ exceptions=“SkipURLHardening“ time=“1029″ url=“/Microsoft-Server-ActiveSync“ server=“mail.frankysweb.de“ port=“443″

Die IP 23.101.75.158 gehört Microsoft und im ganz speziellen wohl zum “Outlook cloud service”:

Leider steht genau diese IP auf Cyren Blacklist, welche auch von der Sophos UTM verwendet wird:

Hier gibt es nähere Informationen zum “Outlook cloud service” und wie die Authentifizierung abläuft:

• Passwords and Security in Outlook for iOS and Android for Exchange Server

Nun wird Microsoft sicher nicht nur diese einzige IP für den Verbindungsaufbau nutzen, daher musste ich die Option “Clients mit schlechtem Ruf blockieren” im Firewall Profil der UTM abschalten:

Die Blacklisten werden somit nicht mehr geprüft und die Outlook App funktioniert wieder. Soweit mir bekannt ist, gibt es keine Möglichkeit eine Whitelist für IPs an der UTM zu pflegen.

Persönlich wäre es mir lieber, wenn die App die Verbindung direkt zu Exchange herstellen würde, ohne Umwege. Lieder gibt es aber keine Option dies zu unterbinden, bei der Benutzung der Outlook App muss man also weiterhin darauf vertrauen, dass Microsoft keinen Mist mit den Login Daten baut.

Der Beitrag Sophos UTM 9: Webserver Protection und Outlook für Android / iOS erschien zuerst auf Frankys Web.

Dies ist der vierte Teil der Serie „Exchange 2016 Hybrid Modus mit Office 365”. In diesem Teil wird der Exchange Hybrid Modus aktiviert und erste Tests durchgeführt.

Hier noch die Links zu den vorherigen Artikeln:

• • Exchange 2016: Hybrid Modus mit Office 365 (Teil 1)
  • Exchange 2016: Hybrid Modus mit Office 365 (Teil 2)
  • Exchange 2016: Hybrid Modus mit Office 365 (Teil 3)

Konfigurieren des Exchange Hybrid Modus

Die ersten Schritte für das Einrichten des Exchange Hybrid Modus sind recht unspektakulär. Im lokalen Exchange Admin Center wird unter dem Punkt “Hybrid” auf Konfigurieren geklickt und es wird zur Anmeldung an Office 365 aufgefordert:

Die Anmeldung erfolgt mit dem Office 365 Administrator Konto:

Nach der Anmeldung an Office 365 landet man wieder im Exchange Admin Center. Hier wird nun erneut auf “Konfigurieren” geklickt:

Der Link führt nun zum “Microsoft Office 365-Hybridkonfigurations-Assistent”. Der Assistent muss runtergeladen und installiert werden:

Nachdem die Installation abgeschlossen ist, startet der Hybridkonfigurations-Assistent:

Im ersten Schritt wird der lokale Exchange Server angegeben, in meiner Testumgebung gibt es nur einen Exchange Server, daher fällt die Wahl hier relativ einfach:

Im nächsten Dialog werden die Anmeldeinformationen zur lokalen Exchange Installation und zu Office 365 abgefragt:

Die Konfigurationsdaten werden nun gesammelt und nach kurzer Zeit kann mit einem Klick auf “Weiter” fortgefahren werden:

Im nächsten Dialog wird „”Vollständige Hybridkonfiguration” ausgewählt:

Der Assistent aktiviert nun die Vertrauensstellung zwischen Office 365 und der lokalen Exchange Installation:

Auch für Office 365 muss die Domain validiert werden, hier ist wieder ein DNS TXT Eintrag erforderlich:

In meinem Fall wird der Eintrag bei meinem Hoster Strato angelegt. Der TXT Eintrag muss öffentlich auflösbar sein:

Danach kann mit Hybrid Konfigurationsassistenten weiter gemacht werden:

Der Assistent kann den lokalen Server automatisch für das Mailrouting zwischen Office 365 und der lokalen Exchange Installation konfigurieren. In diesem Fall werden die Sende- und Empfangsconnectoren durch den Assistenten konfiguriert:

Für den Empfangsconnector muss der entsprechende Exchange Server angegeben werden:

Gleiches gilt auch für den Sendeconnector:

Das Mailrouting zwischen dem lokalen Exchange Server und Office 365 wird für die verschlüsselte Übertragung ein Zertifikat benötigt. Ich nutze hier das Wildcard Zertifikat, welches auch an den IIS Dienst gebunden ist. In meiner Umgebung muss ich später noch ein paar kleine Anpassungen vornehmen. Dazu später mehr:

Im letzten Dialog muss noch der öffentliche FQDN des lokalen Exchange Servers angegeben werden. In meiner Testumgebung ist dies outlook.frankysweb.org:

Hinweis: Hier geht es um das Mail Routing zwischen Office 365 und der lokalen Exchange Umgebung. Der Assistent erfragt hier im Prinzip den MX Eintrag für die Domain frankysweb.org. Der Hintergrund ist folgender: In einer Hybriden Konfiguration kann beispielsweise die E-Mail Adresse abc@frankysweb.org zu einem Office 365 Postfach gehören und die Mail Adresse xyz@frankysweb.org zu einem Postfach auf dem lokalen Exchange Server. Wenn nun abc@frankyweb.org eine Mail an xyz@frankysweb.org schreibt, muss Office 365 den lokalen Exchange Server bzw. den den zuständigen Mailserver kennen, an dem die Mail weitergeleitet werden soll. Gleiches gilt in die andere Richtung.

Im letzten Schritt noch einmal auf “Aktualisieren” klicken:

Der Assistent konfiguriert nun Office 365 und die lokale Exchange Umgebung entsprechend der Einstellungen:

Nach kurzer Zeit erscheint dann das gewünschte Ergebnis:

Anpassung Office 365 / Exchange Mail Routing

Wie bereits kurz erwähnt muss ich für meine Testumgebung noch ein paar kleine Anpassung an der Konfiguration vornehmen. In meiner Testumgebung fungiert die Sophos UTM als SPAM Filter. Die UTM verwende ich allerdings auch für meine private Umgebung und habe für die UTM und den SPAM Filter nur ein Zertifikat für frankysweb.de, nicht aber für frankysweb.org. Hier gibt es allerdings in diesem Fall ein Problem mit dem Connector von Office 365. Der Office 365 Connector übermittelt in der Standard Einstellung die Mails nur, wenn das Zertifikat auch den entsprechenden Eintrag enthält. In meinem Fall wird also frankysweb.org auf dem Zertifikat vorausgesetzt.

Die Einstellung lässt sich allerdings anpassen, dazu kann das Exchange Online Admin Portal aufgerufen werden:

Unter dem Punkt “Nachrichtenfluss” findet sich der Reiter “Connectors”. Hier findet sich der Connector “Outbound to …”:

Dieser Connector routet Mails zwischen Office 365 und der lokalen Server, allerdings nur, wenn das Zertifikat auch gültig ist. In meinem Fall kommt es hier also zum Mismatch:

Ich habe daher die Einstellungen des Connectors angepasst, sodass alle Zertifikate akzeptiert werden:

Somit funktioniert auch das Mailrouting in meiner Testumgebung einwandfrei (auf der UTM habe ich dazu ein SMTP Profil erstellt, welches Mails an frankysweb.org an die Testumgebung weiterleitet).

Erste Tests

Damit das Zusammenspiel des lokalen Exchange Servers mit Office 365 getestet werden kann, wird natürlich auch ein Postfach benötigt, welches in Office 365 gehostet wird. Office 365 Postfächer lassen sich nun bequem über die lokale Exchange Admin Center anlegen:

Wie auch bei einem lokalen Benutzer müssen die entsprechenden Informationen angegeben werden. Das Benutzerkonto wird dabei im lokalen Active Directory angelegt und mittels Azure AD Ccnnect zu Azure AD synchronisert:

Auch Office 365 Postfächer können über das lokale Exchange Admin Center verwaltet werden:

Im Office 365 Portal muss nun dem neuen Benutzer noch eine Lizenz zugewiesen werden:

Nachdem eine Lizenz zugewiesen wurde, kann die Anmeldung mit dem neuen Benutzer am Office 365 Portal getestet werden:

Ich teste zunächst OWA:

Eine Testnachricht von einem externen Empfänger schlägt schon mal im Office 365 Postfach auf. DIe Mail wird dabei über die lokalen Exchange Server zu Office 365 geroutet:

Ein weiterer Test von Office 365 zu einem lokalen Postfach, die Abfrage des Adressbuchs funktioniert schon einmal:

Und hier noch einmal der Weg von einem lokalen Postfach zu Office 365:

Alle Mails konnten erfolgreich zugestellt werden, die ersten Tests waren also erfolgreich.

Im nächsten Artikel geht es dann etwas mehr ans Eingemachte: E-Mail Routing, Frei/Gebucht Informationen, Adressbücher, Migration.

Der Beitrag Exchange 2016: Hybrid Modus mit Office 365 (Teil 4) erschien zuerst auf Frankys Web.

Auf dem Exchange Team Blog sind drei ausführliche Artikel zu Exchange Server und TLS 1.2 veröffentlicht worden. Die Artikel sind nicht nur sehr lesenswert, sondern haben auch einen wichtigen Hintergrund:

Ab Oktober 2018 setzt Office 365 TLS 1.2 voraus und akzeptiert keine Mails von Servern die nur TLS 1.0 oder TLS 1.1 unterstützen.

Im Klartext heißt dies, wenn euer Exchange Server Mails an Office 365 Empfänger zustellen will und kein TLS 1.2 unterstützt, werden die Mails den Empfänger ab Oktober 2018 nicht erreichen. Gleiches gilt natürlich auch für Smarthosts und Relays die Mails an Office 365 zustellen möchten.

Soweit bekannt, betrifft die Änderung ab Oktober den Weg der Mails zu Office 365. Für Mails von Office 365 zu Empfängern außerhalb von Office 365 gilt weiterhin Opportunistic TLS. Wenn der empfangene Mail Server kein TLS unterstützt, kann die Mail also auch ohne Transportverschlüsselung von Office 365 gesendet werden.

Vielleicht kann die kleine Grafik es besser erläutern:

Nähere Informationen gibt es in den drei Artikel auf dem Exchange Team Blog:

• Exchange Server TLS guidance, part 1: Getting Ready for TLS 1.2
• Exchange Server TLS guidance Part 2: Enabling TLS 1.2 and Identifying Clients Not Using It
• Exchange Server TLS guidance Part 3: Turning Off TLS 1.0/1.1

In den Artikel wird auch beschreiben welche Einstellungen für Windows Server vorgenommen werden müssen, damit Exchange TLS 1.2 verwenden kann. Gleiches gilt wie auch schon erwähnt für vorgelagerte SPAM-Filter, Smarthosts und Relays die Mails an Office 365 zustellen. Für diese muss ebenfalls sichergestellt sein, dass sie TLS 1.2 unterstützen und verwenden.

Der Beitrag Exchange Server und TLS 1.2 erschien zuerst auf Frankys Web.

Zwar besitzt die UTM mit dem HTML5 VPN auch eine Lösung um RDP Verbindungen im Browser darzustellen, jedoch läuft diese als innerhalb des Userportals. Wer nur eine öffentliche IP hat, muss also wie ich mit der eingebauten Sophos Lösung auf einen anderen Port ausweichen. Oft sind in anderen Netzwerken aber oft nur die gängigen Ports wie 80 und 443 geöffnet.

Ich stand vor genau diesem Problem, nur eine öffentliche IP, oft konnte ich über andere Ports keine Verbindung zum UTM Userportal herstellen. Der HTTPS Port wird schon durch die Webserver Protection und andere Dienste belegt.

Ich habe dann zunächst das Windows Admin Center getestet, ziemlich brauchbare Lösung, nur leider nicht in Verbindung mit der UTM Webserver Protection. Das Windows Admin Center verwendet WebSockets, dies wird jedoch nicht durch die UTM Webserver Protection unterstützt.

Es gibt aber Apache Guacamole Projekt, dies funktioniert bei mir bisher perfekt in Zusammenspiel mit der Webserver Protection. Vielleicht hilft dieser kleine Artikel ja noch anderen Leuten weiter, daher hier einmal kurz die Einrichtung der Webserver Protection für Guacamole.

Mein Aufbau sieht in etwa wie folgt aus:

Die Sophos UTM Webserver Protection nutzt ein kostenloses Wildcard Zertifikat von Let’s Encrypt. Die Webserver Protection läuft auf Port 443 (https) und leitet je nach Hostnamen an die echten Webserver weiter. Zur Zeit sind dies zum Beispiel ein Exchange Server und ein weiterer Webserver:

Zusätzlich kommt jetzt nun noch eine kleine CentOS VM dazu, auf die Guacamole laufen soll. Ich nutze die CentOS Minimal Installation mit 1 GB RAM und 1 CPU. Die Installation von Guacamole ist ziemlich einfach, ich habe einfach dieses Installationsscript verwendet:

• https://sourceforge.net/projects/guacamoleinstallscript/files/CentOS/

Das Script fragt ein paar Einstellungen ab und installiert eine fertige Guacamole Umgebung.

Kleiner Hinweis: Ich habe Guacamole mit NGINX installiert, mehr dazu später.

Sobald Guacamole installiert ist, kann auf der UTM ein neuer Webserver angelegt werden:

Danach wird ein Firewall Profil benötigt:

Damit Guacamole funktioniert, sind ein paar Ausnahmen nötig. Diese Regeln musste ich übergehen:

• 981257
• 981245
• 981246
• 981243
• 981204
• 981172
• 981173
• 960015
• 981203
• 981318
• 981176

Jetzt kann der virtuelle Webserver angelegt werden (Firewall Profil nicht vergessen):

Da die Guacamole Installation über das Verzeichnis /guacamole aufgerufen wird, habe ich die NGIX Konfiguration noch etwas angepasst. So muss nicht bei jedem Aufruf das /guacamole angehangen werden:

• /etc/nginx/conf.d/guacamole_ssl.conf

Somit wird nun beispielsweise ein Aufruf von https://rdp.frankysweb.de nach https://rdp.frankyweb.de/guacamole umgeleitet. Mit einer entsprechenden Umleitung direkt in der UTM wollte es bei mir nicht funktionieren. Aktuell ist es also doppelt gemoppelt (UTM + NGNIX). Vielleicht hat da ja noch jemand einen Tipp?

Bisher konnte ich keine Einschränkungen in Verbindung mit der UTM feststellen, alles funktioniert wie geschmiert:

Der Funktionsumfang ist zwar nicht mit dem Windows Admin Center zu vergleichen, aber die RDP Verbindung im Browser funktioniert erstklassig und ist extrem schnell:

Ich habe zusätzlich noch die Reverse Authentication vorgeschaltet, dadurch wird derzeit allerdings doppelt nach Benutzernamen und Passwort gefragt. Ich werde mal schauen, ob sich Guacamole auf Basic Authentication umstellen lässt. man könnte es natürlich auch als 2-Faktor Authentifizierung so belassen

Der Beitrag RDP im Browser: Apache Guacamole und Sophos UTM erschien zuerst auf Frankys Web.

In diesem Artikel hatte ich bereits darauf hingewiesen, dass Office 365 ab Oktober 2018 nur noch TLS 1.2 unterstützen wird. Bevor auf die aktuelle TLS 1.2 Version umgestellt wird, sollten jedoch die Clients / Server ermittelt werden, mit denen der lokale Exchange Server noch nicht via TLS 1.2 kommuniziert.

Das folgende kleine Script kann verwendet werden um die TLS Versionen der Clients und Server zu ermitteln, die Mails empfangen / senden. Das Script wertet die Logs der Connectoren aus und erzeugt CSV Dateien mit der jeweiligen TLS Version.

In Zeile 1 muss dazu der Pfad angegeben werden, wo die CSV Dateien gespeichert werden. In Zeile 2 muss der Pfad zu den SMTP Connector Logs angegeben werden (Für Exchange 2016 schon vorbelegt):

$LogExportPath = "C:\Scripts\TLSVersion\"
$SMTPLogPath = "C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\ProtocolLog"

write-host "Getting Logs"
$Logs = (Get-ChildItem $SMTPLogPath\*.log -Recurse| select Fullname).Fullname
$TLS12Log = "$LogExportPath" + "TLS12.csv"
$TLS11Log = "$LogExportPath" + "TLS12.csv"
$TLS10Log = "$LogExportPath" + "TLS12.csv"

foreach ($Log in $Logs)
{
 write-host "Processing $Log"
 $LogImport = Get-Content -Path $Log  | Select-Object -Skip 3 | Out-String | ConvertFrom-Csv | select -property @{N='DateTime';E={$_."#Fields: date-time"}}, @{N='LocalEndpoint';E={$_."local-endpoint"}}, @{N='RemoteEndpoint';E={$_."remote-endpoint"}}, @{N='Message';E={$_.context}}
 $TLS12 = $LogImport | where {$_.Message -match "SP_PROT_TLS1_2" -and $_.Message -match "succeeded"} | export-csv $TLS12Log -append -delimiter ";"
 $TLS11 = $LogImport | where {$_.Message -match "SP_PROT_TLS1_1" -and $_.Message -match "succeeded"} | export-csv $TLS11Log -append -delimiter ";"
 $TLS10 = $LogImport | where {$_.Message -match "SP_PROT_TLS1_0" -and $_.Message -match "succeeded"} | export-csv $TLS10Log -append -delimiter ";"
}
write-host "Done"
write-host "For Hosts using TLSv1.2 see $TLS12Log"
write-host "For Hosts using TLSv1.1 see $TLS11Log"
write-host "For Hosts using TLSv1.0 see $TLS10Log"

Das Script durchsucht die Logs nach den Strings SP_PROT_TLS1_2, SP_PROT_TLS1_1 und SP_PROT_TLS1_0 und speichert die gefunden Einträge in den jeweiligen CSV Dateien TLS12.csv, TLS11.csv und TLS10.csv, so lassen sich die Ergebnisse später weiter verarbeiten:

Das Script ist natürlich nur aussagekräftig, wenn der Exchange selbst die Mails aus dem Internet empfängt und auch versendet. Dies dürfte in den meisten Fällen nicht der Fall sein, da beispielsweise ein vorgelagertes AntiSPAM Gateway zum Einsatz kommt.

Falls das AntiSPAM Gateway die verwendete TLS Version in den Logs nicht anzeigt, kann der folgende Test weiterhelfen:

• https://www.checktls.com/TestReceiver

Der Test zeigt die verwendete TLS Version in den Ergebnissen an, dies gibt Aufschluss darüber, ob das Gateway in der Lage ist, Mails via TLS 1.2 zu empfangen:

Damit es keine Schwierigkeiten mit Office 365 und den lokalen Mailservern gibt, sollten auch SPF, DKIM und DMARC  entsprechend umgesetzt sein. Ob SPF, DKIM und DMARC entsprechend implementiert sind, lässt sich mit einer Mail an den folgenden Test feststellen:

• https://www.checktls.com/TestSender

Der Beitrag Exchange Server: TLS Versionen der Server / Clients ermitteln erschien zuerst auf Frankys Web.

Bei der Migration von Exchange 2010 / 2013 zu Exchange 2016 kann es zu Problemen mit Autodiscover in Verbindung mit Kerberos kommen. Die Probleme äußern von permanenten Abfragen der Anmeldeinformationen in Outlook bis zum kompletten Absturz von Outlook wenn ein Postfach auf einen Exchange 2016 Server verschoben wurde.

Wann kann das Problem auftreten?

Das Problem kann auftreten wenn die Exchange Server für die Kerberos Authentifizierung konfiguriert wurden (RollAlternateserviceAccountCredential.ps1) und die AD-Konten der Benutzer Mitglied von vielen Gruppen sind. “Viele Gruppen” ist dabei relativ, schon um die 100 Gruppen sind problematisch.

Wie äußert sich das Problem?

Postfächer die noch nicht zu Exchange 2016 migriert wurden, fragen unter Umständen permanent nach den Anmeldeinformationen:

Der Autodiscover Test schlägt fehl und meldet den http-Statuscode 400, sowie einige andere Fehlercodes (Der Fehlercode 400 geht aus dem Screenshot nicht hervor, würde aber direkt nach dem Statuscode 401 angezeigt werden, leider habe ich keine Screenshots in denen es ersichtlich wird):

Wenn Postfächer von den alten Exchange Servern zu Exchange 2016 verschoben werden stürzt Outlook nach einem Neustart ab:

Das Abstürzen von Outlook konnte mit den Outlook Versionen 2010, 2013 und 2016 nachgestellt werden.

Ursache und Lösung

Da Exchange 2016 als Proxy für die älteren Exchange Versionen fungiert, wird auch das Kerberos Token im HTTP-Header weitergereicht. Hierbei kann es vorkommen, dass bei großen Kerberos Token und somit großen HTTP-Headern, die Exchange 2010 Server die HTTP-Anfrage ablehnen und den folgenden Fehler liefern:

• HTTP 400 – Bad Request (Request header too long)

Um das Problem zu beheben, kann könne  die Limits entsprechend angepasst werden. Auf allen Exchange 2010 und Exchange 2013 Servern müssen dazu, die folgenden 4 Registry Schlüssel gesetzt werden:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Name: MaxTokenSize
Typ: REG_DWORD (32Bit)
Wert: 65536
Basis: Dezimal

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w3svc\parameters 
Name: MaxClientRequestBuffer
Typ: REG_DWORD (32Bit)
Wert: 32768
Basis: Dezimal

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters 
Name: MaxFieldLength
Typ: REG_DWORD (32Bit)
Wert: 65536
Basis: Dezimal

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters 
Name: MaxRequestBytes
Typ: REG_DWORD (32Bit)
Daten: 16777216
Wert: Dezimal

Auf allen Domain Controllern muss der folgende Registry Schlüssel gesetzt werden:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Name: MaxTokenSize
Typ: REG_DWORD (32Bit)
Value data: 65536
Basis: Decimal

Die Exchange Server und Domain Controller müssen nach dem Setzen der Registry Schlüssel neu gestartet werden.

Der Beitrag Exchange Migration: Probleme mit Autodiscover (HTTP 400) und Kerberos erschien zuerst auf Frankys Web.

Es wurden neue Updates für alle Exchange Server Versionen veröffentlicht. Auch Exchange 2010 befindet sich darunter. Hier geht es direkt zum Download:

• Exchange Server 2016 CU10
• Exchange Server 2013 CU21
• Exchange Server 2010 Update Rollup 22

Hier geht es zu den Details der Änderungen:

• Exchange Server 2016 CU10
• Exchange Server 2013 CU21
• Exchange Server 2010 Update Rollup 22

Artikel zu den Updates auf dem Exchange Team Blog:

• Exchange Team Blog

Hier findet sich ein Artikel über Punkte die bei der Installation von CUs für Exchange 2016 beachtet werden müssen:

Exchange 2016: Kumulative Updates (CU) installieren

Insbesondere der Windows Defender und andere Virenscanner sollten für die Dauer der Installation deaktiviert werden, diese verursachen gern mal Probleme während der Aktualisierung. Der Windows Defender sorgt insbesondere dafür, das Exchange CUs mehrere Stunden für die Installation benötigen.

Auch die Server Component States sollten nach der Installation eines Updates kontrolliert werden, hier finden sich entsprechende Informationen:

Exchange 2016: Server Component States

Hier findet sich auch noch ein Artikel über mögliche Stolpersteine bei den .NET Framework Abhängigkeiten der CUs für Exchange 2013 und Exchange 2016:

Exchange 2013: Stolperstein beim Update einer alten Version auf das aktuelle CU

Der Beitrag Exchange Server: Neue Updates (Juni 2018) erschien zuerst auf Frankys Web.

Größenbeschränkungen für Mails lassen sich mit Exchange Server 2016 an mehreren Stellen setzen. Nicht nur für Empfangs- und Sendeconnectoren gibt es Größenbeschränkungen für Mails, sondern auch für ActiveSync, Exchange Web Services (EWS) und OWA (oder Outlook on the Web).

Das Standardlimit für ActiveSync Clients liegt bei 10 MB, wohin das Limit für EWS bei 64 MB liegt und für OWA bei 35 MB. Allerdings muss hier noch die Base64-Kodierung berücksichtigt werden. Die Base64-Kodierung erhöht die Größe der Mail um ca. 33%. Für ActiveSync bedeutet dies, dass eine Mail nur ca. 7 MB groß sein darf, für EWS sind es in etwa 48 MB. Wie groß eine Mail genau sein darf, lässt sich nicht genau sagen, als Faustregel kann aber folgendes gelten:

• Größe der Mail inkl. Anhänge + 33 % = Tatsächliche Mailgröße

Wenn Benutzer von Tablets und Smartphones via ActiveSync Mails verschicken möchten die größer als ca, 7 MB sind, kann das Limit entsprechend angehoben werden.

Manuelles Anpassen des Active Sync Limits

Das Limit für ActiveSync lässt sich manuell über das Editieren der IIS Konfiguration im IIS-Manager und der web.config des ActiveSync Verzeichnisses durchführen. Etwas einfacher geht es per Script (siehe unten), die manuelle Methode eignet sich also eher zur Kontrolle der Einstellungen oder für kleine Exchange Organisationen.

Im IIS-Manager wird dazu der Konfigurations-Editor für das ActiveSync Verzeichnis ausgewählt:

Jetzt kann der Abschnitt “system.webServer/security/requestFiltering” ausgewählt werden:

Unter dem Punkt “requestLimits” findet sich die Einstellung “maxAllowedContentLength”. In der Standardeinstellung ist hier ein Wert von 30000000 Bytes angegeben, was in etwa 28 MB entspricht. Wenn geplant ist das ActiveSync Limit auf einen Wert unterhalb von 28 MB anzuheben, kann der Standardwert also beibehalten werden. Bei größeren ActiveSync Limits wie beispielsweise 50 MB, muss der Wert entsprechend angehoben werden. In diesem Beispiel wird das Limit auf ca. 50 MB für die tatsächliche Mailgröße festgelegt:

• 50 MB + 33 % = 66,5 MB (umgerechnet 69730304 Bytes)

Der Wert für “maxAllowedContentLength” entspricht in diesem Beispiel also 69730304:

Die gleichen Einstellungen müssen nun einmal für das Exchange Back End wiederholt werden:

Nachdem die Konfiguration im IIS-Manager angepasst wurde, finden sich jetzt entsprechende web.config Dateien in den folgenden Verzeichnissen:

• %ExchangeInstallPath%FrontEnd\HttpProxy\Sync\web.config (FrontEnd)
• %ExchangeInstallPath%ClientAccess\Sync\web.config (Backend)

Hinweis: Die web-config Dateien existieren erst, wenn der Wert im IIS-Manager angepasst wurde.

In beiden Dateien muss nun die folgende Zeile editiert werden, hier wird der Wert nun in Kilobyte angegeben:

• <httpRuntime maxRequestLength=“10240″ fcnMode=“Disabled“ />

50 MB + 33 % = 66,5 MB (umgerechnet 68096 KiloBytes)

In der web.config des Backends muss noch ein weiterer Wert angepasst werden, hier sind es allerdings wieder Bytes:

• <add key=“MaxDocumentDataSize“ value=“10240000″>

50 MB + 33 % = 66,5 MB (umgerechnet 69730304 Bytes)

Nachdem die Einstellungen durchgeführt wurden muss der IIS mittels “iisreset” neugestartet werden.

Anpassen des ActiveSync Limits per Script

Das folgende kleine Script kann verwendet werden, um das die entsprechenden Einstellungen zu setzen. Das Script setzet das Limit für Active Sync auf 66,5 MB, was in etwa einer tatsächlichen Mail Größe von 50 MB entspricht. Wenn es mehrere Exchange 2016 Server in der Organisation gibt, muss das Script auf allen Exchange Servern ausgeführt werden:

%windir%\system32\inetsrv\appcmd.exe set config "Default Web Site/Microsoft-Server-ActiveSync/" -section:system.webServer/security/requestFiltering /requestLimits.maxAllowedContentLength:69730304
%windir%\system32\inetsrv\appcmd.exe set config "Default Web Site/Microsoft-Server-ActiveSync/" -section:system.web/httpRuntime /maxRequestLength:68096
%windir%\system32\inetsrv\appcmd.exe set config "Exchange Back End/Microsoft-Server-ActiveSync/" -section:system.webServer/security/requestFiltering /requestLimits.maxAllowedContentLength:69730304
%windir%\system32\inetsrv\appcmd.exe set config "Exchange Back End/Microsoft-Server-ActiveSync/" -section:system.web/httpRuntime /maxRequestLength:68096
%windir%\system32\inetsrv\appcmd.exe set config "Exchange Back End/Microsoft-Server-ActiveSync/" -section:appSettings /[key='MaxDocumentDataSize'].value:69730304

Nachdem das Script ausgeführt wurde, muss der IIS neu gestartet werden:

iisreset

Die Limits lassen sich im Script anpassen, hier muss auf die unterschiedlichen Einheiten geachtet werden:

• maxAllowedContentLength = Wert in Bytes
• maxRequestLength = Wert in KiloBytes
• MaxDocumentDataSize = Wert in Bytes

Hinweis

Da die Einstellung zu den Limits in der web.config vorgenommen werden, kann es passieren das nach der Installation von Exchange Updates wieder die Standardwerte gelten. Nachdem ein CU für Exchange 2016 installiert wurde, sollten die Einstellungen also kontrolliert werden. Ein kleines Batch Script wie oben beschrieben, kann auch vorsorglich nach einem Update von Exchange ausgeführt werden (nicht den IISReset vergessen).

Der Beitrag Exchange 2016: Größenbeschränkung für ActiveSync verändern erschien zuerst auf Frankys Web.

Mit der Überwachungsprotokollierung können bestimmte Aktionen für Postfächer protokolliert werden, besonders sinnvoll ist diese Funktion für Postfächer auf denen mehrere Benutzer Zugriff haben. So lässt sich zum Beispiel nachvollziehen, welcher Benutzer auf eine bestimmte Mail geantwortet hat, oder wer welche Mail gelöscht hat. Auch bei den normalen Benutzerpostfächern, kann die Überwachungsprotokollierung (Audit Logging) hilfreich sein. Zwar sind die Audit Logs meist nicht für die Fehleranalyse hilfreich, aber es lässt sich so feststellen, was der Benutzer mit einer Mail angestellt hat.

In der Standardeinstellung sind die Mailbox Audit Logs deaktiviert und können je Postfach aktiviert werden. Die Mailbox Audit Logs werden in der Standardeinstellung 90 Tage lang gespeichert.

Die folgenden Aktionen werden für Postfächer mit aktivierten Mailbox Audit Logging protokolliert:

Quelle: https://docs.microsoft.com/de-de/Exchange/policy-and-compliance/mailbox-audit-logging/mailbox-audit-logging

Konfigurieren der Überwachungsprotokollierung

Um das Mailbox Audit Logging für ein bestimmtes Postfach zu aktivieren, kann der folgende Befehl verwendet werden:

Get-Mailbox frank | Set-Mailbox -AuditEnabled $true

Mit dem folgenden Befehl kann die Überwachungsprotokollierung für alle Postfächer aktiviert werden:

Get-Mailbox -ResultSize Unlimited | Set-Mailbox -AuditEnabled $true

Das Abschalten der Protokollierung kann mit folgenden Befehlen für ein einzelnes Postfach oder für alle Postfächer durchgeführt werden:

Get-Mailbox Frank | Set-Mailbox -AuditEnabled $false
Get-Mailbox -ResultSize Unlimited | Set-Mailbox -AuditEnabled $false

In der Standardeinstellung beträgt die Aufbewahrungszeit für die Mailbox Audit Logs 90 Tage, dieses Limit lässt sich mit dem folgenden Befehlen anpassen (Zum Beispiel auf 180 Tage für ein einzelnes Postfach oder für alle):

Get-Mailbox Frank | Set-Mailbox -AuditLogAgeLimit 180
Get-Mailbox -ResultSize Unlimited | Set-Mailbox -AuditLogAgeLimit 180

Je nach Aktivität des Benutzers und Dauer der Speicherung der Logs, erhöht sich der Speicherbedarf der Mailbox. Der erhöhte Platzbedarf muss also mit einkalkuliert werden. bevor die Überwachung für alle Postfächer aktiviert wird, sollte dies zunächst nur für einige Postfächer konfiguriert werden, somit lässt sich der zusätzliche Platzbedarf abschätzen.

Prüfen der Überwachungsprotokollierung

Nachdem die Protokollierung eingeschaltet wurde, wird ein neuer Ordner mit dem Namen “Audits” im Postfach des Benutzers erstellt. In diesem Ordner werden die Überwachungsereignisse gespeichert. Der Benutzer kann nicht auf den Ordner “Audits” zugreifen und bekommt ihn auch nicht in Outlook angezeigt. Mit der Exchange Management Shell lässt sich prüfen, ob der Ordner erstellt wurde und ob bereits Ereignisse gespeichert wurden. Dazu kann der folgende Befehl verwendet werden:

get-mailbox frank | Get-MailboxFolderStatistics | where {$_.name -eq "Audits"} | ft name,itemsinfolder

Im Screenshot ist zu sehen, dass der Ordner “Audits” im Postfach “Frank” erstellt wurde und bereits 5 Ereignisse enthält. Auf diesem Weg lässt sich auch der Speicherbedarf der Überwachungsprotokollierung prüfen:

get-mailbox frank | Get-MailboxFolderStatistics | where {$_.name -eq "Audits"} | ft name,itemsinfolder,foldersize

Abrufen der Protokolle

Damit ein Benutzer die Überwachungsprotokolle einsehen kann, muss der Benutzer Mitglied der AD-Gruppe “Compliance Management” sein. In der Standardeinstellung hat kein Benutzer das Recht die Protokolle einzusehen. Mit dem folgenden Befehl kann ein Benutzer zur Gruppe “Compliance Management” hinzugefügt werden:

Add-RoleGroupMember "Compliance Management" -Member administrator

Dieser Vorgang ist auch direkt via Active Directory Konsole oder über das Exchange Admin Center möglich.

Häufig werden nur die Überwachungsprotokolle für einen bestimmten Benutzer benötigt. Die schnellste Möglichkeit ist es, sich das Protokoll direkt auf der Exchange Management Shell anzeigen zu lassen. Für einen einzelnen Benutzer funktioniert dies mit dem folgenden Befehl:

Search-MailboxAuditLog frank -ShowDetails -StartDate ((get-date).AddDays(-2)) -EndDate (get-date)

In diesem Fall werden die Ereignisse der letzten 2 Tage für den Benutzer “Frank” in der Shell angezeigt:

Bei Bedarf lassen sich die Ereignisse entsprechend filtern. Hier zum Beispiel alle Ereignisse der letzten 2 Tage in denen ein “HardDelete” ausgeführt wurde (Mail mit Shift+Entf gelöscht):

Search-MailboxAuditLog frank -ShowDetails -StartDate ((get-date).AddDays(-2)) -EndDate (get-date) | where {$_.Operation -eq "HardDelete"}

Im Exchange Admin Center gibt es ebenfalls eine Möglichkeit an die Überwachungsprotokolle zu kommen. In diesem Fall werden die Ergebnisse per E-Mail als XML-Datei an einen Empfänger zugestellt. Die XML-Datei lässt sich dann wiederum mit der PowerShell oder anderen Tools weiterverarbeiten.

Die Protokolle können wie folgt im Exchange Admin Center abgerufen werden:

Es lässt sich dann entsprechend festlegen für welche Benutzer die Postfachüberwachungsprotokolle exportiert werden sollen und wer der Empfänger der Ergebnisse ist:

Das Zustellen der Ergebnisse per Mail und XML-Datei lässt sich auch direkt aus der Exchange Management Shell auslösen, dafür kann der folgende Befehl verwendet werden:

New-MailboxAuditLogSearch "hans3" -Mailboxes hans,frank -StatusMailRecipients frank@frankysweb.org -StartDate ((get-date).AddDays(-2)) -EndDate (get-date) -ShowDetails

Der folgende Screenshot zeigt eine entsprechende Mail und die XML-Datei:

Die XML-Datei lässt sich dann wiederum mit entsprechenden Tools filtern oder weiter verarbeiten. Auch die PowerShell bietet sich hier hier an:

Hinweis

Wenn der Exchange Server auf einem “nicht englisch sprachigem” Server installiert wurde, werden keine Audit Logs angezeigt. Hier hilft es die Sprache auf “English – US” umzustellen:

• Search-AdminAuditLog or Search-MailboxAuditLog with parameter returns empty results in Exchange Server

Der Beitrag Exchange 2016: Überwachungsprotokollierung für Postfächer aktivieren erschien zuerst auf Frankys Web.

Nur eine kleine Information am Rande, die Exchange Server Dokumentation ist vom Technet zu Microsoft Docs umgezogen. Die Doku findet sich nun unter folgendem Link:

• https://docs.microsoft.com/de-de/exchange/

Die alten URLs sind weiterhin verfügbar, es besteht also kein unmittelbarer Handlungsbedarf seine Favoriten zu aktualisieren. Die Doku und Informationen zu Exchange 2010 und Exchange 2013 finden sich weiterhin im Technet.

Ich finde die neue Seite übersichtlicher und besser strukturiert. Hier zum Vergleich einmal die “alte Technet” Seite:

Microsoft Docs wirkt irgendwie moderner, außerdem kann man sich den neuen Link besser merken

Der Beitrag Exchange Server 2016: Dokumentation unter neuer URL verfügbar erschien zuerst auf Frankys Web.

Seit gestern Abend war meine Seite nur sehr sporadisch erreichbar. Ab heute Mittag war die Seite fast komplett offline. Es wurde in den meisten fällen nur der Fehlercode HTTP 500 ausgeliefert. Betroffen war die komplette Webseite inkl. aller Unterseiten. Leider konnte ich mich erst jetzt dem Problem annehmen.

Schuld war ein WordPress Plugin, welches eigentlich die Seiten für den schnelleren Zugriff cachen sollte. Das Plugin ist schon recht lange im Einsatz und hatte bisher gute Dienste geleistet. Scheinbar kam es nun aber zu einer Fehlfunktion. Seitdem das Plugin deaktiviert und der Cache gelöscht ist, funktioniert die Seite wieder wie gewohnt und auch die ersten Kommentare trudeln wieder ein.

Für das Plugin werde ich eine Alternative suchen und diese vorher ausgiebig testen. Ich denke ich werde mir auch Gedanken um ein “Notfall”-System machen und solche längeren Ausfälle in Zukunft abfangen zu können.

Dies war jetzt übrigens die zweite längere Downtime in den 8 Jahren die diese Seite existiert, der erste Ausfall liegt schon ein paar Jahre zurück und war ein Routingproblem im Rechenzentrum bei meinem alten Hoster. Nun also mal zur Abwechslung ein WordPress Plugin.

So schnell ist übrigens die Verfügbarkeitsstatistik von 99,9 % dahin

Der Beitrag Kurze Info: FrankysWeb funktioniert wieder erschien zuerst auf Frankys Web.

Derzeit gibt es Probleme mit Exchange Server und den Juli Updates für Windows Server. Microsoft hat das fehlerhafte Update mittlerweile zurückgezogen und eine aktualisierte Version via Windows Update bereitgestellt. Bei dem aktuellen Update handelt es sich um KB4345418, Exchange Server sollten schleunigst aktualisiert werden um Probleme mit dem MSExchangeTransport Dienst zu vermeiden.

Hier gibt es den entsprechenden Beitrag auf dem Exchange Team Blog:

• Issue with July Updates for Windows on an Exchange Server

Hier gibt es Details zum neuen Update:

• July 16, 2018—KB4345418 (OS Build 14393.2367)

KB4345418 behebt ebenfalls ein Problem mit einem DHCP Failover Cluster bei denen Clients keine gültigen IP Konfiguration erhalten haben. Auch SQL-Server starteten mit dem alten Update möglicherweise nicht mehr richtig. Das aktuelle Update lässt sich auch direkt über den Windows Update Katalog runterladen und manuell installieren:

• http://www.catalog.update.microsoft.com/Search.aspx?q=KB4345418

In meinem Fall wird es aber bereits per Windows Update verteilt. Das fehlerhafte Update ist übrigens KB4338814, Server auf denen dieses Update installiert ist, sollten also schnell mit KB4345418 versorgt werden.

Der Beitrag Probleme mit Juli Windows Updates und Exchange Server erschien zuerst auf Frankys Web.

Nach knapp 4 Monaten hat Sophos ein Update für die UTM veröffentlicht. Das Update auf die Version 9.510-4 schließt diverse Sicherheitslücken und behebt einige funktionale Probleme. Lang erwartete Features, wie zum Beispiel die Unterstützung von Let’s Encrypt und IKEv2 lassen weiterhin auf sich warten.

Hier ist die Liste mit den Änderungen:

• [NUTM-8273]: [Basesystem] Inconsistent reporting data in hot standby environment
• [NUTM-9089]: [Basesystem] ulogd restarting randomly
• [NUTM-9423]: [Basesystem] Missing DMI info or missing WiFi card should turn status LED red for desktop refresh models
• [NUTM-9516]: [Basesystem] CVE-2017-3145: BIND vulnerability
• [NUTM-9764]: [Basesystem] multiple NTP vulnerabilities
• [NUTM-9862]: [Basesystem] CVE-2018-8897: Don’t use IST entry for #BP stack
• [NUTM-9944]: [Basesystem] ‚ethtool -p‘ is not working for shared port
• [NUTM-9945]: [Basesystem] SG/XG 125/135 upper 4 ports LEDs at front and rear side not behaving as expected
• [NUTM-9286]: [Email] CVE-2011-3389: SSL/TLS BEAST Vulnerability And Weak Algorithms
• [NUTM-9460]: [Email] Quarantine unscannable and encrypted content not working as expected
• [NUTM-9539]: [Email] SMTP callout with TLS does not work
• [NUTM-9627]: [Email] Parent proxy for WAF (ctipd) not applied without active e-mail subscription
• [NUTM-9771]: [Email] Redesign TFT detection to decrease false positives/negatives
• [NUTM-9836]: [Email] HSTS usage breaks Quarantine Report release link
• [NUTM-9789]: [Logging] Not able to archive logs using SMB share
• [NUTM-8969]: [Network] Inconsistent DHCP leases in WebAdmin
• [NUTM-9049]: [Network] Cannot change IPv4 interface as IPv6 gateway is required
• [NUTM-9194]: [Network] Static route switching to different VLAN
• [NUTM-9646]: [Network] eth0 is falsely marked „dead“ when running „hs“ on slave
• [NUTM-9739]: [Network] Network monitor restarting on slave nodes
• [NUTM-9795]: [RED] RED50 issue with large packets in Transparent/Split mode
• [NUTM-9607]: [Reporting] Upper case umlauts in PDF Executive Reports are not displayed correctly
• [NUTM-9624]: [Reporting] WAF – Top attackers won’t be displayed after upgrade to v9.5
• [NUTM-9719]: [SUM] Web Protection service shown as down in SUM
• [NUTM-9547]: [UI Framework] UserPortal does not correctly detect browser specified preferred language for Chinese Simplified
• [NUTM-9527]: [WAF]mod_url_hardening stack corruption
• [NUTM-8038]: [WebAdmin] WebAdmin not available
• [NUTM-9232]: [WebAdmin] Sometimes ‚backend connection failed‘ while login
• [NUTM-9529]: [WebAdmin] Role with ‚Web Protection Manager‘ rights can’t access Aplication Control
• [NUTM-9689]: [WebAdmin] Report Auditor role is unable to open the dashboard
• [NUTM-5293]: [Web] Google is missed in the Search Engines reports
• [NUTM-6240]: [Web] FTP download through HTTP Proxy in standard mode not possible
• [NUTM-9039]: [Web] Connections may fail when using upstream proxies due to „Proxy-Connection“ header being sent
• [NUTM-9399]: [Web] Classification for Windows Updates differs between AFC and conntrack
• [NUTM-9413]: [Web] Unable to upload certificate to „Local Verification CAs“
• [NUTM-9491]: [Web] HTTP Proxy coredumps with SIGABRT
• [NUTM-9549]: [Web] Proceeding after content warning results in display issues on redirected pages
• [NUTM-9599]: [Web] HTTP Proxy requests stuck without appropriate timeout
• [NUTM-9630]: [Web] Fallback log flooded with samlogon cache timeout messages
• [NUTM-9664]: [Web] Country blocking exception not working when HTTP Proxy is using SSO
• [NUTM-9720]: [Web] Can’t proceed content warning for MIME types if URL contains spaces
• [NUTM-9745]: [Web] HTTP Proxy coredumps with SIGSEGV
• [NUTM-7628]: [Wireless] Wireless clients frequently failing to connect with STA WPA failure reason code 2
• [NUTM-8946]: [Wireless] APs displayed as inactive in WebAdmin while clients can connect
• [NUTM-9591]: [Wireless] Both local WiFi using 2.4GHz band and same channel in default configuration
• [NUTM-9592]: [Wireless] Unable to broadcast same SSID on both LocalWifi0 and LocalWifi1
• [NUTM-9594]: [Wireless] Incorrect channel information showing on overview for LocalWifi
• [NUTM-9608]: [Wireless] Incorrect generic error message in WebAdmin while configuring band for wireless network
• [NUTM-9638]: [Wireless] Both local WiFi AP named ‚Local‘
• [NUTM-9731]: [Wireless] Not able to configure channel 12 and 13 on newer desktop models
• [NUTM-9735]: [Wireless] Set default channel width to 40MHz for 5GHz band
• [NUTM-9737]: [Wireless] SGw appliances missing frequency definitions for Nigeria

Leider erscheinen Updates für die UTM in immer unregelmäßigeren Abständen, wie eingangs erwähnt liegt das letzte Update schon 4 Monate zurück. Sophos schließt beispielsweise erst mit diesem Update eine Lücke in BIND (CVE-2017-3145), gemeldet wurde das Problem allerdings schon im Januar 2018:

https://kb.isc.org/article/AA-01542/0/CVE-2017-3145%3A-Improper-fetch-cleanup-sequencing-in-the-resolver-can-cause-named-to-crash.html

Ich würde mir wünschen, dass Sophos hier zügiger Updates veröffentlicht.

Wenn das Update noch nicht in WebAdmin angezeigt wird, kann es hier manuell runtergeladen werden:

http://ftp.astaro.de/UTM/v9/up2date/u2d-sys-9.509003-510004.tgz.gpg

Da Sophos in der Vergangenheit kein glückliches Händchen mit Updates hatte, sollte vor dem Update ein Backup erstellt werden.

Der Beitrag Sophos UTM: Neues Update (9.510-4) erschien zuerst auf Frankys Web.