[Dovecot] auth issues on centos5 with ldap backend

[Jurvis LaSalle]

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