[Dovecot] auth issues on centos5 with ldap backend
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@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 1000sof 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@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!!!!
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?
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=yes
Anyway, one sure way to reduce PAM problems would be to get rid of it and just configure Dovecot to use LDAP directly.
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
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.
On Jun 4, 2008, at 8:54 PM, Timo Sirainen wrote:
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?
I'm not sure I understand your question. Here's my observations: when I
$ telnet localhost 143 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'.
- OK Dovecot ready. 1 login validLDAPaccount XXXXX 1 OK Logged in. 2 logout
- BYE Logging out 2 OK Logout completed. Connection closed by foreign host.
I see in /var/log/secure an error like this:
Jun 5 12:37:46 khan dovecot-auth: pam_unix(dovecot:auth):
authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=
rhost=127.0.0.1 user=validLDAPaccount
So the user was logged in, but an error was logged for some reason.
OTOH, when I log in using the dovecotadmin account, no error is
logged. I've tried changing the order of the passdb sections and
removing the dovecotadmin section entirely, but an error is always
logged for an LDAP user even though they successfully login.
Does that answer your question? Please let me know if I can provide
any additional info to figure this out. I'll work on removing PAM
from the equation as auth locked up on us again while I was writing
this even though I removed the blocking=yes from the passdb:driver:pam
section.
Thanks, JL
Jurvis LaSalle wrote:
On Jun 4, 2008, at 8:54 PM, Timo Sirainen wrote:
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?
I'm not sure I understand your question. Here's my observations: when I
$ telnet localhost 143 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'.
- OK Dovecot ready. 1 login validLDAPaccount XXXXX 1 OK Logged in. 2 logout
- BYE Logging out 2 OK Logout completed. Connection closed by foreign host.
I see in /var/log/secure an error like this:
Jun 5 12:37:46 khan dovecot-auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser= rhost=127.0.0.1 user=validLDAPaccount
So the user was logged in, but an error was logged for some reason.
OTOH, when I log in using the dovecotadmin account, no error is logged. I've tried changing the order of the passdb sections and removing the dovecotadmin section entirely, but an error is always logged for an LDAP user even though they successfully login.Does that answer your question? Please let me know if I can provide any additional info to figure this out. I'll work on removing PAM from the equation as auth locked up on us again while I was writing this even though I removed the blocking=yes from the passdb:driver:pam section.
Thanks, JL
Hello,
The first time i tried out dovecot, although it preformed quite nicely after the login, i remember having a bit of lag when the client was first logging in. At the time i was using LDAP backend for user authetication.
Now i can't recall if i was getting the same type of error you show from your log file, but i do recall that same "wait" uppon login. My problem was that, by default, dovecot would ALSO check using PAM/passwd backends, before going for the LDAP backend.
Right after i eliminated the PAM/passwd passdb definitions ALL dovecot's operations were blazing fast.
I'm not saying that's your problem, but it's worth checking.
Regards,
Hugo Monteiro.
-- ci.fct.unl.pt:~# cat .signature
Hugo Monteiro Email : hugo.monteiro@fct.unl.pt Telefone : +351 212948300 Ext.15307
Centro de Informática Faculdade de Ciências e Tecnologia da Universidade Nova de Lisboa Quinta da Torre 2829-516 Caparica Portugal Telefone: +351 212948596 Fax: +351 212948548 www.ci.fct.unl.pt apoio@fct.unl.pt
ci.fct.unl.pt:~# _
On Thu, 2008-06-05 at 12:55 -0400, Jurvis LaSalle wrote:
Jun 5 12:37:46 khan dovecot-auth: pam_unix(dovecot:auth):
authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=
rhost=127.0.0.1 user=validLDAPaccountSo the user was logged in, but an error was logged for some reason.
This error comes from PAM. Maybe you have PAM configured to do multiple different lookups?
On Jun 5, 2008, at 3:47 PM, Timo Sirainen wrote:
On Thu, 2008-06-05 at 12:55 -0400, Jurvis LaSalle wrote:
Jun 5 12:37:46 khan dovecot-auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser= rhost=127.0.0.1 user=validLDAPaccount
So the user was logged in, but an error was logged for some reason.
This error comes from PAM. Maybe you have PAM configured to do
multiple different lookups?
Here's my dovecot PAM conf (i've manually included the include
lines). I tried to comment out the pam_unix.so lines so that only
ldap would be checked, but that made all authentication attempts
fail. I'm not quite sure how to trim this down so only the ldap
accounts are queried. Any PAM experts out there?
[root@borg ~]# cat /etc/pam.d/dovecot #%PAM-1.0 auth required pam_nologin.so auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass debug auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so
account required pam_unix.so broken_shadow debug account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_ldap.so account required pam_permit.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in
crond quiet use_uid
session required pam_unix.so debug
session optional pam_ldap.so
Thanks, JL
On Thu, 2008-06-12 at 17:31 -0400, Jurvis LaSalle wrote:
Here's my dovecot PAM conf (i've manually included the include
lines). I tried to comment out the pam_unix.so lines so that only
ldap would be checked, but that made all authentication attempts
fail. I'm not quite sure how to trim this down so only the ldap
accounts are queried. Any PAM experts out there?
I think you could remove all lines with pam_unix.so
auth requisite pam_succeed_if.so uid >= 500 quiet .. account sufficient pam_succeed_if.so uid < 500 quiet .. session [success=1 default=ignore] pam_succeed_if.so service in
crond quiet use_uid
All of these look kind of suspicious for IMAP server, I'd remove them too.
participants (4)
-
Hugo Monteiro
-
Jurvis LaSalle
-
Scott Silva
-
Timo Sirainen