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" 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? > > > > 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 o...@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