On Jun 4, 2008, at 7:44 PM, Timo Sirainen wrote:
On Wed, 2008-06-04 at 19:21 -0400, Jurvis LaSalle wrote:
Hi,
We've had some issues with auth. /var/log/secure is full of 1000s
of these lines:Jun 4 19:12:08 khan dovecot-auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser= rhost=127.0.0.1 user=user123
Someone's trying to brute-force in?
sorry. i changed that from a valid username at our site to user123.
nearly all of the errors are for valid accounts.
Users can usually login OK with their ldap credentials, but occasionally logins slow to a crawl if not outright fail, esp people checking mail through Squirrelmail. Things get better after a
dovecot restart.You used blocking=yes with PAM, which means the PAM processes get reused. This might be why restarting helps. Have you tried how it
works without the blocking=yes?
when we were still using the rh rpm, we were troubleshooting the
outlook offline issue and found this thread:
http://www.mail-archive.com/dovecot@dovecot.org/msg04150.html
It seemed pertinent to our situation and led us to install from source
and use blocking=yes. I just commented it out. I'm still getting an
error per login in /var/log/secure. I'll see if it keeps things from
locking up during the thick of it tomorrow.
Googling around, I thought if we switched the order or disabled the second passdb we had configured for our dovecotadmin account, these failures would go away but that did not happen.
What do you mean second passdb? There's only one passdb in your
dovecot -n output:
there's only one passdb now because I disabled the second to try to
get rid of the error. I thought it would after reading this thread: http://www.mail-archive.com/dovecot@dovecot.org/msg03102.html
since we're transitioning accounts using imapsync and don't know the
ldap passwords for all accounts, this is what the dovecot -n output
usually looks like:
# 1.0.13: /etc/dovecot/etc/dovecot.conf log_path: /var/log/dovecot.log info_log_path: /var/log/dovecot-info.log ssl_cert_file: /etc/pki/dovecot/certs/star.idi.harvard.edu.crt ssl_key_file: /etc/pki/dovecot/private/star.idi.harvard.edu.key login_dir: /etc/dovecot-1.0.13/var/run/dovecot/login login_executable: /etc/dovecot/libexec/dovecot/imap-login mail_location: maildir:/RAID5/mailboxes/%u maildir_stat_dirs: yes maildir_copy_with_hardlinks: yes imap_client_workarounds: outlook-idle delay-newmail auth default: executable: /etc/dovecot/libexec/dovecot/dovecot-auth master_user_separator: * debug: yes debug_passwords: yes passdb: driver: pam args: blocking=yes passdb: driver: passwd-file args: /etc/dovecot.master master: yes userdb: driver: passwd args: blocking=yes
passdb: driver: pam args: blocking=yes userdb: driver: passwd args: blocking=yes
Anyway, one sure way to reduce PAM problems would be to get rid of it and just configure Dovecot to use LDAP directly.
That does appear to be the last avenue open.
Thanks for the quick reply.
Cheers, JL