SMTP-Relay in der Office 365-Umgebung | Teil 3#4

Nach der Migration zu Office 365 (Exchange Online) beschweren sich Benutzer darüber, dass sie keine E-Mail-Nachrichten mehr von einem Faxgerät erhalten, das sich im Büro der Organisation befindet.

Sie beginnen mit der Untersuchung dieses Problems und überprüfen die Einstellungen des Faxgeräts erneut. Alles sieht in Ordnung aus und dennoch erreichen E-Mail-Nachrichten, die über das Faxgerät gesendet werden, ihr Ziel nicht. Mmmm … was ist passiert?
Das Kleine, was wir vergessen haben, ist, dass bisher E-Mail-fähige Geräte\Anwendungen für die Verbindung mit dem lokalen Exchange-Server konfiguriert waren.

Bevor wir die Fähigkeit dieser E-Mail-fähigen Geräte/Anwendung wiederherstellen können, E-Mails an Organisationsempfänger (die sich in der Cloud befinden) zu senden, müssen wir einige „Hindernisse“ überwinden. „Keine Angst, es gibt eine Lösung!

Senden Sie eine E-Mail an Exchange Online - Artikelserie

• E-Mail an Exchange Online senden | Teil 1#4
• Senden Sie E-Mails über eine Standard-SMTP-Sitzung an Exchange Online | Teil 2#4
• SMTP-Relay in der Office 365-Umgebung | Teil 3#4
• SMTP-Relay in der Office 365-Umgebung | Fehlerbehebungsszenarien |Teil 4#4

Der aktuelle Artikel ist der dritte Artikel in der Artikelserie, die sich mit der Anforderung des E-Mail-Versands über die Mail-Dienste von Office 365 befasst.
Im vorherigen Artikel haben wir ein Szenario beschrieben, in dem wir die Mail-Dienste von Office 365 ansprechen der MX-Eintrag, der „unseren Mailserver“ in Office 365 darstellt.

Der Nachteil dieser Methode besteht darin, dass diese Konfiguration als nicht sicher konfiguriert ist und eingebaute Einschränkungen aufweist, z. B. die Unfähigkeit, E-Mails an den externen Empfänger zu senden oder die Option „im Namen senden“ zu implementieren.

Die „Lösung“ für diesen Nachteil und die bevorzugte Methode zur Anbindung der Office 365-Mail-Infrastruktur ist die Verwendung eines sicheren Kommunikationskanals basierend auf dem TLS-Protokoll und der Notwendigkeit, dass der Mail-Client Benutzeranmeldeinformationen bereitstellen muss.

Die größte Herausforderung, vor der wir stehen, besteht darin, dass in einem Szenario, in dem der „Mail-Client“ ein Hardwaregerät wie ein Scanner oder Drucker oder eine bestimmte Software ist, dieser „Mail-Client“ oft nicht die zwingende Notwendigkeit der Erstellung eines sicheren Geräts unterstützt Kommunikationskanal über das TLS-Protokoll.

In diesem Fall wird die Lösung mithilfe eines Brokers oder Vermittlers implementiert, der als Mail-Relay bezeichnet wird.
Im aktuellen Artikel besprechen wir die Verwendung des integrierten SMTP-Servers, der im Windows Server-Betriebssystem vorhanden ist - Der IIS-SMTP-Server.

Mail-Client zur Adressierung von Mail-Diensten | Optionale Szenarien

Szenario 1 - LAN-Mail-Clients (Geräte\Anwendung), die einen internen Mailserver ansprechen

In einem Szenario, in dem LAN-Mail-Clients (Geräte\Anwendungen) einen internen Mailserver ansprechen, wird grundsätzlich davon ausgegangen, dass die LAN-Umgebung als „sicher“ (isoliert vom externen Netzwerk) gilt.
Aus diesem Grund ist das typische Zeichen der Kommunikation zwischen den E-Mail-fähigen Geräten/Anwendungen und dem lokalen Mailserver ist:

