Sophos UTM Email Protection contains a bug where recipient verification is simply skipped. In the case of recipient verification via Active Directory and the query via SSL, no verification of the recipients takes place. Here are the problematic settings:
- Recipient verification using Active Directory
- Querying the Active Directory with SSL
In the Email Protection live log, it then leads to the following log entries:
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
The query of the domain controller fails and the recipient verification is skipped.
Recipient check via server request (CallOut)?
The behavior is particularly unpleasant with Exchange 2013 and Exchange 2016, because recipient verification via CallOut (with server request) is difficult to implement without an Edge Transport Server.
Since Recipient Validation only takes place at the Hub Transport Connector, but not at the FrontEnd. In this case, Exchange will always respond with "250 Recipient OK". The lack of recipient validation on the Exchange side is due to the architecture. A mail is always accepted by the "Default Frontend" receiving connector and forwarded bluntly to the "Default" receiving connector:
In this case, recipient verification is therefore always successful for the UTM's Mail Protection, as the recipient is only validated by the downstream connector. This is also the case if the Exchange AntiSPAM Agents are installed.
Disable LDAP SSL?
Uh? No, because NO!
Customize Sophos UTM Mail Protection (workaround)
Customizing the UTM configuration via shell will probably cause problems with support, which is already indicated at login:
NOTE: If not explicitly approved by Sophos support, any modifications
done by root will void your support.
The procedure should therefore be discussed with Support. I only have the Home version, so I can't fall back on the support anyway.
After you have obtained root rights on the shell using "sudo su -" to obtain root rights, the following file can be edited using VI:
vi /var/chroot-smtp/etc/openldap/ldap.conf
The following line is added to the file:
TLS_REQCERT allow
Then save the file and restart Mail Protection. Now the recipient check via LDAP SSL also works:
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: ………….