Nachdem Teil 1 schon das Erzeugen eines Backups mit der Windows Server-Sicherung beschrieben hat und Teil 2 die Wiederherstellung eines Postfachs aus der Sicherung, sind in Teil 3 nun die weiteren Optionen dran.

Nicht immer möchte man ein vorhandenes Postfach mit dem Postfach aus der Sicherung überschreiben, weitere Möglichkeiten zur Wiederherstellung werden im folgenden beschrieben. Grundlage ist die Wiederherstellungsdatenbank aus Teil 2. Ich liste daher nur die entsprechenden Befehle für die Wiederherstellung auf.

Wiederherstellung in einen Unterordner des Postfachs

Mit dem folgenden Befehl wird das Postfach des Benutzers “Administrator” in das Postfach “Administrator” in den Unterordner “Rücksicherung” wiederhergestellt:

New-MailboxRestoreRequest -Name "Administrator" -SourceDatabase RecoveryDB -SourceStoreMailbox "Administrator" -TargetMailbox "Administrator" -TargetRootFolder "Rücksicherung"

Der Ordner “Rücksicherung” wird automatisch angelegt.

Tipp: Bevor ein komplettes Postfach in einen Unterordner des bestehenden Postfachs wiederhergestellt wird, lohnt es sich einen Blick auf die Größe des Postfachs und der konfigurierten Limits zu werfen.

Wiederherstellung in ein Archiv Postfach

Auch die Wiederherstellung in ein Archiv Postfach ist möglich. Dazu kann der folgende Befehl verwendet werden:

New-MailboxRestoreRequest -Name "Administrator" -SourceDatabase RecoveryDB -SourceStoreMailbox "Administrator" -TargetMailbox "Administrator" -TargetIsArchive

Falls der entsprechende Benutzer kein Archiv Postfach besitzt kommt es zu einer Fehlermeldung. Das Archiv Postfach wird nicht automatisch angelegt:

Ein Archiv Postfach lässt sich mit dem folgenden Befehl anlegen, damit die Wiederherstellung funktioniert:

Enable-Mailbox administrator -Archive -ArchiveDatabase FWARCH1

Wiederherstellung in ein anderes Postfach

Auch die Wiederherstellung eines Postfachs aus der Sicherung in ein anderes Postfach ist möglich. In diesem Beispiel wird das Postfach “Info” aus der Sicherung in das Postfach “Administrator” in den Unterordner “Wiederherstellung” wiederhergestellt:

New-MailboxRestoreRequest -Name "Info" -SourceDatabase RecoveryDB -SourceStoreMailbox "Info" -TargetMailbox "Administrator" -TargetRootFolder "Wiederherstellung" -AllowLegacyDNMismatch

Tipp: Auch hier sollte auf die konfigurierten Limits geachtet werden

Wiederherstellung einzelner Ordner

Wenn bekannt ist, welcher Ordner aus der Sicherung wiederhergestellt werden soll, ist dieses ebenfalls möglich. Der folgende Befehl stellt nur den Ordner “Posteingang” ohne Unterordner wieder her:

New-MailboxRestoreRequest -Name "Administrator" -SourceDatabase RecoveryDB -SourceStoreMailbox "Administrator" -TargetMailbox "Administrator" -IncludeFolders "Posteingang" -TargetRootFolder "Wiederherstellung Posteingang"

Um einen Ordner und die Unterordner wiederherzustellen kann der folgende Befehl verwendet werden:

New-MailboxRestoreRequest -Name "Administrator" -SourceDatabase RecoveryDB -SourceStoreMailbox "Administrator" -TargetMailbox "Administrator" -IncludeFolders "Posteingang/*" -TargetRootFolder "Wiederherstellung Posteingang"

Wiederherstellung einzelner Mails?

Die Wiederstellung einzelner Mails ist nicht direkt möglich. Es gibt keinen Parameter für “New-MailboxRestoreRequest” der auf bestimmte Absender oder eine bestimmte Zeitspanne filtern kann. Die Wiederherstellung einzelner Mails für einen Benutzer kann sich aber auch zu einer langwierigen Geschichte hinziehen, gerade wenn der Benutzer nicht mehr genau weiß was er sucht…

Als Alternative würde ich vorschlagen das komplette Postfach aus der Sicherung wiederherzustellen, am besten in ein separates Postfach und dem Benutzer dann Zugriff auf das Postfach zu geben:

New-MailboxRestoreRequest -Name "Administrator" -SourceDatabase RecoveryDB -SourceStoreMailbox "Administrator" -TargetMailbox "TempRestoreMailbox" -AllowLegacyDNMismatch
Add-MailboxPermission TempRestoreMailbox -User Administrator -AccessRights FullAccess

Das Postfach aus der Sicherung wird in das Postfach “TempRestoreMailbox” wiederhergestellt und dem Benutzer zur Verfügung gestellt. Der Benutzer kann nun selbst nach der gewünschten Mail suchen und in sein Postfach kopieren. Nachdem der Benutzer die Mail gefunden hat, kann “TempRestoreMailbox” wieder gelöscht werden. So bläht sich das Postfach des Benutzers nicht unnötig auf und der Admin muss nicht stundenlang nach einer Mail suchen.

MailboxRestoreRequests anzeigen oder löschen

Vorhandene MailboxRestoreRequests lassen sich mit den folgenden Befehlen anzeigen:

Get-MailboxRestoreRequest
Get-MailboxRestoreRequest | Get-MailboxRestoreRequestStatistics

Mit dem folgenden Befehl lassen sich alle RestoreRequests löschen:

Get-MailboxRestoreRequest | Remove-MailboxRestoreRequest

MailboxRestoreRequest hängt im Status “Queued”

Für den Fall, dass MailboxRestoreRequests im Status “Queued” hängen bleiben und folgende Fehlermeldung im Eventlog protokolliert wird:

EventID 1006

Quelle: MSExchange Mailbox Replication

The Microsoft Exchange Mailbox Replication service was unable to process jobs in a mailbox database.
Database: RecoveryDB
Error: MapiExceptionRecoveryMDBMismatch: Unable to open message store. (hr=0x80004005, ec=1165)
Diagnostic context:
Lid: 55847   EMSMDBPOOL.EcPoolSessionDoRpc called [length=132]
Lid: 43559   EMSMDBPOOL.EcPoolSessionDoRpc returned [ec=0x0][length=248][latency=1]

Bei mir hat es bisher immer geholfen den Dienst “Microsoft Exchange-Postfachreplikation” neu zu starten:

Löschen der Wiederherstellungsdatenbank

Nach der Wiederherstellung der entsprechenden Daten, kann die Wiederherstellungsdatenbank wieder gelöscht werden:

Dismount-Database RecoveryDB
Remove-MailboxDatabase RecoveryDB

Danach können die Datenbankdateien gelöscht werden, diese werden nicht automatisch gelöscht und belegen nach der Wiederherstellung der Daten nur unnötig Speicherplatz:

Der Beitrag Exchange 2016: Backup und Wiederherstellung mit Windows Server Sicherung (Teil 3) erschien zuerst auf Frankys Web.

Ende letzten Jahres hatte ich bereits schon einen Artikel zu dem Thema RPCoverHTTP, besser bekannt als Outlook Anywhere geschrieben:

Exchange 2016: Wird RPCoverHTTP noch benötigt?

Ich habe daher Outlook Anywhere im Dezember 2016 in meiner Umgebung abgeschaltet. Auf Probleme bin ich bisher nicht gestoßen. Outlook 2016 funktioniert mit MAPIoverHTTP einwandfrei.

Nachdem nun also über zwei Monate ins Land gezogen sind, nehme ich dies zum Anlass meine aktuelle Konfiguration der Sophos UTM Webserver Protection in Verbindung mit Exchange 2016 zu veröffentlichen. Die Umgebung ist immer noch gleich. Es gibt einen Domain Controller und einen Exchange 2016 mit aktuellem CU 4:

Da ich das Rad nicht ständig neu erfinden möchte, baut dieser Artikel auf der ursprünglich Konfiguration auf, bzw. die UTM Konfiguration inkl. RPCoverHTTP wird angepasst, sodass für den Outlook Remote Zugriff nur noch MAPIoverHTTP unterstützt wird. ActiveSync und EWS bleiben unberührt und funktionieren weiterhin:

Sophos UTM 9.4 WAF und Exchange 2016

Die UTM Web Application Firewall ist wie folgt konfiguriert:

Echter Webserver

Zunächst einmal die Einstellungen für den “Echten Webserver” in diesem Fall also Exchange:

Hier habe ich nur das HTTP-Keep-Alive an die Standardeinstellung von Exchange 2016 angeglichen.

Autodiscover Firewall Profil

Das Autodiscover Firewall Profil habe ich unverändert gelassen:

Entry URLs:

/autodiscover
/Autodiscover

Skip Filter Rules:

• 960015
• 960911

Webservices Firewall Profil

Am Firewall Profil für die Webservices habe ich die Option “Outlook Anywhere passieren lassen” deaktiviert. die Einstieg URLs habe ich auch gleich angepasst um die zukünftige REST-Api zu unterstützen:

/ecp
/ECP
/ews
/EWS
/Microsoft-Server-ActiveSync
/oab
/OAB
owa
/OWA
/
/mapi
/MAPI
/api
/API

Auch die Filterregeln sind deutlich weniger geworden:

• 960010
  960015
  981204
  981176

Webservices Ausnahmen

An den Ausnahmen hat sich einiges verändert. Hier gibt es nur noch eine Ausnahme für die Webservices und eine Ausnahme für Autodiscover und die Webservices:

