Howto: Exchange Online Protection (EOP) mit Exchange 2013 On-Premise

In diesem Artikel wird die Basiskonfiguration von Exchange Online Protection mit Exchange Server 2013 beschrieben.

https://products.office.com/de-de/exchange/microsoft-exchange-online-protection-email-filter-and-anti-spam-protection-email-security-email-spam

Diese Anleitung ist ebenfalls für Exchange 2016 gültig.

Nachdem man einen Account hat, landet man im Office 365 Dashboard. Unter dem Punkt „Setup“ kann die Grundkonfiguration erfolgen:

Schritt 1: Domain hinzufügen.

Ich verwende „frankysweb.com“ zum Testen:

Meine Domain hostet Strato, da Strato in der Liste für die Schrittanweisungen nicht aufgeführt ist, wähle ich „Allgemeine Anweisungen“ aus. Die Domain muss validiert werden, daher wird ein TXT Eintrag und alternativ ein MX Eintrag angezeigt um die Domain zu validieren. Ich verwende den TXT Eintrag:

Um die Domain zu bestätigen wird also jetzt nur der TXT Record angelegt. Bei Strato funktioniert das ganz einfach:

Einstellungen speichern und fertig

Die Domain wird anhand des TXT Records erfolgreich validiert:

Die gerade hinzugefügt Domain wird jetzt unter dem Punkt „Domänen“ angezeigt:

Als nächstes wird der Nachrichtenfluss zwischen dem lokalen Exchange Server und Exchange Online Protection (EOP) konfiguriert. Dazu wird im Office 365 Dashboard auf „Online Protection for Exchange“ geklickt

Es öffnet sich ein neues Fenster mit dem Exchange Admin Center, auch hier sollte bereits die eben hinzugefügt Domain angezeigt werden, die Domain kann doppelt angeklickt werden um die Einstellungen zu öffnen:

Da die E-Mails von EOP zu Exchange weitergeleitet werden sollen, wird der Typ der Domain auf „Internes Relay“ umgestellt:

Jetzt werden 2 Connectoren benötigt, die unter dem Punkt Connectors hinzugefügt werden.

Der erste Connector ist für den Empfang der Nachrichten vom lokalen Exchange Server zuständig. Also wird bei „Von“ die Einstellung „E-Mail Server ihrer Organisation“ und bei „An“ die Einstellung „Office 365“ vorgenommen:

Der Connector benötigt einen sprechenden Namen, wie beispielsweise Exchange-to-EOP

Im nächsten Schritt wird die externe IP-Adresse des Exchange Servers angegeben. In kleinen Umgebungen dürfte es sich dabei wahrscheinlich um die WAN IP handeln. In meiner Testumgebung ist es meine öffentliche WAN IP:

Zum Schluss wird noch eine Zusammenfassung angezeigt und der erste Connector ist angelegt

Der zweite Connector ist für das Weiterleiten der Nachrichten an den lokalen Exchange Server. Also wird bei „Von“ die Einstellung „Office 365“ und bei „An“ die Einstellung „E-Mail Server ihrer Organisation“ vorgenommen:

Auch hier wieder einen sprechenden Namen eingeben, beispielsweise „EOP-to-Exchange“

Im nächsten Dialog werden die entsprechenden Domains hinzugefügt, für die der lokale Exchange Server zuständig ist. Bei mehreren Domains mit mehreren Exchange Servern, werden entsprechend mehrere Connectoren angelegt. In meinem Fall ist es aber nur „frankysweb.com“:

Jetzt muss wieder die externe IP-Adresse des Exchange Servers angegeben werden, damit die Mails von EOP zu dem lokalen Exchange Server geschickt werden können:

Da ich ein selbst signiertes Zertifikat verwende, welches für EOP nicht vertrauenswürdig ist, wähle ich die Einstellung TLS mit allen Zertifikaten:

Auch hier wird wieder eine Zusammenfassung angezeigt, es geht allerdings noch einen Schritt weiter:

