[Dovecot] Possible bug with proxy in 2.0.4
Hi, I *think* there might be an auth/proxy bug in 2.0.4
Specifically I cloned my 1.2 virtual machine, upgraded the clone to 2.0.4 and tested it by trying to login using CRAM-MD5. I get the errors:
Sep 29 22:50:23 mail_test dovecot: imap-login: Disconnected (auth failed, 1 attempts): user=<demo@abc.com>, method=CRAM-MD5, rip=x.x.x.x, lip=x.x.x.x, mpid=0, TLS Sep 29 22:50:30 mail_test dovecot: auth: mysql: Connected to mysql-local (postfix) Sep 29 22:50:30 mail_test dovecot: imap-login: Error: proxy: password not given: user=<demo@abc.com>, method=CRAM-MD5, rip=x.x.x.x, lip=x.x.x.x, mpid=0, TLS
Interestingly the config here (accidently as it happens) causes the connection to use the dovecot "proxy" feature back to the original 1.2 machine. I updated my config so that everything stays on the 2.0.4 machine and authentication proceeds normally, messages about generating MD5 hash from the DB, etc, logged in ok.
I then change the configuration so that the 2.0.4 machine proxies the connection back to the 1.2 machine (again) and try to login to the 2.0.4 machine and get the same errors as above. Seems like the error is only when proxying (needless to say, the old 1.2 machine works fine with CRAM and that's how it's normally accessed, so also does the 2.0.4 machine, it's only proxying one to the other which isn't apparently working?)
It's late and so I haven't managed to probe the 1.2 machine too much, but initially looking at the log files I don't see any evidence of the 2.0.4 machine actually contacting it?
Does this make sense?
Thanks
Ed W
On 29.9.2010, at 23.03, Ed W wrote:
Specifically I cloned my 1.2 virtual machine, upgraded the clone to 2.0.4 and tested it by trying to login using CRAM-MD5. I get the errors:
Sep 29 22:50:30 mail_test dovecot: imap-login: Error: proxy: password not given: user=<demo@abc.com>, method=CRAM-MD5, rip=x.x.x.x, lip=x.x.x.x, mpid=0, TLS
CRAM-MD5 doesn't work directly with proxying. It can't work, by CRAM-MD5 design. The only way to make it work is if your passdb lookup returns a password, either the user's actual password in plaintext or some master password, that the backends accepts with plaintext authentication.
I then change the configuration so that the 2.0.4 machine proxies the connection back to the 1.2 machine (again) and try to login to the 2.0.4 machine and get the same errors as above. Seems like the error is only when proxying (needless to say, the old 1.2 machine works fine with CRAM and that's how it's normally accessed, so also does the 2.0.4 machine, it's only proxying one to the other which isn't apparently working?)
If it worked with v1.2, it either wasn't proxying or it was doing something like I mentioned above.
On 30/09/2010 00:19, Timo Sirainen wrote:
On 29.9.2010, at 23.03, Ed W wrote:
Specifically I cloned my 1.2 virtual machine, upgraded the clone to 2.0.4 and tested it by trying to login using CRAM-MD5. I get the errors:
Sep 29 22:50:30 mail_test dovecot: imap-login: Error: proxy: password not given: user=<demo@abc.com>, method=CRAM-MD5, rip=x.x.x.x, lip=x.x.x.x, mpid=0, TLS CRAM-MD5 doesn't work directly with proxying. It can't work, by CRAM-MD5 design. The only way to make it work is if your passdb lookup returns a password, either the user's actual password in plaintext or some master password, that the backends accepts with plaintext authentication.
I'm not quite sure I understand the nuances of that?
Yes I do have a passdb (on the remote machine) which returns a plain password. Actually since it's DB driven I have already returned all the information needed to auth the user on the proxying machine
The password query is the same on both sides and it looks like:
password_query = SELECT NULLIF(mail_host, '%l') as proxy,
NULLIF(mail_host, '%l') as host,
email as user, password,
home userdb_home, concat(home, '/', maildir) as userdb_mail,
2000 as userdb_uid, 2000 as userdb_gid
FROM users
WHERE email = if('%d'<>'','%u','%u@mailasail.com') and flag_active=1
The NULLIF stuff is a holdover from before the proxy code was enhanced in 1.2. Basically the effect I'm trying to achieve is a couple of hybrid frontend/backend imap servers, where they will proxy between each other to get the user to the correct server.
I then change the configuration so that the 2.0.4 machine proxies the connection back to the 1.2 machine (again) and try to login to the 2.0.4 machine and get the same errors as above. Seems like the error is only when proxying (needless to say, the old 1.2 machine works fine with CRAM and that's how it's normally accessed, so also does the 2.0.4 machine, it's only proxying one to the other which isn't apparently working?) If it worked with v1.2, it either wasn't proxying or it was doing something like I mentioned above.
I cannot be sure if I tried proxying with MD5 in 1.2 - with the 1.2 installation the proxying is used very rarely.
That said because of the prefetch configuration I'm using in this case, it doesnt seem impossible to make proxy work correctly with CRAM?
I don't have a protocol trace, but I'm getting the idea it's because each server picks a different secret that we get a problem? The proxy server would need to auth the user, whilst at the same time doing a different auth to the proxied server? It seems a shame to remove CRAM as an option if I want proxying to work - do you see a way around this? (Feature request..?)
Thanks
Ed W
On Thu, 2010-09-30 at 08:08 +0100, Ed W wrote:
CRAM-MD5 doesn't work directly with proxying. It can't work, by CRAM-MD5 design. The only way to make it work is if your passdb lookup returns a password, either the user's actual password in plaintext or some master password, that the backends accepts with plaintext authentication.
I'm not quite sure I understand the nuances of that?
Yes I do have a passdb (on the remote machine) which returns a plain password. Actually since it's DB driven I have already returned all the information needed to auth the user on the proxying machine
The password query is the same on both sides and it looks like:
password_query = SELECT NULLIF(mail_host, '%l') as proxy, NULLIF(mail_host, '%l') as host,
email as user, password, \
Add: ..., password, password as pass, ..
On 30/09/2010 18:48, Timo Sirainen wrote:
On Thu, 2010-09-30 at 08:08 +0100, Ed W wrote:
CRAM-MD5 doesn't work directly with proxying. It can't work, by CRAM-MD5 design. The only way to make it work is if your passdb lookup returns a password, either the user's actual password in plaintext or some master password, that the backends accepts with plaintext authentication. I'm not quite sure I understand the nuances of that?
Yes I do have a passdb (on the remote machine) which returns a plain password. Actually since it's DB driven I have already returned all the information needed to auth the user on the proxying machine
The password query is the same on both sides and it looks like:
password_query = SELECT NULLIF(mail_host, '%l') as proxy, NULLIF(mail_host, '%l') as host,
email as user, password,
Add: ..., password, password as pass, ..
Aha - this is the master login stuff. That does kind of make sense.
Quite subtle mind
Thanks for replying
Ed W
participants (2)
-
Ed W
-
Timo Sirainen