Zur Beachtung - Anleitungen

Bitte beachten Sie, daß die bereitgestellten Informationen zum Zeitpunkt der Erstellung im Rahmen von durchgeführten Arbeiten dokumentiert und validiert wurden. In einer geänderten Systemumgebung können für die Schritte Anpassungen erforderlich sein. Dies gilt insbesonders, falls die Informationen Workarounds oder Fehlerbehebungen betreffen. Die Informationen sind entsprechend spezifisch für die Systemumgebung und Version der Systeme zum Zeitpunkt der Arbeiten. Schritte, die sich für uns von selbst erschließen, sind ggf. nicht in den Anleitungen enthalten. Dasselbe gilt auch für konzeptionelle Anleitungen. Diese sind für spezifische Umgebungen und spezifische Erfordernisse erstellt und müssen vor Anwendung überprüft werden, ob sie für die angedachte Umgebung passend sind. Die Verwendung erfolgt auf eigene Gefahr.

Wir raten in jedem Fall dazu, vorab ein Backup in einem Umfang zu erstellen, der die Wiederherstellung der Systeme im Fehlerfall sichert. Dies betrifft bei Active-Directory-integrierten Diensten auch das Active-Directory.

 

(05.10.2024)

Validiert mit MS Exchange 2019 CU14

Im Gegensatz zu anonymen Relays erfordern authentifizierte Relays die Anmeldung mit einem gültigen Benutzer. Ein Postfach ist dabei nicht erforderlich.

Von Exchange 2013 auf 2016 wurde das Verhalten der Empfangskonnektoren verändert. Frontend-Empfangskonnektoren unterstützen die erweiterten Rechte

  • ms-Exch-SMTP-Accept-Any-Sender
  • ms-Exch-SMTP-Accept-Authoritative-Domain-Sender

nicht mehr. Bei Zuweisung wird keine Fehlermeldung ausgegeben, die Rechte werden aber ignoriert.

Bei Versuch eine Mail zu senden, wird als SMTP-Fehler 550 5.7.60 Client does not have permissions to send as this sender zurückgegeben.

Entsprechend ist die Konfiguration eines Relays, das alle Absenderadressen und alle Empfängeradressen für bestimmte authentifizierte Benutzer akzeptiert, seit Exchange 2013 nicht mehr mit Frontend-Konnektoren umsetzbar.

Da auf Port 25 Frontend-Konnektoren standardmäßig erzeugt werden, ist die Erstellung eines Hub-Transport-Konnektors auf demselben Port nicht möglich und es muß ein anderer Port gewählt werden (hier:8025).

Die Zuweisung der Benutzerrechte kann einzelbenutzerspezifisch und über eine Sicherheitsgruppe erfolgen. Letzteres ist vorzuziehen, wenn mehrere Systeme das authentifizierende Relay nutzen sollen.

Vorgehensweise:

  • Anlegen Gruppe "SMTP-Sender"
  • Anlegen Benutzer <smtp.user>, Mitglied der primären Gruppe "SMTP-Sender"
  • Anlegen Empfangskonnektor:
    • New-ReceiveConnector -Name "Relaying Authentifiziert" -TransportRole HubTransport -Bindings "0.0.0.0:8025" -RemoteIPRanges "<ip-bereich>" -Custom -AuthMechanism BasicAuth[,BasicAuthRequireTLS],TLS -Banner "220 <server> ESMTP Authenticated Relay Service ready"
    • get-ReceiveConnector "Relaying Authentifiziert"|add-ADPermission -user <domäne>\SMTP-Sender -ExtendedRights ms-Exch-SMTP-Submit
    • get-ReceiveConnector "Relaying Authentifiziert"|add-ADPermission -user <domäne>\SMTP-Sender -ExtendedRights ms-Exch-SMTP-Accept-Any-Sender
    • get-ReceiveConnector "Relaying Authentifiziert"|add-ADPermission -user <domäne>\SMTP-Sender -ExtendedRights ms-Exch-SMTP-Accept-Any-Recipient
    • get-ReceiveConnector "Relaying Authentifiziert"|add-ADPermission -user <domäne>\SMTP-Sender -ExtendedRights ms-Exch-SMTP-Accept-Authoritative-Domain-Sender
    • get-ReceiveConnector "Relaying Authentifiziert"|add-ADPermission -user <domäne>\SMTP-Sender -ExtendedRights ms-Exch-Accept-Headers-Routing
  • Firewall: New-NetfirewallRule -DisplayName "Freigabe 8025/tcp Authentifiziertes Relaying" -Direction Inbound -Protocol TCP -LocalPort 8025 -RemoteAddress <ip-bereich> -Action Allow

 

Anmerkungen:

  • wird BasicAuthRequireTLS weggelassen, dann kann die Authentifizierung auch bei unverschlüsselten Verbindungen verwendet werden. Ggf. ist das für den Endpunkt notwendig.
  • die remoten Adressbereiche für Empfangskonnektor und Firewalleinstellungen müßen angeglichen werden