UTM Email Protection: Recipient verification with Active Directory

In my private environment with a Sophos UTM 9.508-10, I have always had the problem that the recipient verification of Email Protection via Active Directory did not work. The following warning was always displayed in the Email Protection live log:

Warning: ACL "warn" statement skipped: condition test deferred: failed to bind the LDAP connection to server 192.168.5.1:636 - ldap_bind() returned -1

The normal authentication of users against the Active Directory ran without any problems, and it was also possible to test the authentication services. Only Email Protection stubbornly refused to verify the email addresses against Active Directory.

In the authentication services of the UTM, I had configured that the connection to the domain controller should be encrypted using SSL. Apparently, however, this causes problems with the UTM's email protection and, at least in my case, leads to the error mentioned above.

Importing the domain controller's certificate didn't help either, so the only thing left for me to do was to use an unencrypted connection.

Here is the configuration that works in my environment:

In order for recipient verification to work, I had to change the setting "Domain controller: Signature requirements for LDAP server" to the value "None". The setting can either be defined in the group policy "Default Domain Controllers Policy" or via a new additional policy for the domain controllers. I am a friend of unchanged default policies, so I would recommend creating a new group policy here, here you must then pay attention to the order of the GPOs so that the default policy does not overwrite the value:

Sophos UTM Email Protection: Recipient authentication via Active Directory

To verify e-mail addresses and users, the UTM requires a user in the ActiveDirectory. The user must only belong to the "Domain users" group. The user's password must not expire:

Recipient authentication via Active Directory

The Distinguished Name (DN) is required from the user's attributes; this can already be copied once:

Recipient authentication via Active Directory

The Distinguished Name (DN) of the Active Directory domain is also required:

Recipient authentication via Active Directory

A new server with the type "Active Directory" is now created in the authentication services of the UTM. SSL is deactivated and port 389 is selected. The value "Bind-DN" corresponds to the Distinguished Name (DN) of the user account. The value for BaseDN corresponds to the DN of the domain:

Recipient authentication via Active Directory

The settings can be tested with "Test server settings" and any user/password combination.

Recipient authentication via Active Directory can now be activated in the Email Protection settings under the Routing menu item. The DN of the domain can again be specified as the "Alternative BaseDN":

Recipient authentication via Active Directory

With these settings, recipient verification via Active Directory works, at least in my environment. If anyone has managed it with SSL, I would be pleased to receive feedback.

8 thoughts on “UTM Email Protection: Empfänger Verifizierung mit Active Directory”

  1. An der Stelle an der Tino stand, stehe ich auch gerade. Gibt es da zwischenzeitlich wohl eine Lösung?

    @Tino: Was meinst Du mit „auf die Exchange-Abfrage zurückstellen“? CallOut statt AD?

    Danke & Gruß

    TJ

    Reply
  2. Hallo Frank,

    nach Einrichten der Adress-Verifizierung nimmt die UTM keine Mails mehr an, die in Exchange Kontakten stehen. Hattest du das Problem auch schon?

    Ich musste es erst mal wieder auf die Exchange-Abfrage zurückstellen, damit Mails an Kontakte geschickt werden können.

    Gruß Tino

    Reply
  3. Als Bind-DN funktioniert übrigends auch user@internedomain, was den Vorteil hat, dass der User auch in eine andere OU verschoben werden kann ohne das es Probleme gibt.

    Reply
    • Hi,

      nein, dass lässt sich leider nicht nutzen. Der Hintergrund:
      Die Recipient Validation von Exchange 2016 greift erst nach dem DATA Kommando in der SMTP Session, nicht schon beim RCPT TO. Dies ist zu spät für SMTP Call Out wie es die UTM anbietet. Exchange müsste die Mail dann schon beim RCPT TO ablehnen und nicht erst nach DATA. Die SMTP Call Out Methode wäre somit immer erfolgreich, die Mail geht durch die UTM und wird dann erst mit von Exchange abgelehnt. Dies lässt sich dann wunderbar für Backscatter SPAM missbrauchen.
      Gruß,
      Frank

      Reply
    • Hallo André,
      korrekt, ich bin wieder in die Falle gelaufen, dass die Einstellungen nach einem Update der UTM zurück gesetzt wurden. Ich habe einfach nicht mehr daran gedacht, dass ich entsprechende Einstellungen direkt in der Konfigurationsdatei vorgenommen habe.
      Gruß,
      Frank

      Reply
  4. Hallo Franky, ich wusste nicht, dass es da Probleme gibt. Bei mir funktioniert das einfach so. Willst Du Dir das mal bei mir ansehen? Was für einen DC hast du verwedet?

    Grüße Volker

    Reply

Leave a Comment