1. Kommunikationskanal - E-Mail-fähige Geräte/Anwendungen kommunizieren mit dem lokalen Mailserver über das SMTP-Protokoll (unverschlüsselte Verbindung).
2. Authentifizierung - In den meisten Fällen verwenden die E-Mail-aktivierten Geräte/Anwendungen keinen Authentifizierungsmechanismus (anonyme Authentifizierung).
3. IP-Adressbeschränkung - Wenn der Administrator in einigen Szenarien einen grundlegenden Sicherheitsmechanismus implementieren möchte, wird der lokale Mailserver so konfiguriert, dass er anonyme SMTP-Verbindungen nur von einer bestimmten vordefinierten IP-Adresse akzeptiert.

Szenario 2 - LAN-Mail-Clients, die Office 365-Mail-Dienste über einen sicheren Kommunikationskanal (TLS) ansprechen

In einem Szenario des E-Mail-Flusses in einem öffentlichen Netzwerk wie der Cloud (Office 365-Mail-Dienste) basieren die Merkmale des Kommunikationskanals auf unterschiedlichen Annahmen - dem Kommunikationskanal - dem Kommunikationskanal zwischen den E-Mail-fähigen Geräten/Anwendungen und dem Büro 365-Mail-Dienste werden über eine öffentliche Netzwerkinfrastruktur (nicht vertrauenswürdige Umgebung) erstellt.

Aus diesem Grund besteht die beste Vorgehensweise aus Sicherheitsgründen darin, einen Sicherheitsmechanismus einzurichten, der den sicheren Versand von E-Mails über die Office 365-Mail-Infrastruktur ermöglicht.

Die „Übersetzung“ für den „sicheren Weg“ ist die Implementierung eines verschlüsselten Kommunikationskanals + die Notwendigkeit, dass die Office 365-Mail-Infrastruktur das „Element“ (Mail-fähige Geräte\Anwendungen) identifiziert, das ihn verbindet und nach Mail-Diensten fragt.

Die Grundlage dieses Szenarios sind Mail-fähige Geräte/Anwendungen, die die Office 365-Mail-Infrastruktur „direkt“ ansprechen können, indem sie die Office 365-Entitäten ansprechen, die die Exchange Online-Mail-Dienste darstellen, die für E-Mail-Clients verfügbar sind.

Um den Office 365-Mailserver - smtp.office365.com über einen sicheren Kommunikationskanal ansprechen zu können, müssen die E-Mail-fähigen Geräte\Anwendungen in der Lage sein, über das TLS-Protokoll zu kommunizieren + Geben Sie Benutzeranmeldeinformationen von Office 365-Benutzern an, die über ein Exchange Online-Postfach verfügen.

Szenario 3 - LAN-Mail-Clients (Geräte\Anwendung), die Office 365-Mail-Dienste über Mail-Relay ansprechen

Das dritte Szenario ist eine Situation, in der wir E-Mail-fähigen Geräten und Anwendungen ermöglichen möchten, die Office 365-E-Mail-Infrastruktur über einen sicheren Kommunikationskanal anzusprechen.

Da die E-Mail-aktivierten Geräte\Anwendungen die obligatorische Anforderung für die Verwendung des TLS-Protokolls + Authentifizierung nicht unterstützen, müssen wir ein Zwischenelement verwenden, das als „logischer Konnektor“ zwischen den E-Mail-aktivierten Geräten\Anwendungen der Organisation und der Office 365-E-Mail dient Infrastruktur (EOP-Server).

Der „Logik-Anschluss“ wird mithilfe eines SMTP-Relay-Servers implementiert.
Der SMTP-Relay-Server verwendet zwei separate Schnittstellen:

• Schnittstelle 1 - die interne Schnittstelle, die mit den E-Mail-fähigen Geräten/Anwendungen der Organisation kommuniziert.
• Schnittstelle 2 - die öffentliche Schnittstelle, die über einen sicheren Kommunikationskanal Kontakt zur Office 365-Mail-Infrastruktur (dem EOP-Server) herstellt.

Die öffentliche Schnittstelle des SMTP-Relay-Servers muss die folgenden zwingenden Anforderungen erfüllen:

