[Dovecot] 1.1.6: PAM passdb/userdb (mis)configuration
I'm sure I'm missing something obvious :-(
Dovecot version 1.1.6, pam authentication via ldap (openldap). basicly, we use:
passdb pam userdb passwd
which work fine, except for Outlook/OL Express users that are asked for their password whenever they "send/receive"... We've had also "passdb shadow" that somehow "fixed" this but allowed also users with expired passwords to login :-( re-added for now, untill the correct configuration is achived).
Here is the output of dovecot -n:
# 1.1.6: /usr/local/etc/dovecot.conf # OS: Linux 2.6.9-55.ELsmp x86_64 Red Hat Enterprise Linux AS release 4 (Nahant Update 7) info_log_path: /var/log/dovecot protocols: imap imaps pop3 pop3s listen(default): * listen(imap): * listen(pop3): *:110 ssl_listen(default): ssl_listen(imap): ssl_listen(pop3): *:995 ssl_ca_file: /usr/local/etc/dovecot/certs/IPS-IPSCABUNDLE.CRT ssl_cert_file: /usr/local/etc/dovecot/certs/dovecot.pem ssl_key_file: /usr/local/etc/dovecot/private/dovecot.pem disable_plaintext_auth: no verbose_ssl: yes login_dir: /usr/local/var/run/dovecot/login login_executable(default): /usr/local/libexec/dovecot/imap-login login_executable(imap): /usr/local/libexec/dovecot/imap-login login_executable(pop3): /usr/local/libexec/dovecot/pop3-login first_valid_uid: 50 mail_debug: yes mail_full_filesystem_access: yes mmap_disable: yes lock_method: dotlock mbox_read_locks: dotlock mbox_write_locks: dotlock mail_executable(default): /usr/local/libexec/dovecot/imap mail_executable(imap): /usr/local/libexec/dovecot/imap mail_executable(pop3): /usr/local/libexec/dovecot/pop3 mail_plugin_dir(default): /usr/local/lib/dovecot/imap mail_plugin_dir(imap): /usr/local/lib/dovecot/imap mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3 imap_client_workarounds(default): outlook-idle delay-newmail imap_client_workarounds(imap): outlook-idle delay-newmail imap_client_workarounds(pop3): pop3_uidl_format(default): %08Xu%08Xv pop3_uidl_format(imap): %08Xu%08Xv pop3_uidl_format(pop3): %08Xv%08Xu pop3_client_workarounds(default): pop3_client_workarounds(imap): pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh namespace: type: private separator: / prefix: mail/ location: mbox:%h/mail list: yes subscriptions: yes namespace: type: private separator: / location: maildir:%h/Maildir:INDEX=/var/dovecot/index/%u:CONTROL=/var/dovecot/control/%u inbox: yes list: yes subscriptions: yes auth default: verbose: yes debug: yes worker_max_request_count: 10 passdb: driver: pam args: dovecot passdb: driver: shadow userdb: driver: passwd args: blocking=yes
Thank you for your help.
\Oved Dr. Oved Ben-Aroya, Head Unix group, Taub Computer Center, Technion Phone: +972 (4) 829 3688 FAX: +972 (4) 823 6212 oved@technion.ac.il PGP key at http://tx.technion.ac.il/~oved/pgp/pubkey PGP Key fingerprint: A9 52 46 04 E8 70 41 99 60 E3 DA 8F BA 39 C2 C8
On Jan 12, 2009, at 2:28 AM, Oved Ben-Aroya wrote:
which work fine, except for Outlook/OL Express users that are asked
for their password whenever they "send/receive"... We've had also
"passdb shadow" that somehow "fixed" this
This really makes no sense. Outlook doesn't know if you're using PAM
or shadow. Do you mean that Outlook anyway can successfully log in,
but just asks the password all the time?
On Mon, Jan 12, 2009 at 09:14:06AM -0500, Timo Sirainen wrote:
On Jan 12, 2009, at 2:28 AM, Oved Ben-Aroya wrote:
which work fine, except for Outlook/OL Express users that are asked
for their password whenever they "send/receive"... We've had also
"passdb shadow" that somehow "fixed" thisThis really makes no sense. Outlook doesn't know if you're using PAM
or shadow. Do you mean that Outlook anyway can successfully log in,
but just asks the password all the time?
Sorry I was not clear in my description of the problem. Yes, users of Outlook log in and read their mail just fine. However, whenever they want to refresh the inbox or send mail, they are presented with a login window of Outlook. With the "passdb shadow" directive that somehow crept in, Outlook users were not asked for password after they logged in (however this broke the password exiration).
All our users are defined in ldap, and both passwd and shadow for the users are obtained from ldap (pointed to by /etc/nsswitch.conf). PAM authentication for users is via ldap.
I wonder if we need to enable authentication cache?
TIA,
\Oved Dr. Oved Ben-Aroya, Head Unix group, Taub Computer Center, Technion Phone: +972 (4) 829 3688 FAX: +972 (4) 823 6212 oved@technion.ac.il PGP key at http://tx.technion.ac.il/~oved/pgp/pubkey PGP Key fingerprint: A9 52 46 04 E8 70 41 99 60 E3 DA 8F BA 39 C2 C8
On Tue, 2009-01-13 at 09:14 +0200, Oved Ben-Aroya wrote:
which work fine, except for Outlook/OL Express users that are asked
for their password whenever they "send/receive"... We've had also
"passdb shadow" that somehow "fixed" thisThis really makes no sense. Outlook doesn't know if you're using PAM
or shadow. Do you mean that Outlook anyway can successfully log in,
but just asks the password all the time?Sorry I was not clear in my description of the problem. Yes, users of Outlook log in and read their mail just fine. However, whenever they want to refresh the inbox or send mail, they are presented with a login window of Outlook. With the "passdb shadow" directive that somehow crept in, Outlook users were not asked for password after they logged in (however this broke the password exiration).
Well, there is some difference between what PAM and shadow does. Perhaps PAM starts failing the login after some time? Enable auth_debug=yes and see what the difference is between when using shadow and pam.
The difference between Outlook/OE and other clients is that they keep logging out and back in all the time, while other clients typically log in only once. Perhaps you have a PAM plugin that limits the number of logins to once every n minutes or something?
I wonder if we need to enable authentication cache?
It shouldn't be necessary, but if the problem is something like what I described above then auth cache will probably work around the actual problem in most cases (but not all).
I was not able to reproduce the Outlook/OL Express users complaints (in a test system). As it turned out, a DB problem in one of our ldap servers led to dovecot authentication failures - showing in the logs that "shadow" authentication failed. Deleting the "passdb shadow" (plus clean up of tens of dovecot-auth processes) fixed it. A couple of days later, a user complained that he can't login with Outlook (OL asking for his password again and again), and a check revealed that his password exired :-)
Still not using authentication cache... Just FYI.
On Tue, Jan 13, 2009 at 12:49:47PM -0500, Timo Sirainen wrote:
On Tue, 2009-01-13 at 09:14 +0200, Oved Ben-Aroya wrote:
which work fine, except for Outlook/OL Express users that are asked
for their password whenever they "send/receive"... We've had also
"passdb shadow" that somehow "fixed" thisThis really makes no sense. Outlook doesn't know if you're using PAM
or shadow. Do you mean that Outlook anyway can successfully log in,
but just asks the password all the time?Sorry I was not clear in my description of the problem. Yes, users of Outlook log in and read their mail just fine. However, whenever they want to refresh the inbox or send mail, they are presented with a login window of Outlook. With the "passdb shadow" directive that somehow crept in, Outlook users were not asked for password after they logged in (however this broke the password exiration).
Well, there is some difference between what PAM and shadow does. Perhaps PAM starts failing the login after some time? Enable auth_debug=yes and see what the difference is between when using shadow and pam.
The difference between Outlook/OE and other clients is that they keep logging out and back in all the time, while other clients typically log in only once. Perhaps you have a PAM plugin that limits the number of logins to once every n minutes or something?
I wonder if we need to enable authentication cache?
It shouldn't be necessary, but if the problem is something like what I described above then auth cache will probably work around the actual problem in most cases (but not all).
-- \Oved Dr. Oved Ben-Aroya, Head Unix group, Taub Computer Center, Technion Phone: +972 (4) 829 3688 FAX: +972 (4) 823 6212 oved@technion.ac.il PGP key at http://tx.technion.ac.il/~oved/pgp/pubkey PGP Key fingerprint: A9 52 46 04 E8 70 41 99 60 E3 DA 8F BA 39 C2 C8
participants (2)
-
Oved Ben-Aroya
-
Timo Sirainen