Die Sophos UTM Email Protection enthält einen Bug bei dem die Empfängerverifizierung einfach übersprungen wird. Im Falle der Empfänger Prüfung mittels Active Directory und der Abfrage via SSL findet keine Verifizierung der Empfänger statt. Hier einmal die problematischen Einstellungen:
- Empfängerverifizierung mittels Active Direcory
- Abfrage des Active Directory mit SSL
Im Live Log der Email Protection führt es dann zu folgenden Logeinträgen:
2016:11:16-20:45:43 utm exim-in[25000]: 2016-11-16 20:45:43 [127.0.0.1] F= R= Verifying recipient address in Active Directory 2016:11:16-20:45:43 utm exim-in[25000]: 2016-11-16 20:45:43 H=mx.frankysweb.com [127.0.0.17]:46804 Warning: ACL "warn" statement skipped: condition test deferred: failed to bind the LDAP connection to server 127.0.0.2:636 - ldap_bind() returned -1
Das Abfragen des Domain Controller schlägt fehl, und die Empfängerverifizierung wird übersprungen.
Empfängerprüfung via Serveranfrage (CallOut)?
Das Verhalten ist insbesondere mit Exchange 2013 und Exchange 2016 unschön, denn eine Empfängerprüfung via CallOut (Mit Serveranfrage) ist ohne Edge Transport Server nur schwer umzusetzen.
Da Recipient Validation erst am Hub Transport Connector stattfindet, aber nicht am FrontEnd. Exchange wird in diesem Fall also immer mit “250 Recipient OK” antworten. Die fehlende Empfänger Prüfung auf Exchange Seite ist hier Architektur bedingt. Eine Mail wird vom “Default Frontend”-Empfangsconnector immer angenommen und stumpf an den “Default”-Empfangsconnector weitergeleitet:
Die Empfängerverifizierung ist in diesem Fall also immer für die Mail Protection der UTM erfolgreich, denn erst der nachgelagerte Connector führt die Validierung des Empfängers durch. Dies ist übrigens auch der Fall, wenn die Exchange AntiSPAM Agents installiert werden.
LDAP SSL abschalten?
Äh? Nein, weil NEIN!
Sophos UTM Mail Protection anpassen (Workaround)
Das Anpassen der UTM Konfiguration via Shell wird wohl Probleme beim Support nach sich ziehen, darauf wird bereits beim Login hingewiesen:
NOTE: If not explicitly approved by Sophos support, any modifications
done by root will void your support.
Das Vorgehen sollte also mit dem Support abgesprochen werden. Ich habe nur die Home Version, also kann ich eh nicht auf den Support zurückgreifen.
Nachdem man sich auf der Shell mittels “sudo su –“ Root-Rechte verschafft hat, kann die folgende Datei mittels VI editiert werden:
vi /var/chroot-smtp/etc/openldap/ldap.conf
In der Datei wird die folgende Zeile hinzugefügt:
TLS_REQCERT allow
Danach die Datei speichern und die Mail Protection neustarten. Jetzt klappt auch die Empfängerprüfung mittels LDAP SSL:
2016:11:16-20:46:23 utm exim-in[24512]: 2016-11-16 20:46:23 [127.0.0.1] F= R= Verifying recipient address in Active Directory 2016:11:16-20:46:23 utm exim-in[24512]: 2016-11-16 20:46:23 H=mx.frankysweb.com [127.0.0.1]:46468 F= rejected RCPT : Address not present in directory
Ich diskutiere auch gerade mit dem Support warum das nach Jahren immer noch nicht implementiert wurde. Zudem ist natürlich fraglich aufgrund der Abkündigung, ob das überhaupt noch passiert…
Wer sich mit dem Thema beschäftigt wird vielleicht noch auf ein zweites Thema stoßen und das ist die Adressverifizierung bei Mailkontakten. Standardmäßig werden diese nämlich nicht abgefragt und daher werden die Mails abgelehnt. Natürlich eine sehr schlechte Idee, wenn man Personen/Gruppen mit einer direkten Weiterleitung auf dem Exchange ausgestattet hat.
Daher noch die Kurzlösung vom Support dafür:
On the backend, there should be a toggle to include mail contacts in the LDAP query for recipient verification. As this will need to be done through CLI/Shell access, please see below for the steps.
1. cc
2. smtp
3. ad_lookup_contacts$
4. =1
You will then need to turn recipient verification back on after applying the steps above.
Nein, es gibt nach wie vor keine Lösung, nur den oben beschriebenen Workaround.
Gibt es ein Update zu dem bekannten Bug mit der Empfängerverifizierung und dem LDAPS Signing? Ich würde gerne auf LDAPS umstellen, wenn die UTM damit zurechtkommt.
Danke für diesen Artikel, der Fehler ist übrigens immernoch nicht behoben und spätestens bis März sollte Sophos das erledigen da Microsoft LDAP signing erzwingen wird:
https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirement-for-windows
Hallo Franky,
in UTM Version 9.502-4 funktioniert die Empfängervalidierung nur, wenn man sich explizit für einen Domänencontroller entscheidet. Siehst du eine Möglichkeit die Validierung redundant über mehrere DCs hinweg nutzen zu können?
https://cloud.blg-fashion.de/s/2fbpPo2296CUhyY
Grüße
Hagen
Hallo Franky
Leider hat die aktuellste Firmware 9.408-4 einen groben Schnitzer!
Konkret ist eine Folge des Updates, dass unter der Einstellung Definitionen & Benutzer/ Authentifizierungsdienste/ Register Server/ Punkt Bind-DN bzw. Bind- Kennwort dieses „zurückgesetzt“ wurde. Das neue setzen des Active Directory Kennworts für den hinterlegten AD- Benutzer bringt zwar eine erfolgreichen Test, jedoch bleibt auch auf diese Art und Weise das Kennwort nicht gespeichert.
Wird die Einstellung nach dem Speichern erneut editiert und gleich wieder erneut der Servereinstellungstest vorgenommen, so wird dieser wieder fehlschlagen, was wiederum zur Folge hat, dass die Empfängerverifizierung via Active Directory nicht mehr funktioniert (Punkt Email Protection/ SMTP/ Routing/ Empfängerverifizierung)
Ja, ein krasser Fehler, somit werden bis das nächste Update herauskommt, sicher keine Mails mehr empfangen werden können, ausser es gibt auch hierfür einen Workaround, welchen ich zurzeit nicht kenne :-(
Betrifft diesen Known Issue, leider noch kein Fix vorhanden bzw. angekündigt.
Daher dieser Workaround aktuell die einzige Lösung. Danke Frank!
ID24065 9.004 Regression from V8: Recipient Verification against AD not working with LDAP-SSL
————————————————————————
Description: SMTP recipient verification against AD is not working with
LDAP-SSL.
Workaround: Option 1: Switch to non encrypted LDAP connections or
recipient verification with callout.
Option 2: Add the following line to
/var/chroot-smtp/etc/openldap/ldap.conf
TLS_REQCERT allow
According to http://linux.die.net/man/5/ldap.conf :
TLS_REQCERT
Specifies what checks to perform on server
certificates in a TLS session, if any. The can be
specified as one of the following keywords:
…
allow
The server certificate is requested. If no certificate
is provided, the session proceeds normally. If a bad
certificate is provided, it will be ignored and the
session proceeds normally.
Fixed in: ………….