1. Sicherer Kommunikationskanal - verschlüsselter Kommunikationskanal, der mithilfe des TLS-Protokolls (Port 587 oder Port 25) erstellt wird.
2. Authentifizierung - der „SMTP-Relay-Server“, der E-Mails an die Office 365-Mail-Infrastruktur weiterleiten möchte, muss Anmeldeinformationen (Benutzername + Passwort) mithilfe des Basisauthentifizierungsprotokolls bereitstellen.
3. IP-Adresse des Mailservers\Hostname - der „SMTP-Relay-Server“, der E-Mails an die 365-Mail-Infrastruktur weiterleiten möchte, muss den öffentlichen Hostnamen des 365-Mailservers kennen (smtp .office365.com).

Der IIS-SMTP-Server kann die obligatorischen Anforderungen von Exchange Online für TLS und Authentifizierung erfüllen. In dem Szenario wird der IIS-SMTP-Server mit zwei „Schnittstellen“ konfiguriert:

1. Die Schnittstelle, die Anfragen von LAN-Mail-fähigen Geräten/Anwendungen akzeptiert - diese „Schnittstelle“ ermöglicht/akzeptiert die Mail-Relay-Anfragen von LAN-Mail-fähigen Geräten/Anwendungen, ohne dass eine Authentifizierung (anonym) und der von uns verwendete Kommunikationskanal erforderlich ist Die Kommunikation mit den LAN-Mail-fähigen Geräten/Anwendungen basiert auf dem SMTP-Protokoll (keine Verschlüsselung erforderlich).
2. Die Schnittstelle, die mit Exchange Online kommuniziert - Der andere „Zweig“ oder die andere Schnittstelle wird vom IIS-SMTP-Server für die Kommunikation mit Exchange Online unter Verwendung von TLS verwendet und implementiert die Anforderungen für die Authentifizierung.

Teil 1 - SMTP-Mail-Relay mithilfe des IIS-Servers implementieren

Im folgenden Abschnitt gehen wir auf alle Einstellungen und Voraussetzungen ein, die wir für die Verwendung von IIS SMTP als Mail-Relay-Server implementieren müssen.

Voraussetzungen für das SMTP-Mail-Relay

1. IIS-SMTP-Benutzeranmeldeinformationen

Bei den Anmeldeinformationen, die IIS SMTP für die Kommunikation mit Exchange Online verwendet, kann es sich um beliebige Office 365-Benutzeranmeldeinformationen handeln, die über eine gültige Lizenz verfügen (Lizenz für Exchange Online Mailbox).

Für diesen Zweck ist es nicht erforderlich, eine „erkannte“ Lizenz zu erwerben. Das einzige „Problem“, das wir in Bezug auf den Empfängernamen (die Office 365-Benutzer, die wir für die Authentifizierung beim Exchange Online-Server verwenden) berücksichtigen sollten, besteht darin, dass standardmäßig jede der Nachrichten, die an den Exchange Online-Server weitergeleitet werden, diesen Empfänger enthält Geben Sie im Feld „Von“ den Namen ein.

Wenn wir beispielsweise den IIS-SMTP-Server so konfigurieren, dass er die Anmeldeinformationen eines Office 365-Benutzers namens John verwendet, wird jede E-Mail-Adresse akzeptiert, die von einem LAN Mail-fähigen Gerät/Anwendungen an andere Office 365-Empfänger gesendet wurde beim Zielempfänger als E-Mail-Adresse, die von „John. ”

Später werden wir uns das Szenario ansehen, in dem die LAN-Mail-fähigen Geräte/Anwendungen unterschiedliche E-Mail-Adressen verwenden, und wie man IIS SMTP aktiviert, um E-Mails „im Namen“ dieser Hosts zu senden.

2. Firewall-Einstellungen

Damit der IIS-SMTP-Server einen Kommunikationskanal zu Exchange Online erstellen kann, müssen wir in der Organisations-Firewall eine Ausgangsregel erstellen, die es dem IIS-SMTP ermöglicht, TLS (Port 587 oder Port 25) zu verwenden.

3. Office 365-Mailserver-Entität | Hostname

