saslauthd stops working every few weeks

Discussion in 'ISPConfig 3 Priority Support' started by James A, Jun 8, 2014.

  1. James A

    James A Member HowtoForge Supporter

    Hi, as the title says every few weeks saslauthd appears to stop working causing an SASL LOGIN authentication failed: authentication failure in the log whenever an SMTP attempt is made.

    Jun 6 07:11:07 srv5 postfix/smtpd[27251]: warning: unknown[212.15.178.94]: SASL PLAIN authentication failed: authentication failure
    Jun 6 07:11:19 srv5 postfix/smtpd[27251]: warning: SASL authentication failure: Password verification failed
    Jun 6 07:11:19 srv5 postfix/smtpd[27251]: warning: unknown[212.15.178.94]: SASL PLAIN authentication failed: authentication failure
    Jun 6 07:11:19 srv5 postfix/smtpd[27251]: warning: SASL authentication failure: Password verification failed
    Jun 6 07:11:19 srv5 postfix/smtpd[27251]: warning: unknown[212.15.178.94]: SASL PLAIN authentication failed: authentication failure
    Jun 6 07:11:38 srv5 postfix/smtpd[27251]: warning: SASL authentication failure: Password verification failed
    Jun 6 07:11:38 srv5 postfix/smtpd[27251]: warning: unknown[212.15.178.94]: SASL PLAIN authentication failed: authentication failure
    Jun 6 07:11:43 srv5 postfix/smtpd[27251]: warning: SASL authentication failure: Password verification failed

    As soon as I restart saslauthd everything starts working properly again.

    Checking ps aux when things have stopped working still shows the standard 5 processes.

    [email protected]:~# ps aux | grep 'saslauthd'
    root 24693 0.0 0.4 151836 76560 ? Ss May21 0:03 /usr/sbin/saslauthd -a pam -c -m /var/spool/postfix/var/run/saslauthd -r -n 5
    root 24695 0.0 0.4 151844 76540 ? S May21 0:03 /usr/sbin/saslauthd -a pam -c -m /var/spool/postfix/var/run/saslauthd -r -n 5
    root 24696 0.0 0.4 151948 76536 ? S May21 0:03 /usr/sbin/saslauthd -a pam -c -m /var/spool/postfix/var/run/saslauthd -r -n 5
    root 24697 0.0 0.4 151936 76544 ? S May21 0:03 /usr/sbin/saslauthd -a pam -c -m /var/spool/postfix/var/run/saslauthd -r -n 5
    root 24698 0.0 0.4 151952 76536 ? S May21 0:03 /usr/sbin/saslauthd -a pam -c -m /var/spool/postfix/var/run/saslauthd -r -n 5


    I'm struggling to work out how to troubleshoot this further as I'm not sure how to log the errors in saslauthd.

    These are the additional lines opening secure auth in etc/postfix/master.cf

    smtp inet n - - - - smtpd
    # Added 2525 to open smtp on this port for clients where port 25 is blocked by the isp.
    2525 inet n - - - - smtpd
    #smtp inet n - - - 1 postscreen
    #smtpd pass - - - - - smtpd
    #dnsblog unix - - - - 0 dnsblog
    #tlsproxy unix - - - - 0 tlsproxy
    submission inet n - - - - smtpd
    -o syslog_name=postfix/submission
    -o smtpd_tls_security_level=encrypt
    -o smtpd_sasl_auth_enable=yes
    -o smtpd_client_restrictions=permit_sasl_authenticated,reject
    -o milter_macro_daemon_name=ORIGINATING
    smtps inet n - - - - smtpd
    -o syslog_name=postfix/smtps
    -o smtpd_tls_wrappermode=yes
    -o smtpd_sasl_auth_enable=yes
    -o smtpd_client_restrictions=permit_sasl_authenticated,reject
    -o milter_macro_daemon_name=ORIGINATING


    And here is the content of etc/postfix/sasl/smtpd.conf

    pwcheck_method: saslauthd
    mech_list: plain login
    allow_plaintext: true
    auxprop_plugin: sql
    sql_engine: mysql
    sql_hostnames: 127.0.0.1
    sql_user: ispconfig
    sql_passwd: xxxxxxxxxxxxxxxxxxxxxx
    sql_database: dbispconfig
    sql_select: select password from mail_user where login = '%u@%r' and postfix = 'y'

    Any suggestions as to how to fix this would be greatly appreciated, even if it's just a way to detect the error automatically so I can restart the service without the user realising there was an issue.

    My system is Debian Wheezy, ISPConfig 3.0.5.3, Courier based on the latest perfect server build
     
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    You should be able to monitor saslauthd with monit. The monit config should be like this:

    Code:
    #saslauthd
    check process saslauthd with pidfile /var/spool/postfix/var/run/saslauthd/saslauthd.pid
           group mail
           start program = "/etc/init.d/saslauthd start"
           stop  program = "/etc/init.d/saslauthd stop"
           if failed unix /var/spool/postfix/var/run/saslauthd/mux then restart
           if 5 restarts within 5 cycles then timeout
           depends on saslauthd_bin
    
    check file saslauthd_bin with path /usr/sbin/saslauthd
           group mail
           if failed checksum then unmonitor
           if failed permission 755 then unmonitor
           if failed uid root then unmonitor
           if failed gid root then unmonitor
    To debug saslauthd, add "-d" in the OPTIONS line in /etc/default/saslauthd and restart saslauthd. The verbose output should be in the syslog then.
     
  3. James A

    James A Member HowtoForge Supporter

    Thanks Till for the advice with Monit.

    Just looking at getting saslauthd into debug mode as described above and there are numerous warnings suggesting not to enter it as an option under /etc/default/saslauthd as this will prevent the system from booting properly as the -d makes it run in the foreground rather than a daemon. I presume I should just stop the daemon (/etc/ini.d/saslauthd stop) and then start saslauthd in the foreground with all the existing options and the -d to debug ie:

    saslauthd -c -m /var/spool/postfix/var/run/saslauthd -r -d
     
  4. till

    till Super Moderator Staff Member ISPConfig Developer

    yes, this might be the better option indeed.
     
  5. James A

    James A Member HowtoForge Supporter

    Just to clarify for anyone reading this the actual command I had to run to saslauthd to run in debug from the command line was:

    saslauthd -a pam -n 5 -c -m /var/spool/postfix/var/run/saslauthd -r -d

    as you need to include the -a for the authentication mechanism, in my case spam, and the -n just gives the number of threads.

    Anyway after doing this and searching the logs a little more, something I'm not always so good at, I did find under the auth.log that the error I'm getting is:

    saslauthd[24693]: DEBUG: auth_pam: pam_authenticate failed: Memory buffer error

    Whilst this doesn't necessarily help me fix what's causing the issue I can a least monitor the log through a script and simply email the error and restart saslauthd when it happens which should make it unnoticeable to our users. Of course I could also just restart saslauthd once a day and that would also fix the issue from a user perspective but....

    Till, can you point me in the right direction with this error?

    Thanks for your help so far.
     
    Last edited: Jun 9, 2014
  6. jon

    jon Member HowtoForge Supporter

    I had the same problem and ended up setting up a cron job to restart it every night. I know it's a bad solution, but it works well and the service is only down for a few seconds.
     
  7. James A

    James A Member HowtoForge Supporter

    Thanks Jon,

    Having written a script to check the logs, I have to say I've just ended up implementing an auto restart once a day via crontab simply because it adds zero extra load compared to reading the auth.log every minute.

    As you say it's not pretty but effective, even if it doesn't feel right.

    If anyone actually has a proper fix for this please let us know.
     
  8. Ben

    Ben ISPConfig Developer ISPConfig Developer

    Eventhough this last post is quite a while ago, I just faced the same issue, running ISCOnfig on a Debian Wheezy.
    While saerching for that memory leak thing, I came across this source: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758660
    Which is common to my setup is using the mysql plugin as well, and the comment of that might cause a memory leak.
    Eventhough I wonder why this happens out of a sudden, as I also did not see so many failed attempts on smtp/pop3/imap which could indicate more load and leaking memory for SASL.
    I just wonder if the suggested patch for the pam mysql module could make it into debian's repo: http://sourceforge.net/p/pam-mysql/bugs/27/#c2aa
    Any idea how to find that out?
     

Share This Page