On Wed, 2008-06-04 at 20:02 -0400, Jurvis LaSalle wrote:
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.
Are there any valid logins at all then?
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.
Having blocking=yes only for userdb passwd should be enough to fix the nss_ldap problem.
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: .. passdb: driver: passwd-file args: /etc/dovecot.master master: yes
passwd-file doesn't have any kind of conflicts with PAM (unlike nss_ldap/pam_ldap).
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.
The performance should also be a lot better than with PAM.