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