Um auf den Exchange Online-Server verweisen zu können, verwendet Office 365 einen allgemeinen Hostnamen: smtp.office365.com

Wenn Sie Informationen zum Exchange Online-Servernamen finden möchten, befolgen Sie die folgenden Anweisungen

1. Melden Sie sich beim Office 365-Portal an
2. Greifen Sie auf den OWA-Client (Mail) zu
3. Klicken Sie im oberen Menü auf das Symbol Einstellungen
4. Wählen Sie das Menü Optionen

5. Wählen Sie in der Menüleiste auf der linken Seite das Menü POP und IMAP
6. Klicken Sie unten auf der Seite auf Einstellungen für POP oder IMAP
7. Suchen Sie in den angezeigten Fenstern nach dem Abschnitt: SMTP-Einstellungen
   Hier finden Sie den Exchange Online-Servernamen (smtp.office365.com) und außerdem können wir sehen, dass es einen gibt zwingende Voraussetzung für die Nutzung des TLS-Protokolls (Port 587 oder Port 25).

Installieren und Konfigurieren des IIS-SMTP-Servers

Im folgenden Abschnitt zeigen wir, wie Sie den IIS-SMTP-Server auf einem Windows 2008-Server installieren.

Schritt 1: IIS-Server installieren

1. Öffnen Sie die Server-Manager-Konsole und wählen Sie unter „Funktionen“ die Option „Funktionen hinzufügen“ aus
2. Wählen Sie die Option „SMTP-Server“
   (Das Zurücksetzen des Installationsvorgangs erfolgt direkt als nächstes, als nächstes usw.)

Schritt 2: IIS SMTP-Dienst

Standardmäßig wird der IIS-SMTP-Dienst nicht gestartet und der Starttyp ist: manuell

1. Wir müssen die Standardeinstellung auf „Automatisch“ ändern.
   Doppelklicken Sie auf den SMTP-Dienst: Simple Mail Transfer Protocol (SMTP) und ändern Sie den Starttyp in Automatisch
2. Startenden IIS-SMTP-Dienst (SMTPSVC)

Schritt 3: IIS SMTP Server MMC

Die Verwaltungskonsole für IIS SMTP ist Internet Information Services 6.0.
(Es gibt keine Möglichkeit, IIS SMTP mit der „Standard“-IIS 7-Verwaltungskonsole zu verwalten). Den IIS 6.0 Manager finden Sie unter Verwaltungstools -> Internetinformationsdienste 6.0

Teil 2 - Konfigurieren des IIS-Servers als Mail-Relay für die Office 365-Umgebung

Im folgenden Abschnitt gehen wir auf alle erforderlichen Einstellungen für die Konfiguration des IIS-SMTP-Servers als „SMTP-Relay“ ein. ”

1. IIS SMTP-Relay „LAN-Schnittstelle“.

Der erste Teil bezieht sich auf die Einstellungen für die Schnittstelle oder den „IIS-Zweig“, der die LAN-Hosts (Mail-fähige Geräte\Anwendungen) bedient.