Der Connector wird im letzten Schritt überprüft, ob EOP in der Lage ist Mails an den lokalen Exchange Server zu senden. An dieser Stelle muss also eine Verbindung auf Port 25 (SMTP) zu dem lokalen Exchange Server möglich sein. Hier reicht normalerweise simples DNAT aus, welches so eingeschränkt wird, das nur EOP Mails einliefern darf. Bei meiner Sophos UTM habe ich also einen DNAT Eintrag (oder auch SNAT genannt) erzeugt und den entsprechend eingeschränkt:

Die Gruppe bei „Datenverkehrsquelle“ enthält dann alle EOP-IPs bzw. die EOP Netzwerke. Welche IPs von Microsoft derzeit verwendet werden, ist hier dokumentiert:

https://technet.microsoft.com/library/dn163583(v=exchg.150).aspx

Damit der Connector erstellt werden kann, muss eine E-Mail Adresse für den Test angegeben werden, in meinem Fall ist das administrator@frankysweb.com:

Nach dem Klick auf „Überprüfen“ startet der Test:

Der Test sollte erfolgreich verlaufen:

In Exchange Admin Center „sollten“ nun 2 Connectoren angezeigt werden:

Seltsamer Weise ist bei mir der Connector EOP-to-Exchange nach kurzer Zeit aus dem EOP-Portal verschwunden. Der Connector ist ist aber weiterhin vorhanden. Ob die Connectoren vorhanden sind lässt sich mittels PowerShell prüfen:

Get-InboundConnector | ft –AutoSize
Get-OutboundConnector | ft -AutoSize

Eine Verbindung zu EOP via Powershell wird wie folgt aufgebaut:

$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.protection.outlook.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session

Eine Liste der verfügbaren CMDLets findet sich hier:

https://technet.microsoft.com/de-de/library/dn621038(v=exchg.150).aspx

Nachdem der Nachrichtenfluss konfiguriert ist, können die Benutzer angelegt werden. In den meisten Fällen bietet es sich an, die Synchronisation automatisch erledigen zu lassen. Um das lokale ActiveDirectory mit EOP (bzw Azure AD) zu synchronisieren, muss es eingerichtet werden:

Schritt 1: Verzeichnissynchronisierung vorbereiten

Im ersten Schritt gibt es einen wichtigen Punkt: Wenn das lokale ActiveDirectory einen Namen verwendet der nicht gleich der E-Mail Domain ist, dann muss die E-Mail Domain als alternativer UPN-Suffix hinzugefügt werden. Beispiel:

• Interner AD-Name: frankysweb.local
• E-Mail Domain: frankysweb.com

Der UPN für Benutzer Frank lautet also frank@frankysweb.local, daher muss dem Benutzer Frank der alternative UPN-Suffix frankysweb.com zugewiesen werden, damit das Zuordnen von lokalem Benutzer zu EOP Benutzer funktioniert.

Das alternaive UPN wird in der Konsole „Active Directory-Domänen und Vertrauensstellungen“ hinzugefügt:

Damit die Benutzer zugeordnet werden können, muss bei jedem Benutzer der UPN geändert werden, am Einfachsten funktioniert das über die PowerShell (siehe Hinweis!!!). Hier gibt es ein entsprechendes Script:

http://blogs.technet.com/b/heyscriptingguy/archive/2013/08/13/add-user-principal-names-in-active-directory-via-powershell.aspx

Aber Vorsicht: Das Ändern des UPN für die Benutzer, sollte sorgfältig geplant werden. Es könnte sonst im Chaos enden, wenn sich kein Benutzer mehr anmelden kann…

Für einzelne Benutzer lässt es sich händisch umstellen:

Wer den UPN nicht verändern möchte oder kann, kann die Benutzer auch mittels CSV-Datei oder auch per Powershell importieren. Schritt 2 kann normalerweise übersprungen werden. Also kann es mit Schritt 3 weitergehen:

Nach dem Klick auf Aktivieren, sollte der Status angezeigt werden und die beiden Tools können runtergeladen werden:

