[Dovecot] /etc/pam.d/dovecot missing? during high load
This morning on our newly built server, the following was logged twice: auth: Error: pam(username,127.0.0.1): pam_authenticate() failed: Authentication failure (/etc/pam.d/dovecot missing?)
This also happened to be during a time of 100+ imap-login processes, where we were seeing: master: Warning: service(imap-login): process_limit reached, client connections are being dropped
The initial error was correct, in that I had not yet created /etc/pam.d/dovecot. I have since created the file. However, we brought this server into production yesterday & there were no complaints, nor was the error logged besides twice this morning within 3.5 minutes of eachother.
In looking at pam documentation, it is my understanding that when a service (dovecot) does not have its own file existing under /etc/pam.d, then pam will instead use the settings from /etc/pam.d/others as defaults. This seems logical to me, and would explain why things have been working fairly well with no errors regarding pam (other than the 2 logged this morning). However, what this does not explain, is why dovecot auth logged about the file missing at all. I can only guess that it was related to logins being dropped due to high load, and was incorrectly logged??
For reference, my current /etc/pam.d/dovecot is: auth required pam_unix.so nullok account required pam_unix.so
My current /etc/pam.d/other is: @include common-auth @include common-account @include common-password @include common-session
Which results in (confirmed via : grep -v ^# common-auth common-account common-password common-session) auth [success=1 default=ignore] pam_unix.so nullok_secure auth requisite pam_deny.so auth required pam_permit.so account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so account requisite pam_deny.so password [success=1 default=ignore] pam_unix.so obscure sha512 password requisite pam_deny.so password required pam_permit.so session [default=1] pam_permit.so session requisite pam_deny.so session required pam_permit.so session required pam_unix.so
So there definitely is quite a difference between the dovecot pam file I created (based on the dovecot2 wiki), and the system default (other). I don't know whether this could have been related, so I figured I'd share.
Otherwise, I'm running dovecot 2.0.9 compiled from source. dovecot -n at the time of the pam errors was probably:
# 2.0.9: /usr/local/etc/dovecot/dovecot.conf # OS: Linux 2.6.32-5-amd64 x86_64 Debian 6.0 auth_debug = yes auth_mechanisms = plain login disable_plaintext_auth = no log_timestamp = "%Y-%m-%d %H:%M:%S " mail_debug = yes mail_location = maildir:~/ mail_privileged_group = mail passdb { driver = pam } protocols = imap pop3 service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } user = root } ssl_cert =
Thanks,
Doug Mortensen Network Consultant Impala Networks Inc CCNA, MCSA, Security+, A+ Linux+, Network+, Server+ . www.impalanetworks.com P: (505) 327-7300 F: (505) 327-7545
Anybody know the answer to this one?? Any thoughts? I haven't received a response yet.
Thanks,
Doug Mortensen Network Consultant Impala Networks P: 505.327.7300
-----Original Message----- From: Douglas Mortensen [mailto:doug@impalanetworks.com] Sent: Thursday, March 03, 2011 2:29 PM To: dovecot@dovecot.org Subject: [Dovecot] /etc/pam.d/dovecot missing? during high load
This morning on our newly built server, the following was logged twice: auth: Error: pam(username,127.0.0.1): pam_authenticate() failed: Authentication failure (/etc/pam.d/dovecot missing?)
This also happened to be during a time of 100+ imap-login processes, where we were seeing: master: Warning: service(imap-login): process_limit reached, client connections are being dropped
The initial error was correct, in that I had not yet created /etc/pam.d/dovecot. I have since created the file. However, we brought this server into production yesterday & there were no complaints, nor was the error logged besides twice this morning within 3.5 minutes of eachother.
In looking at pam documentation, it is my understanding that when a service (dovecot) does not have its own file existing under /etc/pam.d, then pam will instead use the settings from /etc/pam.d/others as defaults. This seems logical to me, and would explain why things have been working fairly well with no errors regarding pam (other than the 2 logged this morning). However, what this does not explain, is why dovecot auth logged about the file missing at all. I can only guess that it was related to logins being dropped due to high load, and was incorrectly logged??
For reference, my current /etc/pam.d/dovecot is: auth required pam_unix.so nullok account required pam_unix.so
My current /etc/pam.d/other is: @include common-auth @include common-account @include common-password @include common-session
Which results in (confirmed via : grep -v ^# common-auth common-account common-password common-session) auth [success=1 default=ignore] pam_unix.so nullok_secure auth requisite pam_deny.so auth required pam_permit.so account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so account requisite pam_deny.so password [success=1 default=ignore] pam_unix.so obscure sha512 password requisite pam_deny.so password required pam_permit.so session [default=1] pam_permit.so session requisite pam_deny.so session required pam_permit.so session required pam_unix.so
So there definitely is quite a difference between the dovecot pam file I created (based on the dovecot2 wiki), and the system default (other). I don't know whether this could have been related, so I figured I'd share.
Otherwise, I'm running dovecot 2.0.9 compiled from source. dovecot -n at the time of the pam errors was probably:
# 2.0.9: /usr/local/etc/dovecot/dovecot.conf # OS: Linux 2.6.32-5-amd64 x86_64 Debian 6.0 auth_debug = yes auth_mechanisms = plain login disable_plaintext_auth = no log_timestamp = "%Y-%m-%d %H:%M:%S " mail_debug = yes mail_location = maildir:~/ mail_privileged_group = mail passdb { driver = pam } protocols = imap pop3 service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } user = root } ssl_cert =
Thanks,
Doug Mortensen Network Consultant Impala Networks Inc CCNA, MCSA, Security+, A+ Linux+, Network+, Server+ . www.impalanetworks.com P: (505) 327-7300 F: (505) 327-7545
On 4.3.2011, at 22.31, Douglas Mortensen wrote:
This morning on our newly built server, the following was logged twice: auth: Error: pam(username,127.0.0.1): pam_authenticate() failed: Authentication failure (/etc/pam.d/dovecot missing?)
This also happened to be during a time of 100+ imap-login processes, where we were seeing: master: Warning: service(imap-login): process_limit reached, client connections are being dropped
This should be irrelevant. If this error goes away, do you still get that pam failure?
In looking at pam documentation, it is my understanding that when a service (dovecot) does not have its own file existing under /etc/pam.d, then pam will instead use the settings from /etc/pam.d/others as defaults.
It does? I don't know. It suggests checking pam.d/dovecot file, because that has been the most common reason why it hasn't worked for some people. Maybe they didn't have the others file either.
This seems logical to me, and would explain why things have been working fairly well with no errors regarding pam (other than the 2 logged this morning). However, what this does not explain, is why dovecot auth logged about the file missing at all.
It logged it only as a guess.
I can only guess that it was related to logins being dropped due to high load, and was incorrectly logged??
The reason for the authentication failure could be anything. Dovecot doesn't know, because PAM doesn't tell. PAM has its own (crappy) logging, maybe it has something?
For reference, my current /etc/pam.d/dovecot is: auth required pam_unix.so nullok account required pam_unix.so
So /etc/shadow.. High load shouldn't really affect that.
In any case, PAM gave Dovecot authentication failure, and there's not much I can do to guess reasons why that happened. Either PAM logged a more specific error message, or it didn't. You could always try not using PAM at all, then you'll get Dovecot's own awesome error logging that tells exactly what goes wrong.
participants (2)
-
Douglas Mortensen
-
Timo Sirainen