[Dovecot] in a major jam... authentication
I was upgrading my debian box and managed to upgrade my dovecot installation at the same time. I wasn't planning on it, but it came along just the same.
I took some notes on what I thought I needed to change, but apparently it wasn't enough.
I've been running this for quite some time now with pgsql authentication and it's been one of those nice applications that always behave themselves.
Until now.
I can connect to the database. But I always fail the authentication. From the logs I'm coming in on a PLAIN authentication and failing on "password mismatch" The database hasn't changed the password in years. The database stores the password as (I believe) an md5 encryption of the real password. Whatever it is, it is definitely encrypted in the table.
What I had in my configuration file was something like this: disable_plaintext_auth = no (this was marked as the default and I enforced it in the new file) auth_mechanisms = plain auth_passdb = pgsql:/etc/dovecot/dovecot-pgsql.conf auth_user = root login = imap
I have updated the configuration as follows: dovecot-pgsql.conf 'driver = pgsql' 'default_pass_scheme = PLAIN-MD5' ( I tried changing this to PLAIN but it didn't help )
dovecot.conf protocols = imap disable_plaintext_auth = no protocol imap { } protocol pop3 { } auth default { mechanisms = plain passdb pam { } passdb sql { args = /etc/dovecot/dovecot-pgsql.conf }
userdb passwd { } user = root }
I'm not sure what to try now, all I know is that my IMAP server is just dead and I'm unable to get the authentication working again. I can't find much that says how to set this up again and am reluctant to just start trying stuff.
tallison1 wrote:
I was upgrading my debian box and managed to upgrade my dovecot installation at the same time. I wasn't planning on it, but it came along just the same.
I took some notes on what I thought I needed to change, but apparently it wasn't enough.
I've been running this for quite some time now with pgsql authentication and it's been one of those nice applications that always behave themselves.
Until now.
I've checked again and the encrypted strings match on both parts of the logging (big_ugly_string). So it's not really a password mismatch... At least not according to the logs.
dovecot: 2006-01-16 15:09:18 Warning: Killed with signal 15 dovecot: 2006-01-16 15:09:19 Info: Dovecot v1.0.alpha5 starting up dovecot: 2006-01-16 15:09:20 Info: auth(default): pgsql: Connected to dbmail dovecot: 2006-01-16 15:09:41 Info: auth(default): client in: AUTH 1 PLAIN service=IMAP lip=192.168.0.5 rip=192.168.1.200 dovecot: 2006-01-16 15:09:41 Info: auth(default): client out: CONT 1 dovecot: 2006-01-16 15:09:41 Info: auth(default): client in: CONT 1 big_ugly_string dovecot: 2006-01-16 15:09:43 Info: auth(default): pam(tallison,192.168.1.200): pam_authenticate() failed: Authentication failure dovecot: 2006-01-16 15:09:43 Info: auth(default): sql(tallison,192.168.1.200): query: SELECT passwd AS password FROM users WHERE userid = 'tallison' dovecot: 2006-01-16 15:09:43 Info: auth(default): sql(tallison,192.168.1.200): Password mismatch dovecot: 2006-01-16 15:09:45 Info: auth(default): client out: FAIL 1 user=tallison dovecot: 2006-01-16 15:09:45 Info: auth(default): client in: AUTH 2 PLAIN service=IMAP lip=192.168.0.5 rip=192.168.1.200 resp=big_ugly_string dovecot: 2006-01-16 15:09:47 Info: auth(default): pam(tallison,192.168.1.200): pam_authenticate() failed: Authentication failure dovecot: 2006-01-16 15:09:47 Info: auth(default): sql(tallison,192.168.1.200): query: SELECT passwd AS password FROM users WHERE userid = 'tallison' dovecot: 2006-01-16 15:09:47 Info: auth(default): sql(tallison,192.168.1.200): Password mismatch dovecot: 2006-01-16 15:09:49 Info: auth(default): client out: FAIL 2 user=tallison dovecot: 2006-01-16 15:09:53 Info: imap-login: Disconnected: user=<tallison>, method=PLAIN, rip=192.168.1.200, lip=192.168.0.5
On Mon, 2006-01-16 at 15:15 -0500, Tom Allison wrote:
I've checked again and the encrypted strings match on both parts of the logging (big_ugly_string). So it's not really a password mismatch... At least not according to the logs. .. dovecot: 2006-01-16 15:09:43 Info: auth(default): sql(tallison,192.168.1.200): Password mismatch
Well, if the passwords really are correct, then it must be a problem with used password scheme being wrong.
I just added auth_debug_passwords setting to CVS, which should help debugging these password mismatch problems.
participants (3)
-
tallison1
-
Timo Sirainen
-
Tom Allison