/ecp/*
/ECP/*
/ews/*
/EWS/*
/Microsoft-Server-ActiveSync*
/oab/*
/OAB/*
/owa/*
/OWA/*
/api/*
/API/*
/MAPI/*
/mapi/*
/autodiscover/*
/Autodiscover/*

Outlook Web Access Ausnahmen

Eine weitere Ausnahme ist für OWA nötig:

Die Ausnahme gilt für die folgenden URLs:

/owa/ev.owa*
/OWA/ev.owa*

Autodiscover Virtueller Webserver

Die virtuelle Webserver für Autodiscover bleibt unverändert und bekommt lediglich das neue Firewall Profil zugewiesen:

Webservices Virtueller Webserver

Auch der virtuelle Webserver für die Exchange Webservices bleibt unverändert und bekommt lediglich das neue Firewall Profil zugewiesen:

MAPIoverHTTP Authentifizierungsprobleme vermeiden

Damit es nicht zu Authentifizierungsproblemen in Verbindung mit MAPIoverhTTP kommt, sollte sichergestellt sein, dass die Anmeldeinformationen entsprechend durchgereicht werden. Die Einstellungen können in der Internetoptionen am Client vorgenommen werden. Dazu wird für die Zone “lokales Intranet” die Option “Automatisches Anmelden nur in der Intranetzone” aktiviert (wenn noch nicht geschehen):

Gegebenenfalls ist es nötig die entsprechende URL auch zur Intranet Zone hinzuzufügen:

Hier einmal die Authentifizierungsmethoden für das Mapi Verzeichnis:

Der Beitrag Sophos UTM 9.4 WAF und Exchange 2016 (ohne RPCoverHTTP) erschien zuerst auf Frankys Web.

Sophos bietet schon seit geraumer Zeit den Nachfolger der UTM, genannt Sophos XG, an. Der Werbeslogan von Sophos dazu:

The next thing in next-gen: ultimative Firewall-Performance, -Sicherheit und –Kontrolle

Bisher habe ich um die Sophos XG einen Bogen gemacht, da bei meinem letzten Test vieles noch nicht wirklich rund funktioniert hat. Mein letzter Test liegt allerdings auch schon eine ganze Weile zurück, daher habe ich mir wieder einmal die Home Edition der XG runtergeladen und einen neuen Versuch gestartet. Die Home Edition gibt es hier:

Sophos XG Firewall Home Edition

Nach der Installation und der initialen Konfiguration, möchte ich zunächst die Webserver Protection der Sophos XG testen. Daher gibt es hier ein kleines Howto in Verbindung mit Exchange 2016.

Die Umgebung sieht wie folgt aus:

Im Prinzip handelt es sich um die gleiche Umgebung in der ich auch mit der Sophos UTM teste. Daher lässt sich die Funktionsweise ganz gut vergleichen. Es gibt einen Domain Controller und einen Exchange 2016 Server, beide sind an die Sophos XG angeschlossen.

Soweit zur Umgebung, es kann losgehen.

Zertifikat auf der Sophos XG installieren

Zunächst wird ein SSL Zertifikat für Webserver Protection benötigt. Ich verwende ein vorhandenes Zertifikat. Dabei handelt es sich um ein SAN Zertifikat welches die Namen autodiscover.frankysweb.de und mail.frankysweb.de enthält. Das Zertifikat liegt im PKCS12 Format vor und kann so auf der XG importiert werden:

Bei dem Import muss nur ein Name, die PFX-Datei und das zugehörige Kennwort angegeben werden:

Nachdem das Zertifikat importiert wurde, erscheint es in der GUI:

Hinweis: Ich verwende hier der Einfachheit halber ein vorhandenes gültiges Zertifikat, kostenlose SAN-Zertifikate gibt es bei Let’s Encrypt. Diese können zum Beispiel auf einem Windows Server beantragt und dann exportiert werden. Das Let’s Encrypt Zertifikat kann dann an der XG wie oben beschrieben wieder importiert werden und lässt sich nutzen. Weitere Infos zu Lets Encrypt gibt es hier:

Exchange 2016: Kostenlose Zertifikate von Let’s Encrypt

Webserver anlegen

Nach dem Import des Zertifikat wird der Exchange Server als Webserver an der XG bekannt gemacht:

Für den Webserver muss wieder ein Name angegeben werden, als Host wird ein neues Objekt mit der IP-Adresse des Exchange Servers erstellt. Auch die Angabe des DNS-Namens ist möglich, hier muss dann sichergestellt sein, das die XG den Namen auflösen kann. Als Typ wird “verschlüsselt (HTTPS) ausgewählt. Als Standard Timeout eignet sich 1850 Sekunden.

Nachdem der Webserver angelegt wurde, erscheint der entsprechende Eintrag:

Firewall konfigurieren (Webservices)

Die XG bringt bereits ein Template für Exchange Server mit, allerdings ist dieses Template nicht mehr ganz auf dem aktuellen Stand, so wird zum Beispiel MAPIoverHTTP noch nicht berücksichtigt und auch die Umleitung von “/” nach “/owa” funktioniert nicht Out-of-the-Box. Aber das Template lässt sich gut als Basis verwenden, wenn man es etwas anpasst. Ich verwendet das Template und passe es dann meinen Bedürfnissen entsprechend an:

Im Dialog der neuen “Geschäftsanwendungsregel” kann dann die Anwendungsvorlage “Exchange General” ausgewählt und ein Name für die Regel vergeben werden. Zusätzlich wird der WAN-Port im Feld “Gehostete Adresse” ausgewählt und die beiden Checkboxen für “HTTPS” und “HTTP umleiten” aktiviert. Im Feld “HTTPS-Zertifikat” wird das zuvor importierte Zertifikat angegeben und alle Domain Namen bis auf den Namen über den sämtliche Exchange Protokolle mit Ausnahme von Autodiscover laufen sollen. In meinem Fall ist es also mail.frankysweb.de für OWA, EWS, ActiveSync etc.

Weiter unten im Dialog finden sich nun die “geschützten Server”, hier muss etwas Hand angelegt werden. Für jeden Pfad muss ein Webserver angegeben werden (roter Kasten), die Pfade “/oma” und “/OMA” sind veraltet und können gelöscht werden (oranger Kasten). Wenn für Exchange intern die Formularbasierte Authentifizierung verwendet wird, muss die Authentifizierung an der XG abgeschaltet werden (blauer Kasten):

Hier einmal exemplarisch die Einstellungen für “/owa”. Als Webserver wird der zuvor angelegte Webserver ausgewählt und die Authentifizierung abgeschaltet:

Diese Einstellungen werden nun für alle Pfade vorgenommen, sodass es in der Übersicht jetzt wie folgt aussieht:

Die restlichen Einstellungen im Dialog können erst einmal so belassen werden:

Nachdem die Regel gespeichert wurde, wird sie in der Übersicht angezeigt:

Weiter geht es mit Autodiscover.

Firewall konfigurieren (Autodiscover)

Für Autodiscover wird eine zweite Geschäftsanwendungsregel benötigt:

Als Vorlage dient diesmal “Exchange Autodiscover” mit entsprechendem Regelnamen. Es wird ebenfalls wieder der WAN Port im Feld “Gehostete Adresse” angegeben und die beiden Checkboxen für “HTTPS” und “HTTP umleiten” ausgewählt. Das bereits importierte Zertifikat wird wieder ausgewählt und alle Domains bis auf “autodiscover.frankysweb.de” gelöscht.

Im weiteren Verlauf des Dialogs müssen wieder ein paar Einstellungen geändert werden. Als Webserver wird wieder der Exchange Server angegeben und die Authentifizierung wird abgeschaltet. Das Abschalten der Authentifizierung hat zur Folge, das der Exchange Server die Authentifizierung von Benutzern durchführt und nicht die XG. Hier das Beispiel für den Pfad “/autodiscover”:

Nachdem alle Pfade angepasst wurde, sieht es wie folgt aus:

Die restlichen Einstellungen in diesem Dialog können so belassen werden:

Nachdem die Regel gespeichert wurde, sind zwei Geschäftsanwendungsregeln angelegt:

Die Grundkonfiguration der XG ist nun soweit abgeschlossen.

Die nächsten Schritte

Damit die Konfiguration funktioniert, sind noch weitere Schritte nötig. Zwar würde OWA, EWS, ActiveSync und Autodiscover bereits funktionieren, wenn die entsprechenden DNS Einträge erstellt werden. Aber für Outlook Anywhere und MAPIoverHTTP muss die Konfiguration noch angepasst werden. Auch funktioniert die Umleitung von HTTP nach HTTPS, aber noch nicht die Umleitung des Root-Folders (https://mail.frankysweb.de) nach “/owa” (https://mail.frankysweb.de/owa) um es den Benutzern möglichst einfach zu machen. Für diese Anpassungen wird es einen zweiten Teil geben, der bereits in Arbeit ist und in den nächsten Tagen veröffentlicht wird.

Der Beitrag Sophos XG: Exchange 2016 und SFOS 16.05 Webserver Protection (Teil 1) erschien zuerst auf Frankys Web.

In Teil 1 wurde bereits die Grundkonfiguration der Sophos XG in Verbidnung mit Exchange 2016 durchgeführt, es fehlt allerdings noch etwas Konfigurationsarbeit damit auch Outlook Anywhere, MAPIoverHTTP und die REST Api funktionieren. Wie bereits in Teil 1 erwähnt sind die Sophos Vorlagen für Geschäftsanwendungen etwas veraltet, daher muss hier manuell nachgebessert werden. Etwas irritierend ist, dass es drei Vorlagen für Exchange gibt. die Vorlage “Exchange General” behandelt die klassischen Webservices, wie OWA, EWS und ActiveSync, enthält aber auch noch völlig veraltete Pfade für OMA (Outlook Mobile Access), welches schon lange keine Verwendung mehr findet.

Wenn die drei Standard Vorlagen genutzt werden, ist es erforderlich die Exchange Webservices (OWA, EWS, ActiveSync, etc), Autodiscover und Outlook Anywhere (RPC, MAPI) von einander zu trennen. Dies bedeutet allerdings auch, dass ein SAN Zertifikat mit drei Namen (Subject Alternate Names) verwendet werden muss.

Es geht auch etwas schöner, zumindest für die aktuellen Protokolle.

Umleitung von “/” nach ”/owa”

Mit den Standard Regeln wird beim Aufruf von des Root-Folders nur eine 404-Fehlerseite angezeigt:

Normalerweise führt hier der Exchange Server den Redirect nach /owa durch. Um dies zu erreichen kann die Regel “Exchange 2016 Webservices” angepasst werden:

Im Abschnitt “Geschützte Server” kann jetzt ein neuer Pfad hinzugefügt werden:

Hier wird ein Schrägstrich “/” als Pfad eingetragen und der Exchange Server als Webserver ausgewählt. Authentifizierung bleibt leer:

Danach wird im Abschnitt “Exceptions” eine neue Ausnahme angelegt:

Als Pfad wird wieder ein Schrägstrich “/” eingetragen und “Statisches URL-Hardening” als Prüfung ausgeschlossen:

Die Firewall Regel kann jetzt gespeichert werden und schon funktioniert die Umleitung nach /owa wieder.

MAPIoverHTTP (/mapi)

MAPIoderHTTP kann ebenfalls recht einfach aktiviert werden. Es wird wieder die Regel “Exchange Webservices” editiert:

Diesmal werden im Bereich “Geschützter Server” zwei neue Pfade angelegt:

Hier werden jetzt die Pfade “/mapi” und “/MAPI” angelegt. Webserver ist wieder der Exchange Server, Authentifizierung bleibt leer:

Nachdem die beiden Pfade angelegt wurden, sieht es wie folgt in der Übersicht aus:

Zum Schluss muss noch die schon vorhandene Expeption editiert werden:

In die Liste der Pfade für die Ausnahme werden jetzt die beiden Pfade “/mapi/*” und “/MAPI/*” hinzugefügt:

Die Liste der Ausnahmen sieht nun wie folgt aus:

Hinweis: Als ich diesen Screenshot erstellt habe ist mir aufgefallen, dass ich vergessen habe die Ausnahmen für “/oma/*” und “/OMA/*” zu löschen (Blauer Kasten). Diese beiden Pfade können ersatzlos gelöscht werden. Outlook Mobile Access (OMA) wird schon lange nicht mehr verwendet und ist auf einem Exchange 2016 Server nicht mehr verfügbar.

Nachdem die Firewall Regel gespeichert wurde funktioniert MAPIoverHTTP (Das neue Outlook Anywhere).

REST API (/api)

Mit dem Stand CU4 für Exchange 2016 ist die REST-Api zwar noch nicht offiziell freigegeben, aber immerhin schon für Tests verfügbar. Die Standard Regeln berücksichtigen die neue API ebenfalls nicht, daher muss sie auf dem gleichen Weg wie MAPIoverHTTP freigegeben werden.

Hier wird wieder, wie schon bei MAPIoverHTTP, die Exchange Webservices Firewall Regel angepasst und zwei neue Pfade hinzugefügt. Diesmal “/api” und /”API”:

In die vorhandene Ausnahmeliste werden dann die Pfade “/api/*” und “/API/*” angegeben:

Jetzt sollte die Ausnahmeliste wie folgt aussehen:

Die Firewall Regel kann nun gespeichert werden und die REST-API funktioniert.

RPCoverHTTP (/rpc)

Bei dem klassischen Outlook Anywhere (RPCoverHTTP) wird es schon etwas trickreicher. Hier empfiehlt es sich vorher zu überlegen, ob dieses Protokoll noch benötigt wird, denn alle von Exchange 2016 unterstützen Outlook Versionen sprechen auch MAPIoverHTTP.

Ich würde an dieser Stelle auf RPCoverHTTP verzichten, zumindest wenn wie in meinem Fall nur zwei Hostnames zur Verfügung stehen. Der Hintergrund ist, dass die meisten Schutzmechanismen der Webserver Protection für Outlook Anywhere abgeschaltet werden müssen. Dieses gilt dann auch für die restlichen Webservices wie OWA und EWS. Wenn Outlook Anywhere, also das klassische RPCoverHTTP noch benötigt wird, empfehle ich einen dritten Hostnamen in das Zertifikat aufzunehmen (bsp. rpc.frankysweb.de) und die Exchange Konfiguration auf diesen Hostnamen anzupassen (wie auch von Sophos vorgesehen). So lässt sich eine neue Geschäftsanwendungsregel aus der Vorlage nutzen, um nur die notwendigen Schutzmechanismen für Outlook Anywhere (RPCoverHTTP) zu deaktivieren und nicht auch gleich für alle anderen Dienste.

Ich habe es trotzdem ausprobiert, ob es möglich ist mit zwei Hostnamen und zwei Firewallregeln auszukommen: Ja, geht, ist aber Kacke, denn meiner Ansicht nach deaktiviert es faktisch die Webserver Protection. Nahezu alle Features müssen deaktiviert werden. Da ich diese Konfiguration für derart unsauber halte möchte ich es auch nicht veröffentlichen. Wer unbedingt darauf besteht, kann mir eine Mail schreiben und bekommt dann ein kleines HowTo.

Der Beitrag Sophos XG: Exchange 2016 und SFOS 16.05 Webserver Protection (Teil 2) erschien zuerst auf Frankys Web.

Hier gibt es einen interessanten Artikel über zwei ActiveSync Bugs, die aktuell in Verbindung mit Apple iOS auftreten:

How to hunt down an EAS bug

Der Artikel ist sehr interessant, da hier tief in die Fehleranalyse eingestiegen wird. Aus meiner Sicht sehr lesenswert.

Beide Probleme kann ich nachvollziehen und warte ebenfalls auf ein Update, wobei mir egal ist, wer das Update liefert, ich will nur das es wieder funktioniert…

Konkret geht es darum, dass zum einen Termineinladungen ohne zutun eines Benutzers an Teilnehmer weitergeleitet werden. Für dieses Problem ist wohl das Feature “Mit aktueller Wegzeit” von iOS verantwortlich. Als Workaround lässt sich dieses iOS Feature abschalten:

Einstellungen –> Kalender –> Standardhinweise –> “Mit aktueller Wegzeit “ deaktivieren

Für das zweite Problem gibt es leider keinen Workaround für die iOS Mail App, Hier wird das Gelesen/Ungelesen Flag nicht in das Postfach synchronisiert wird. Auch dieses Problem tritt bei mir teilweise auf. Als alternative lässt sich noch Outlook für iOS verwenden, dort treten diese Probleme nach meiner Erfahrung nicht auf.

In der Schlussfolgerung liegt der Clueless Guy auch richtig: Es ist nicht das einzige Flag was betroffen ist, ich habe ebenfalls Probleme mit einem weiteren Flag festgestellt: Wenn von einem iOS Gerät eine Mail weitergeleitet wird, wird im Postfach nicht angezeigt, dass die Mail weitergeleitet wurde (Datum / Uhrzeit). Der Text “Sie haben diese Nachricht am XX weitergeleitet” fehlt:

Allerdings tritt es nicht immer auf, vermehrt konnte ich das Problem im französischen Mobilfunknetz (Orange Telecom) beobachten. Das nächste Exchange CU dürfte bald erscheinen, mal sehen ob es dann besser wird. Ich vermute aber eher, dass hier Apple ein entsprechendes Update liefern muss.

Der Beitrag ActiveSync und Apple iOS: 2 aktuelle Bugs mit iOS 10 erschien zuerst auf Frankys Web.

Heute wurde ein wichtiges Update für die folgenden Exchange Server Versionen veröffentlicht:

• Microsoft Exchange Server 2013 Service Pack 1
• Microsoft Exchange Server 2013 Cumulative Update 14
• Microsoft Exchange Server 2016 Cumulative Update 3

Interessant ist, dass die Exchange Versionen nicht mehr ganz aktuell sind. Es gibt bereits das CU4 für Exchange 2016, sowie CU15 für Exchange 2013.

Microsoft schreibt folgendes zur Schwachstelle und stuft das Sicherheitsupdate mit dem Schweregrad „Hoch“ ein:

https://technet.microsoft.com/library/security/MS17-015

Es besteht eine Sicherheitsanfälligkeit durch Rechteerweiterungen in Microsoft Exchange Outlook Web Access (OWA), da Webanforderungen nicht ordnungsgemäß verarbeitet werden. Ein Angreifer, der diese Sicherheitsanfälligkeit erfolgreich ausnutzt, kann Skript- oder Inhaltseinschleusungsangriffe durchführen und versuchen, den Benutzer zum Offenlegen vertraulicher Informationen zu verleiten.

Ein Angreifer kann diese Sicherheitsanfälligkeit ausnutzen, indem er eine speziell gestaltete E-Mail mit einem schädlichen Link an einen Benutzer sendet. Alternativ könnte ein Angreifer einen Chat-Client nutzen, um einen Benutzer dazu zu verleiten, auf den schädlichen Link zu klicken.

Das Sicherheitsupdate behebt die Sicherheitsanfälligkeit, indem korrigiert wird, wie Microsoft Exchange Webanforderungen überprüft.

HINWEIS: Diese Sicherheitsanfälligkeit kann ausgenutzt werden, wenn ein Benutzer auf einen schädlichen Link eines Angreifers klickt.

Hier geht es direkt zum Download der Updates:

• Security Update For Exchange Server 2013 SP1 (KB4012178)
• Security Update For Exchange Server 2013 CU14 (KB4012178)
• Security Update For Exchange Server 2016 CU3 (KB4012178)

Scheinbar ist die Lücke in der aktuellen Exchange Version (CU4 für Exchange 2016, CU15 für Exchange 2013) nicht vorhanden, zumindest passen die Versionsnummern dann nicht überein:

Exchange 2016 CU4: 15.01.0669.032

KB4012178 für Exchange 2016 CU3: 15.01.0544.030

Der Beitrag Wichtiges Update für Exchange 2013/2016 erschien zuerst auf Frankys Web.

In diesem Blogpost hat Thomas Shinder von Microsoft den neuen “Microsoft Security Guide” vorgestellt. Der Artikel ist ziemlich interessant und sehr lesenswert.

Besonders der letzte Abschnitt hat es mir angetan. Dort heißt es:

The Security Update Guide development API can be used to create a report in CVRF format. To use this API, click the DEVELOPER tab, and log into TechNet when prompted. From this tab, you can see code samples in a variety of scripting languages.

Jetzt wird es doch interessant. Microsoft veröffentlicht also Sicherheitsprobleme und Updates im Security Guide und bietet direkt auch eine API an. Das Beste daran: Es gibt sogar ein PowerShell Modul, welches einem etwas Arbeit abnimmt. Die Daten können aber auch via Webrequest direkt im XML oder JSON Format runtergeladen und weiter verarbeitet werden. Um an die Daten zu kommen wird lediglich ein kostenloser API-Key benötigt.

Als ich den Artikel gelesen hatte, habe ich direkt gedacht: Eine Mail sobald Exchange Updates oder Sicherheitslücken veröffentlicht werden, wäre schon klasse…

Ich habe daher angefangen ein kleines Script zu schreiben, welches diese Aufgabe erfüllt. So sieht es bisher aus:

Das Script, welches weiter unten runtergeladen werden kann, ist noch nicht perfekt, aber es steht ja noch am Anfang. Ich plane das Script in den Exchange Reporter, sowie in den Exchange Monitor aufzunehmen. Bis es soweit ist, warte ich aber noch ein paar CVEs ab um Erfahrungen zu sammeln.

Das PowerShell Script hat zwei Voraussetzungen. Den API Key und das PowerShell Modul “MsrcSecurityUpdates”. Der API-Key kann kostenlos auf der Website des Microsoft Security Guide beantragt werden, dazu wird lediglich ein Microsoft-Konto benötigt:

Nachdem sich mit einem Microsoft-Konto angemeldet wurde, kann der API Key direkt angezeigt werden:

Jetzt kann das Powershell Modul MsrcSecurityUpdates installiert werden. Für die Installation muss die PowerShell mit Administratorrechten gestartet werden:

Install-Module MSRCSecurityUpdates -force

Im Script selbst müssen die ersten 7 Zeilen angepasst werden, ich denke es erklärt sich von selbst:

Hier kann das Script runtergeladen werden:

ExchangeCVENotification 1.94 KB

Download

Nach den erforderlichen Anpassungen kann eine neue geplante Aufgabe angelegt werden, welche das Script täglich startet:

Derzeit erwartet das Script noch, dass es täglich gestartet wird. Das Script benachrichtigt nur wenn neue Inhalte für Exchange Server gefunden wurden. Es gibt noch einiges zu verbessern, Feedback nehme ich gerne entgegen.

Der Beitrag E-Mail bei neuen Exchange Updates erhalten (Microsoft Security Guide) erschien zuerst auf Frankys Web.

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

• Exchange Server 2016 CU5
• Exchange Server 2013 CU16
• Exchange Server 2010 SP3 UR17
• Exchange Server 2007 SP3 UR23

Hier geht es zu den Details der Änderungen:

• Exchange Server 2016 CU5
• Exchange Server 2013 CU16
• Exchange Server 2010 SP3 UR17
• Exchange Server 2007 SP3 UR23

Das UR23 für Exchange 2007 dürfte damit das letzte Update für Exchange 2007 sein, denn der Support für Exchange 2007 läuft am 11. April aus.

Exchange 2013 und Exchange 2016 erfordern nun .Net Framework 4.6.2:

Exchange Server 2013 and 2016 require .Net 4.6.2

As previously announced, Exchange Server 2013 and Exchange Server 2016 now require  .Net 4.6.2 on all supported operating systems.  Customers who are still running .Net 4.5.2 should deploy Cumulative Update 4 or Cumulative Update 15, upgrade the server to .Net 4.6.2 and then deploy either Cumulative Update 5 or Cumulative Update 16.

Quelle: Exchange Team Blog

Der Beitrag Exchange Server: Neue Updates (März 2017) erschien zuerst auf Frankys Web.

Ich bin heute über einen interessanten Workaround für die Sophos UTM und Let’s Encrypt Zertifikate gestolpert:

https://github.com/rklomp/sophos-utm-letsencrypt

René hat sich die Mühe gemacht und ein Script erstellt, welches auf der Sophos UTM Let’s Encrypt Zertifikate automatisch erneuern kann.

Die Umsetzung ist relativ einfach und hat bei mir in der Testumgebung auf Anhieb funktioniert. Da die Let’s Encrypt CA auf den Webserver zugreifen muss um die Domain Validierung durchzuführen, muss die Prüfdatei auf den hinter der WAF liegenden Webserver kopiert werden. Ich hatte es erfolgreich mittels FTP getestet.

Hinweis: Hier handelt es sich um einen Workaround, der nicht offiziell von Sophos unterstützt wird, derzeit bietet die Sophos UTM keine direkte Unterstützung für den ACME Client. Für Testumgebung ist es aber dennoch eine gute Möglichkeit um an gültige Zertifikate zu kommen.

Direkte Unterstützung für Let’s Encrypt und Sophos UTM ist nach meinen Informationen für eine der nächsten Versionen geplant. Bis dahin wird man sich wohl noch etwas gedulden müssen.

Es kann sicherlich nicht schaden, wenn noch ein paar Votes zum Feature Request hinzukommen:

http://ideas.sophos.com/forums/17359-utm-formerly-asg-feature-requests/suggestions/10409280-let-s-encrypt-integration

Der Beitrag Sophos UTM und Let’s Encrypt Zertifikate erschien zuerst auf Frankys Web.

Ich habe nun schon mehrere Mails mit Fragen zum Exchange 2016 Update Prozess bekommen. Es finden sich auch immer diverse Fragen in den Kommentaren zu Artikeln die auf Updates hinweisen. Daher gibt es hier jetzt ein kleines Howto, wie Exchange Updates installiert werden.

Was ist ein Kumulatives Update für Exchange?

Updates für Exchange werden als Kumulative Updates (CU) veröffentlicht, dass heißt konkret, alle bis zum Zeitpunkt der Veröffentlichung des CUs sind in dem Update Paket enthalten. Dabei handelt es sich immer um das komplette ISO für Exchange. Bestehende Exchange Installationen können mit dem CU aktualisiert, sowie auch Neuinstallationen durchgeführt werden. Von dieser Regelung ausgenommen sind Sicherheitsupdates die nach Bedarf veröffentlicht werden. Das nächste reguläre CU enthält dann wieder die zuvor veröffentlichen Sicherheitsupdates, wenn es welche gegeben hat.

Da ein CU immer die kompletten Installationsdateien umfasst ist es nicht notwendig CUs aufbauend zu installieren. Wenn zum Beispiel die Exchange Organisation mit CU2 läuft, muss nicht erst CU3, CU4 und danach CU5 installiert werden. CU3 kann direkt nach CU5 aktualisiert werden.

Reihenfolge

Bei einer größeren Exchange Organisation werden die Exchange 2016 Server in der folgenden Reihenfolge aktualisiert:

• Exchange Server die Dienste im Internet bereitstellen (Internet-facing), interne und externe URLs sind konfiguriert
• wenn vorhanden: Exchange Server die Dienste im lokalen Netzwerk bereitstellen (Non-Internet-facing), nur interne URLs sind konfiguriert
• wenn vorhanden: Exchange Transport Server

Update planen

Je nach Exchange Umgebung, müssen ein paar Sachen eingeplant oder beachtet werden.

• Active Directory Schema Update erforderlich?
• Wartungsfenster / Exit Strategie
• Bekannte Probleme
• Berichte anderer Benutzer

Viele der Exchange CUs erfordern eine Aktualisierung des AD Schemas. In größeren Umgebungen sollte das Schema Update des Active Directory unabhängig von der Installation des CUs durchgeführt werden. Erst wenn alle Domain Controller repliziert sind, was in Umgebungen mit mehreren Domänen und mehreren Sites dauern kann, sollte das eigentliche CU installiert werden.

In Umgebungen mit nur einem Exchange Server muss ein entsprechendes Wartungsfenster eingeplant werden. In der Zeit in der das CU installiert wird, ist keine Verbindung mit dem jeweiligen Exchange Server möglich (SMTP, sowie Outlook und ActiveSync). Auch über eine Exit Strategie sollte sich Gedanken gemacht werden, wie Lange kann im Problemfall nach einer Lösung gesucht werden und was ist zu tun wenn keine Lösung gefunden wird (Wie komme ich zum letzten funktionsfähigen Stand zurück?)

In einer hochverfügbaren Umgebung ist der unterschiedliche Versionsstand der Exchange Server supported, allerdings sollte das Ziel sein, alle Exchange Server auf dem gleichen Patchlevel zu haben.

Zu den CUs werden in der Regel auch bekannte Probleme veröffentlicht, diese Probleme im Vorfeld zu kennen, kann viel Ärger ersparen, ebenfalls sollten die Berichte anderer Benutzer geprüft werden, ob es ggf. zu Problemen gekommen ist.

• Vorbereitungen

• Bevor Updates für Exchange installiert werden, sollten die Vorbereitungen erledigt werden:
• Download des CUs
• Wenn das Schema Update vorab durchgeführt wurde: Replikation der DCs und Schema Version prüfen
• Sicherungen überprüfen (Exchange und Active Directory)
• Sicherung von speziellen Einstellungen (Änderungen in der Registry zu Exchange Diensten, Login Templates, etc)
• Überprüfung der Zertifikate

Da die CU alle Exchange Installationsdateien enthalten, sind CUs relativ groß und brauchen je nach Bandbreite Zeit für den Download. Wer nur ein begrenztes Wartungsfenster hat, muss ja nicht unnötig Zeit für den Download verschwenden.

Da Exchange CUs auch Updates für das Active Directory Schema enthalten können, aber nicht zwangsweise müssen, ist es wichtig dass Sicherungen für Exchange und auch für das Active Directory vorliegen. Wenn mal etwas schief gehen sollte, will man nicht nur eine 8 Wochen alte Sicherung zu Hand haben.

Spezielle Einstellungen für Exchange, also Änderungen in der IIS web.config, Änderungen an der OWA Login Maske oder Einstellungen in der Registry werden vom Update Prozess ggf. überschrieben. Wenn solche Änderungen vorgenommen werden, sollten sie also dokumentiert und vorher gesichert werden.

Abgelaufene Zertifikate können dazu führen, dass der Update Prozess abbricht. Die Zertifikate sollten also unbedingt vorher überprüft werden.

Vor der Installation

Wenn das CU ein Schema Update erfordert, sollte es in Umgebungen mit mehreren Domains oder Domain Controller separat vom CU eingespielt werden. Zwar aktualisiert auch das Exchange Setup das Schema während der Installation, aber hier kann es bei größeren Umgebungen zu Problemen kommen. Das Schema kann wie folgt aktualisiert werden:

setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms
setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms
setup.exe /PrepareDomain /IAcceptExchangeServerLicenseTerms

Der letzte Befehl muss nur ausgeführt werden, wenn es mehrere Active Directory Domänen gibt, gibt es nur eine Domain in dem Exchange installiert ist, reicht es den ersten und zweiten Befehl auszuführen. Wenn es mehrere AD Domänen gibt, muss der letzte Befehl in allen Domänen ausgeführt werden, die Postfächer oder Exchange Server enthalten.

Nachdem das Schema aktualisiert wurde, muss die Replikation des Active Directory abgewartet oder manuell durchgeführt werden.

Bevor die Installation gestartet wird, sollten alle Dienste von Drittanbieter Software (Backup Tools, Spamfilter die auf Exchange Servern installiert werden, VIRENSCANNER) gestoppt werden. Virenscanner sorgen in vielen Fällen während des Updates für Probleme oder verlängern den Update Prozess teilweise deutlich, daher unbedingt für die Dauer des Updates abschalten, auch den Windows Defender nicht vergessen.

Wenn noch ein Neustart des Servers aussteht, muss dieser vor dem Update durchgeführt werden, da sonst das Setup den Update Prozess nicht startet.

Da während des Updates diverse PowerShell Scripte ausgeführt werden, muss die PowerShell Execution Policy auf “Unrestricted” gestellt werden:

Get-ExecutionPolicy
Set-ExecutionPolicy Unrestricted

Der erste Befehl zeigt die aktuelle Execution Policy an, der zweite Befehl ändert die Execution Policy auf “Unrestricted”. Nach erfolger Installation kann der ursprüngliche Wert wieder gesetzt werden.

Installation

Wenn es nur einen Exchange Server gibt, dann kann meiner Meinung nach jetzt das Update einfach per Doppelklick auf setup.exe aus dem ISO gestartet werden.

In hochverfügbaren Umgebungen ist es etwas aufwändiger. Zunächst wird der Server der aktualisiert werden soll aus dem Loadbalancing Pool entfernt oder deaktiviert, sodass der Loadbalancer keine Verbindungen mehr zu dem Exchange Server schickt. Danach wird der Transport Dienst in den Wartungsmodus gesetzt und Mails aus der Warteschlange an einen verbleibenden Server umgeleitet:

Set-ServerComponentState FWEX1 –Component HubTransport –State Draining –Requester Maintenance
Redirect-Message -Server FWEX1 -Target FWEX2.frankysweb.local

Wenn der Server Mitglied einer DAG ist, kann nun auch der Wartungsmodus aktiviert werden und aktive Datenbanken auf einen anderen Server verschoben werden:

Suspend-ClusterNode –Name FWEX1
Set-MailboxServer FWEX1 –DatabaseCopyActivationDisabledAndMoveNow $true
Set-MailboxServer FWEX1 –DatabaseCopyAutoActivationPolicy Blocked

Jetzt kann kontrolliert werden ob keine Datenbanken mehr auf dem Exchange Server aktiv sind, wenn das der Fall ist, kann der Server offline geschaltet werden:

Set-ServerComponentState FWEX1 –Component ServerWideOffline –State InActive –Requester Maintenance

Da jetzt der Server im Wartungsmodus ist kann jetzt das Update entweder per Doppelklick auf setup.exe gestartet werden, oder direkt über die Shell:

setup /m:upgrade /IAcceptExchangeServerLicenseTerms

Wenn das Update erst einmal läuft, ist Zeit für Kaffee. CU5 für Exchange 2016 hat auf meinem recht schwachen Test-Exchange mit 12 GB RAM und 2 CPUs 90 Minuten benötigt. Eine halbe Stunde kann man aber eigentlich immer einplanen.

Nach der Installation

Nachdem das CU installiert wurde, können Virenscanner und sonstige Dienste wieder gestartet werden. Auch die PowerShell Execution Policy kann wieder auf den Standard Wert “Restricted” (Windows Server 2016) oder “RemoteSigned” (Windows Server 2012 R2) gestellt werden.

In hochverfügbaren Umgebungen muss jetzt natürlich auch wieder der Wartungsmodus abgeschaltet werden:

Set-ServerComponentState FWEX1 –Component ServerWideOffline –State Active –Requester Maintenance
Resume-ClusterNode –Name FWEX1
Set-MailboxServer FWEX1 –DatabaseCopyAutoActivationPolicy Unrestricted
Set-MailboxServer FWEX1 –DatabaseCopyActivationDisabledAndMoveNow $false
Set-ServerComponentState FWEX1 –Component HubTransport –State Active –Requester Maintenance

Spezielle Einstellungen wie Registry Werte, web.config oder Anpassungen am OWA Login Template müssen nach der Installation kontrolliert werden. Ebenfalls stehen jetzt die Funktionstests an, im wesentlichen handelt es sich dabei um folgende Überprüfungen / Tests:

• Ereignisanzeige auf Fehler / Probleme prüfen
• Prüfen ob alle Exchange Dienste gestartet sind
• Status der Datenbanken und des Indexes prüfen
• Verbindung Outlook / ActiveSync / OWA testen
• E-Mail Übermittlung (Senden / Empfangen)

In größeren Umgebungen:

• Status der DAG prüfen
• Mailbox Datenbanken entsprechend der Aktivierungspräferenz verteilen (geschieht bei Exchange 2016 ab CU2 automatisch)
• Server wieder zum Loadbalacing Pool hinzufügen

Tipp

Erstellt euch ein Update Cookbook. Beim nächsten CU könnt ihr dafür alle nötigen Befehle die vor und nach der Installation ausgeführt werden dokumentieren. Auch alle Dienste und Programme die gestoppt wurden, können in dem Cookbook dokumentiert werden, sowie auch Probleme die aufgetreten sind. Gibt es zum Beispiel Programme die neu gestartet werden müssen, nachdem die Exchange Dienste nicht verfügbar waren, sollten diese ebenfalls dokumentiert werden. Für zukünftige Updates, kann dann einfach die Doku zu Hand genommen werden und alle nötigen Schritte schnell und nach Standard abgearbeitet werden. So kommt es auch zu deutlich weniger Problemen.

Der Beitrag Exchange 2016: Kumulative Updates (CU) installieren erschien zuerst auf Frankys Web.

Falls jemand einen Exchange 2016 Server mit der Edge Transport Rolle auf Windows Server 2016 einsetzt, sollte dich den Post vom Exchange Team Blog durchlesen, dort heißt es:

Today we are announcing an update to our support policy for Windows Server 2016 and Exchange Server 2016. At this time we do not recommend customers install the Exchange Edge role on Windows Server 2016

Quelle: Exchange Team Blog

Falls jemand bereits die Edge Transport Rolle auf Windows Server 2016 einsetzt, dann sollte das Windows Update KB4013429 nicht installiert werden. Falls die Installation der Edge Transport Rolle geplant ist, dann sollte diese auf Windows Server 2012 R2 installiert werden.

Aber jetzt mal ehrlich, setzt jemand die Egde Transport Rolle wirklich ein? Ich muss ganz ehrlich gestehen, dass mir noch nie ein produktiver Edge Server untergekommen ist. Ich lasse mich da aber gern eines besseren belehren.

Mein persönliche Meinung dazu ist: Es gibt so viele wirklich gute AntiSPAM Filter, teilweise sogar schon in Firewalls wie die Sophos UTM integriert oder als OpenSource Lösung, wozu dann die Edge Transport Rolle mit ihrem doch recht statischem Regelwerk installieren? Selbst Microsoft bietet mit Exchange Online Protection (EOP) eine deutlich mächtigere Alternative zum Edge Transport Server, von den vielen anderen Herstellern mal ganz zu schweigen.

Ich würde mal ganz gerne eine kleine Umfrage starten, was von euch bevorzugt wird, also einfach mal abstimmen:
Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

Der Beitrag Exchange 2016 Edge Transport Server und Windows Server 2016 erschien zuerst auf Frankys Web.

Zertifikate von Let’s Encrypt werden immer beliebter, ist ja auch kaum verwunderlich, denn die Zertifikate sind kostenlos und es gibt einfache Clients um die Zertifikate zu bekommen. Let’s Encrypt Zertifikate sind zwar nur 3 Monate lang gültig, aber die verfügbaren Clients übernehmen das Erneuern der Zertifikate.

Exchange 2016 lässt sich sogar mit einem kleinen PowerShell Script völlig automatisieren. Im Prinzip ist dieses auch mit Exchange 2010 machbar, was bereits einige angefragt haben und das Script sogar selbst abgewandelt haben. Damit später aber keine Zertifikatswarnungen auftauchen ist ein wenig Vorarbeit nötig.

Ich habe daher eine kleine Demoumgebung bestehend aus einem Domain Controller und einem Exchange 2010 Server aufgebaut um eine der möglichen Konfigurationen zu veranschaulichen.

Das Active Directory hört auf den Namen frankysweb.local. Die Benutzer verwenden die E-Mail Adressen @frankysweb.org. Eine Umgebung dieser Art dürfte man noch recht häufig vorfinden, daher verwende ich diese Umgebung auch für dieses HowTo.

Der Domain Controller hört auch den Namen dc.frankysweb.local und der Exchange 2010 Server auf den Namen ex2010.frankysweb.local.

Für Exchange 2010 gilt es als Best-Practise interne und externe Zugriffspunkte von einander zu trennen. Diese kleine Umgebung wird daher die folgenden Zugriffspunkte nutzen:

• outlook.int.frankysweb.org (Interner Zugriffspunkt)
• outlook.frankysweb.org (Externer Zugriffspunkt)
• autodiscover.frankysweb.org (Autodiscover Intern sowie Extern)

Der Exchange Server ist via Router direkt mit dem Internet verbunden:

Am Router sind entsprechende Port Forward Regeln eingerichtet. Port 80,443 und 25 werden direkt auf den Exchange Server weitergeleitet. Port 25 ist für diesen Artikel nicht relevant. Port 80 und 443 sind Pflicht.

Hinweis: Das HowTo besteht aus zwei Artikeln, bitte erst beide Artikel abwarten. Siehe “Nächste Schritte” am Ende des Artikels. Wichtig ist ebenfalls der Abschnitt “Exchange CAS Array”!

DNS

Das DNS auf meinem Domain Controller kennt nach der Testinstallation nur die Zone “frankysweb.local”, in dieser Zone gibt es auch den Host-A Eintrag des Exchange Servers mit dem Namen EX2010:

In dieser Testumgebung habe ich noch keine Konfiguration vorgenommen, was zur Folge hat, das Outlook nun eine Verbindung zum Exchange Server mit dem Namen “EX2010.frankysweb.local” aufbaut. Dies ist auch in der Outlook Verbindungsübersicht zu sehen:

Solange der DNS-Name “EX2010.frankysweb.local” auf dem Zertifikat für Exchange vorhanden ist, stellt dies auch kein Problem dar. Let’s Encrypt, sowie auch alle anderen CAs stellen aber keine Zertifikate für private TLDs aus (.local, .intern, etc). Mit einer eigenen CA kann man solche Zertifikate ausstellen, mit öffentlichen CAs funktioniert dieses nicht, auch weil im Falle von Let’s Encrypt der interne Name nicht verifiziert werden kann.

Die Verbindung muss also über einen öffentlich gültigen DNS-Namen hergestellt werden. Um dies zu erreichen und gleichzeitig die Exchange 2010 Best-Practise “Trenne interne und externe Zugriffpunkte” umzusetzen, werden zunächst am internen DNS zwei neue Zonen angelegt. Hier wird also ganz klassisch DNS Split Brain genutzt.

Die Zone “int.frankysweb.org” bekommt nur einen HOST-A Eintrag mit der internen IP des Exchange Servers. Der DNS-Name outlook.int.frankysweb.org wird dann später für die internen Zugriffe verwendet:

Die Zone “frankysweb.org” bekommt zwei HOST-A Einträge mit den Namen “outlook” und “autodiscover”. Diese beiden Einträge werden später auch beim Hoster der öffentlichen DNS-Zone angelegt und werden für Outlook Anywhere und Autodiscover verwendet:

Für das Let’s Encrypt Zertifikat ergeben sich somit später 3 DNS-Namen:

• outlook.int.frankysweb.org (Interner Zugriffspunkt)
• outlook.frankysweb.org (Externer Zugriffspunkt)
• autodiscover.frankysweb.org (Autodiscover Intern sowie Extern)

Dazu später mehr.

Exchange CAS-Array

Das Exchange 2010 CAS-Array ist etwas tükisch. In der Standardkonfiguration ist kein CAS-Array konfiguriert, was zur Folge hat das alle Outlook Verbindungen zum lokalen FQDN des Exchange Servers aufgebaut werden. In Outlook Verbindungsstatus wird dies deutlich:

Mit dem CAS-Array ist es möglich, den FQDN des Exchange Servers zu ändern, dies ist Voraussetzung wenn eine hochverfügbare Exchange Umgebung konfiguriert wird, aber eben auch um den lokalen Servernamen eines einzelnen Exchange Servers loszuwerden.

Das gemeine am CAS-Array ist folgendes: Wenn es bereits Outlook Profile gibt die den lokalen FQDN verwenden und das CAS-Array nachträglich eingerichtet wird, ändert sich das Outlook Profil nicht. Das heißt konkret, bereits eingerichtete Outlooks werden nicht auf den neuen FQDN des CAS-Arrays verwiesen, sondern behalten den alten FQDN bei. Hier hilft nur nach der Einrichtung des CAS-Arrays auch das Outlook Profil neu zu erstellen, oder es mit mit dem Tool “RichProfile” nachträglich zu ändern.

Um ein das CAS-Array zu erzeugen und den FQDN für den Zugriff zu ändern wir der folgende Befehl auf der Exchange Shell ausgeführt:

New-ClientAccessArray -Name CASArray -Fqdn outlook.int.frankysweb.org -Site Default-First-Site-Name

Das CAS-Array ist nun angelegt und muss dann den Mailbox Datenbanken zugewiesen werden:

Set-MailboxDatabase MBDB1 -RpcClientAccessServer outlook.int.frankysweb.org

Nachdem das vorhandene Outlook Profil neu erstellt wurde, oder das Profil mit dem oben genannten Tool angepasst wurde, läuft nun die Verbindung gegen “outlook.int.frankysweb.org”

Die restlichen Exchange URLs können jetzt ebenfalls angepasst werden.

Exchange URLs

Damit später keine Zertifikatswarnungen auftreten und Autodiscover einwandfrei funktioniert, können nun auch die restlichen URLs für die jeweiligen Exchange Dienste angepasst werden.

Zunächst wird die Autodiscover URL auf “autodiscover.frankysweb.org” verändert:

Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://autodiscover.frankysweb.org/Autodiscover/Autodiscover.xml

Dann kann Outlook Anywhere eingeschaltet werden, oder bei bereits eingeschalteten Outlook Anywhere der Hostname auf “outlook.frankysweb.org” geändert werden. Für Outlook Anywhere muss nur der externe Hostname angegeben werden, der interne Name ist der FQDN des CAS-Arrays, welches vorher schon konfiguriert wurde:

Die virtuellen Verzeichnisse werden nun mit den entsprechenden URLs konfiguriert. interner FQDN ist outlook.int.frankysweb.org und externer FQDN ist outlook.frankysweb.org, daraus ergeben sich dann die URLs. Hier im Beispiel für OWA:

Gleiches gilt für ECP:

Und hier für ActiveSync:

Und auch für das OAB:

Es gibt noch ein weiteres Verzeichnis welches nicht direkt via Exchange Konsole konfiguriert werden kann, sondern nur mit der Exchange Shell. Um die EWS URL zu ändern, kann der folgende Befehl verwendet werden:

Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -InternalUrl https://outlook.int.frankysweb.org/EWS/Exchange.asmx -ExternalUrl https://outlook.frankysweb.org/EWS/Exchange.asmx

Nachdem alle URLs angepasst wurden, wird der IIS einmal neu gestartet:

iisreset

Der Outlook Autodiscover Test sollte jetzt nur noch die entsprechend konfigurierten URLs für interne und externe Zugriffspunkte verteilen. der interne FQDN “EX2010.frankysweb.local” darf nicht mehr auftauchen:

Nächste Schritte

Ohne ein gültiges Zertifikat kommt es jetzt zu Zertifikatswarnungen. Im zweiten Teil wird dann das externe DNS angepasst und das Let’s Encrypt Zertifikat konfiguriert.

Der Beitrag Exchange 2010: Zertifikate von Let’s Encrypt nutzen (Teil 1) erschien zuerst auf Frankys Web.

In Teil 1 wurden bereits die Vorbereitungen für Let’s Encrypt Zertifikate und Exchange 2010 durchgeführt. Dieser Artikel baut daher direkt auf Teil 1 auf.

In Teil 1 wurde die Exchange Organisation entsprechend angepasst, daher geht es in Teil 2 direkt weiter mit der Konfiguration den öffentlichen DNS.

Ich habe ich noch vergessen zu erwähnen, dass die komplette Umgebung auf Windows Server 2008 R2 installiert ist. Ich habe mich absichtlich für Server 2008 R2 entschieden, da es für Exchange 2010 eine weit verbreitete Plattform ist.

Öffentliches DNS

Damit Exchange über das Internet erreichbar ist, müssen am Öffentlichen DNS Server ebenfalls die entsprechenden DNS Einträge erstellt werden. In meinem Fall nutze ich Strato als Provider, daher werden dort auch die DNS Einträge erstellt. Damit Let’s Encrypt die DNS-Namen die später auf dem Zertifikat stehen sollen validieren kann, muss die Let’s Encrypt CA den Exchange Server mittels Port 80 (http) erreichen können. Daher werden die 3 DNS Namen auch am öffentlichen DNS Server bekannt gemacht:

• autodiscover.frankysweb.org
• outlook.frankysweb.org
• outlook.int.frankysweb.org

Die DNS Namen verweisen jeweils auf die öffentliche IP des Exchange Servers. In diesem Szenario ist es die WAN IP des Routers:

Der Router hat ein ein Portforward für Port 80 und 443 auf den Exchange Server konfiguriert:

Es muss also sichergestellt sein, dass die konfigurierten DNS Namen aus dem ersten Teil auch aus dem Internet erreichbar sind. Im Prinzip lässt sich dass ganz einfach prüfen, wenn unter jeder URL eine IIS Testseite aufgerufen werden kann, passt die Konfiguration.

An dieser Stelle dürfen die Browser übrigens noch eine Zertifikatswarnungen anzeigen, denn das gültige Zertifikat muss erst noch erstellt beantragt werden.

Let’s Encrypt

Meine Demoumgebung läuft auf Windows Server 2008 R2. Ich habe absichtlich den Exchange 2010 Server auf Server 2008 R2 installiert, denn diese Konstellation dürfte noch recht weit verbreitet sein.

Server 2008 R2 wird mit der PowerShell 2.0 ausgeliefert, diese ist nicht mehr zeitgemäß und muss daher aktualisiert werden, damit die nachfolgende Script funktioniert.

Für Server 2008 R2 und Exchange 2010 wird die PowerShell 4 unterstützt, daher kann das Windows Management Framework 4.0 installiert werden:

Windows Management Framework 4.0

das Windows Management Framework enthält unter anderem die PowerShell in der Version 4. Nach der Installation sollte der Befehl “get-host” die Version 4 der PowerShell anzeigen:

Hinweis: Die Exchange Management Shell wird weiterhin mit der PowerShell 2 gestartet, dies ist normal und verursacht keine Probleme für den weiteren Verlauf:

Nachdem die PowerShell Version aktualisiert wurde, muss PowerShellGet installiert werden, erst dann sind die nötigen CMDLets verfügbar um den LetsEncrypt Client zu installieren. Der entsprechende Download findet sich hier:

PowerShell Gallery

Nachdem PowerShellGet installiert wurde, stehen die CMDLets für die Installation bereit, jetzt kann der Let’s Encrypt Client “ACMESharp” installiert werden:

install-module -name ACMESharp

Jetzt ist es fast geschafft, denn die aktuelle Version des “Certtificate Assistant” unterstützt nun auch Exchange 2010.

Hinweis: Björn hat den ursprünglichen “Certificate Assistant” angepasst, damit er auch mit Exchange 2010 funktioniert. Seine Anpassungen haben in meiner Umgebung einwandfrei funktioniert. Ich habe dann noch einen Fehler beseitigt der auf meinem Mist gewachsen ist. Der Dank an dieser Stelle gehört also Björn!

Die aktuelle Version des “Certificate Assistant” gibt es hier:

Let's Encrypt Exchange Zertifikatsassistent 4.39 KB

Download

Nach dem Download muss das Script nur noch mit der PowerShell 4 ausgeführt werden. Bitte nicht die Exchange Management Shell verwenden, sondern die zuvor aktualisierte Version der “normalen” Windows PwoerShell.

Ein Task zur Automatischen Erneuerung des Zertifikats kann ebenfalls direkt im Script angelegt werden:

Falls es bisher noch keine Registrierung bei Let’s Encrypt gegeben hat, wird der folgende Fehler angezeigt:

Das Script führt dann die Registrierung durch, beantragt das Zertifikat und weißt es dem Exchange Server zu:

Der Beitrag Exchange 2010: Zertifikate von Let’s Encrypt nutzen (Teil 2) erschien zuerst auf Frankys Web.

Der Browser Chrome meldet bei Webseiten die auf einem IIS Server der auf Windows Server 2016 läuft den folgenden Fehler:

ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY

Chrome lässt in diesem Fall nicht zu den Fehler zu ignorieren. Das Problem tritt auch bei Exchange 2016 Servern auf, die auf Windows Server 2016 installiert wurden.

Das Problem liegt in alten Ciphersuiten und Protokollen die selbst bei Windows Server 2016 immer noch aktiv sind. Teilweise handelt es sich dabei wirklich um uralten Kram.

Es gibt mehrere Wege das Problem aus der Welt zu schaffen, es läuft aber immer darauf hinaus die alten Cipher und Protokolle in der Windows Registry zu deaktivieren.

Um das Problem zu beheben kann die folgende REG Datei genutzt werden. Somit werden die alten Cipher deaktiviert und nach einem Neustart des Servers treten keine Probleme mehr mit Chrome auf.

Server2016SChannelSettings 0.75 KB

Download

Alternativ kann auch das Tool IIS Crypto eingesetzt werden, IIS Crypto nimmt die gleichen Einstellungen in der Registry vor, wie die REG Datei oben.

Das Tool IIS Crypto kann hier runtergeladen werden:

IIS Crypto

Nach dem Start, kann auch “Best Practise” geklickt werden, welches ebenfalls die alten Cipher und Protokolle deaktiviert:

Nachdem die alten Cipher deaktiviert wurden, öffnet auch Chrome die Seite problemlos:

Wer den alten Kram lieber per GPO abschalten möchte, wird hier fündig:

Gruppenrichtlinie zum Deaktivieren von SSL 3.0 und TLS 1.0 (ADM und ADMX)

Per Gruppenrichtlinie können die folgenden Protokolle abgeschaltet werden:

• MultiProtocol Unified Hello
• PCT 1.0
• SSL 2.0
• SSL 3.0

Zusätzlich können die folgenden Cipher Deaktiviert werden:

• NULL Cipher
• DES 56/56
• RC2 (alle)
• RC4 (alle)

Wichtig ist das auch hier ein Neustart des Servers durchgeführt wird.

Der Beitrag Chrome und Windows Server 2016: ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY erschien zuerst auf Frankys Web.

Mit Windows Server 2016 wurde ein neues Privileged Access Management Feature eingeführt, welches es ermöglicht Benutzer nur für einen gewissen Zeitraum einer Gruppe hinzuzufügen und nach Ablauf der Zeit automatisch wieder zu entfernen.

Nützlich ist dieses Feature, wenn einem Benutzer nur für einem gewissen Zeitraum administrative Rechte (Zum Beispiel Domain Admin) gegeben werden sollen. Ein anderer Anwendungsfall wäre die zeitbegrenzte Aufnahme in Exchange Verteilergruppen.

Das Feature ist allerdings nur verfügbar wenn das Gesamtstrukturfunktionslevel bereits auf “Windows Server 2016” angehoben wurde. Dies bedeutet konkret: Es dürfen und können keine Windows Server 2012 R2 Domain Controller mehr in Betrieb sein.

In diesem kleinen Beispiel ist das Gesamtstrukturfunktionslevel bereits auf Windows Server 2016 angehoben worden:

Das Feature welches die zeitbegrenzte Aufnahme in Gruppen ermöglicht, nennt sich “Privileged Access Management Feature”. Das Feature ist optional und muss zunächst aktiviert werden. Nachdem das Privileged Access Management Feature aktiviert wurde, kann es nicht wieder deaktiviert werden. Die Aktvierung erfolgt über folgenden Befehl:

Enable-ADOptionalFeature "Privileged Access Management Feature" -Scope ForestOrConfigurationSet -Target frankysweb.de

Nach der Aktivierung lassen sich Mitglieder zeitbegrenzt zu Gruppen hinzufügen. Der Typ der Gruppe ist nicht relevant, es kann sich hier um Sicherheit- sowie um Verteilergruppen handeln.

Im folgenden Beispiel wird der Benutzer “Frank” für die Zeitspanne von 5 Tagen zur Gruppe “Info” hinzugefügt:

$timespan = New-TimeSpan -Days 5
Get-ADGroup info | Add-ADGroupMember -Members frank -MemberTimeToLive $timespan

“New-TimeSpan” gibt dabei die Zeitspanne an, hier lassen sich auch Stunden (-Hours) oder ein Enddatum (-End) angeben:

Auf diese Weise ist es allerdings nicht möglich Start- und Enddatum anzugeben. Die Zeitspanne kann also nicht in der Zukunft liegen:

Die oben gezeigte Zeitspanne würde also beim Zuweisen eines Benutzers 24 Stunden gelten und nicht erst am 07.04.2017 starten, sondern sofort.

In der Konsole “Active Directory Benutzer und Computer” ist nicht erkenntlich, ob die Mitgliedschaft zeitlich begrenzt ist:

Mittels PowerShell lässt sich die verbleibende TTL allerdings anzeigen. Die Mitglieder und ggf. deren TTL wird hierbei in Sekunden angegeben:

Get-ADGroup info -Property member -ShowMemberTimeToLive

Der Benutzer “Frank” ist dieser Gruppe also noch 431974 Sekunden zugeordnet. Mit dem folgenden Script lässt sich die Ausgabe auch etwas übersichtlicher gestalten:

$GroupName = "info"
$GroupMembers = (Get-ADGroup $GroupName -Property member -ShowMemberTimeToLive).Member
$MemberList=@()
foreach ($GroupMember in $GroupMembers)
 {
  if ($GroupMember -match "TTL=")
   {
	$TTL = $GroupMember.split(",")[0].split("=")[1].replace(">","")
	$TTLDate = (Get-Date).AddSeconds($TTL)
	$MemberDN = $GroupMember.Split(">")[1].Replace(",CN","CN")
	$MemberList += new-object PSObject -property @{DN=$MemberDN;TTLDate="$TTLDate";TTL="$TTL"}
   }
   else
   {
    $TTL = "Unlimited"
	$TTLDate = "Unlimited"
	$MemberDN = $GroupMember
	$MemberList += new-object PSObject -property @{DN=$MemberDN;TTLDate="$TTLDate";TTL="$TTL"}
   }
 }
$MemberList

TTLDate ist Zeitpunkt an dem der Benutzer automatisch wieder entfernt wird. Die Zuordnung zur Gruppe wird dann entfernt und der Benutzer taucht dann auch nicht mehr als Mitglied der Gruppe auf:

Jetzt müssen nur noch alle Domain Controller aktualisiert werden…

Der Beitrag Privileged Access Management Feature: Zeitbegrenzte Gruppenzugehörigkeit erschien zuerst auf Frankys Web.

Vorwort

Dieser Artikel ist nicht ganz ernst gemeint. Jedoch gibt es aus meiner Sicht ein paar Ungereimtheiten mit dem Windows Update.

Creators Update für Windows Server 2016?

Nils hat es schon am 15. März auf Twitter veröffentlicht, Windows Update bietet das Creators Update auch auf einem Windows 2016 Server an:

Ich fand das witzig und habe daher mal ausprobiert, was passiert, wenn ich das Update durchführen möchte. Mir wurde das Update heute auch als “Gute Neuigkeit” präsentiert:

Ich habe daher mal auf den “Ja, was muss ich tun?” Link geklickt:

Ich muss also erst JavaScript aktivieren. Gesagt, getan, ich WILL das Update, SOFORT! Nach dem Aktivieren von JavaScript sehe ich nur den Hinweis das die Windows Enterprise Editionen nicht unterstützt werden. Macht ja auch nichts, ich setze ja Windows Server 2016 Datacenter Edition ein:

Natürlich möchte ich nicht warten, ich will Creators Update auf meinem Server, also geht es weiter zur “Softwaredownloadseite”. Nachdem ich den Windows 10 Software Update-Assistent runterladen und starten konnte, habe ich kurz inne gehalten:

Nur für den Fall der Fälle habe ich einen Snapshot meines Servers erstellt und dann auf “Jetzt aktualisieren” geklickt.

Schade, der Systemadmin ist gerade nicht greifbar (er kauft neue PCs online), also wird es heute nichts mehr mit dem Update.

Um wieder etwas ernster zu werden

Es gibt noch weitere Ungereimtheiten mit Windows Update auf Windows Server 2016, es lässt sich zum Beispiel die Nutzungszeit einstellen:

Die Nutzungszeit finde ich ja für Clients eine gute Idee, aber für Server?

Ich darf Server also nur 12 Stunden pro Tag nutzen?

Ich muss ehrlich gestehen, dass ich es bisher nicht ausprobiert habe, was passiert, wenn auch automatische Update aktiviert werden. Ich lasse die Updates nur runterladen und führe dann die Installation manuell durch:

Das hat aber auch zur Folge, dass Signaturupdates für den Windows Defender manuell installiert werden müssen. Der Server meldet sich also jeden Tag mit ausstehenden Updates für die Signaturen von Windows Defender. Ich muss also jeden Tag manuell Signaturupdates installieren…

Das Fazit

Ja, dieser Artikel ist nicht ganz ernst gemeint. Trotzdem sollte hier meiner Meinung nach besser zwischen Client und Server unterschieden werden.

Was hat denn zum Beispiel dieser Dienst auf einem Windows 2016 Server verloren?

Warum wird das Creators Update auf einem Server angeboten? Bin ich in meiner Sichtweise einfach zu altmodisch oder habe ich das Prinzip nicht verstanden?

Der Beitrag Windows 10 Creators Update für Windows Server 2016? erschien zuerst auf Frankys Web.

OPNSense ist ein Fork der bekannten OpenSource Firewall PFSense, mir persönlich gefällt OPNSense besser, die GUI ist aufgeräumter, es gibt eine REST-Api und die wichtigsten PlugIns sind ebenfalls verfügbar.

Da für OPNSense ein Plugin für HAProxy und auch für Let’s Encrypt existiert, habe ich angefangen diese Kombination in Verbindung mit Exchange 2016 zu testen. OPNSense kann also direkt ein kostenloses Zertifikat von Let’s Encrypt anfordern und kümmert sich dann auch selbstständig um die Erneuerung.

Kostenlose Firewall und kostenlose Zertifikate, hört sich doch gut an. Hier ein erster Test.

Umgebung

Meine Testumgebung ist wie folgt aufgebaut:

Der Internetzugang wird über eine Fritzbox hergestellt. OPNsense stellt die Internetverbindung über die Fritzbox her. Der Exchange Server befindet sich “hinter” der OPNsense VM, hier findet also ein doppeltes NAT statt. Hier die Auflistung der IP-Adressen:

Vorbereitung

Nach der Installation und der Einbindung in mein Netzwerk habe ich zuerst einmal den Port für den Verwaltungswebsite geändert. Die Verwaltungsoberfläche hört in der Standardkonfiguration auf Port 443 (https). Port 443 möchte ich aber für Exchange nutzen. Ich habe mich hier für Port 4444 entschieden.

Danach werden die erforderlichen Plugins nachinstalliert. Das Plugin “os-acme-client” ist das Plugin für Let’s Encrypt, “os-haproxy” übernimmt die Veröffentlichung von Exchange. Da es sich in meiner Umgebung um eine VM auf ESXI handelt, habe ich auch die VMware Tools installiert:

Neben der entsprechenden Netzwerkkonfiguration waren das schon alle Vorbereitungen.

Firewall

Nachdem OPNsense in mein Netzwerk integriert wurde, habe ich zunächst zwei Firewall Regeln erstellt, die http und https Verkehr auf dem WAN Port zulassen:

Für die beiden Regeln wird als Schnittstelle jeweils “WAN” und als Protokoll “TCP” ausgewählt. Als Zielportbereich wird für eine Regel “HTTP” und für die zweite Regel “HTTPS” ausgewählt.

Nach dem Anlegen der beiden Regeln sieht es dann so aus:

Eine Regel für HTTP und eine Regel für HTTPS. Somit wird schon einmal Traffic von extern erlaubt. Weiter geht es mit HAProxy.

HAProxy

Weiter geht es mit der grundlegenden Konfiguration von HAProxy für Exchange 2016. In den HAProxy Einstellungen wird zunächst der Exchange Server als Real Server angelegt:

Ich habe des Exchange Server wie folgt angelegt, die Option “Überprüfen Sie das SSL-Zertifikat” habe ich abgeschaltet, da Exchange ein selbst signiertes Zertifikat verwendet:

Sobald der Server angelegt wurde, kann ein BackEnd erstellt werden:

Für das Backend werden die folgenden Einstellungen getätigt:

Jetzt wird eine ACL angelegt, für diesen Test mache ich es mit einfach und erstelle nur eine ACL:

Die folgenden Einstellungen gelten für die ACL:

Nachdem die ACL angelegt wurde, wird eine “Aktion” erstellt:

Für die Aktion wird folgendes konfiguriert:

Zum Schluss wird das Frontend angelegt:

Für das FrontEnd werden die folgenden Einstellungen verwendet. Die IP-Adresse 192.168.10.107 ist dabei die WAN IP Adresse der OPNsense Firewall (NAT hinter Fritzbox) plus den HTTPS-Port (443). In diesem Fall also 192.168.10.107:443

Dan noch ein Zertifikat von Let’s Encrypt existiert, verwende ich zunächst das Standard Zertifikat für die Web GUI. So lässt sich die Konfiguration schon einmal testen. Des weiteren wird auch die “X-Forwarded-For-Kopfzeile” aktiviert:

In den erweiterten Einstellungen des Frontend sind diese Einstellungen definiert;

Danach kann HAProxy aktiviert werden:

Falls HAProxy schon aktiviert war, dann am besten einmal neu starten.

Jetzt funktioniert schon einmal OWA, aber da noch kein gültiges Zertifikat vorliegt kommt es natürlich zu Zertifikatswarnungen:

Jetzt kann das Let’s Encrypt Plugin konfiguriert werden.

Let’s Encrypt

Let’s Encrypt bietet die Möglichkeit die Integration über das “Staging Enviroment” zu testen. Für offiziell gültige Zertifikate hat Let’s Encrypt Limitierungen eingebaut, so können zum Beispiel nicht beliebig viele Zertifikate ausgestellt werden. Für Tests bietet es sich also an mit dem Staging Enviroment zu starten und erst auf das “Production Enviroment” umzustellen wenn alles funktioniert.

In diesem Fall wird auch zunächst das Staging Enviroment genutzt:

Sobald das PlugIn aktiviert wurde, kann der Account angelegt werden:

Für den Account wird nur eine E-Mail Adresse benötigt:

Jetzt kann die Überprüfungsmethode konfiguriert werden:

Als Überprüfungsmethode habe ich HTTP-01 belassen, außerdem musste ich in meiner Umgebung die WAN IP explizit angegeben, da sonst keine Verbindung aufgebaut werden konnte. Als FrontEnd wird das zuvor erstellte “Exchange_2016_Frontend” ausgewählt:

Hinweis: Das Exchange 2016 Frontend wurde nur auf Port 443 (HTTPS) konfiguriert, Let’s Encrypt prüft die Domain mit der Validierungsmethode HTTP-01 allerdings auf Port 80 (HTTP), daher habe ich einen zusätzliches FrontEnd auf Port 80 (HTTP) für Let’s Encrypt erstellt:

Für das Let’s Encrypt Frontend wird ebenfalls die IP des WAN Interfaces angegeben, dies mal allerdings mit Port 80. Als Standard Backend wird “acme_challende_backend” ausgewählt, welches durch das Plugin erstellt wurde. Gleiches gilt auch für die Aktion “redirect_acme_challanges”:

Zurück zum Let’s Encrypt Plugin, hier kann jetzt das Zertifikat konfiguriert werden:

Mein Exchange Server ist hört auf die Namen mail.frankysweb.de für alle Webservices (ActiveSync, Outlook Anywhere, EWS, etc) und autodiscover.frankysweb.de für Autodiscover. Daher gebe ich die folgenden Werte für das Zertifikat an:

Nachdem das Zertifikat konfiguriert wurde, steht es im Status “Pending”, daher kann jetzt das Zertifikat ausgewählt und der Button “Zertifikate jetzt ausstellen oder erneuern” geklickt werden:

Nach kurzer Zeit ist dann unter “Last Acme Status” der Wer “OK” zu sehen:

Jetzt ist das Test-Zertifikat, welches vom Let’s Encrypt Staging Environment ausgestellt wurde, in der Zertifikatsübersicht zu sehen. Ausgestellt wurde es von der da “Fake LE Intermediate X1”:

Um nun an ein gültiges Zertifikat zu kommen, kann nun die Let’s Encrypt Umgebung auf “Production Environment” umgestellt werden:

Nachdem das “Production Environment” ausgewählt wurde, muss noch das Zertifikat erneut ausgestellt werden:

In der Übersicht der Zertifikate ist nun das gültige Zertifikat zu sehen, welches von der CA “Let’s Encrypt Authority X3” ausgestellt wurde:

Zum Schluss muss das Zertifikat nur noch dem Exchange Frontend zugewiesen werden:

In den Einstellungen zum Frontend kann jetzt das gültige Zertifikat ausgewählt werden:

Nun erscheinen auch keine Zertifikatswarnungen mehr:

Fazit

Die Konfiguration ist etwas aufwändiger als zunächst gedacht. Während ich diesen Artikel erstellt habe, wurde zwischenzeitlich ein Update für die Plugins HAProxy und Let’s Encrypt veröffentlicht, daher habe ich zwischenzeitlich wieder von vorne angefangen, um es mit der aktuellen Version zu testen.

Diese Konfiguration funktioniert zwar, ist aber alles andere als perfekt. Ich muss mich noch einmal eingehenden mit den ACLs und Aktionen vertraut machen um eine vernünftige Konfiguration zu erstellen. Für einen ersten Test, ist es aber ganz vielversprechend.

Der Beitrag Exchange 2016: OPNsense, HAProxy und Let’s Encrypt erschien zuerst auf Frankys Web.

Im Januar habe ich die erste öffentliche Version des Exchange Autodiscover Whitepaper veröffentlicht. Bisher verzeichnet das PDF mehr als 5000 Downloads, jetzt gibt es eine aktualisierte Version.

Das PDF umfasst nun 64 Seiten zu Exchange Autodiscover, inklusive Beispielkonfigurationen (6 Seiten mehr). Eine Überarbeitung war nötig, da ich bisher nur auf das Thema Split-DNS in Verbindung mit Autodiscover eingegangen war. Aufgrund zahlreicher Mails, habe ich nun die Abschnitte zur DNS Konfiguration überarbeitet. Im aktuellen Whitepaper werden nun zwei Optionen für die DNS-Einträge behandelt. Ebenfalls sind Informationen zu Lets’ Encrypt und MAPIoverHTTP aktualisiert worden.

An dieser Stelle möchte ich mich für die zahlreichen Mails mit Verbesserungsvorschlägen bedanken. Leider konnte ich noch nicht alle Vorschläge umsetzen, ich versuche aber zeitnah neue Versionen zu veröffentlichen.

Den entsprechenden Download Link, habe ich gerade aktualisiert:

Exchange Autodiscover Whitepaper 3.01 MB

Download

Vorschläge und Korrekturen nehme ich gerne entgegen, am liebsten einfach per Mail oder Kontaktformular schicken.

Aufgrund der positiven Resonanz habe ich mir vorgenommen, bestimmte Themengebiete zu Exchange Server in weiteren Whitepapern zu behandeln. An dieser Stelle kann nun darüber abgestimmt werden, welches Gebiet das nächste Whitepaper abdecken soll:

Der Beitrag Neue Version des Autodiscover Whitepaper erschien zuerst auf Frankys Web.

In Artikel 2 hatte ich bereits meine Meinung zu RPCoverHTTP (Outlook Anywhere) in Verbindung mit der Sophos XG und zwei öffentlichen DNS-Namen geschrieben. Hier noch einmal kurz zur Wiederholung:

Der Hintergrund ist, dass die meisten Schutzmechanismen der Webserver Protection für Outlook Anywhere abgeschaltet werden müssen. Dieses gilt dann auch für die restlichen Webservices wie OWA und EWS. Wenn Outlook Anywhere, also das klassische RPCoverHTTP noch benötigt wird, empfehle ich einen dritten Hostnamen in das Zertifikat aufzunehmen (bsp. rpc.frankysweb.de) und die Exchange Konfiguration auf diesen Hostnamen anzupassen (wie auch von Sophos vorgesehen).

Mich haben allerdings doch einige Mails erreicht, in der genau diese Konfiguration benötigt wird. Der Hintergrund der meisten Mails ist relativ einfach: Es wird noch Exchange 2010 eingesetzt und dieser spricht eben noch kein MAPIoverHTTP. In einigen Fällen wurde auch gerade erst das Zertifikat verlängert, sodass hier auch der Austausch des Zertifikats gegen eines mit drei DNS Namen nicht ohne zusätzliche Kosten möglich ist.

Ich habe mich also doch dazu verleiten lassen, die entsprechende Konfiguration mit zwei DNS Namen und Exchange 2016 zu veröffentlichen. Ob diese Konfiguration auch mit Exchange 2010 funktioniert, habe ich bisher nicht getestet.

Diese Konfiguration baut direkt auf der beschrieben Konfiguration aus Teil 1 und Teil 2 auf.

Anpassung für RPCoverHTTP (Outlook Anywhere)

Die bereits vorhandene Firewall Regel “Exchange 2016 Webservices” muss editiert werden, um auch Outlook Anywhere zu unterstützen:

Im Abschnitt “Path-specific routing” werden dazu zwei weitere Pfade hinzugefügt:

Die folgenden Pfade müssen der Regel hinzugefügt werden:

• /RPC
• /rpc

Als Webserver dient schon wie zuvor der Exchange 2016 Host:

Nachdem die Regel editiert wurde, sieht der Abschnitt “Path-specific routing” nun wie folgt aus:

Des weiteren müssen die beiden Pfade auch im Abschnitt “Exceptions” hinzugefügt werden:

Die folgenden Ausnahmen müssen vom “Static URL Hardening” ausgenommen werden:

• /rpc/*
• /RPC/*

Bis hierhin ist es halb so wild, aber damit Outlook Anywhere funktioniert, muss zusätzlich noch die “Protection Policy” angepasst werden:

Um nicht zwingend die Policy “Exchange 2016 General” zu verändern, kann auch eine neue Policy erzeugt werden, diese muss zunächst die gleichen Einstellungen haben wie “Exchange 2016 General” und wird dann wie folgt angepasst:

“Pass Outlook Anywhere” wird aktiviert und die Entry URLs /rpc und /RPC werden hinzugefügt, AntiVirus wird abgeschaltet:

Im weiteren Verlauf muss dann noch “Ridgid Filtering” deaktiviert werden und die folgenden Regeln ausgenommen werden:

• 960010
• 960015
• 960018
• 981203
• 981204

Alle Prüfungen bis aus “Protocol Violations” müssen abgeschaltet werden, welches die WAF nahezu deaktiviert:

Outlook Anywhere funktioniert nun zwar, aber die WAF ist durch diese Art der Konfiguration meiner Ansicht nahezu wirkungslos.

Ich würde also lieber ein Zertifikat mit drei DNS Namen kaufen, die entsprechende Konfiguration der Sophos XG liefere ich dann noch nach.

Der Beitrag Sophos XG: Exchange 2016 und SFOS 16.05 Webserver Protection (Teil 3 Optional) erschien zuerst auf Frankys Web.

Das offizielle Update auf die Version 9.5 ist zwar noch nicht verfügbar, dennoch hat Sophos heute ein Mini Update freigegeben. Das Update hebt die Version der UTM 9 auf 9.412-2 an:

Das Update enthält die folgenden Bugfixes:

• Fix [NUTM-7483]: [Basesystem] Optimize LPC usage
• Fix [NUTM-7564]: [SUM] RED Link state is shown wrong in Gateway Manager

Falls das Update noch nicht via Up2date angeboten wird, lässt es sich über folgenden Link runterladen und manuell installieren:

• http://ftp.astaro.de/UTM/v9/up2date/

Ich habe es bereits installiert und aufgrund diverser Probleme in der Vergangenheit mit virtualisierten UTMs, habe ich vorher einen Snaphot erzeugt. In diesem Fall konnte ich allerdings keine Probleme feststellen und bisher läuft alles wie gewohnt. Es wurden auch lediglich 4 Pakete aktualisiert:

• cm-nextgen-agent-9.40-16.gd2afd53.rb3.i686.rpm
• tools-9.40-2.g78bd00c.rb3.i686.rpm
• ep-init-9.40-16.ga469d4d.noarch.rpm
• ep-release-9.412-2.noarch.rpm

Etwas interessanter dürfte das Update auf die Version 9.5 ausfallen, welches allerdings aktuell nur als Beta verfügbar ist:

https://community.sophos.com/products/unified-threat-management/unified-threat-management-beta/sophos-utm-9-5-beta/f/sophos-utm-9-5-public-beta/90621/welcome-to-the-utm-9-5-beta

Mit der Version 9.5 kommt zwar noch keine Unterstützung für Let’s Encrypt, aber die WAF wird etwas erweitert, was wahrscheinlich schon das Handling mit den Let’s Encrypt Zertifikaten erleichtern dürfte:

• WAF URL Redirection gives you the ability to redirect traffic for a WAF protected URL to a different backend system or URL.

Mit der Version 9.5 wird es auch Exchange Templates für die WAF geben, allerdings sind diese bisher nicht ganz aktuell:

https://community.sophos.com/products/unified-threat-management/unified-threat-management-beta/sophos-utm-9-5-beta/f/sophos-utm-9-5-public-beta/90662/waf-protection-templates-for-common-microsoft-services

Aber im oben verlinkten Artikel wird ja auf eine Lösung verwiesen Thanks Attila!

Der Beitrag Sophos UTM: Update verfügbar (9.412-2) erschien zuerst auf Frankys Web.