Problem: SASL authentication failure - SMTPS endpoint not reachable

SASL authentication failure - SMTPS endpoint not reachable


Problem:

Mail clients cannot be configured because the secure SMTP (SMTPS) endpoint cannot be reached. As a result, authentication via SASL fails and mail clients are unable to establish a secure connection.

In /var/log/mail.log or journalctl, the following errors appear:

postfix/smtps/smtpd[550828]: oauthbearer_client_plug_init() failed in sasl_server_add_plugin(): error when parsing configuration file
postfix/smtps/smtpd[553318]: warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory
postfix/smtps/smtpd[553318]: warning: SASL authentication failure: Password verification failed
postfix/smtps/smtpd[553318]: warning: unknown[10.159.92.27]: SASL PLAIN authentication failed: generic failure, sasl_username=user@example.com

Environment:

  • UCS version: 5.2-3 errata248

  • Installed components:

    • fetchmail=6.4.37
    • mailserver=16.0
    • ox-connector=3.0.0
    • oxseforucs=7.10.6-ucs11
  • Relevant packages:

    libsasl2-2:amd64 2.1.28+dfsg-10
    libsasl2-modules:amd64 2.1.28+dfsg-10
    libsasl2-modules-oauthbearer 1.0.0-5
    sasl2-bin 2.1.28+dfsg-10
    univention-sasl 10.0.2
    

Investigation:

By default, on UCS 5.2 systems, the saslauthd service is installed but not enabled automatically.

When checking the service status, the output may show the service as active (exited):

systemctl status saslauthd
● saslauthd.service - LSB: saslauthd startup script
     Loaded: loaded (/etc/init.d/saslauthd; generated)
     Active: active (exited) since Mon 2025-11-03 22:02:04 CET; 1s ago
       Docs: man:systemd-sysv-generator(8)
    Process: 484615 ExecStart=/etc/init.d/saslauthd start (code=exited, status=0/SUCCESS)
        CPU: 32ms

Nov 03 22:02:04 ucs5primary systemd[1]: Starting saslauthd.service - LSB: saslauthd startup script...
Nov 03 22:02:04 ucs5primary saslauthd[484615]: To enable saslauthd, edit /etc/default/saslauthd and set START=yes ... (warning).
Nov 03 22:02:04 ucs5primary systemd[1]: Started saslauthd.service - LSB: saslauthd startup script.

The system logs indicate:

To enable saslauthd, edit /etc/default/saslauthd and set START=yes ... (warning)

In /etc/default/saslauthd, the following line is missing:

# Should saslauthd run automatically on startup? (default: no)
START=yes

Without this configuration, the /var/run/saslauthd/ directory and corresponding socket files are created incorrectly or not initialized, preventing Postfix from connecting to the SASL authentication daemon.

Example output:

total 968K
drwx--x---  2 root sasl  140  3. Nov 23:43 .
drwxr-xr-x 39 root root 1,4K  5. Nov 04:19 ..
-rw-------  1 root root    0  3. Nov 23:43 cache.flock
-rw-------  1 root root 963K  3. Nov 23:43 cache.mmap
srwxrwxrwx  1 root root    0  3. Nov 23:43 mux
-rw-------  1 root root    0  3. Nov 23:43 mux.accept
-rw-------  1 root root    7  3. Nov 23:43 saslauthd.pid

Root Cause

The template file /etc/univention/templates/files/etc/default/saslauthd does not enable automatic startup of the saslauthd service.
This issue is tracked under Bug #58791.


Workaround

  1. Edit the UCS template:

    /etc/univention/templates/files/etc/default/saslauthd
    
  2. Add or ensure the following line is present at the beginning:

    # Should saslauthd run automatically on startup? (default: no)
    START=yes
    
  3. Apply the change:

    ucr commit /etc/default/saslauthd
    
  4. Restart the saslauthd service:

    systemctl restart saslauthd.service
    

Verification

After applying the workaround, verify that the service is running properly:

systemctl status saslauthd.service

Expected output:

● saslauthd.service - LSB: saslauthd startup script
     Active: active (running)
     CGroup: /system.slice/saslauthd.service
             ├─491931 /usr/sbin/saslauthd -a pam -c -r -m /var/run/saslauthd -t 1800 -n 5
             ├─491932 /usr/sbin/saslauthd -a pam -c -r -m /var/run/saslauthd -t 1800 -n 5

Once the service is running, Postfix can connect to the SASL authentication socket and mail clients can successfully authenticate via Secure SMTP.