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
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. 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. Any
thoughts or additional info I can provide? Pardon the unusual install
prefix. We're trying to keep the source install separated from the
ancient dovecot rpm shipped in rhel5.
Thanks,
Jurvis
[root at khan ~]# /etc/dovecot/sbin/dovecot -n
# 1.0.13: /etc/dovecot-1.0.13/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
userdb:
driver: passwd
args: blocking=yes
on 6-4-2008 4:21 PM Jurvis LaSalle spake the following:> 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 > > 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. > 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. Any thoughts or > additional info I can provide? Pardon the unusual install prefix. We're > trying to keep the source install separated from the ancient dovecot rpm > shipped in rhel5. > > Thanks, > Jurvis > > [root at khan ~]# /etc/dovecot/sbin/dovecot -n > # 1.0.13: /etc/dovecot-1.0.13/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 > userdb: > driver: passwd > args: blocking=yes > > > > > >Do you need something special compiled in? If not, you could save some hassle by using a dovecot rpm from atrpms.net. -- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't!!!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature URL: <http://dovecot.org/pipermail/dovecot/attachments/20080604/037ca7a1/attachment-0002.bin>
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=user123Someone's trying to brute-force in?> 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?> 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:> passdb: > driver: pam > args: blocking=yes > userdb: > driver: passwd > args: blocking=yesAnyway, one sure way to reduce PAM problems would be to get rid of it and just configure Dovecot to use LDAP directly. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20080605/1231fd00/attachment-0002.bin>
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 at 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 at 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