Öffnen Sie die IIS-SMTP-Verwaltungskonsole, klicken Sie mit der rechten Maustaste auf
[SMTP Virtual Server #1] und wählen Sie: Eigenschaften

1. Registerkarte „Zugriff“ | Authentifizierung

Wählen Sie die Registerkarte Zugriff -> Authentifizierung

Wählen Sie im Authentifizierungsfenster die Option: Anonymer Zugriff (E-Mail-fähige Geräte/Anwendungen müssen keine Authentifizierung verwenden).

2. Registerkarte „Zugriff“ | Relais

Die „Relay“-Einstellungen dienen zum Konfigurieren der IP-Adresse von: E-Mail-fähigen Geräten/Anwendungen, die mit dem IIS-SMTP-Server kommunizieren (E-Mail weiterleiten).
In unserem Beispiel haben wir zwei Hosts, die E-Mails an den senden müssen IIS SMTP-Server:

Helpdesk-Anwendung, die auf einer Workstation mit der IP-Adresse 10.100.102.2 installiert ist, und ein FAX-Gerät, das die IP-Adresse 10.100.102.3 verwendet
Um diesen Hosts das Senden (Relay) von E-Mails an den IIS-SMTP-Server zu ermöglichen, benötigen wir Folgendes um diese IP-Adresse zur „Zulassungsliste“ hinzuzufügen.

Wählen Sie die Registerkarte Zugriff -> klicken Sie auf die Schaltfläche Relay….

Fügen Sie im Fenster Relay-Einschränkung die IP-Adresse der E-Mail-fähigen Geräte/Anwendungen hinzu, die mit dem IIS-SMTP-Server kommunizieren (E-Mail weiterleiten).

Weitere Informationen zu den Relay-Einstellungen finden Sie im nächsten Artikel - SMTP-Relay in der Office 365-Umgebung | Fehlerbehebungsszenarien |Teil 4#4

2. IIS SMTP-Mail-Relay-„Cloud“-Schnittstelle

In diesem Abschnitt erstellen wir die erforderlichen Einstellungen, die es dem IIS-SMTP-Server ermöglichen, E-Mail-Nachrichten an den Exchange Online-Server weiterzuleiten.

Registerkarte „Lieferung“.

Auf der Registerkarte Lieferung können Sie die IIS-SMTP-„Schnittstelle“ konfigurieren, die mit dem Exchange Online-Server kommuniziert.

1. Registerkarte „Lieferung“ | Ausgehende Sicherheit

Wählen Sie die Registerkarte Lieferung -> Option Ausgehende Sicherheit.

Wählen Sie im Fenster Ausgehende Sicherheit die Option: Basisauthentifizierung

Wir müssen die Anmeldeinformationen des Office 365-Benutzers angeben, der über das Exchange Online-Postfach verfügt. In unserem Beispiel verwenden wir die Anmeldeinformationen eines Benutzers mit dem Namen: John@o365info.com

Wählen Sie die Registerkarte Lieferung -> Option Ausgehende Sicherheit.
Wählen Sie im Fenster Ausgehende Sicherheit die Option: TLS-Verschlüsselung (zum Erstellen eines sicheren Kommunikationskanals zu Exchange Online).

2. Registerkarte „Lieferung“ | TCP-Port

Wählen Sie die Registerkarte Lieferung -> Option Ausgehende Verbindung.

Die TLS-Portnummer, die wir für die Kommunikation mit Exchange Online verwenden, ist:25 (oder Port 587)

(Bitte stellen Sie sicher, dass die Firewall der Organisation über die erforderliche Ausgangsregel verfügt, die es dem IIS-SMTP-Server ermöglicht, diesen Port zu verwenden.)

3. Registerkarte „Lieferung“ | Fortgeschritten

Wählen Sie die Registerkarte Lieferung -> Option Erweitert

Im Textfeld Smart Host müssen wir den Namen des Exchange Online-Servers angeben.

Der Abschnitt Vollqualifizierter Domänenname ist keine zwingende Anforderung. Sie können den FQDN des IIS-SMTP-Servers hinzufügen.

Teil 3 - Aktivieren Sie das IIS-SMTP-Relay, um E-Mails im Namen einer anderen E-Mail-Adresse zu senden

Nachdem wir die erforderlichen Einstellungen für das IIS-SMTP-Relay erstellt haben, müssen wir das zusätzliche Problem lösen, das wie folgt beschrieben werden kann: Aktivieren Sie das IIS-SMTP-Relay, um E-Mails im Namen einer anderen E-Mail-Adresse zu senden.

Zu Demonstrationszwecken verwenden wir das folgende Szenario:
Wir möchten zwei internen Hosts ermöglichen, E-Mails über den IIS-SMTP-Server zu senden.

Ein Host ist eine Helpdesk-Anwendung, die die E-Mail-Adresse HelpDesk@o365info.com verwendet, und der andere Host ist ein Faxgerät, das die E-Mail-Adresse FaxService@o365info.com

Falls diese Hosts versuchen, E-Mails an den IIS-SMTP-Server weiterzuleiten, wird diese E-Mail-Nachricht vom Exchange Online-Server abgelehnt, weil: standardmäßig ein Empfänger (in unserem Beispiel: John@o365info .com) kann nicht E-Mails „im Namen“ anderer Empfänger senden (in unserem Beispiel: FaxService@o365info. com und HelpDesk@o365info.com).

Die gute Nachricht ist, dass wir kein Benutzerkonto und kein Postfach erstellen müssen, die diese Hosts „repräsentieren“, die E-Mails an den IIS-SMTP-Server weiterleiten.

Um dem IIS-SMTP-Server das Senden von E-Mails für diese Hosts zu ermöglichen, können wir eine der folgenden Lösungen wählen:

1. Verwenden Sie die Verteilergruppe und weisen Sie „Senden als“-Berechtigungen zu.

Diese Lösung basiert auf der Erstellung einer Verteilergruppe für jeden Host, der E-Mails an den IIS-SMTP-Server weiterleiten muss.
Die Verteilergruppe ist als Sicherheitsgruppe konfiguriert (eine Gruppe „Sicherheit\Verteilung“).
Der Nächste Schritt ist: Zuweisen der Berechtigung „Senden als“ für den Empfänger, den der IIS-SMTP-Server zur Authentifizierung verwendet (in unserem Beispiel:John@o365info.com).

Die Berechtigung „Senden als“ kann über die Webschnittstelle oder einen PowerShell-Befehl zugewiesen werden.

Weisen Sie die Berechtigung „Senden als“ über die Webverwaltungsoberfläche von Office 365 zu.

1. Melden Sie sich beim Office 365-Portal an und wählen Sie im Admin-Menü die Option: Exchange
2. Wählen Sie im Exchange Admin Center das Menü Empfänger -> Gruppen
3. Klicken Sie auf die Option „Hinzufügen“ und wählen Sie die Option Sicherheitsgruppe.

4. In unserem Beispiel nennen wir die neue Sicherheitsverteilungsgruppe FaxService
5. Doppelklicken Sie auf den Namen der neuen Sicherheitsverteilung (FaxService) und wählen Sie das Menü - Gruppendelegation.
6. Klicken Sie auf die Option Hinzufügen und fügen Sie den Empfängernamen hinzu, den wir für die IIS-SMTP-Anmeldeinformationen verwenden (in unserem Beispiel: John).

Wir müssen diesen Vorgang für jeden LAN-Host wiederholen, der E-Mails über den IIS-SMTP-Server weiterleiten muss.

Weisen Sie mit dem PowerShell-Befehl die Berechtigung „Senden als“ zu.
Zuweisen Sie Berechtigungen „Senden als“ für eine Postfach-/Verteilungsgruppe

Beispiel für die PowerShell-Befehlssyntax:

Add-RecipientPermission FaxService -AccessRights SendAs -Trustee John

2. Fügen Sie eine zusätzliche E-Mail-Adresse (Alias) hinzu.

Die andere Option, die wir verwenden können (anstelle der Lösung „Sicherheit\Verteilungsgruppe“), ist: Fügen Sie die E-Mail-Adresse, die von den LAN Mail-fähigen Geräten/Anwendungen verwendet wird, als zusätzliche E-Mail-Adresse (Alias) für den Empfänger hinzu, der von verwendet wird der IIS-SMTP-Server.

In unserem Beispiel fügen wir dem Empfänger namens John zwei zusätzliche E-Mail-Adressen hinzu

1. Melden Sie sich beim Office 365-Portal an und wählen Sie im Admin-Menü die Option: Exchange
2. Wählen Sie im Exchange Admin Center das Menü Empfänger -> Postfächer
3. Wählen Sie den Empfängernamen, der vom IIS-SMTP-Server verwendet wird (in unserem Beispiel John).

4. Klicken Sie auf die Option „Hinzufügen“.
5. Wählen Sie in den Postfacheigenschaften die Option: E-Mail-Adresse.
6. In unserem Beispiel fügen wir zu „John Mailbox“ zwei zusätzliche E-Mail-Adressen (Alias) hinzu: FaxService@o365info.com und HelpDesk@o365info.com