Unser Umzug nach Azure und Office 365 – Teil 3

Wie betreibt man eigentlich Exchange Hybrid ohne lokale Infrastruktur? Warum installieren die Kollegen der ML Network denn einen Exchange in Azure, wenn Exchange Online das doch gar nicht braucht? Damit befassen wir uns heute im Detail. Die Vorgeschichte können Sie in Teil 1 und Teil 2 unserer kleinen Beitragsreihe nachlesen.

Die Ausgangslage

Um unsere Ausgangslage kurz zu beschreiben, müssen wir ein Stück in die Vergangenheit schauen. Da wir bereits seit längerer Zeit Microsoft Teams einsetzen, hatten wir bereits einen Office 365 Tenant, ADSync und SSO mit ADFS im Einsatz. Damit wir alle Funktionen, vor allem den nahtlosen Teams-Kalender, benutzen können, haben wir schon vor unserer Migration in die Cloud Exchange Hybrid konfiguriert – auch als wir noch nicht vorhatten, Mailboxen zu migrieren. Unser Ticketsystem war für den IMAPS-Abruf aus einer Mailbox konfiguriert und sendete Mails nach intern wie extern über den Exchange. Verschiedene Systeme wie unser Veeam-Backup haben interne Mails über unseren Exchange-Server gesendet. Mails kamen eingehend (gefiltert durch eine Sophos UTM) direkt an unserem Exchange-Server an und wurden auch durch diesen nach extern versendet. So weit, so simpel.

Exchange auf Azure

Die Migration der Mailboxen zu Exchange Online war ebenfalls simpel genug. Unser Ticketsystem haben wir auf lokalen SMTP-Empfang mit Postfix umgestellt und einen entsprechenden Sende-Connector am lokalen Exchange gebaut. Man hätte nun den Mailflow drehen und unseren lokalen Exchange abreißen und vollständig in Exchange Online arbeiten können. Wir haben aber aus (ursprünglich) zwei Gründen in Azure einen weiteren Exchange-Server in Betrieb genommen:

• Wir verwenden Azure AD Connect für den Verzeichnisabgleich. Das bedeutet auch, dass Benutzer lokal angelegt und nach Office 365 synchronisiert werden. Um die Exchange-Attribute der Benutzer in der AD pflegen zu können, wird Exchange Hybrid benötigt – hier ist das von Microsoft erklärt
• Da wir uns möglichst an die modernen Sicherheitsstandards für Office 365 halten wollen, andererseits aber unsere internen Systeme nicht unbedingt moderne Authentifizierung unterstützten, planten wir, von der Nutzung von IMAPS und SMTP-Authentifizierung in Exchange Online abzusehen. Daher sollte der Exchange-Server Mails aus dem Ticketsystem und von unseren anderen Systemen relayen. Soweit jedenfalls der Plan…

Die Aussage von Microsoft lautet hierzu auf den ersten Blick:

Die Bereitstellung auf virtuellen Microsoft Azure-Computern wird unterstützt, wenn alle für Exchange-Datenbanken und Datenbanktransaktionsprotokolle verwendeten Speichervolumes (einschließlich Transportdatenbanken) für Azure Premium Storage konfiguriert sind.

Mailflow

Als wir unseren lokalen DNS-Record für den SMTP-Versand, den alle internen Systeme verwenden, auf die Maschine in Azure gedreht haben, fiel uns schnell auf, dass die Mails aus dem Ticketsystem nicht nach extern versendet werden konnten und auf dem neuen Exchange in der Warteschlange blieben. Es stellte sich rasch heraus, warum:

Starting on November 15, 2017, outbound email messages that are sent directly to external domains (such as outlook.com and gmail.com) from a virtual machine (VM) are made available only to certain subscription types in Microsoft Azure. Outbound SMTP connections that use TCP port 25 were blocked. (Port 25 is primarily used for unauthenticated email delivery.)
This change in behavior applies only to new subscriptions and new deployments since November 15, 2017. (Quelle: Microsoft)

Natürlich war unser Abonnement nicht in „only certain subscription types“ inbegriffen. So blieb uns entgegen unserer Planung doch nur, Mails von den internen Systemen per SMTP-Authentication direkt über Exchange Online zu versenden. Um Mails an unser Ticketsystem zu routen, mussten wir uns der erweiterten Exchange Transportregeln in Exchange Online bedienen, damit die Mails per Sende-Connector weitergeleitet werden, statt sie in das vorhandene Postfach zuzustellen. Damit ist der Exchange in Azure aus dem Mailflow ausgeklammert.

Mails durchlaufen nun Exchange Online Protection, bevor sie in unseren Postfächern landen bzw. an den externen Empfänger gesandt werden. Hier stand noch ein wenig Grundkonfiguration in Bezug auf Anti-Spam-, Anti-Malware- und Anti-Phishing-Policies an, die standardmäßig zwar aktiviert sind, aber beispielsweise nicht über Benachrichtigungseinstellungen verfügen.

Zu Guter Letzt haben wir noch unseren lokalen Exchange-Server deinstalliert. Damit war also auch unser Exchange migriert.

MFA und Conditional Access

Natürlich haben wir für unser Azure AD Multifaktorauthentifizierung für alle Anwender konfiguriert. Damit die Kollegen bei der Arbeit mit Office im Büro der über die Remote Desktop Services nicht regelmäßig Ihr Telefon oder Smartphone bemühen müssen, haben wir – außer für die globalen Admins unseres Office 365 Tenants – Conditional Access konfiguriert, der einen Zugriff ohne zweiten Faktor von unserer öffentlichen IP-Adresse erlaubt.

Azure AD Connect und ADFS

ADFS haben wir zugunsten von Azure AD Pass-through Authentication abgelöst. Beim Umzug des AD Connect auf einen der Domain Controller in Azure war dann lediglich noch zu beachten, dass die Sync-User per Conditional Access von MFA ausgenommen wird – am besten wird hier die Rolle „Directory Synchronisation Accounts“ als Ausnahme konfiguriert.

Weg mit dem alten Zeug…

Mit jedem migrierten Dienst konnten wir einen weiteren lokalen Server abschalten – und haben uns über jeden einzelnen gefreut. Natürlich war das noch nicht alles. Wir hatten noch ein bisschen zu automatisieren und das Backup hübsch zu machen – um den Feinschliff geht es dann im nächsten Beitrag.