Die beiden Tools werden auf einem Domain Controller benötigt. Das Tool ldfix kann dazu verwendet werden Probleme bei der Synchronisation vorab zu beheben:

In meiner Umgebung sind keine Probleme aufgetreten:

Daher kann das Tool dirsync installiert werden

Nachdem das Tool installiert wurde, am besten das Häkchen bei „Konfigurations-Assistenten jetzt starten“ abwählen und vor der Konfiguration den Benutzter abmelden und wieder anmelden:

Der Assistent kann nach dem Anmelden über das Startmenü oder über die Desktop Verknüpfung gestartet werden. Im ersten Dialog muss der EOP Benutzer angegeben werden:

Im nächsten Dialog muss ein Benutzer mit Domain Administrator Rechten angegeben werden, zusätzlich muss der Benutzer Mitglied der Gruppe „FIMSyncAdmins“ sein, die bei der Installation erstellt wurde:

Der Modus „Hybride Bereitstellung“ erlaubt es, dass auch Änderungen von EOP in das lokale AD synchronisiert werden können, der Modus ist aber nicht zwingend erforderlich:

Auch die Kennwortsynchronisation mit Azure AD ist nicht zwingend nötig:

Die Konfiguration sollte ohne Fehler abgeschlossen werden:

Abschließend kann das lokale AD mit Azure synchronisiert werden:

Der Synchronisationsvorgang kann mit dem Synchronization Service Manager überwacht werden. Das Tool findet sich unter folgendem Pfad:

C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe

Nachdem die Synchronisation abgeschlossen wurde, werden die Benutzer im Office 365 Portal unter „Aktive Benutzer“ angezeigt. Bei Benutzern mit geänderten UPN funktioniert die Zuordnung (rot), bei Benutzern ohne geänderten UPN nicht (blau)

Hinweis: Das lokale AD wird alle 3 Stunden mit Azure AD synchronisiert. Der Intervall lässt sich über folgende Datei anpassen:

C:\Program Files\Windows Azure Active Directory Sync\Microsoft.Online.DirSync.Scheduler.exe.Config

Hier das Beispiel für 1 Stunde:

Nach dem Anpassen der Datei, muss der Dienst „Windows Azure Active Directory Sync Service“ neugestartet werden. Die Synchronisation lässt sich auch manuell anstoßen, dazu kann ein PowerShell SnapIn aus folgendem Verzeichnis geladen werden:

C:\Program Files\Windows Azure Active Directory Sync\DirSync

Import-Module .\DirSync.psd1
Start-OnlineCoexistenceSync

Die EOP Konfiguration ist jetzt soweit abgeschlossen, es fehlt noch eine kleine Exchange Konfiguration und das Umstellen der MX Records.

Zuerst den lokalen Exchange Sendeconnector anlegen, damit ausgehende Mails über EOP geleitet werden:

New-SendConnector -Name "Exchange-To-EOP" -AddressSpaces * -CloudServicesMailEnabled $true -Fqdn "outlook.frankysweb.de" -RequireTLS $true -SmartHosts frankysweb-com.mail.protection.outlook.com -TlsAuthLevel CertificateValidation

Der Befehl muss etwas angepasst werden:

-fqdn: gibt den externen Namen des Exchange Servers an, normalerweise ist das der HELO Eintrag, der auch auf dem Zertifikat steht

-smarthosts: Domain-TLD.mail.protection.outlook.com. Domain und TLD werden durch Bindestrich getrennt

Der alte Sende Connector kann zunächst deaktiviert oder direkt gelöscht werden

Zum Schluss noch den MX Record beim Provider umstellen (in meinem Fall wieder Strato):

Normalerweise ist der MX Reocrd auch domain-tld.mail.protection.outlook.com. Der MX lässt sich aber auch unter dem Punkt „Domänen“ mit einem Klick auf „DNS verwalten“ anzeigen:

Hier werden neben dem MX auf die SPF Einträge angezeigt, die konfiguriert werden sollten, wenn der Provider dies unterstützt:

Strato Konfiguration für SPF:

Fertig, zumindest mit der grundlegenden Konfiguration…